Hours not saving if inputted via multiple tabbing to next input field

[ericbenwa]

I got to another persons My StaffPlan view, change hours on a project (via inputting hours then tab input hours tab...) and click People. Those hours I just edited are not saved (that persons totals on People is not updated, and if I return to that persons My StaffPlan view, those hours are reset to their prior state, losing my changes).

If you recreate try doing it by edit hours > tab > edit hours > tab... do this a few times.
And make your edit hours a 0.
It seems that it may be saving the first edit, but not subsequent edits, and it doesn't seem to like 0.

See video for flow...
https://github.com/user-attachments/assets/7cf824ca-fee4-44cc-8da9-9953299ae461

[zhukovdigital]

@ericbenwa The behavior as in the video is not reproducible for me. It may have been fixed in previous PRs. Can you check again if this behavior is reproduced now?

@ericbenwa @fermion I also noticed that if you enter a value greater than 168, the backend does not save the changes, but visually they happen and after refreshing the page the values become as they were.
It is logical not to save values more than hours in a week (7 * 24 = 168), but we need to show it visually to the user.

[fermion]

@zhukovdigital @ericbenwa it's a validation on the backend, work weeks can't have more than 168 hours added. There are 168 hours in any week (24 * 7).

[ericbenwa]

@zhukovdigital Just tested this again. I can still reproduce the hours not saving issue (video attached that I just took).

Start with a row of '5' hours.
Then change them all to '0' by tabbing to each input field.
Do at least five input fields set to '0'.
Then navigate to another page and back.
= Not all input fields saved those changes.

Then repeat these steps after two or three times it then seems to correctly save the changes.
https://github.com/user-attachments/assets/6b5d8dfe-ccfb-4f83-98a3-e2ee7acb0635

[zhukovdigital]

@ericbenwa This problem relates to #465 . And it is most likely related to the way the backend handles value 0 and empty string.

And about entering more than 168 hours, what should we do? Any ideas how to inform the user that more than 168 hours cannot be entered?

[ericbenwa]

@zhukovdigital
And about entering more than 168 hours, what should we do?
I'll put that on my list to think about – thank you for finding!

[fermion]

@zhukovdigital looking at this now, I'm not sure this is related to the backend handling of 0 or '' values, since the save does seem to work the second time (from @ericbenwa's video). I'm going to see if I can repro locally to better understand this.

[fermion]

@zhukovdigital from what I can see this looks like another issue with client side state not updating itself correctly as values are being mutated. See this screen cap:

Kapture.2025-01-20.at.13.43.12.mp4

I followed the same steps that @ericbenwa did in his video, only at the end I refresh the project page. When I do you can see that the page is rendering the weeks where I've tried to blank out the values correctly. Let me know if I can help here!