MantisBT - Issues

0011931: iOS wallet: no accessibility identifiers, so UI automation cannot address controls stably (patch attached)

Wed, 04 Nov 2026 13:18:58 +0000

The iOS wallet has no accessibility identifiers, so UI automation can only
address controls by element type, accessibility label and on-screen frame.
That makes automated tests fragile in three ways: a reworded label breaks the
test, a localized build cannot be driven at all, and two controls with the same
label on one screen cannot be told apart.

While building a coverage-guided UI exploration harness for the wallet I hit
all three. The attached patch adds stable identifiers to single-purpose leaf
controls and collects them in a new
TalerCommon/Helper/AccessibilityIdentifiers.swift, so they stay greppable and
unique.

Why leaves only
---------------

SwiftUI propagates .accessibilityIdentifier to every accessibility element
inside the view it is applied to, and OVERWRITES identifiers those elements
already carry. Measured on the onboarding screen by dumping the accessibility
tree before and after:

* identifier on a leaf -> lands on exactly that element;
* identifier on a container -> propagates to every descendant; in the probe,
an existing "gear" identifier on the Settings button was replaced by the
container's.

So annotating containers would produce duplicate identifiers (useless for
addressing) and silently clobber more specific ones. The patch therefore only
touches leaves, and the header comment in the new file records the rule.

What it does not change
-----------------------

Identifiers are never shown or spoken. Measured before/after on the same
screen: the element count is unchanged (75 -> 75), and no accessibility label,
hint or ordering changes. The existing deliberate tree shaping in this
codebase (.accessibilityElement(children: .combine), .accessibilityHint,
.accessibilityHidden) keeps working. Identifiers are placed next to the
existing accessibility modifiers, since SwiftUI is order-sensitive about them.

Scope of the patch
------------------

* new TalerCommon/Helper/AccessibilityIdentifiers.swift with the A11yID
constants and the leaves-only rule;
* 14 single-purpose leaf buttons in TalerCommon/HelperViews/Buttons.swift
(hamburger, QR, done, plus, more, settings, back, forward, scroll up/down,
zoom in/out, reload, paste);
* CopyButton and ShareButton gain an optional a11yID parameter. It is
defaulted, so no existing call site has to change, but the wire-transfer
screen now passes a distinct one per field - otherwise every copy button on
that screen would share one identifier;
* the leaves of the withdrawal path: onboarding "Get demo cash" and
"Withdraw ", Terms of Service open and accept, Confirm
Withdrawal, and the loading/stalled Cancel and Retry buttons.

Verified
--------

Built for the simulator (GNU_Taler, Xcode 27.2, iOS 27.2) and driven through
onboarding -> Withdraw -> Terms of Service -> Accept -> Confirm Withdrawal with
the accessibility tree dumped at every step. The identifiers appear on the
intended controls:

Accept Terms of Service -> button.withdraw.tos.accept
Confirm Withdrawal -> button.withdraw.confirm
Terms of Service -> button.withdraw.tos.open
Withdraw CHF -> button.onboarding.withdrawReal
Scan QR code -> button.qr
Paste -> button.paste

and the identifiers the system or the app already provided (gear, BackButton,
dictation) are preserved.

The patch is against master (cb7e4bab) and applies cleanly. It is additive;
nothing is renamed or removed.

Filed by an agent (bot-cg) on behalf of Christian Grothoff.

0011936: OIM history: ArrowHistoryView (512 lines) cannot be compiled into any target, and the DE/DEU chest assets are split so OIMdollars has no closed chest

Wed, 04 Nov 2026 13:16:36 +0000

Coverage analysis of an exploration campaign showed OIM/ArrowHistoryView.swift
at exactly 0% and never moving. It is not a gap in the testing: the file
cannot be compiled into any shipped target.

1. ArrowHistoryView (512 lines) is unreachable
----------------------------------------------

Its only call site is OIMtransactions.swift:200, inside `#if TALER_WALLET`:

if oimChart {
ChartHistoryView(...)
} else {
#if TALER_WALLET
ArrowHistoryView(...)
#else
RiverHistoryView(...)
#endif
}

OIMtransactions is itself only ever instantiated at
TransactionsListView.swift:139, inside `#if OIM`:

#if OIM
.overlay { if #available(iOS 16.4, *) {
if controller.oimModeActive { OIMtransactions(...) }
} }
#endif

So reaching ArrowHistoryView needs TALER_WALLET and OIM at once. From
project.pbxproj, the three app targets are:

GNU_Taler GNU_TALER OIM
Taler_Nightly TALER_NIGHTLY OIM USELAYOUT
Taler_Wallet TALER_WALLET EMPTY

No target carries both, so the `#else` branch always wins and it is always
RiverHistoryView. 512 lines of view code are dead in every build.

2. The DE / DEU chest assets are split, which makes OIMdollars unusable
-----------------------------------------------------------------------

OIMcurrency.swift:74 declares the USD currency with `chest: "DEU"`, and the
chest images are built as "ChestClosed" + chest and "ChestOpen" + chest. The
asset catalog contains:

ChestClosedCdI ChestClosedCHF ChestClosedDE ChestClosedEU ChestClosedEUR ChestClosedSLE
ChestOpenCdI ChestOpenCHF ChestOpenDEU ChestOpenEU ChestOpenEUR ChestOpenSLE

The German pair is the only one spelled inconsistently: closed is DE, open is
DEU. There is no spelling that resolves both, so `chest: "DEU"` gives a
missing image for the closed chest and `chest: "DE"` would give a missing image
for the open one.

This is latent today: OIMdollars is not in `OIMcurrencies`
(OIMcurrency.swift:13) and `oimCurrency()` never returns it
(OIMcurrency.swift:15-24, which maps KUDOS, TESTKUDOS and CHF and otherwise
falls back to OIMeuros). It would surface the moment USD is wired up.

Checked and NOT a problem
-------------------------

OIMpayView looked like a third instance of the same thing, but it is fine: its
call site at PaymentScan.swift:134 is inside `#if OIM`, not a condition that no
target defines, so it is reachable in GNU_Taler and Taler_Nightly whenever
`controller.oimSheetActive` is set. Mentioning it so nobody re-investigates.

How to reproduce
----------------
Both are static facts about the build, so they reproduce by reading:

grep -n "SWIFT_ACTIVE_COMPILATION_CONDITIONS" TalerWalletXC.xcodeproj/project.pbxproj
grep -rn "ArrowHistoryView" --include=*.swift .
sed -n '195,210p' TalerWallet1/Views/OIM/OIMtransactions.swift
sed -n '132,145p' TalerWallet1/Views/Transactions/TransactionsListView.swift
grep -n "chest:" TalerWallet1/Views/OIM/OIMcurrency.swift
find . -name 'ChestOpen*' -o -name 'ChestClosed*'

How the exploration harness surfaced it
---------------------------------------

The harness is on branch dev/phoenix-bot/fuzzbang (local name
dev/bot-cg/fuzzbang), under harness/. After a campaign, per-file coverage is:

python3 -m taler_fuzz coverage --run --top 30 --untouched

ArrowHistoryView.swift appears under "never entered" with 512 lines, and stays
there however long the campaign runs, including with the OIM strategy that does
reach the other OIM views:

python3 -m taler_fuzz --orientation landscapeRight \
--prefer "demo cash,withdraw,confirm,accept,terms,balance,chest" \
explore -n 4 --run-id oim

That run takes OIMbalances.swift from 0% to about 72% and BalancesListView.swift
to about 80%, while ArrowHistoryView.swift stays at 0.

No patch attached, deliberately
-------------------------------

Both fixes are product decisions rather than mechanical changes, and guessing
would waste your time:

* ArrowHistoryView: delete it, or give some target both conditions, or make
the arrow/river choice a setting like oimChart already is. Which one
depends on whether the arrow presentation is still wanted.
* the chest assets: rename ChestOpenDEU to ChestOpenDE, or ChestClosedDE to
ChestClosedDEU, or change OIMdollars to a third spelling and add both
images. Renaming an asset touches the catalog and I could not verify the
rendering, so I have left it alone.

Found by automated UI exploration; the coverage gap is what pointed at it.

Estimated severity
------------------
Low - cosmetic.

Estimated effort to fix
-----------------------
Small for the chest assets - one rename plus a check that nothing else refers to the old name. For ArrowHistoryView the work is the decision, not the edit: deleting it is minutes, making it reachable means deciding how the arrow and river presentations should be selected and testing both.

Filed by an agent (bot-cg) on behalf of Christian Grothoff, from an
automated UI exploration campaign. Left unassigned deliberately.

0011815: UI shows non-existing template option (select products)

Tue, 03 Nov 2026 22:54:50 +0000

I was surprised and happy to see it in the UI, but it seems to be unimplemented in the backend. UI should not show it then in the first place.

0011929: Backup restore test

Tue, 03 Nov 2026 17:14:53 +0000

Test recovery of key data from backups (production, product- and software-development systems)

0011930: Backup restore test

Tue, 03 Nov 2026 17:14:53 +0000

Test recovery of key data from backups (production, product- and software-development systems)

0011921: support DD101 token semantics in merchant backend

Tue, 03 Nov 2026 15:01:22 +0000

Instead of just supporting it in the Web PoS, the merchant backend should directly evaluate the rules of semantic tokens.

