Bug 31458 - Remove Koha::Patron::Debarment::AddDebarment and use $patron->add_restriction in preference
Summary: Remove Koha::Patron::Debarment::AddDebarment and use $patron->add_restriction...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on: 31095
Blocks: 31457
  Show dependency treegraph
 
Reported: 2022-08-25 09:44 UTC by Martin Renvoize
Modified: 2024-04-22 11:18 UTC (History)
3 users (show)

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


Attachments
Bug 31458: Add add_restriction to Koha::Patron (1.74 KB, patch)
2022-08-25 11:14 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 31458: Add add_restriction to Koha::Patron (1.74 KB, patch)
2022-08-25 15:30 UTC, Martin Renvoize
Details | Diff | Splinter Review
Add _update_patron_restriction_fields (2.00 KB, patch)
2022-08-25 15:30 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2022-08-25 09:44:28 UTC
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.
Comment 1 Martin Renvoize 2022-08-25 11:14:11 UTC
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.
Comment 2 Martin Renvoize 2022-08-25 15:30:09 UTC
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.
Comment 3 Martin Renvoize 2022-08-25 15:30:13 UTC
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.
Comment 4 Kyle M Hall 2022-08-29 18:04:09 UTC
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.
Comment 5 Tomás Cohen Arazi 2022-09-15 14:36:38 UTC
What is the status of this bug?
Comment 6 Martin Renvoize 2022-09-15 15:28:26 UTC
'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
Comment 7 Martin Renvoize 2022-09-15 15:29:44 UTC
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.
Comment 8 Martin Renvoize 2023-01-04 11:38:24 UTC
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?
Comment 9 Tomás Cohen Arazi 2023-01-04 11:41:17 UTC
(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.
Comment 10 Katrin Fischer 2023-01-04 12:47:44 UTC
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.