Bug #2007
closedWrong direction for P134
Description
I came upon a possible bug in the mapping of preceding/succeding events:
e.g. these events:
https://thanados.openatlas.eu/entity/196289 - The Novara sails from Saint Paul Island to Amsterdam Island
https://thanados.openatlas.eu/entity/196290 - The Novara sails from Amsterdam Island to Sri Lanka (Galle)
https://thanados.openatlas.eu/entity/196291 - The Novara sails from Sri Lanka (Galle) to Chennai (Madras)
They are listed in the UI correctly with preceding and succeding events.
So the correct mapping should be:
domain_id:196290 - property_code:P134 - range_id:196289 (the later event contiunues the earlier one)
and:
domain_id:196291 - property_code:P134 - range_id:196290 (the later event contiunues the earlier one)
However the links are the following:
property_code | domain_id | range_id |
P134 | 196289 | 196290 |
P134 | 196290 | 196291 |
If my assumption is right, the directions got mixed up. Actually the links in model.link table represent the inverse property. So an earlier event "is continued by" the later one. The UI labels the wrong direction to the correct meaning but it is stored wrong in the db.
Updated by Alexander Watzinger over 1 year ago
- Subject changed from wrong direction for P134 to Wrong direction for P134
- Status changed from New to Assigned
- Assignee set to Alexander Watzinger
- Target version set to 7.15.0
Thank you for reporting. I will look into this.
Updated by Alexander Watzinger over 1 year ago
- Category set to CRM
- Status changed from Assigned to Resolved
- Assignee changed from Alexander Watzinger to Bernhard Koschiček-Krombholz
You were right, a good catch again ;)
I fixed the code and added an SQL to fix existing entries in the branch feature_fix_2007. With merging to develop we will wait till shortly before the next release to not complicate the SQL updates.
@ Bernhard: can you check if the API needs adaptions for fixing P134 by reversing it? In case no adaptions are needed (or made in this feature branch) you can assign it back to me. But please keep this issue as resolved and code changes in the branch feature_fix_2007.
Updated by Bernhard Koschiček-Krombholz over 1 year ago
- Assignee changed from Bernhard Koschiček-Krombholz to Alexander Watzinger
From the view of a 2nd Event:
LOUD
"continued": [ { "id": "http://127.0.0.1:5000/api/entity/186218", "type": "Activity", "_label": "1. Event" } ], "continued_by": [ { "id": "http://127.0.0.1:5000/api/entity/186220", "type": "Activity", "_label": "3. Event" } ]
LPF
"relations":[ { "label":"1. Event", "relationTo":"http://127.0.0.1:5000/api/0.3/entity/186218", "relationType":"crm:P134 continued", "relationSystemClass":"activity", }, { "label":"3. Event", "relationTo":"http://127.0.0.1:5000/api/0.3/entity/186220", "relationType":"crm:P134i was continued by", "relationSystemClass":"activity", } ]
This looks correct to me. So no adaptations needed.
Updated by Alexander Watzinger over 1 year ago
- Status changed from Resolved to Closed
Fixed in develop and the database update script will take care of existing entries.
Updated by Alexander Watzinger over 1 year ago
- Target version changed from 7.15.0 to 7.13.0