Updates reset changes in progress #42

Closed
crazedsanity opened this Issue Mar 27, 2014 · 5 comments

Comments

Projects
None yet
1 participant
@crazedsanity
Owner

crazedsanity commented Mar 27, 2014

When updating a value in saves (for instance), I can change "magic mod" to one thing, and as I'm updating the next box ("misc mod"), it gets immediately overwritten and the box is marked clean (goes from blue to white).

The server response indicates there's a change in the box I'm working in, so the Javascript overwrites my changes. The status of the input is changed from dirty to clean, so the update is never sent.

@crazedsanity

This comment has been minimized.

Show comment
Hide comment
@crazedsanity

crazedsanity Mar 27, 2014

Owner

This bug will be addressed after #37 is implemented.

Owner

crazedsanity commented Mar 27, 2014

This bug will be addressed after #37 is implemented.

@crazedsanity

This comment has been minimized.

Show comment
Hide comment
@crazedsanity

crazedsanity Mar 28, 2014

Owner

The javascript function callback_showUpdatedInput(xmlObj) seems mostly responsible for this problem. One possible fix is to avoid changing any input that has focus.

Owner

crazedsanity commented Mar 28, 2014

The javascript function callback_showUpdatedInput(xmlObj) seems mostly responsible for this problem. One possible fix is to avoid changing any input that has focus.

crazedsanity added a commit that referenced this issue Mar 31, 2014

Simplification and display tweaks
 * simplify (a lot) using update_and_get_changes()
 * cleanup some old comments & such
 * csbt_save::_get_record_extras() adds 'display_name'
 * minor tests to avoid PHP warnings/errors
 * partially fixes issue with updates resetting changes in progress (#42): only changed values get updated now (if those are being changed, the bug will still occur)
@crazedsanity

This comment has been minimized.

Show comment
Hide comment
@crazedsanity

crazedsanity May 5, 2014

Owner

This is mostly fixed by way of a workaround, implemented early in v0.9.x. Future fixes would require something more sophisticated, and probably converting the data returned by the server to be in the JSON format.

Owner

crazedsanity commented May 5, 2014

This is mostly fixed by way of a workaround, implemented early in v0.9.x. Future fixes would require something more sophisticated, and probably converting the data returned by the server to be in the JSON format.

@crazedsanity

This comment has been minimized.

Show comment
Hide comment
@crazedsanity

This comment has been minimized.

Show comment
Hide comment
@crazedsanity

crazedsanity Oct 5, 2017

Owner

Just as an update to the comment from May 5 2014: I believe this came about during the time when the inputs were getting marked as disabled/readonly (which was intended to prevent changes when an update was processing). This problem as been fully resolved as of v0.4.0 (it was still affecting the notes field).

Owner

crazedsanity commented Oct 5, 2017

Just as an update to the comment from May 5 2014: I believe this came about during the time when the inputs were getting marked as disabled/readonly (which was intended to prevent changes when an update was processing). This problem as been fully resolved as of v0.4.0 (it was still affecting the notes field).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment