fields should be hidden when the relevant ".show" org unit setting is false

Bug #1815950 reported by a. bellenir
60
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned
3.10
Confirmed
Medium
Unassigned
3.11
Confirmed
Undecided
Unassigned
3.8
Won't Fix
Medium
Unassigned
3.9
Won't Fix
Medium
Unassigned

Bug Description

settings for field visibility, au.prefix.show, for example, cannot be used to hide fields by setting their value to false.

i want to hide the prefix field from the patron editor, even when "All fields" is selected (we don't use it).

setting au.prefix.show to false has no effect.
setting it to true will cause the field to show up when viewing "Suggested Fields" or "Required Fields".

irc discussion: http://irc.evergreen-ils.org/evergreen/2019-02-14#i_394888

Changed in evergreen:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I agree with the description, but think this is a change in behavior and so not exactly a bug. I've confirmed this and set the importance to Wishlist as I think this would be a new feature or at least a change in behavior of an existing feature.

I think it also depends on whether or not you can unset a setting from the staff client once it has been set, i.e. can you delete an org_unit setting from an org unit via the client. I typically mess with these in the database where it is easy to delete them.

What I envision is the following: Setting the .show setting to true makes it show up for "All Fields," "Suggested Fields," and "Required Fields" as it currently does. Setting the .show setting to false will cause the field to not show up at all. Having the setting unset, it will only show up for "All Fields" as it currently does for unset or being set to a false value.

I also think the .suggested and .required settings should have precedence over .show, so that if either of those is true and the .show setting is false, then the .show setting behaves as if unset.

If anyone disagrees with this new behavior, please chime in.

Revision history for this message
a. bellenir (abellenir) wrote :

here's a patch

tags: added: orgunitsettings patron
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I don't agree with my comment from four years ago. I now consider this to be a bug.

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
importance: Wishlist → Medium
Revision history for this message
Jason Stephenson (jstephenson) wrote (last edit ):

I have verified that the patch works on Evergreen 3.7, but I want to also look at 3.10.

There are related bugs about specific fields and the settings so I'm still leaning toward bug on this.

Bug 1967180
Bug 1910579

no longer affects: evergreen/3.10
no longer affects: evergreen/3.9
Changed in evergreen:
importance: Medium → Wishlist
Changed in evergreen:
importance: Wishlist → Medium
Changed in evergreen:
status: Confirmed → In Progress
Revision history for this message
Jason Stephenson (jstephenson) wrote :

This is a summary of how things work now and the perceived bugs.

Fields with a required setting get a visibility value of 3.

Field with a show setting get a visibility value of 2.

Field with a suggested setting get a visibility value of 1.

Other fields get a visibility value from either the default visibility map or a visibility of 0 if the field is not present in the map. For fields listed in the default visibility map, a show, required, or suggested organizational unit setting will override the default value.

Showing "Required Fields" shows fields with visibility of 2 or higher.

Showing "Suggested Fields" shows fields with visibility of 1 or higher.

Showing "All Fields" shows fields with a visibility of 0 or higher.

Fields with a show or required setting always show. Fields with a suggested setting show when showing suggested fields or all fields. Other fields without a default visibility map entry only show when showing all fields.

(The difference between show and required settings is that the input boxes for required fields are highlighted, and the interface will not save unless they are filled in.)

The ui.patron.edit.default_suggested setting makes "Suggested Fields" the default view level in the interface.

The above flow is sound and workable. However, there are some bugs.

1. The required, suggested, and show settings all take a true/false value. Setting the value to false does nothing. Thus, there is no way to completely hide a nonessential field.

2. The interface looks up a limited number of settings. Adding a setting for a field that is not hard-coded into the settings look up in the interface does not affect the field's visibility.

3. There are a limited number of settings available with the stock installation, and as mentioned previously adding new ones has no effect on the interface.

4. The values in the default visibility map for some fields are likely too high.

If anyone thinks I have missed something in the above description, please feel free to add a comment. I am posting this to look for feedback.

Number 1 is solved by a.bellenir's patch on this bug for those fields that have show settings to look up.

Number 2 and 3 can be solved by adding new settings to the database and expanding the list of setting retrieved in the interface. (It may become cost prohibitive to look up each field as it is referenced, so we are likely stuck with an ever-expanding hard-coded list of settings until someone comes up with a better solution.)

I propose fixing number 4 by setting most of the fields in the default visibility list that have a value of 2 (show) to have a value of 1 (suggested).

There are some fields that MUST be required. These fields are required by the database in order to store a minimal amount of patron data. We could possibly add some safeguards for these fields against someone adding a show setting and making the value false.

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
status: In Progress → Confirmed
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

Remote bug watches

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