[Bug 40420] New: Add Patron API call should respect mandatory borrower fields
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40420 Bug ID: 40420 Summary: Add Patron API call should respect mandatory borrower fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: tomascohen@gmail.com 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. -- 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=40420 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #1 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- 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=40420 --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- 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=40420 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- (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. -- 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=40420 --- Comment #4 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- (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 :) -- 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=40420 Eric Phetteplace <ephetteplace@cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ephetteplace@cca.edu -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org