Bug 40420 - Add Patron API call should respect mandatory borrower fields
Summary: Add Patron API call should respect mandatory borrower fields
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-07-16 17:07 UTC by Andrew Fuerste-Henry
Modified: 2025-07-17 12:03 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2025-07-16 17:07:34 UTC
When creating a patron via the API, the call will fail when missing the values required by the API itself (surname, library, category) and if it's missing a patron attribute that's marked as mandatory for the staff interface (see bug 40220).

However, the API call succeeds and makes a patron when missing values defined as mandatory in either BorrowerMandatoryField or PatronSelfRegistrationBorrowerMandatoryField. 

To recreate:
1: set BorrowerMandatoryField to include surname, library, category and anything else. I used phonepro (secondary phone)
2: use Postman or similar to add a patron, sending only surname, library, and category
3: confirm your patron is created without the required secondary phone (or whatever you used)
4: set PatronSelfRegistrationBorrowerMandatoryField to match BorrowerMandatoryField
5: repeat steps 2 and 3

Following discussion on other bugs, I think we have an open question whether this should follow BorrowerMandatoryField or PatronSelfRegistrationBorrowerMandatoryField or a new third option of APIBorrowerMandatoryField. But it should follow something.
Comment 1 Christopher Brannon 2025-07-16 19:28:21 UTC
Just to reiterate from the other bug, I don't know if this can be solved with a single switch.  I could see the possibility of a mandatory setting for API in some situations and not others.  It depends on its application.  And having a single switch for something like this would lock it into one behavior and not make it usable for others.  I know that there are attributes we don't want the patron to set when it comes to self registration, but we want staff to be able to do that.  It makes sense to have this attribute set with a not mandatory setting if it is being addressed with self registration (adding a patron) through API.  But what if we have some other 3rd party software creating patrons from a staff aspect, and they need to set that attribute?  I don't even know if that exists, but we should approach this from both aspects, I think.
Comment 2 Christopher Brannon 2025-07-16 19:28:33 UTC
Just to reiterate from the other bug, I don't know if this can be solved with a single switch.  I could see the possibility of a mandatory setting for API in some situations and not others.  It depends on its application.  And having a single switch for something like this would lock it into one behavior and not make it usable for others.  I know that there are attributes we don't want the patron to set when it comes to self registration, but we want staff to be able to do that.  It makes sense to have this attribute set with a not mandatory setting if it is being addressed with self registration (adding a patron) through API.  But what if we have some other 3rd party software creating patrons from a staff aspect, and they need to set that attribute?  I don't even know if that exists, but we should approach this from both aspects, I think.
Comment 3 Andrew Fuerste-Henry 2025-07-17 12:02:57 UTC
(In reply to Christopher Brannon from comment #2)
> Just to reiterate from the other bug, I don't know if this can be solved
> with a single switch.  I could see the possibility of a mandatory setting
> for API in some situations and not others.  

Fair. Following that logic, we could add an option to the API call that allows one to specify whether this call should be treated as an OPAC action or a staff interface action. Then individual integrations could specify why permission/rules/configuration they want to be subject to.
Comment 4 Andrew Fuerste-Henry 2025-07-17 12:03:57 UTC
(In reply to Andrew Fuerste-Henry from comment #3)
> (In reply to Christopher Brannon from comment #2)
> > Just to reiterate from the other bug, I don't know if this can be solved
> > with a single switch.  I could see the possibility of a mandatory setting
> > for API in some situations and not others.  
> 
> Fair. Following that logic, we could add an option to the API call that
> allows one to specify whether this call should be treated as an OPAC action
> or a staff interface action. Then individual integrations could specify why
> permission/rules/configuration they want to be subject to.

Heh, essentially what you said in your comment on Bug 40220 that I hadn't read yet :)