Skip to content
This repository was archived by the owner on Mar 13, 2025. It is now read-only.

[$30] Nice to have: Changes for Working Days field #50

Closed
sandhiyakavi opened this issue Jun 25, 2021 · 7 comments
Closed

[$30] Nice to have: Changes for Working Days field #50

sandhiyakavi opened this issue Jun 25, 2021 · 7 comments

Comments

@sandhiyakavi
Copy link
Collaborator

Description:

  1. Currently if we change the daysWorked for a resource, there is no way to ensure it's changed except refreshing. can we add a green colour blink or some checkmark near the field to denote it is updated to the server?

image

  1. 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.
@maxceem
Copy link
Contributor

maxceem commented Jun 30, 2021

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.

@maxceem
Copy link
Contributor

maxceem commented Jun 30, 2021

Sum up:

  • For now we would only implement the first part of this issue.
  • 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

      image

    • 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 maxceem added the CF Issues for Community Fixes label Jun 30, 2021
@maxceem maxceem changed the title Nice to have: Changes for Working Days field [$30] Nice to have: Changes for Working Days field Jun 30, 2021
@sandhiyakavi
Copy link
Collaborator Author

@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.

bandicam.2021-07-05.18-17-48-257.mp4

@maxceem
Copy link
Contributor

maxceem commented Jul 5, 2021

@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.

@sandhiyakavi
Copy link
Collaborator Author

Verified on Dev Env. Working as expected.

image

@maxceem
Copy link
Contributor

maxceem commented Jul 7, 2021

@maxceem maxceem added the PAID label Jul 7, 2021
@sandhiyakavi
Copy link
Collaborator Author

Verified on Prod Env with @nkumar-topcoder

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants