Course Reserves
(UXPROD-791)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q1 2020 | Parent: | Course Reserves |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Kelly Drake | Assignee: | Kelly Drake |
| Resolution: | Done | Votes: | 0 |
| Labels: | po-mvp, q4-2019-spillover, team-mvp | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Epic Link: | Course Reserves | ||||||||
| Front End Estimate: | Very Small (VS) < 1day | ||||||||
| Front End Estimator: | Mike Taylor | ||||||||
| Back End Estimate: | Very Small (VS) < 1day | ||||||||
| Back End Estimator: | Kurt Nordstrom | ||||||||
| Development Team: | Thor | ||||||||
| Report Functional Area(s): |
Resource Access
|
||||||||
| Rank: Chicago (MVP Sum 2020): | R5 | ||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||
| Rank: Lehigh (MVP Summer 2020): | R4 | ||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||
| Description |
|
Course Reserves requires the following Permissions
|
| Comments |
| Comment by Mike Taylor [ 25/Sep/19 ] |
|
There is little to do on the front-end, hence the low estimate. This will be mostly to do with wrapping parts of the UI in <IfPermission> so that users who lack permissions don't run into error messages, they simply don't get offered the functions they're not allowed to use. |
| Comment by Mike Taylor [ 18/Feb/20 ] |
|
Kelly Drake Can you please provide a one-line description for "Settings (Courses)" as you did for the other two? |
| Comment by Mike Taylor [ 18/Feb/20 ] |
|
Kelly Drake Thanks for the description, and for the two new permissions. Does "Courses: Read, Add, edit" include the ability to add items to a course? |
| Comment by Mike Taylor [ 18/Feb/20 ] |
|
I have assumed for now that it does. This should be fixed.
|
| Comment by Kelly Drake [ 18/Feb/20 ] |
|
I was thinking it would be activated in tandem with "Courses: Add, edit, and remove items" - if the user needed those permissions. Having the separate provides a bit of flexibility. That said, in reality, someone who can create Courses, and always add, edit, etc the items. So whichever makes most sense to you - is good by me. |
| Comment by Mike Taylor [ 18/Feb/20 ] |
|
No, no, don't pull me into making PO-level decisions! Seriously, it's no problem for me either way: just tell me which you prefer, and I'll do it. |
| Comment by Kelly Drake [ 18/Feb/20 ] |
|
Separate it is! The more granularity we can provide the better.
|
| Comment by Mike Taylor [ 18/Feb/20 ] |
|
I modified the package file accordingly. Now we wait for Kurt Nordstrom to OK my pull-request on the back-end module descriptor, and for Wayne Schneider to deploy the results. |
| Comment by Wayne Schneider [ 21/Feb/20 ] |
|
This should be deployed on simmons-test-cr.hosted-folio.indexdata.com. I'm not entirely sure how the permissions updates will look in the UI. If necessary, we can clean up the permissions storage by hand. |
| Comment by Mike Taylor [ 21/Feb/20 ] |
|
Thanks, Wayne Schneider! I see the new ui-courses permissions in the list when I go to add a permission to a set, but unfortunately as predicted we still also see the old low-lecel permissions from mod-courses: the ones whose names all in lowercase. Can we find a way to clear those out? Thanks! |
| Comment by Wayne Schneider [ 24/Feb/20 ] |
|
Mike Taylor Unfortunately there does not appear to be an easy way to do this. When you upgrade a module, the permissionSets are not redefined. There are a few old issues that complain about how mod-permissions handles this kind of thing (
So the only way to "clear these out" is to go looking for them and redefine them. I am working on a general-purpose script for this, as it seems that it will be needed to ensure that permission updates are handled cleanly for module upgrades. |
| Comment by Mike Taylor [ 26/Feb/20 ] |
|
OK, thanks Wayne Schneider. Kelly Drake Can you just ignore the all-lower-case permissions for now? |
| Comment by Mike Taylor [ 26/Feb/20 ] |
|
Ah, no, though! Wayne Schneider we're not seeking to remove the old permissions — indeed we must not do that, we need to retain them. We just to make them invisible at the UI level, i.e. flip their visible bit. I have removed as the visible:true entries from the definitions of all the relevant permissions — https://github.com/folio-org/mod-courses/pull/63 — but although this has been merged and the resulting version redeployed it does not seem to have resulted in the required change. Could it be that we need to explicitly add visible:false? |
| Comment by Mike Taylor [ 26/Feb/20 ] |
|
For example, https://github.com/folio-org/mod-courses/blob/87f1a7b575e75fbf20f556c88dd46430e05f89c1/descriptors/ModuleDescriptor-template.json#L699-L707 says
{
"permissionName": "course-reserves-storage.processing-statuses.read",
"displayName": "course reserves processing statuses read permissions",
"description": "pending",
"subPermissions": [
"course-reserves-storage.processing-statuses.collection.get",
"course-reserves-storage.processing-statuses.item.get"
]
},
but the "course reserves processing statuses read permissions" permission is still visible in Settings -> Users -> Permission sets. But if I put "visible": false in there, and we merge and redeploy, might that explicitly override the presumably still-in-place {{"visible": true}?? |
| Comment by Wayne Schneider [ 26/Feb/20 ] |
|
Mike Taylor see
|
| Comment by Mike Taylor [ 26/Feb/20 ] |
|
So are you saying the present behaviour is that once a permission has been added, we're stuck with it for all time ands can never change it? If so, that needs to be raised as a much higher priority issue. |