Mercurial > getan
view doc/old_issues.txt @ 466:9dab95965ac6
Authors adds in --version.
author | Magnus Schieder <mschieder@intevation.de> |
---|---|
date | Wed, 02 May 2018 13:46:50 +0200 |
parents | 45b7b83efaed |
children | 050ffdec60d9 |
line wrap: on
line source
20180117 Magnus Schieder 20170317 BER: Reproduce and then fix a defect that it is surprising which entries are moved by `m` or deleted by 'd'. It probably has to do how multi-selection are handled. Maybe they are not cleared properly at the end of an operation. One description: It happens when you have changed a lot of entries from different projects (I assume), e.g. by editing the description, the length or timedate and then use move where you intend to only move one, the unwanted result is several moved entries. reproduced with getan 2.1 20180118BER Reproduced with urwid v1.3.0, python3.4.6, getan 2.2.dev1 r445 Creating a new database with test data: 1) Delete getan_test_data.db if it already exists to create a new database. 2) Execute getan_test_data.py to get the test database getan_test_data.db. (getan/test_data/getan_test_data.py) - Bug 1.0 2) Open getan with the test database. (getan /path/getan_test_data.db) 3) Switch to the entries from the project pro1 with tab. 4) Mark with return and arrow keys ent1 and ent2. 5) Go back to the projects with tab. 20180118BER: Observation: ent1 and ent2 are not highlighted anymore. 6) Switch back to the entries of project pro1. 7) Mark this time ent3 and ent4. 8) Press m, then 3 and then y to move ent3 and ent4 to pro3. Expectation: ent3 and ent4 are moved to pro3. Result: ent1, ent2, ent3 and ent4 were moved to pro3. - Bug 1.1 Execute 1) to 7) from 1.0. 8) Press d to delete ent3 and ent4. Expectation: ent3 and ent4 are deleted. Result: ent1, en2, ent3 and ent4 are deleted.