Course Reserves (UXPROD-791)

[UXPROD-2063] Course Reserves - Permissions Created: 24/Sep/19  Updated: 16/Sep/20  Resolved: 17/Mar/20

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:
Blocks
blocks UICR-19 Set up a minimal-permissions user to ... Open
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

  • Courses: All Permissions
    • The highest level is CRUD Course Reserves which allows the user to maintain courses, items, instructors, cross listed courses, etc. (includes all of the following permissions)
  • Courses: Read All
    • Allows user read only access to Courses and Reserves
  • Courses: Read, Add, edit
    • Allows user the ability to read, add and edit Course Records - but not to delete. (does not include item add, edit and remove)
  • Courses: Add, edit, and remove items
    • this permission allows a user to add and edit items to a course
  • Settings (Courses): All Permissions
    • This permission allows the user to Create, edit and delete all Course Settings


 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.

  • Courses: Read, Add, edit
    • Allows user the ability to read, add and edit Course Records - but not to delete. (does not include item add, edit and remove)
  • Courses: Add, edit, and remove items
    • this permission allows a user to add and edit items to a course
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 ( MODPERMS-34 Closed , MODPERMS-17 Closed ). This is actually pretty bad for in-place upgrades in general. In addition, when you disable a module, the permissions persist, and are not redefined if you re-enable it.

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 MODPERMS-34 Closed . I think probably it will probably not work, though it is certainly worth a try. Kurt Nordstrom or Heikki Levanto may have more insight.

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.

Generated at Fri Feb 09 00:20:49 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.