Bug 29059 - Keep non-repeatable attribute from patron to preserve
Summary: Keep non-repeatable attribute from patron to preserve
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement with 10 votes (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 28217
Blocks:
  Show dependency treegraph
 
Reported: 2021-09-20 14:57 UTC by Jonathan Druart
Modified: 2022-12-12 21:24 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
22.05.00


Attachments
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging (4.17 KB, patch)
2021-09-20 15:01 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging (4.24 KB, patch)
2022-02-25 15:59 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging (4.24 KB, patch)
2022-03-29 17:41 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2021-09-20 14:57:44 UTC
See bug 21648 comment 17.

Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error.
Comment 1 Jonathan Druart 2021-09-20 15:01:33 UTC
Created attachment 125070 [details] [review]
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging

See bug 21648 comment 17.

Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error.

A side-effect will be that when several patrons are merged, the
non-repeatable attribute from the first one will be kept, which can
result in unexpected result if the original patron does not have the
attribute defined.
Comment 2 Christopher Brannon 2021-09-20 15:21:23 UTC
It would be preferable if we are given the setting in both and could choose which to use.

Also, it is more likely that the more recent record will have up-to-date information.  Keeping the first one is not necessarily the best option.  But it would be preferred to review the different entries and select the correct one.
Comment 3 Jonathan Druart 2021-09-20 15:36:16 UTC
Then we need the full UI suggested by bug 21648 and this bug report can be closed.
Comment 4 Andrew Fuerste-Henry 2022-02-25 15:59:27 UTC
Created attachment 131126 [details] [review]
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging

See bug 21648 comment 17.

Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error.

A side-effect will be that when several patrons are merged, the
non-repeatable attribute from the first one will be kept, which can
result in unexpected result if the original patron does not have the
attribute defined.

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Comment 5 Andrew Fuerste-Henry 2022-02-25 16:01:40 UTC
Thanks, Jonathan! The enhancement in bug 21648 would be great, but this is a perfectly workable solution for the time-being!
Comment 6 Nick Clemens 2022-03-29 17:41:50 UTC
Created attachment 132485 [details] [review]
Bug 29059: Keep non-repeatable attribute from patron to preserve when merging

See bug 21648 comment 17.

Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error.

A side-effect will be that when several patrons are merged, the
non-repeatable attribute from the first one will be kept, which can
result in unexpected result if the original patron does not have the
attribute defined.

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Comment 7 Fridolin Somers 2022-04-08 13:52:44 UTC
Pushed to master for 22.05, thanks to everybody involved 🦄