Closed sandhiyakavi closed 3 years ago
Also is it possible to add some form of warning for the user to know that if the daysworked set (if user sets the days) for the first, second of first, last and second of last WP's are subjected to change if there is Change in the Resource Booking dates? Otherwise if user sets daysworked and then if RB dates changed, the daysworked will also be changed. User won't be aware of it.
@sandhiyakavi I think if we add some message for the first and last WPs it would be not enough. Because if we change RB dates for example in half, then half of the WPs would be removed and WP which would be the new last/first one, would be also updated, even though, before it was in the middle.
So far I don't see a good solution for such edge cases. I think what we can do, is log this issue separately, and we could try to discuss it with Will or other end users of the TaaS Admin App. We could learn from them their usage patterns, or maybe they would have some idea regarding this, how do they feel would be natural for them.
Sum up:
When we change Working Days, we send the API request to the server. If request failed, we already show the error toastr.
if the request is successful we have to indicate it by showing the green checkmar in the green circle with some animation, for example this one https://codepen.io/kuvinod5/pen/WNvzazr
but use our green color #137D60
this checkmark should be show next to the Wokring Days input field like this
after 2 seconds (this time should be configurable) this checkmark should fade away.
showing this green checkbox should NOT cause jumping of data in the table, so this checkbox should be shown using `position: absolute
@maxceem Currently if we try to increase WorkingDays beyond its fitting to the RB dates,error message is getting displayed but if we try to again change it back to its previous number(without refreshing), the green tick mark is getting displayed which should not happen as the number is not changed in this case.
@sandhiyakavi this is a bit tricky issue.
The reason for this, when we increase the number it send to the server and gets error, but visually, the number stays as increased. When we decrease it back to previous value we send request to the server again, and this time server returns success - actually value is not changed we just send request to set the same value which is already there.
So the green tick kind of works correctly, it is shown when request is successful.
I'm not sure how it would be better to handle such case if error happened, but if you think we should do something about, I suggest logging a separate issue for this case.
Verified on Dev Env. Working as expected.
Verified on Prod Env with @nkumar-topcoder
Description: