[UIU-497] Loan: Change due date Created: 13/May/18 Updated: 04/Sep/18 Resolved: 03/Jul/18 |
|
| Status: | Closed |
| Project: | ui-users |
| Components: | None |
| Affects versions: | None |
| Fix versions: | 2.13.0 |
| Type: | Story | Priority: | P2 |
| Reporter: | Emma Boettcher | Assignee: | md331 (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | demo39, loans, resourceaccess, sprint38, sprint39 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue links: |
|
||||||||
| Sprint: | |||||||||
| Analysis Estimate: | Medium < 5 days | ||||||||
| Analysis Estimator: | Emma Boettcher | ||||||||
| Back End Estimate: | Medium < 5 days | ||||||||
| Front End Estimate: | Medium < 5 days | ||||||||
| Description |
|
Change due date is a feature that can be launched from Loans, Loan details and Check out. Purpose: Allow users to change the due date for a loan without renewing it. User story: As a staff member, I want to extend a patron’s loan period without renewing the item, so that I can accommodate their need for a longer due date while controlling the loan period of the item. Scenarios
Notes: |
| Comments |
| Comment by Marc Johnson [ 14/May/18 ] |
|
Emma Boettcher Jakub Skoczen Following the call, I've just quickly checked. It doesn't look like there is anything that restricts updating the due date at the moment, and actions are unconstrained, so the UI should only need to change the due date and action for this. In scenario 5, what do we mean by the end of the day, is that 23:59:59? Should that also apply when checking out or renewing (I thought we typically used the current time, as loans could be for less than a day in some cases)? |
| Comment by Emma Boettcher [ 14/May/18 ] |
|
Marc Johnson end of day is 23:59:59, yes. SIG was adamant about that, but only for change due date so far as I know - end of day should not be the default when checking out or renewing. |
| Comment by Marc Johnson [ 14/May/18 ] |
|
Emma Boettcher Thanks for the quick answer |
| Comment by md331 (Inactive) [ 29/May/18 ] |
|
Hey Emma Boettcher, are the warnings intended to stop the due date from being changed? Or is it there purely for the user's information and if they decide to go ahead with setting a due date past the user's expiration etc they should be able to do so? Seems like they're just for display but making sure.. |
| Comment by Emma Boettcher [ 29/May/18 ] |
|
For display. Thanks for checking. At a later date might want to set it up so that some users have permissions to make those kinds of changes and some don't . But for now, just display the warning without any prevention. edited: to tag md331 and clean up typos. |
| Comment by md331 (Inactive) [ 04/Jun/18 ] |
|
PRs merged so moving this to In Review now. |
| Comment by md331 (Inactive) [ 08/Jun/18 ] |
|
Hey Emma Boettcher, my bad on that button ordering. Good catch! Fix has been merged to Git so it'll be in the next update of stable. About the last due date, I think I know why it didn't show up but I want to confirm. The logic I used for determining the last due date starts off its comparisons with the current date. So if none of the selected loans are later than the current date, the Date picker will default to the current date. I can change this fairly easily but now that I think more about it, it seems intuitive, especially since using a last due date in the past will immediately throw a warning on the screen. Anyway, if that's the issue you're seeing, then that's the explanation for it. And let me know if you want me to change it to always use the last due date, even if it's in the past. |
| Comment by Emma Boettcher [ 08/Jun/18 ] |
|
Hey md331, thanks for the quick fix on the buttons. Re: due date automatically populating: the thought behind using the actual due date of at least one item in the queue is that if you confirm it by mistake, you've done minimal damage. However, this could lead to the due-date-in-the-past warning being displayed too often & people ignoring it when it does occur, so that's a good point. Let's leave as-is for now and I'll ask which of those would be the bigger issue. |
| Comment by Emma Boettcher [ 11/Jun/18 ] |
|
md331 After talking with the loans folks, I think the way to go on this is have it always default to the current due date (even if that is in the past), for consistency's sake or (and this may even be preferred) leave the due date field blank entirely so that there's no danger of having the user submit the wrong thing without thinking. Due time would still have the default of 11:59:59. Is that possible? |
| Comment by md331 (Inactive) [ 11/Jun/18 ] |
|
Emma Boettcher, both of those are a breeze. I went ahead and implemented it so that it leaves the due date blank. And since that's processed as an invalid date, the Save and close button will be disabled until the user actually selects a date. Merging that PR now but let me know if you want any further tweaks to that or anywhere else. |
| Comment by Emma Boettcher [ 11/Jun/18 ] |
|
Thank you md331! |
| Comment by md331 (Inactive) [ 11/Jun/18 ] |
|
Oh Emma Boettcher, I see your edit on the description and I think I misunderstood. I thought you wanted the default date to only be blank if the latest current due date was in the past, but to use that date if it was in the future. E.g., DD #1 May 1 2018, DD #2 June 1 2018. If accessed today, then the default date would be blank. If you want it to always be blank, I can do that. |
| Comment by Emma Boettcher [ 11/Jun/18 ] |
|
md331 always be blank, no matter when the current due date is. (Reason being that you probably wouldn't be using the current due date as the item's changed due date, even if it is in the future - it was only the default as a way not to penalize the user for hitting "save & close" without thinking.) thank you for clarifying! |
| Comment by md331 (Inactive) [ 11/Jun/18 ] |
|
Great, merging that change now! |
| Comment by Emma Boettcher [ 13/Jun/18 ] |
|
md331 I think I might have led you astray re: warning text color. The warning text should be using the centrally defined warning text color, rather than anything custom. (Makes it easier to change all warning text if necessary in the future, and the orange on the change due date mockups and in production doesn't meet WCAG standards, which I only thought to check after seeing it on the sprint review yesterday.) |
| Comment by md331 (Inactive) [ 14/Jun/18 ] |
|
Emma Boettcher, yeah, I was actually aware of it and it was a bit of a placeholder. We currently don't have a good way of getting variables (ie, colours) from where they're defined (CSS) into our Javascript code. Normally we'd just write another CSS file but it seemed like unnecessary overhead for just that colour. So I was chatting with John Coburn about whether or not we'd want to add a better way of getting those colours into JS code and we were thinking that yes, we did want to do it, but probably not right now. So I just put a placeholder colour and not the correct colour to purposely remind us that it should get changed. I'll just go ahead and fix it up now though and eventually refactor it when we do get that extra functionality. |
| Comment by Emma Boettcher [ 14/Jun/18 ] |
|
md331 if it'll be a better remind to leave it as is, I can understand that. Just didn't want you to be overriding existing behavior in order to match the mockup, but it sounds like that's not the case. Sorry! |
| Comment by md331 (Inactive) [ 19/Jun/18 ] |
|
Alright! Emma Boettcher, I saw that we'd need similar colouring functionality in a couple of others places including the bulk renewals feature that's going through review now so I went ahead and coded up the ability to colour all of our icons based on a status, which will grab the centrally-defined colours. It'll be in the next stable build! |