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

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.

here's a patch

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

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

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.

For Feedback Fest - Would be nice to have these settings work, can it be bumped up?

At long last, here's a working branch that does the thing:

user/dyrcona/lp1815950-hide-fields-patron-registration-edit

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1815950-hide-fields-patron-registration-edit

It starts with a.bellenir's patch and adds a commit to prevent hiding database-required fields, defined as those having an entry in the default_visibility hash with a value of 3.

Testing is pretty straightforward:

1. Apply the patch
2. Add an org unit setting to set ".show" to false for an optional field on actor.usr (photo_url is an easy choice).
3. Log out of the staff client, if logged in, to pick up the setting change.
4. Log in and go to patron registration or patron edit and verify that the hidden field does not show up.

You can repeat the same for a required field, like barcode, to see that it does not get hidden.

I followed Jason's instructions and was able to confirm that photo_url was hidden for the branch I set the setting as "false" for and showed up in the editor for the branch I didn't have it set to false for.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/lew/lp1815950-hide-fields-patron-registration-edit-signoff

If we set Show Barred to false, and Suggest Barred to true, we see Barred under Suggested Fields and All Fields. If we set Show Barred to false and leave Suggest Barred unset, we see Barred under All Fields. I'm not sure what behavior we want for that first scenario, but for the second we definitely want Barred to be hidden under All Fields, right?

I may be struggling with caching, so I'll poke again tomorrow.

I'll grab this one. I've tested and it provides the flexibility needed for much better control of the visibility of the fields in patron registration than we currently have.

Regarding Jason's Comment #9 setting Show Barred to false and leaving Suggest Barred as unset had the expected result. The Barred field did not display at all.

Setting a single setting for each field provides the best flexibility:

Show = False - the field does not display
Show = True - the field displays in All, Suggested, Required
Suggest = True - the field displays in All and Suggested, but not Required
Require = True - the field displays in All, Suggested, Required

With all settings for a field Unset, the field displays in All, but not Suggested or Required.

Pushed to main for 3.15beta with some release notes.

Thanks to a.bellenir, Jason S. Llewellyn and Jason E.!

I'm purposely not backporting this since library settings that already exist in systems may result in a change of behavior.