[pull] master from gradido:master - #72
Merged
Merged
Conversation
…th readers Bernd used the card at a counter and every line that mattered was the smallest thing on the screen. The amount step carried the heading "Gradido empfangen" twice: the wallet's title bar already writes it from the route's pageTitle, and the page repeated it word for word. The page's own copy is gone. What is left grows: the hint that a card was scanned is mid-sized, and the card's label — the one thing the merchant checks before typing an amount — is now the biggest thing there. The "Karte:" prefix in front of it is dropped; the screen is about a card, so the word only pushed the answer to the right. On the PIN step the amount was small grey text. It is the number somebody is about to agree to pay on a device that is not theirs, so it is now the largest line, with the card label readable underneath it. The closing screen is read by TWO people, and that is what it was getting wrong. The payer is still holding the phone when it appears and hands it back a moment later, so "Du hast X von Y empfangen" was true for whoever read it second and wrong for the person who had just paid. It now names both sides — the amount large, then "gesendet von <payer> an <merchant>". The merchant's name comes from the store, where the wallet has had it since the login. "1000 Dank!" became "Vielen Dank!": next to a payment, a number reads as an amount. Four locale keys replaced by two in all ten files; German translated, the other nine English as the rest of this block still is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix(frontend): make the till screens readable, and the receipt fit both readers
From Bernd walking the settings page. Wording. The Gradido card said whoever receives it can "Dir Gradido schenken"; it is a transfer, not a present, so it now says "senden". The thank you card panel was headed "Mit Karte danken" and now names what it is: "Deine Dank-Karte - Gradido senden mit Karte". "Kartenzahlung ausschalten" became "Karten-Funktion ausschalten" - what is switched off is the whole function, not one payment. German translated, the other nine English as this block still is. The PIN dialog showed TWO sets of buttons: its own Save, and an untranslated OK/Cancel pair underneath. The cause was not styling. The dialog carried `hide-footer`, and bootstrap-vue-next calls that prop `no-footer` - the old name is taken as a plain attribute and does nothing at all, with no warning. So the default footer had been there the whole time. The footer is the answer rather than something to hide: a dialog's actions belong in it, and it brings the Cancel this dialog never had - until now the only way out was the little x. The OK button carries the save wording and the gold variant the inline one had; Cancel is translated; closing the dialog any way at all now forgets a half-typed PIN. `@ok.prevent`, because the dialog must not close itself: `savePin` closes it only after the server has taken the PIN. A refused PIN has to leave the dialog standing, or the message lands on a screen that no longer shows the field it is about, with the digits already gone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
coderabbit's finding on #3762, half built and half declined, both measured. Built: `busy` instead of `ok-disabled`. The library derives both buttons from it (`disableCancel = cancelDisabled || busy`, `disableOk = okDisabled || busy`, read in the shipped bundle). With only OK guarded, Cancel stayed live during the save and pressing it shut the dialog on a request still in flight. Declined: sealing the x, Escape and the backdrop while busy. Dismissing mid-save costs nothing -- the mutation is already sent, `run` still refetches and reports, and `@hide` clears the field; the worst case is a success message arriving after the box is gone. Sealing all three would buy that back at the price of a hung request leaving somebody locked in a dialog with two dead buttons and no way out, because `run` has no timeout. That trade is worse than the thing it fixes, and the reason now stands in the template. The stub had to learn the same rule: it computed the disabled state from `okDisabled` alone, and the page passes only `busy` -- so it reported both buttons live and would have tested nothing. It now derives them the way the library does. Injection: back to `ok-disabled` and the new test falls. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ding fix(frontend): give the pin dialog one set of buttons, and say "send"
…current
The two Bernd parked, plus one found while building them.
**The cursor waits in the PIN field.** At a counter the phone changes hands and
the payer should be able to type at once, rather than being told to tap the box
first. `focus` is the method BFormInput exposes for this, so there is no
reaching through `$el`.
**The balance in the header asks again** when the member opens the overview or
their transactions. It was fetched ONCE, when the dashboard layout mounts, and
that layout outlives every route change - so the only thing that ever refreshed
it was a page saying so: `Send` after a transfer, `Transactions` on paging. A
payment made anywhere else left the old number standing on every screen the
member visited next, and a thank you card payment is exactly that: its own
page, at somebody else's till, saying nothing to the layout.
Worth writing down because the first guess was wrong: this is not a cache
policy and not a page reload. The query already asks the server
(`network-only`); it simply never ran a second time. A reload would have hidden
that by throwing the whole application away, which is why it looked like an
answer. Refetched with no arguments, so somebody on page three of their
transactions is not sent back to page one.
**And the way out of the dead end was pointing at nothing.** The screen a
blocked or unknown card lands on offered one button, `:to="{ name: 'Overview'
}"` - but the route at `/overview` carries no name at all. `name: 'Overview'`
in `Overview.vue` is the component's name and has nothing to do with routing,
so vue-router threw on it. Every other link to the overview in this wallet uses
the path, and now this one does too. Held against the real route table in the
test, so it fails if either end moves.
The layout spec never unmounted its wrappers. Harmless while nothing in there
reacted to anything global, and wrong the moment something did: one navigation
reached four live layouts and the refetch spy counted four calls.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Half of coderabbit's finding on #3763, and the half it names is real - partly made worse by this PR. `pending` is handed down to the page inside the router-view, and `onError` never cleared it: a refetch that fails left that page waiting for something that was never coming. It mattered less while only a deliberate action set it (paging, or sending). Since the watch added here sets it on every navigation to the overview or the transactions, one failed request would strand whatever the member opened next. Cleared now, with a test; the injection that removes the one line fails exactly it. Declined: adding `<!-- AI-GENERATED - not an architecture reference -->` to DashboardLayout.vue. AGENTS.md line 166 is explicit that the marker is for new files written by an AI, "not to edits an AI makes to existing human-written files" - and this file is Dario's, from June. Marking it would brand a human-written file as generated, and by the same document a marked file must not be used as an architecture reference, so the marker would mislead every later reader about one of the load-bearing files in the wallet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…alance fix(frontend): put the cursor in the pin field, and keep the balance current
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )