View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010149 | Taler | wallet-core | public | 2025-07-04 09:54 | 2025-07-29 22:22 |
| Reporter | avalos | Assigned To | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | implementing | Resolution | open | ||
| Product Version | 1.0 | ||||
| Target Version | post-1.0 | ||||
| Summary | 0010149: implement a new notification type for payment sounds | ||||
| Description | Right now, iOS implements a quite monsterly logic to decide when to play sounds and which sounds to play based on transaction-state-transition notifications and the types of transactions. For the sake of consistency across platforms, I believe it is not the right approach to decide this on the UI. In my opinion, this logic should be moved to wallet-core: https://git.gnunet.org/taler-ios.git/tree/TalerWallet1/Backend/WalletCore.swift?id=14c7991224949565cd2b63db38efb5e14c3baaf6#n200 Thus, I propose a new notification type, `transaction-feedback-event`, that contains an enum that allows the UI to decide which sounds or feedback to play, for instance: PAYMENT_SENT, PAYMENT_RECEIVED, ERROR, idk. | ||||
| Tags | No tags attached. | ||||
| As mentioned in #9258, I think this shouldn't be a new notification type, especially as a notification clearly must already exist for these and we shouldn't do multiple notifications for the same thing. Florian, WDYT? | |
| When does the sound need to play? We should spec that out first. Then, we should not use a new notification type for that. Instead, I would suggested (sticking to state machine terminology) to add a *label* to transitions. Based on the label (paid, error-retry, user, ...), the UI could then decide whether to play a payment sound or not. | |
| We have two sounds, I'd play one whenever our balance ultimtely increases (withdraw completed, p2p receive completed) and the other whenever it decreases (successful payment, deposit, p2p-send accepted). | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-07-04 09:54 | avalos | New Issue | |
| 2025-07-04 09:54 | avalos | Description Updated | |
| 2025-07-04 10:02 | Christian Grothoff | Note Added: 0025415 | |
| 2025-07-04 10:02 | Christian Grothoff | Assigned To | => Florian Dold |
| 2025-07-04 10:02 | Christian Grothoff | Status | new => assigned |
| 2025-07-04 10:03 | Christian Grothoff | Status | assigned => feedback |
| 2025-07-09 11:54 | Christian Grothoff | Target Version | => 1.1 |
| 2025-07-09 13:53 | Florian Dold | Note Added: 0025462 | |
| 2025-07-09 13:53 | Florian Dold | Assigned To | Florian Dold => avalos |
| 2025-07-29 22:21 | Christian Grothoff | Assigned To | avalos => |
| 2025-07-29 22:21 | Christian Grothoff | Status | feedback => implementing |
| 2025-07-29 22:21 | Christian Grothoff | Product Version | => 1.0 |
| 2025-07-29 22:21 | Christian Grothoff | Target Version | 1.1 => post-1.0 |
| 2025-07-29 22:22 | Christian Grothoff | Note Added: 0025579 |