View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004345 | Taler | obsolete component | public | 2016-03-23 17:25 | 2016-04-07 20:39 |
| Reporter | Christian Grothoff | Assigned To | Marcello Stanisci | 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 | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0004345: account numbers should not be random | ||||
| Description | Account numbers should be assigned sequentially. If not accounts exist, the bank should _always_ on startup create 0: bank 1: exchange taler-bank-manage --preaccounts should then create accounts for Tor/GNUnet/Taler as 2/3/4, and -- sampledata should fill those with some transactions (but again consistently: withdraw from bank to exchange, and from exchange -> Tor/GNUnet/Taler. The invariance that all account balances add up to zero should be maintained. | ||||
| Tags | No tags attached. | ||||
| Adding the basic accounts creation at startup, but the bank gets account number 1, as changing the starting value of an AutoField requires injecting Postgres specific SQL into the Django's routine which fills the tables (technically called 'migration'), which is not cross-DB practice. See link below http://stackoverflow.com/questions/11298392/initial-value-for-django-model-autofield | |
| Sure, we can start with account 1. Can you set it up so that the exchange's account is also always created as #2? I guess we should also be more specific about which taler-bank-manage option does what. For the bank-lib testcase, the following would be ideal: --definetables: create tables AND setup bank + exchange accounts --preaccounts: create FSF/GNUnet/Tor/etc. accounts based on configuration --sampledata: put in some transaction history We also still need a way to set/reset an account's password. | |
| That's already there. You can also run 'python manage.py dump_talerdb' in order to see how accounts and history look like. | |
| fixed by 07b6805. To change password via cli, run $ python manage.py bank_admin users --reset-password USER NEWPASSWORD This script is meant to be a "swiss army knife" for bank operations, so it'll likely replace the shell script that is currently deployed. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-03-23 17:25 | Christian Grothoff | New Issue | |
| 2016-03-23 17:25 | Christian Grothoff | Status | new => assigned |
| 2016-03-23 17:25 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2016-04-05 15:15 | Marcello Stanisci | Note Added: 0010379 | |
| 2016-04-05 15:15 | Marcello Stanisci | Note Edited: 0010379 | |
| 2016-04-05 15:37 | Christian Grothoff | Note Added: 0010380 | |
| 2016-04-05 16:41 | Marcello Stanisci | Note Added: 0010381 | |
| 2016-04-07 16:20 | Marcello Stanisci | Note Added: 0010402 | |
| 2016-04-07 16:20 | Marcello Stanisci | Status | assigned => informing |
| 2016-04-07 16:20 | Marcello Stanisci | Resolution | open => fixed |
| 2016-04-07 20:39 | Christian Grothoff | Status | informing => closed |
| 2016-04-07 20:39 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2016-04-07 20:39 | Christian Grothoff | Target Version | 0.1 => 0.0 |
| 2022-08-23 18:26 | Christian Grothoff | Category | bank (demonstrator) => py bank (demonstrator, obsolete) |
| 2023-12-03 00:23 | Christian Grothoff | Category | py bank (demonstrator, obsolete) => obsolete componet |
| 2023-12-11 19:08 | Florian Dold | Category | obsolete componet => obsolete component |