https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |31457 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31457 [Bug 31457] Move Koha::Patron::Debarment into Koha::Object based classes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #1 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 139764 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139764&action=edit Bug 31458: Add add_restriction to Koha::Patron This patch adds the beggnings of an add_restriction method to Koha::Patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #3 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 139800 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139800&action=edit Add _update_patron_restriction_fields This still needs some work.. picking which of the two constructs for ordering works and removing new lines from the debarredcomment field. Do we even need the local debarredcomment field any more... and should the debarred field just become a boolean.. or should we just drop the fields from the borrowers table entirely and rely on relations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- I believe we've discussed this elsewhere, but just to make sure it's public; The field borrowers.debarred was retained so that existing code utilizing the debarred field would continue to work. In practice, sometimes that field gets out of sync with the actual debarments. At this point in time, it makes a lot more sense to remove borrowers.debarred from the database. I think the same can be said for debarredcomment as well. (In reply to Martin Renvoize from comment #3)

Created attachment 139800 [details] [review] Add _update_patron_restriction_fields

This still needs some work.. picking which of the two constructs for ordering works and removing new lines from the debarredcomment field.

Do we even need the local debarredcomment field any more... and should the debarred field just become a boolean.. or should we just drop the fields from the borrowers table entirely and rely on relations.

-- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- 'Still on my list' is the status ;P I need to swing back around to it soon, but have had other priorities the last couple of weeks :S -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #8 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- OK, So Kyle suggests we can/should remove the debarred and debarredcomment fields from the borrowers table. We do however return a restricted boolean field in the current API.. I think it makes a fair bit of sense to continue to return this piece of primary information about the borrower there.. but it opens up the question.. should we actually remove the field from the table now and thus require a join for API queries or should I go ahead of convert the current date field to a proper boolean that's maintained by add_restriction and friends? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 --- Comment #9 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Martin Renvoize from comment #8)

OK, So Kyle suggests we can/should remove the debarred and debarredcomment fields from the borrowers table.

We do however return a restricted boolean field in the current API.. I think it makes a fair bit of sense to continue to return this piece of primary information about the borrower there.. but it opens up the question.. should we actually remove the field from the table now and thus require a join for API queries or should I go ahead of convert the current date field to a proper boolean that's maintained by add_restriction and friends?

I did it a boolean so we can remove those heh. The idea is that we would just embed the restriction objects, each of which should include its own information. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31458 Bug 31458 depends on bug 31095, which changed state. Bug 31095 Summary: Remove Koha::Patron::Debarment::GetDebarments and use $patron->restrictions in preference https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31095 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.