Summary: | API Incorrectly Requires Mandatory Extended Attributes Not Visible in OPAC | ||
---|---|---|---|
Product: | Koha | Reporter: | Leo Stoyanov <leo.stoyanov> |
Component: | REST API | Assignee: | Leo Stoyanov <leo.stoyanov> |
Status: | Failed QA --- | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | andrew, cbrannon, george, nick, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35635 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40420 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 40219 | ||
Bug Blocks: | |||
Attachments: | Bug 40220: Added Consderation of API Interface for Mandatory Extended Attributes |
Description
Leo Stoyanov
2025-06-23 14:21:37 UTC
Created attachment 183422 [details] [review] Bug 40220: Added Consderation of API Interface for Mandatory Extended Attributes Test Plan: 1. Create an extended borrower attribute with: mandatory = 1 (checked), opac_display = 1, and opac_editable = 0 (unchecked - not editable in OPAC). 2. Setup your Postman, or any other mock API software, to obtain an OAuth token (/api/v1/oauth/token) and to register a patron (/api/v1/patrons). 3. With the OAuth token, send a POST request to /api/v1/patrons with valid patron data and missing mandatory extended attribute data. 4. Observe the API response wtih the 400 error. Despite this attribute not being required in the OPAC, the API requires it. 5. Apply the patch and repeat step 3. Observe the API response with the patron data returend, indicating the patron has been created. After bug 35635 attributes may be made mandatory/not in the intranet and OPAC distinctly and an attribute cannot be mandatory via the OPAC without being visible via the OPAC. However, bug 35635 explicitly makes the API follow staff client requirements rather than OPAC requirements. We're generally moving toward making the API align with the OPAC for patron actions. Following that logic, should we switch the API to following the OPAC mandatory value on attributes? Or should attributes also have an "API Mandatory" value? Because API can be used for both staff and public uses, it seems that we absolutely need some way of indicating on the remote end what the end use is for. We could have an API setting in the attributes, but that would lock it into only one behavior. I'm thinking that maybe, so as not to have to duplicate all get functionality for public or staff, that there needs to be some indicator in the request that specifies end use (public/staff). But would that be too easy to circumvent? |