Rename 'All parts' to 'Any part' in hold placement screen

[Terran McCanna]

In 3.4:

When placing a hold on a record where some copies have parts defined and some don't, there is an option to place a hold on 'All parts' which implies that a hold will be placed on every different part. For clarity, it should be renamed 'Any part.'

[Terran McCanna (tmccanna)]

My patch is ready for review: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1902120_parts_hold_wording

(The change is already in place in the Angular staff client, so this just changes the OPAC template and the BooPAC template.)

[John Amundson (jamundson)]

Full disclosure - I have not tested this patch.

In our system, the option to select "All Parts" is still a more appropriate label than "Any Part". Selecting "All Parts" places a title-level hold, and any item WITHOUT a part can fill it.

In testing the Angular Catalog on a local 3.6 server, I see the "Any Part" label on the Place Hold screen. This is an inaccurate label. I can create a new bug on that if needed, but I think updating additional locations to the "Any Part" label is a mistake.

Although a /little/ awkward, I think "All Parts" is much more appropriate because there is an assumption that an item without a part on a part-focused record would be the full set of whatever it is and include all parts.

Other possible labels such as "No Part", "Title-level" feel even more confusing for patrons. Is there a better option?

Does the "All/Any Parts" option behave differently in other networks?

[Terran McCanna (tmccanna)]

"All Parts" selects from anything that does not have a part label, but it is still going to select one of those items without a part label randomly, so I think "Any Part" is still much more accurate than "All Parts."

As a patron, if I really didn't care what I got, then "Any Part" would make sense to me. If I saw "All Parts" then I would think that I would literally have holds placed on all of the different parts that are available.

[Elaine Hardy (ehardy)]

We do see that when "All parts" is chosen, a title hold is placed. I am also pretty certain only the items without a part label will fulfill the hold since the number of potential copies matches the number of potential items with no designation.

I think that using "all parts" here implies that a hold will be placed on each part. So if there are 4 volumes on the record, the hold would be for volumes 1,2,3, and 4. Rather than what the targeter does -- pick a random item. Since I thought I was getting all parts, I would be a little upset when I only got one.

