Skip to content
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

Subject Ordinal field resets to 0 if value is non-numeric and user changes another field #250

Open
rhigman opened this issue Jun 3, 2021 · 2 comments
Labels
bug Something isn't working

Comments

@rhigman
Copy link
Member

rhigman commented Jun 3, 2021

On the Work > New Subject subform, type an invalid (non-numeric) value into the Subject Ordinal field, then e.g. start typing in the Subject Code field. The entered Subject Ordinal value will suddenly change to 0.

This is due to the logic of the component's ChangeOrdinal message: it stores invalid values underlyingly as 0, but it avoids re-rendering the component in order to keep the user-entered string visible. However, changing any other field re-renders the component anyway. The New Issue form Issue Ordinal field works the same way, but as there are no other fields on the form, the bug is not apparent.

This is a very minor issue, but we would like to improve the MVC pattern of the GUI in due course (compare the more complex parsing problem and workaround added under #249), and we should also address this at that point.

@rhigman
Copy link
Member Author

rhigman commented Jul 12, 2021

There is a similar issue with the numeric fields on the Work page (Width, Height, Page/Image/Table/Audio/Video Counts). Typing a value such as "6.5" in e.g. the Width field (which we may start needing to do when we implement #259) results in the "6." being overwritten by the "5". Typing a value such as "0.5" initially looks like it succeeds, but changing any other field results in the value jumping to "0", due to it being underlyingly stored as 0 as above.

@rhigman
Copy link
Member Author

rhigman commented Oct 6, 2021

String fields are also affected in that they are trimmed before saving: for example, on the Work page, entering a value such as " title " for the Title field is permitted, but as soon as another field which has parsing logic is edited (e.g. numeric fields, URLs, DOI), the displayed value will jump to its trimmed version, "title". Very minor, but slightly confusing, particularly as it is inconsistent (e.g. most plain string fields don't have parsing logic and don't trigger a re-render, so a user may enter leading/trailing spaces in several string fields and think that this is not an issue until these fields suddenly change when a numeric field is edited).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant