This bug serves to add a new add_restriction method to the Koha::Patron class and then replace all occurences of AddDebarment with said method before finally removing the AddDebarment method from Koha::Patron::Debarment.
Created attachment 139764 [details] [review] Bug 31458: Add add_restriction to Koha::Patron This patch adds the beggnings of an add_restriction method to Koha::Patron.
Created attachment 139799 [details] [review] Bug 31458: Add add_restriction to Koha::Patron This patch adds the beggnings of an add_restriction method to Koha::Patron.
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.
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] [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.
What is the status of this bug?
'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
Must admit.. I'd also be more motivated to continue if the dependant bug was moving ;P.. Bug 31095 seems to have stalled waiting for someone to test.
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?
(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.
We might need to put a warning again in any reports using these fields so people can see that they need to fix on update (I think we did this before with biblio_metadata)? Also: will the patron import change? People possibly rely on being able to set debarments on import.