0011922: implement iOS test automation for Taler wallet

Tue, 03 Nov 2026 14:59:07 +0000

We need to develop tests, automate app builds, do CI.

0011923: make self-service merchant report emails easy to use

Tue, 03 Nov 2026 14:57:59 +0000

Right now to configure them, you need to understand how the API works.

The merchant portal webui should show a simplified interface to configure the reports.

We should also allow sending test reports.

0011925: SPA design to make self-service merchant report emails easy to use

Tue, 03 Nov 2026 14:57:43 +0000

Just create the design. We need to basically at a high level first pick the type of report,
then have fields for the query parameters and select the desired mime-type.

0011920: merchant backend KYC status breaks when one exchange changes its master public key

Tue, 03 Nov 2026 14:51:40 +0000

While this is not a normal or acceptable situation (on the side of the exchange), even a completely broken exchange should not leave the merchant entirely unable to complete KYC or show the KYC status for other exchanges.

0011924: merchant backend KYC status breaks when one exchange changes its master public key needs a test

Tue, 03 Nov 2026 14:50:55 +0000

Just build a taler-harness test to reproduce the issue.

0011223: enable HTTP 2+3 on exchange deployments

Tue, 03 Nov 2026 14:44:36 +0000

Some clients try HTTP3 by default, which would explain higher latency for first download.
We should enable HTTP3 on all of our servers at this point.

0011158: Clarify incoming wire transfer subject constraint

Tue, 03 Nov 2026 14:42:07 +0000

The current unspecified rule is that only a public reserve key can be used only once, whereas a KYC key can be reused and the same key can therefore be used once for the reserve and several times for KYC.
We need to specify this formally somewhere (in the wire gateway API?) and ensure that the exchange and wire gateway implementations behave consistently.

0009010: Payments status API

Tue, 03 Nov 2026 14:40:14 +0000

Add a payments status API for an admin dashboard

0010236: Asset token with voting MVP [meta]

Tue, 03 Nov 2026 14:38:10 +0000

Meta bug for asset tokenization feature with share based voting.

0010082: design document for (CRDT) incremental sync protocol

Tue, 03 Nov 2026 14:37:05 +0000

The new sync protocol with CRDT functionality should be discussed and specified in detail, including:

- What should be backed up (and what not)?
- When should backups run (and when not)?
- When to backup/restore incrementally (and when not)?
- Encoding of changes/deletions and other events.
- Garbage collection and DB maintenance.
- Client-side conflict resolution.
- Complementary data structures (i.e. blob hash table).
- etc, etc, etc.

0011779: merchant does not allow easily querying for order changes of $N orders

Tue, 03 Nov 2026 14:36:25 +0000

Let's say the merchant portal webui is displaying the latest 20 transactions. Via long-polling, we can easily find out about *new* transactions.

However, we can't find out about *changed* transactions.

Possible fixes are:
* Allow long-polling with an ETag (over the returned transactions list), so that changes result in long-poll returns
* This still requires two in-flight queries, one for new transactions and one for changes on the existing list that is displayed
* Introduce a more general notification / change notification mechanism
* General but potentially complex and/or expensive
* Just do traditional polling and re-request the 20 transactions every, say, 10 seconds.

0010347: Tutorial-dev "Repurchase detection"

Tue, 03 Nov 2026 14:34:06 +0000

tutorial for developers

0010343: Tutorial-dev "How to handle payment link"

Tue, 03 Nov 2026 14:33:53 +0000

tutorial for developers "how to handle taler:// payment link on android and ios"

0010342: Tutorial-dev "How to pay from android intents"

Tue, 03 Nov 2026 14:33:37 +0000

tutorial for developers

0010348: Tutorial-dev "Contracts with multiple currencies = multiple exchanges"

Tue, 03 Nov 2026 14:33:24 +0000

tutorial for developers

0011002: complete interation 2 of dd74

Tue, 03 Nov 2026 14:29:39 +0000

once is completed i can fully implemented in backoffice

https://docs.taler.net/design-documents/074-merchant-backend-simplification.html#settings-structure

> Status: incomplete draft

> The proposed simplifications here are still under discussion and will only be implemented once iteration 2 is done.

0010345: Tutorial "Wallet installation on Android"

Tue, 03 Nov 2026 14:28:27 +0000

Play market + fdroid

0010349: Tutorial-dev "Sell with discount tokens, subscriptions"[25h]

Tue, 03 Nov 2026 14:28:05 +0000

Contract v1
text+video

0011422: add de_CH lang ("Deutsch (Schweiz)")

Tue, 03 Nov 2026 14:27:44 +0000

Same as ticket 0011421, but here for Android.