I prefer any part because it implies a random part so I know up front I will have one item coming and it might be vol.1 it might be vol.3. (what I don't know, of course, is that if only vol.3 isn't labelled, that's what I get).

"Any undesignated part" would be more descriptive but no less confusing for patrons.

[John Amundson (jamundson)]

My opinion stands that "Any Part" is misleading. "All/Any Parts" only appears on the Place Hold screen when there is at least one item without a part on the record. If every item on the record has a part, then that option won't even appear.

Here are some examples that can exist in our system. I don't feel like this are uncommon for others.

There is a record for a 6 volume set of books. 3 libraires part out each volume separately. 2 libraries circulate the set as a whole and therefore do not have part labels. If a patron places a "Any Part" hold, they will receive the full 6 volume set at pickup, which could be confusing to the patron who just wanted a "random" volume of the set to complete their paper.

There is another record for Season 1 of a TV show. A small handful of libraries part out the discs. DISCS 1-3, DISCS 5-7. Most libraries circulate it as the full season. The patron does not want to watch the the second half of the season first, so they don't risk placing an "Any Part" hold. Instead they place a hold on DISCS 1-3 and limit themselves to the number of available copies. They also have to place a second hold to get the remaining discs.

There is a record for the combo DVD/Blu-Ray pack for a movie. 99 libraries catalog the item as a combo pack with no part. 1 library separates the discs into parts: DVD, Blu-Ray. The majority of patrons in this example do not have a blu-ray player, so they place a hold on "DVD" on the chance that "Any Part" brings back a blu-ray. Patrons now have to wait longer for an item that is actually sitting on the shelf at 99 libraires.

There are definitely cases in our catalog where an item is not cataloged properly and a library forgets to add a part. In those cases, yes, a title-level hold is a grab bag for the patron, and "any part" may fill it. Those are cataloging mistakes, though, and I don't think it makes sense for the label to cater to them.

Could "Complete Set" or something like that be a better alternative?

[Michele Morgan (mmorgan)]

I think that both labels "All Parts" and "Any Part" could be interpreted differently by different patrons.

Some time ago, after much discussion, we customized the label to read "Complete Set". This is generally accurate in our consortium since our libraries either split up sets into parts or circulate the whole set together. Any item without a part is understood to represent the entire work described by the bib record.

Just throwing that out there as another possible option.

[Elaine Hardy (ehardy)]

I think I see the underlying issues here that are due to how we have implemented parts.

PINES does not allow out of system holds on av materials. Because of that, we have only implemented part labels on print materials since there is no way to tell which system has which volume while placing the hold. PINES also doesn't dictate how libraries package items, so you can have a library that circulates a DVD set as a set, one that does each part individually, and others that package together several parts. Without a way to designate which library owns which volume, a patron could get their hold refused until they finally hit the volumes for their library.

When Evergreen was developed, holds on parts had not been developed (the old volume hold was supposed to be that. Long story around that I won't put here) Parts holds weren't developed for a number of years. PINES didn't implement it right away because of the logistics around assigning labels to everything in the database that needed them. We get them corrected as we can since implementation.

Generally, PINES libraries circulate multivol print works as individual vols and don't circulate as a set. However, I would require the library that did so to create a part label for that set that would indicate which parts were circulating together. (We have a controlled vocabulary for parts labels). We might have a library that didn't assign a label on any of their vols where everyone else did; but,they would be circulating them individually and not as a set. This also means that using "Complete set" wouldn't work for us either.

[Ken Cox (kenstir)]

As a long time patron, short time mobile app developer, "All Parts" scared me. I thought some poor page would have to fetch all 52 volumes of Naruto.

Once it was explained to me how title hold targeting actually worked, "Any Parts" made the most sense. I think it still does, unless your catalog is 100% clean and and all items either have part labels or really are complete sets.

But if your catalog is 100% clean, couldn't you also label your complete sets with a part label "Complete Set"?

[Joan Kranich (jkranich)]

I like 'But if your catalog is 100% clean'. We sure try hard, but.

We also use the Part field for magazine issues, which I know may be different than other sites, and things like travel books to note the year, for example Fodor's Italy. Complete Set would not be appropriate for those types of records.

As a patron, I do not want any part of a DVD collection and probably not any part of a magazine collection. Graphic novels may vary. It seems that All Parts or Any Part means to the system that the part is not identified. 'Other Part' may not be very clear either but it matches system behavior.

[Michele Morgan (mmorgan)]

Maybe the best solution for this would be to make the "All Parts" label a Library Setting. That way, each installation, and even each library, where appropriate, could specify the label that works best for their situation.

[Elaine Hardy (ehardy)]

+1

[John Amundson (jamundson)]

I like the idea of a library setting.

After yesterday's comments, I also wanted to offer another suggestion.

On our Place Hold screen, image attached, the Part Dropdown is accompanied by text: "Select a Part (Optional). I haven't used stock Evergreen in a while, so I do not know how much of this text or styling is custom, but what if similar text is used for the dropdown itself?

For example, update "All Parts" and "Any Parts" to "Select a Part (Optional)". This dropdown text will only appear when an item without a part is attached to the record, so the "optional" portion of the text will be accurate regardless of the status of the items on the record.

This is easy to understand for staff and patrons, and there's no direct implication that not choosing a part will result in a complete set or a random part.

Thoughts?

[Michele Morgan (mmorgan)]

See bug 1956254 as another argument against the label "Any Part".

I think we have come down to two options to resolve this:

  1. Make the label a library setting.

  2. Change the label to "Select a Part (Optional)"

[Ruth Frasur Davis (redavis)]

https://bugs.launchpad.net/evergreen/+bug/1965446 is related to this issue and points toward a library setting or library settings. I also do like Michele's 2nd option as a bit of a bandaid (at least for Evergreen Indiana).

[Andrea Neiman (aneiman)]

Equinox is working on this under contract with Evergreen Indiana.

[Jason Etheridge (phasefx)]

Top commit at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1902120-eparts-label

This feature creates a new table for localizable strings intended to be used in
UI's. This is not a replacement for the existing I18N system for templates,
but does allow developers to choose some strings to be more easily accessible
to staff/admins for dynamic localization. The string we're focused on here is
a replacement for the "All Parts" and "Any Part" label in various Place Hold
interfaces when monographic parts are an option. There is a UI for managing
such strings under Administration -> Server Administration -> I18N: Localized
UI Strings. An admin could change the "string" field directly, or use the
existing Apply Translation mechanism to customize the string for a specific
locale.

As a bonus feature, we also expose an alternate UI for handling entries for
said Translation mechanism. This can be found under Administration -> Server
Administration -> I18N: Localized Fieldmapper Strings.

These customizations are global to the Evergreen installation.

[Ruth Frasur Davis (redavis)]

I have tested this code and consent to signing off on it with my name, rfrasur, and email address, <email address hidden>.

[Michele Morgan (mmorgan)]

I think this is a great idea, but I'm seeing a few issues with this patch.

- It changes existing behavior in the tpac and bpac to use "Any part", there were many arguments against that change. Retaining the "All Parts" label with the option to change it would be less disruptive.

- I was pleased to see that permission was required to change the label via the interface in the client, but I found that, logged in as a staff user without that permission, I was able to choose the entry, select Edit and make changes in the modal. When I clicked Save, the toast indicated the update was successful, but the change was not applied. The toast should indicate failure in this case.

- I also found that (with permission) I was able to delete the entry for the Any Part label via the client interface. Once deleted, the option shows as blank in all catalogs. It's also not possible to restore the row for the preferred label via the client since adding a new row would get a different database id and the pm is specifically looking for the database id of 1.

Adding a needswork tag.

[Andrea Neiman (aneiman)]

Hi Michele - thanks for testing.

The new UI Jason refers to in his comment allows you to change the labelling to whatever you wish - "all parts" "any parts" or something else altogether.

We will look into the success toast issue as well as protecting against deletion.

[Andrea Neiman (aneiman)]

To assist other testing, here's an excerpt from the notes I wrote up for our test partner, ECDI:

The new interface at Administration → Server Administration -> I18N: Localized UI Strings currently has an entry for “Any Parts” which will apply in the interface where a parts selection is available on the record. This can be changed to “All Parts” (or any other text you want) to show the customization mechanism. You will need to reload the place holds interface(s) to see the string update, but it shouldn’t require autogen or any other server mechanism to display.

The test server only has the Parts labeling available. With further development (or custom local development), this interface could be used to customize labels for other interfaces.

To edit a String Configuration, double click on the row of the string. The modal has the following fields:

Context - this describes the context of the string. It is free text.
ID - this is a system-assigned ID number and is not editable.
String - enter the value you want displayed in the interface.

[Michele Morgan (mmorgan)]

Hi Andrea, thanks for the feedack!

Yes, the UI makes it easy for users with permission to change the label to whatever they wish and the change is essentially instantaneous. That is awesome! My concern was that changing the existing public facing "All Parts" label to "Any Part" as the default would force sites for which "All Parts" worked fine, to change it. Retaining "All Parts" as the default would mean that only sites for which the label is an issue would need to change it.

I do think the ability to delete the entry is a serious concern as access to the database or a change in the code is required to recover from that.

I'm happy to hear other feedback!

[Andrea Neiman (aneiman)]

Ah, I misunderstood your concern about the default labelling! I got it now :) I'll add that to the list.

[Jennifer Weston (jweston)]

Tested on https://bugsquash.mobiusconsortium.org/eg/staff

Loving the option to change the label! However, I confirmed that the issues raised by Michele in comments #18 and #21 are still present:

1. Default value for the new localized string is "Any Part" so any library already using "All Parts" with their current documented workflow would be forced to change the new default setting back to "All Parts" to continue with their existing practices. Setting the default to "All Parts" to match current functionality would be preferable.

2. The false impression that a staff account without permission can change a part is a known thing (I just tested again in 3.9). Save is allowed but no change is made. The toast should indicate failure in this case -- but this is not a new behavior related to custom part labels.

3. I did not test the ability to delete the entry for the Any Part label via the client interface because I did not want to break the test server but +1 to protecting against deletion that would wreak havoc

[Mike Rylander (mrylander)]

I've pushed a commit to Jason's collab branch that:
 1) changes the seed data default value to "All Parts" so current behavior is the default for new installations and upgrades, and adjusts the context information a little to be more generic/descriptive
 2) provides a code-level default value for both OPAC and staff, in case the seed value is accidentally deleted

[Michele Morgan (mmorgan)]

Thanks for the patch Mike. This does address the default label, but the ability to delete the localized strings via the interface with no way to recover them remains a concern.

A band-aid would be to prevent deletion of entries in the I18N: Localized UI Strings interface. A more far reaching approach could be to link to the localized strings by referencing a list of codes with associated descriptions, rather than a static database id.

[Mike Rylander (mrylander)]

I've added an additional commit the the collab branch which prevents the possibility of deleting rows from the new translatable strings table. The UI will still let you attempt to delete a row from the table, but because the IDL doesn't have a delete action, pcrud won't know how to do that.

This will be an exceedingly rarely-used interface, so while a custom admin UI would allow us to address that, it seems like a followup wishlist item rather than a blocking bug, IMO.

Thanks, all!

[Jason Etheridge (phasefx)]

I force-pushed a rebased version of the branch with just a few more tweaks. Thanks!

[Jason Boyer (jboyer)]

After finally taking the time to look more in-depth at how this feature works and asking a colleague for additional opinions, I've got a list of issues that will need to be addressed before this patch can make it in to main.

1. The seed data isn't tagged for i18n (oils_i18n_gettext) so pre-translations can't be made available as part of a release.

2. The table backing this feature should have its sequence bumped to a remarkably high number, 100000 or more. Should admins want to use it for local strings they can, and a delete trigger can be added to deny the deletion of any id in the "system" range. (If the id field isn't entirely dropped, depending on how the third point may be implemented.)
That PCRUD can blanket-prevent deletes is functional for protecting system entries but it's not sufficient if users are able to add new entries to this table; they need to be able to remove their own additions. (I noticed that the sequence has been bumped in a recent patch, but because some strings can be quite small we should probably give more space than usual.)

3. Magic numbers like this in code a not a good practice at all. In an instance like this the original English string would be the ideal key. I would also like to see some kind of code context (separate from "translator's context") added so that you can tell in the code why 'All Parts' on the place hold screen might be a separate entry from 'all parts' used elsewhere for a different purpose, even in the same language. This could take the form of another text field used similarly to the grp field in org unit settings, or something similar. Not for end users or translators, but to help the ui distinguish otherwise similar strings. Using the original / default English text as the key also makes it significantly easier to write the user's context in the db.
Also, using the English text as the key allows an easy fallback should there be a problem with the database table, or could perhaps allow entries to be deleted and re-added without concern for their id number. In this instance a thin wrapper-api could simply return the text key it was given if there's nothing in the db for that key.

3.5. Adding some thin wrappers to ctx in the BPAC or a simple core service in Angular could allow easier usage for developers going forward, such as [% ctx.get_custom_i18n('opac_place_hold', 'All Parts') %] or <eg-custom-i18n-string context='opac_place_hold'>All Parts</eg-custom-i18n-string> or similar. This likely wouldn't be required to be added to main but something along these lines is necessary long-term to ensure that the feature is easy enough to be used and used correctly in the future.

[Jason Etheridge (phasefx)]

I've pushed a rebased and tweaked branch at working/collab/phasefx/lp1902120-eparts-label2
with the top 5 commits being the pertinent ones.

This fixes the seed data with oils_18n_gettext, and adds utility methods for both the OPAC ctx environment and Angular in the staff client. We're sticking with surrogate keys; there are pros and cons for going either way, but this is the consensus. Deletion through the UI is still disabled, but given that the only staff-intended function is editing strings, this seems acceptable.

[Ruth Frasur Davis (redavis)]

When testing this in the OPAC, it is very glitchy. I logged in as Leon Anderson to place a hold on Bib ID 210. In the staff catalog, the part I applied and the updated UI string appeared as expected. In the OPAC, when clicking on "Place Hold" from the record results page, the "select a part" field only shows the part label, but not the UI string (not ANY UI string). If I go into the record, and select "place hold," again the UI string doesn't appear in the part dropdown. If I REFRESH this screen, the UI string appears.

[Andrea Neiman (aneiman)]

removing pullrequest pursuant to comment #30 - this might be a caching issue but it won't get enough testing prior to 3.12 freeze

[Jason Etheridge (phasefx)]

I've pushed a rebased version of the branch to collab/phasefx/lp1902120-eparts-label2-rebased, but I'm not able to reproduce the behavior with concerto bibs 53 and 84. Bib 210 doesn't have parts in stock concerto. In the staff client for that one, I get N/A in the Part column.

[Blake GH (bmagic)]

I've loaded this patch onto our bugsquash machine:

https://bugsquash.mobiusconsortium.org

admin/demo123

Please test!

[Terran McCanna (tmccanna)]

It doesn't make any sense to me that you can create new entries through this interface when they will not serve any purpose - particularly, since you can't delete them.

It would make more sense to remove both of those options.

[Andrea Neiman (aneiman)]

Terran, our original idea was to have this interface be able to be leveraged for future label changes.

However, at present this is only covers the Parts label - so, in light of your comment, would you prefer to see this interface:

1) ONLY allow creation of a single label; and
2) Specify that this is (right now) just for Parts?

[Terran McCanna (tmccanna)]

Andrea - for future label changes a developer would still need to modify the Angular code for a given label in order for that label to be customizable in the interface, right? If that is correct, then it would make more sense to me for the patch that modified the Angular to also include seed data for the new entry rather than for the administrator to have to create it in the interface.

Or am I looking at the problem upside down and backwards?

[Jason Etheridge (phasefx)]

Terran, I agree for now. That might change in the future, but it's a simple change to reinstate later. One could almost get away with just using the i18n core interface for this string feature, but there's still benefit for being able to change the actual value outside of locale, and this makes them easier to find.

Here's a new branch affecting that change as well as being freshly rebased against main:
collab/phasefx/lp1902120-eparts-label2-rebased2

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1902120-eparts-label2-rebased2

[Jason Etheridge (phasefx)]

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1902120-eparts-label2-rebased3

For a minor rebase

[Blake GH (bmagic)]

All,

Thanks Jason for the quick rebase! It's merging clean now on main. Stephanie and I spent about an hour clicking through the interfaces:

1. The eg2/en-US/staff/admin/local/config/i18n_string interface indicates that you might be able to create a new entry but the button is greyed out. We found that the permission to do so was* in the IDL but removed in a later commit. Which is by design now, we don't want people to make entries in there using the UI. Turns out, it's a bug with all auto-generated IDL interfaces. That can be addressed in a different LP bug discussion.

