Angular admin pages "Library" scope

Bug #1873322 reported by Christine Burns
64
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.5
Fix Released
High
Unassigned
3.6
Fix Released
High
Unassigned

Bug Description

The Library drop down menu always scopes to CONS

This should automatically scope to the workstation location and the checkboxes for +Ancestors/+Descendants should be sticky/saved as a workstation setting.

This drop down is found on various different admin interfaces

Local Admin examples
- Address Alert Configuration
- Carousels Configuration
- Group Penalty Threshold Configuration

Server Admin examples
- Billing Type Configuration
- Call Number/Volume Suffix Configuration
- Copy Tags Configuration
- Hard Due Date Configuration

Acquisitions Admin
- Cancel Reason Configuration
- Claim Policy Configuration

Booking Admin
- Resource Type Configuration
- Resource Attribute Value Configuration

In the old interfaces this was called "context org unit" and it was automatically scoped to the workstation location

Revision history for this message
Christine Burns (christine-burns) wrote :
Changed in evergreen:
status: New → Confirmed
tags: added: angular
Changed in evergreen:
milestone: none → 3.5.0
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

When eg-org-select has applyDefault=true, the selector will default to the workstation OU. But applyDefault is false by default, and only a tiny number of UIs use applyDefault=true (Booking > Pull List, Booking > Create Reservation, fm-editor, and the workstation registration screen).

We could modify the org selector to have applyDefault=true by default, and then explicitly set it to false case-by-case as needed. It sounds like this would be more consistent with the behavior of the pre-Angular context org unit selector. Note that applyDefault will trigger an onChange event when the default value is applied; if we want to avoid that, we could use initialOrg instead, but that would require a bit more rethinking.

Revision history for this message
Michele Morgan (mmorgan) wrote :

Jeff, your proposal to have applyDefault=true by default makes perfect sense to me. I can't think of any interface that should default to the Consortium rather than the workstation OU.

summary: - Angualr admin pages "Library" scope
+ Angular admin pages "Library" scope
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

Unfortunately, simply changing the default value for applyDefault from false to true seem to doesn't make a difference.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

...doesn't seem to make a difference.

Changed in evergreen:
milestone: 3.5.0 → 3.5.1
Changed in evergreen:
milestone: 3.5.1 → 3.5.2
Changed in evergreen:
milestone: 3.5.2 → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Revision history for this message
Jennifer Weston (jweston) wrote :

Strong support indicated by attendees of February Cataloging Working Group meeting for need to address the scoping.

Changed in evergreen:
importance: Undecided → High
assignee: nobody → Jane Sandberg (sandbej)
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Here's a branch that does part 1 (interfaces default to workstation ou): user/sandbergja/lp1873322_angular_admin_pages_default_ou

This does not remember the sticky values for the Ancestors/Descendants checkboxes; I wanted to check on the desired behavior before implementing that. Is it desired that those checkboxes are sticky, but the org selector is not? Is the sticky behavior still necessary when everything is defaulting to the workstation org unit?

Not applying the pullrequest tag yet while I wait on answers to those questions, but please feel free to use that branch to test the user experience with just the workstation OU default.

Changed in evergreen:
assignee: Jane Sandberg (sandbej) → nobody
Revision history for this message
Christine Burns (christine-burns) wrote :

Hi Jane

Thank you so much for working on this. Part 1 is the most important piece (interfaces default to workstation ou):

My desired behaviour would be for the org selector to default to working location (not sticky).

I would like the checkboxes to be sticky but it's not critical.

Use case = check the +Ancestors box so I can see options available to my branch + system. It would be good if this was sticky so the next time I went to the interface it showed options available to my branch + system

Revision history for this message
Jane Sandberg (sandbergja) wrote :

I could see part 2 being potentially confusing to users. For example, this behavior:

* Org selector defaults to the user's branch
* The user wants to see the system, so they change to system and click "include descendants"
* When they come back to the screen, Evergreen has only remembered the checkbox, not that they wished to view the screen at the system level

However, I could definitely be convinced! I'll propose that we move part 2 to its own bug, and I'll open a pullrequest for just part 1 for now.

tags: added: pullrequest
Revision history for this message
Tiffany Little (tslittle) wrote :

Jane, I agree that that would be confusing. I'd rather the org selector+checkbox be sticky, not just the checkboxes. That seems most customizable to different kinds of use cases, since the individual decides what's best for them to see.

Revision history for this message
Elaine Hardy (ehardy) wrote :

+1

Revision history for this message
Michele Morgan (mmorgan) wrote :

Just wanted to add that the old interface defaulted to the workstation and included Ancestors and Descendants.

For continuity, I would lean toward the angular page defaulting the same way: Workstation with Ancestors and Descendants selected.

Also, as Tiffany suggests, I'd agree that the selector+checkbox be sticky so that users can customize if the default behavior doesn't work for them.

Changed in evergreen:
milestone: 3.6.2 → 3.6.3
Michele Morgan (mmorgan)
Changed in evergreen:
assignee: nobody → Michele Morgan (mmorgan)
Revision history for this message
Michele Morgan (mmorgan) wrote :

Tested this at the Newdevs meeting and it works great! My signoff is at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1873322_signoff

tags: added: signedoff
Changed in evergreen:
assignee: Michele Morgan (mmorgan) → nobody
Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
milestone: 3.6.3 → 3.7-beta
Revision history for this message
Jason Stephenson (jstephenson) wrote :

Works for me. Pushed to master, rel_3_6, and rel_3_5 for future updates.

Thanks, everyone!

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.