-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perspective field ordering bug #1109
Comments
Here is an anti-rating of perspectives with duplicate columns positions:
|
* Correct sub_positions and next positions * Refactoring * Correct next field position
On dictionary import (e.g. from .eaf) some fields are created with own sub-fields. In such cases sub-field's position iterator starts from '1' inspite of current position. So, sub-fields get already occupied positions and moreover next root-fields are counted up ignoring sub-fields. |
* reorder columns * auto reordering * fix * comments
Created graphql api for columns correct reordering. It can be run only with Administrator token.
|
Seems like all causes of duplicate columns positions within one perspective are solved. The main one is counting parent columns disregarding nested columns. So when a nested column becames parent one or conversely, correct ordering may be broken. Now the corrective mutation and all related places in code generate through numeration of columns. So any column (parent or nested) within one perspective has unique position. The issue can be tested and closed. |
Users report inability to change perspective field ordering.
Open https://lingvodoc.ispras.ru/dictionary/5576/1/perspective/5576/2/edit, click perspective dropdown menu, click Properties, click up arrow of the Cognates field, no effect.
Expected: Cognates field goes up in the list.
Looks like the problem is two fields having the same position ordering, open perspective properties looking at development -> network, see perspective -> columns GraphQL data:
So it seems when we try to exchange positions of these two fields, exchange of identical position values does nothing:
We need to:
Look through backend and frontend sources and check everything relevant to how perspective field positions are assigned and changed, and fix any bugs that are present.
Create an administrator only accessible mutation that for each perspective would check if the field ordering is valid, and if not fix it according to the current order of the fields in the interface.
If the order is indetermined, ties can be broken via creation time and/or client id/object id numbers.
The text was updated successfully, but these errors were encountered: