https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633
Emily Lamancusa (emlam) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #106 from Emily Lamancusa (emlam) <[email protected]> --- Testing notes: after applying patch and running updatedatabase, also need to run yarn build, then restart_all The test plan works and sorting works as expected, both in auto-complete and in the results table, including with patrons that were added using Koha's patron import tool. However, there is one blocker for me with this version - I think the way the feature is functionally enabled/disabled based on the collective settings of all 3 of the Unwanted prefs is going to be very confusing to users. It is especially an issue that adding preferred_name to all 3 Unwanted prefs will cause existing preferred_name data to be overwritten piecemeal, as patrons happen to get edited for any reason, without warning that this will happen. At the very least, there needs to be a clear warning in the description of each of the Unwanted prefs stating that if preferred_name is marked unwanted in all 3, that existing preferred_name data will be overwritten as patrons are edited. Personally, I think the best solution would be for the first name to overwrite the preferred_name if and only if (preferred_name eq firstname or preferred_name is empty), regardless of how the Unwanted prefs are set. As far as I know, all other fields retain their data unless explicitly deleted, even if they're fully hidden, so I think that behavior would be fine in this case, too. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
