Inventory (UXPROD-785)

[UXPROD-2166] Inventory Permissions. View Instance records which are marked as Staff suppress Created: 26/Nov/19  Updated: 18/Feb/21  Resolved: 18/Feb/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Inventory

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-1371 Inventory Permissions (Basic CRUD) Closed
Defines
is defined by UIIN-746 Inventory - Permissions. View Instanc... Closed
Epic Link: Inventory
Analysis Estimator: Charlotte Whitt
Front End Estimate: Very Small (VS) < 1day
Estimation Notes and Assumptions: CW: This feature is defined by one story: UIIN-746 - which is pointed to be a 2 story point story by the Core Functional team.
Development Team: Prokopovych
PO Rank: 137
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R4
Rank: Lehigh (MVP Summer 2020): R4
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R1

 Description   

Purpose: To create Inventory permission for View of Instance records which are marked as Staff suppress.

Usecase:

  1. Cataloger managers/Library administrators want to be able to give e.g. catalogers, technical staff users permissions to View Instance records which are marked as Staff suppress
  2. All staff who do not have the special permission to view instance records which are marked as Staff suppress, will not get these records when doing a search in Inventory.

In scope:

  1. Create the new Inventory permission for View of Instance records which are marked as Staff suppress
  2. Review and possible update existing Inventory permissions does not allow for seeing these records when doing a search in Inventory


 Comments   
Comment by Cate Boerema (Inactive) [ 28/May/20 ]

The focus of this feature is to implement basic CRUD based permissions for Inventory

Charlotte Whitt, we already have basic CRUD permissions for Inventory. Should this be removed from the above description?

Circulation or public services staff have many use cases for editing holdings and items. For example, staff often have a source bib record for, say, a type of equipment, and then they manage the equipment underneath the record without having to get tech services involved. They may edit holdings, add/withdraw items, and other features. Some public services staff also have stacks management responsibilities, esp. the case for special collections libraries. How are these permissions sets being conceived / defined?

There is a lot here. I think we need to parse it.

staff often have a source bib record for, say, a type of equipment, and then they manage the equipment underneath the record without having to get tech services involved

They could do that today, if they were given "Inventory: View, create, edit items". Are you saying we need a permission that would provide access to edit just a single record? Or access to edit any records with a given type (e.g. equipment)? For the former, Teams might be a potential solution. I don't think we have any architecture in place to support the latter.

They may edit holdings

We already have a permission to support this.

withdraw items

Putting permissions around specific actions like withdrawing items is currently only possible when we have a dedicated endpoint for that action. For withdrawn, we have such an endpoint and Emma Boettcher has a story in for creating a permission for Withdrawn ( UIIN-889 Closed ). Other actions (like mark an item missing) don't have their own endpoints. These types of actions need to be wrapped into the standard Update permission for the record.

We have long discussed the need for "action based permissions" ( UXPROD-1828 Closed ) so we have more flexibility. If you look at UXPROD-1828 Closed , you'll see several UXPROD permission features linked as blocked by it. I think it would be best if you could create separate UXPRODs for each of the specific permissions you think are missing in inventory and we can then link them as blocked by UXPROD-1828 Closed or not. I think it will be important to coordinate with Emma Boettcher, as well, as she likely will create JIRAs for permissions related to her features (e.g. Missing, Claimed returned etc).

Thanks!

Comment by Charlotte Whitt [ 28/May/20 ]

Cate Boerema - permission to view e.g. records being marked as Staff suppress is not an Action based permission.
But while this is the only story related to this feature right now, then I'll update the subject line.

Comment by Cate Boerema (Inactive) [ 29/May/20 ]

Yes, you're right. That one's not action-based. Thank you for updating the title - this is much clearer!

Comment by Charlotte Whitt [ 11/Nov/20 ]

Hi Cate Boerema - this feature has kind of dropped under the radar. Shouldn't it be implemented for the round_iv libraries, so for R1 2021?

Right now when a user have the regular permissions for Inventory, and perform a search, then the search result will include records which are marked as staff suppressed

CC: Kelly Drake Laura Daniels

Comment by Cate Boerema (Inactive) [ 11/Nov/20 ]

You're right! It wasn't on our radar, given the PO rank was quite low.

Unfortunately, I don't think this is a standard ui-only permission. As far as I know, FOLIO doesn't support permissions based around data (like staff suppress = yes). I could be wrong, though.

Let's start by asking Bohdan Suprun and Sergiy Sergiyenko to estimate this and go from there.

Comment by Bohdan Suprun (Inactive) [ 11/Nov/20 ]

Cate Boerema, Charlotte Whitt,

You're right, we don't have data based permissions, only API endpoint permissions.

There two ways to solve this:

  • Have separate endpoints for non suppressed/non suppressed + suppressed instances and then UI should decide which one endpoint to use based on user's permissions, it is not ideal because UI has to implement some business logic. Thinks may be more complicated if we also need special permissions to update the staff suppressed records or view them by id (search and view instance by id are separate endpoints), delete them.
  • A better solution might be if we keep existing endpoints but adjust them so they check if user has certain permission and based on this include/exclude suppressed instances. The main challenge with this is that we don't have any experience with direct use of user's permissions and they also managed by a separate service, so that we will have to introduce a new dependency between the mod-inv-storage and mod-permissions what FOLIO tries to avoid (introducing dependencies for storage modules).

There is also impact on other business flows, for example:

  • check-out;
  • requests;
  • discovery;
  • etc.

CC: Marc Johnson, Jakub Skoczen.

Comment by Cate Boerema (Inactive) [ 11/Nov/20 ]

Thanks Bohdan Suprun.

Charlotte Whitt, if this proves tricky (as it seems it will be) could a workaround/simple fix be to make Inventory filter out the Staff suppress = Yes items by default? So users would have to click a checkbox to "include staff suppressed items"?

Comment by Marc Johnson [ 12/Nov/20 ]

Bohdan Suprun Thanks for your thorough response, I agree that those are our options.

A better solution might be if we keep existing endpoints but adjust them so they check if user has certain permission and based on this include/exclude suppressed instances. The main challenge with this is that we don't have any experience with direct use of user's permissions and they also managed by a separate service, so that we will have to introduce a new dependency between the mod-inv-storage and mod-permissions what FOLIO tries to avoid (introducing dependencies for storage modules).

I believe FOLIO has a mechanism for this known as desired permissions (I tend to call the use of this mechanism action based permissions because I think it better describes the users intent). This mechanism has rarely been used. I believe Oleksandr Vidinieiev from the Vega team recently experimented with this approach for UIU-2019 Closed and may do so more in the follow up spike CIRC-992 Closed .

An aspect of this particular feature that is especially involved is that these records should be omitted from search results.

In order to do that, we would need to manipulate the CQL that the front-end provides to remove these records. We might also need to reject (or change) CQL queries where folks specifically ask for records that are suppressed when they don't have permission to do so.

Normally, the interpretation of CQL is done by RAML Module Builder, this feature would likely mean needing to manipulate it in the module itself as well.

Does that make sense?

Comment by Charlotte Whitt [ 16/Dec/20 ]

Needed work. Right now everyone if having the right to view instance records, can also see records being suppressed.

For the purpose of display of search results, then it's necessary to have this distinction between

  • allowed to see all records (including Staff suppressed records)
  • not allowed to see records which are being marked as Staff suppressed
Generated at Fri Feb 09 00:21:42 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.