| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000121 | SKGB-intern | sepa | public | 2014-07-20 16:13 | 2014-08-31 14:29 | ||||||||
| Reporter | aj | ||||||||||||
| Assigned To | |||||||||||||
| Priority | none | Severity | major | Reproducibility | always | ||||||||
| Status | confirmed | Resolution | won't fix | ||||||||||
| Projection | major rework | ETA | none | ||||||||||
| Platform | The Web | OS | HTTP | OS Version | 1.1 | ||||||||
| Product Version | 1.3 | Product Build | 2014-07-20 | ||||||||||
| Target Version | Fixed in Version | 1.3 | |||||||||||
| Summary | 0000121: Edge cases in GS-Verein data cause severe sync issues for accounts and sepadb | ||||||||||||
| Description | When a user account or a member entity is (supposed to be) created or deleted while an entry in sepadb already exists for that particular user, the update is either not applied or applied incorrectly. | ||||||||||||
| Steps To Reproduce | - add email address to a snail mail recipient in GS-Verein, then do an update => user account is not created, email is removed from but name not added to sepadb (0x1004), creating a sepadb inconsistency => WITH reset: two updates with same EXPORT.txt required (0x0_05 + 0x0_04), but old SeqType isn't removed from separun, which creates the need for manual intervention in sepa-db-edit - remove email address from member in GS-Verein, then do an update => user account is deleted (0x1006) and the member is added to sepadb (may require second update), but one row stays perpetually in DELETE action (0x0002) => user account is deleted and the member is added to sepadb (two updates required, 0x1_06 + 0x1_0C), but old SeqType isn't removed from separun - remove member in GS-Verein, then do an update => user account is deleted (0x0002), but the member stays perpetually in DELETE action (0x0002) because the member isn't removed from sepadb => WITH reset: (works as intended), but old SeqType isn't removed from separun - add new member in GS-Verein, then do an update => (works as intended, although two updates are required) | ||||||||||||
| Additional Information | workaround: (1) reset / DROP sepadb (while retaining separun) (2) apply update twice (3) use sepa-db-edit to check SeqType, fix where necessary problems with that: - SeqType may have to be changed for certain members; workaround: make sure these cases are handled separately, i. e. don't do a reset by default - in particular, SeqType is set to 'frst' if the mandate isn't known in sepadb => new flag to not modify separun at all - update may fail to match new user account to old separun entry; workaround: manual correction using sepa-db-edit | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
||||||
|
||||||
 Relationships |
| Notes |
|
|
aj (manager) 2014-07-20 17:47 Last edited: 2014-07-20 17:57 |
BTW, the SEPA columns in update check seem to be messed up when a member is removed in GS-Verein: debit and ibancheck and gbetrag are still in col GS-Verein, while only mandate is in col intern also BTW: action 0x___5 is obviously wrong for adding accounts |
|
aj (manager) 2014-08-31 14:29 |
Is perhaps 0000130 merely a symptom of this problem? |
| Notes |