Tags - Central Management
(UXPROD-775)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | TBD | Parent: | Tags - Central Management |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Ann-Marie Breaux (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | LC4, chalmers, loc, round_iv, tags, tags-phase_2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||
| Release: | Not Scheduled | ||||||||||||||||||||
| Epic Link: | Tags - Central Management | ||||||||||||||||||||
| Analysis Estimate: | Medium < 5 days | ||||||||||||||||||||
| Analysis Estimator: | Ann-Marie Breaux (Inactive) | ||||||||||||||||||||
| Front End Estimate: | XL < 15 days | ||||||||||||||||||||
| Front End Estimator: | Zak Burke | ||||||||||||||||||||
| Back End Estimate: | XXL < 30 days | ||||||||||||||||||||
| Back End Estimator: | Jakub Skoczen | ||||||||||||||||||||
| Estimation Notes and Assumptions: | beside the first scenario this effectively calls for mass-edit operation on records, functionality we don't have. Estimate XXL, note "assumes and includes estimate for mass edit functionality in RMB and rolling it out across modules, assume but excludes module registration already included in UXPROD-654". Btw, I know there are other issues that call for mass-edit, but you don't need to know that. | ||||||||||||||||||||
| Development Team: | None | ||||||||||||||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 1 | ||||||||||||||||||||
| PO Rank: | 61 | ||||||||||||||||||||
| PO Ranking Note: | None of Tags-Central Management Epic marked po-mvp since only 1 library has ranked any issues as go-live | ||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R4 | ||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R4 | ||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R4 | ||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||
| Rank: hbz (TBD): | R2 | ||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R4 | ||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R2 | ||||||||||||||||||||
| Rank: Leipzig (ERM Aut 2019): | R2 | ||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R4 | ||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||||||||||||||
| Description |
|
Implement central tag management:
Functionality is similar to what Charlotte Whitt needs in
|
| Comments |
| Comment by Heikki Levanto [ 25/May/18 ] |
|
This all sounds pretty difficult, with the current design of the tag system. For the first, we would need to search all records with a given tag, no matter what type of record. At the moment the tag system does not even know which types of records use tags - New modules can be installed that use tags, and the tag module will not be aware that something like mod-meeting-rooms may use tags, and that it may need search there too. For the second, this kind of mass update may be slow, if we have millions of records with a given tag. IMHO this is not a "medium" thing |
| Comment by Ann-Marie Breaux (Inactive) [ 30/May/18 ] |
|
Hi Heikki Levanto Then should there be a central index when a tag is added to a record? Might that help? The individual apps are consulting the central tag list when a tag is added to a record, to see if it already exists or not, and to autosuggest. If a tag is added or deleted from a record, would it add much complexity if the individual app reported that action back to some sort of central index? My guess is that we won't end up with millions of records with a certain tag, but could possibly have hundreds or perhaps thousands. |
| Comment by Heikki Levanto [ 30/May/18 ] |
|
The central tag list could keep a list for each tag, listing all the modules that are using this tag. It would only need to be updated the first time a tag is assigned to a new kind of record. That would solve the easier part of the problem. The harder part is to mass-update all records that have a tag, and remove or replace the tag on all records. At the moment we do not have any mechanism for mass-updating records. Even "hundreds" of records will probably be too slow to do in one API call. The error handling poses interesting problems too: What if another user tries to mess with the same tags at the same time? Or even just adds a tag to some record while we are trying to remove all occurrences of that tag? Not saying that this is impossible, but it is complex, and needs serious extensions to the current design. |
| Comment by Marie Widigson [ 13/Sep/19 ] |
|
Having started to use tags on Agreements and eHoldings (a favorite FOLIO functionality!), and already having made several typos... the need to edit and possibly delete tags becomes very real. We have therefore changed the prio back to a quarter after go-live. If there is an simpler solution that makes it possible to edit/delete tags, that would be ok for us as a short term solution. Please let me know if there's another Jira that we should be aware of. The central list and reassigning parts are very nice but not as crucial. (We will probably mostly use tags for the ERM-related apps, not for Inventory or users.) Ann-Marie Breaux |
| Comment by Ann-Marie Breaux (Inactive) [ 13/Sep/19 ] |
|
Good to know, and I completely understand about the typos. Right now, there's not a lighter-weight solution for removing "bad" tags that should not be used. We could have a story as part of tags-basic management that said something like: When a tag has been removed from all records that were using it, and no longer is associated with any record, then automatically remove it from the central tag list, and do not display it in the tag dropdown list. Cate Boerema Khalilah Gambrell If we had a story like that, any chance that Spitfire or Core-fxn might be able to pick it up??? |
| Comment by Cate Boerema (Inactive) [ 16/Sep/19 ] |
This seems like a sensible solution. I am actually surprised it doesn't already work that way.
There is always a chance if the story is dev-ready and there are no other dev-ready MVP stories. I'd say get it ready and we'll go from there. |
| Comment by jackie.gottlieb@duke.edu (Inactive) [ 10/Nov/20 ] |
|
While Duke University is highly interested in the Tags feature, we have reduced our ranking due to the lack of functionality scoped in these Jiras. A global vision/strategic plan is needed that includes cross-discipline contributions. As written, tags would be fine for individual, adhoc use but not for tenant/group level mgmt. For Tags to be useful to Duke, it needs to have the following capabilities:
If full functionality is not going to be developed for Tags, then Duke will need to highly rank a jira for granular CRUD permissions (perhaps the intention of UXPROD- 258?). We will need to be able to limit/control use of Tags at our permissions sets level. We would like to see a collaborative conversation occur to assess the likelihood of a strategic plan being developed as part of this Jira story. |
| Comment by Ann-Marie Breaux (Inactive) [ 10/Nov/20 ] |
|
Hi jackie.gottlieb@duke.edu Thank you for your feedback. I believe that this central management feature will give Duke most of what they require, especially if you intend to lock down tags to a controlled vocabulary which most users can assign, but cannot create new tags. Depending on the library and their comfort level with uncontrolled vocabulary, these Tags-central management stories will allow for more or less control. The original vision was for tags to be uncontrolled, but based on requirements from other libraries in addition to Duke, these central management requirements have evolved to encompass that. And permissions for the central tag list will control which users have permission to create new tags, merge duplicate tags, and other tag management functionality. However given where this is ranked currently, I don't expect that this feature will be developed any time soon, even though I want it to be! |
| Comment by Erin Nettifee [ 17/Nov/20 ] |
|
Ann-Marie Breaux is
|
| Comment by Ann-Marie Breaux (Inactive) [ 21/Mar/23 ] |
|
Questions from Aly DesRochers about tags; adding LOC label so that this feature can be reviewed by LC. |