2. I ended up learning "the hard way" that the core interface: eg2/en-US/staff/admin/local/config/i18n_core will get entries created in it when the "Apply Translations" button is pressed on the i18n_string interface. But also* you can create new core entries at will. Knowing what goes into a new core entry is a complete mystery. Using deduction, we figured out that one of the fields needed to contain a string that is found in config.i18m_locale ("en_US" for example). I would say that if those are the only values that can be entered into that field, it should be a combobox to the foreign key.

3. I'm presently confused about this feature. I think Stephanie was too. We want the label for "Any Part" to be whatever we want. This feature is setting up a foundation for changing strings, theoretically anywhere. Looking at how the one use case (Any Part) is brought to the OPAC, I see that it's hard coded to ID number 1. this.pcrud.retrieve('i18ns', 1)

So, if we wanted to utilize this feature in other places, it would seem we'd need to hard code the ID numbers from that table to the interfaces.

The included documentation didn't give me enough information for me not to be confused. Part of the confusion is the back-end core interface. IMO that interface just needs to be removed until it's more fleshed out. In order for a new string to override the old string, I figured out by trial and error that I needed to click on "Apply Translations"

I like the idea of being able to change certain key phrases around different interfaces to be more easily customizable. But, since code is required to call out a specific ID number, the strings that are included in the table would need to come with accompanying UI code. I could see moving forward that we would add more and more rows into the strings table as more and more strings are identified as wanting to be changed with this mechanism.

I think we need:

* Remove the core table editor from Server Administration
* Better documentation: 1) explain that UI code changes are needed to replace a string in any given interface. 2) "Apply Translations" is the button that does the work.
* Words about why we're starting this feature, and ideas for other places in the UI we could use it.

[Jason Etheridge (phasefx)]

Thanks Blake. Let's step through my thinking:

* The main impetus behind the feature is to make the All Parts label configurable through the staff client, and it only needs to work globally. It is currently customizable, but only through template changes.
* So we need some staff interface for that configuration.
* With existing infrastructure, there are a few options for implementing this: library settings, global flags, and A/T.
* Library settings would be a nice fit (see Courier Code as an example), except that values you provide for a free-text setting are not localizable.
* The value field for global flags has the same problem.
* Applying our translation infrastructure to free-text is a no-go.
* So, we need new infrastructure, and to leverage the existing staff-facing translation infrastructure, we need for the label itself (not a variable or placeholder for it) to exist in the database and be accessible through the IDL.
* Thus, I just made a new table for it. In library-speak, the string is a controlled or authorized value.
* The UI can retrieve it via its hard-coded ID through an API call.
* We get a free admin interface for it by leveraging routing and the BasicAdminComponent.
* By default, such interfaces expose actions like New and Delete. But these are still controlled by permissions. It's a matter of philosophy on whether such actions should be hidden or disabled (or prompt for new authorization) when permissions are lacking, not a bug per se. A larger bug is that we don't have a design philosophy and style guide for development.
* Originally, I thought the feature might be useful for non-stock development or local customizations, so I didn't mind enabling the New action via permission, and simply reserved a range of IDs for stock Evergreen, and bumped the sequence. Terran had a good argument for talking me out of it, though perhaps we should keep it configured for pcrud in the IDL, but just create a new permission for it.
* This does feel like overkill for a single label, but infrastructure-wise, it's kind of the way to go. From the UI-side, we could make a "dedicated interface" for it, but BasicAdminComponent seems like a better idea if the feature does get more use in the future. I can imagine a lot more of the I18N work moving to the database.
* Being an infrequently used interface, it doesn't need a lot of polish, though the BasicAdminComponent does give a minimum level of polish.

For the "bonus" admin interface for the I18N core interface, it's another BasicAdminPage freebie, and while not useful for creating new entries whole-cloth, it is useful for seeing and modifying all existing translations at a glance. I don't see the harm in having it, and see some benefit. It's only tangentially related to the All Parts label feature.