Summary: | Add additional fields common to all ILL requests | ||
---|---|---|---|
Product: | Koha | Reporter: | Mathieu Saby <mathsabypro> |
Component: | ILL | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | lisette, pedro.amorim, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Mathieu Saby
2025-02-06 18:37:47 UTC
The ILL requests additional fields (usually refered to as ILL request attributes or illrequestattributes) is similar to, but not exactly the same as, the additional fields implemented specifically for other supporting tables. I believe ILL request attributes were designed the way they are because different ILL backends may require different attributes and there is no way for Koha core to know or consider all of those. Whereas for additional fields, these are specifically configured on the Staff UI, and only those are will be considered/displayed on their respective forms. My understanding of the original design is that it was meant to consider this possibility (any arbitrary key->value pair), and each backend would implement its own create form, listing whatever specific attributes it may need. I'm not saying there isn't work to be done here, I want only to clarify that additional fields and ILL request attributes are sadly not exactly a 1:1. Thank you for the explanation. So if I read you well, currently if we want to add new fields systematically visible in request forms, and visible for staff in the monitoring table, the solution would be to write a specific back end? (In reply to Mathieu Saby from comment #2) > Thank you for the explanation. > > So if I read you well, currently if we want to add new fields systematically > visible in request forms, and visible for staff in the monitoring table, the > solution would be to write a specific back end? There are different options. Writing a specific backend may be overkill just to have different additional fields in the form. What backend are we referring to here? If it's the Standard backend currently in core, you can: 1) Have a patch to add new static fields in core Standard, if these are common fields that are currently missing. 2) Use jQuery to add static field inputs to the form. These will then be submitted and added as any other illrequestattribute when the form is submitted. I was thinking of fields useful in a French context, so for most of them probably non integrable in the main code of Koha. But rather than asking a vendor to write a very specific patch for such and such field, my idea was a more generic way to do it, by giving the library the ability to define its own supplementary fields, like we can do in other parts of Koha. (In reply to Mathieu Saby from comment #4) > But rather than asking a vendor to write a very specific patch for such and > such field, my idea was a more generic way to do it, by giving the library > the ability to define its own supplementary fields, like we can do in other > parts of Koha. I can definitely see how additional fields applied to ILL requests in this way makes sense. May be tricky how this interacts with illrequestattributes (or not), but definitely doable and valuable. New remark : some additional fields could only be visible in the request detail, other in the table with all requests. (In reply to Pedro Amorim from comment #5) > I can definitely see how additional fields applied to ILL requests in this > way makes sense. May be tricky how this interacts with illrequestattributes > (or not), but definitely doable and valuable. Could we set up a plugin hook so a plugin could add it's illrequestattributes to the additional fields and/or set it so the additionalfields basically creates new illrequestattribute type="additionalfieldcode"? (In reply to Lisette Scheer from comment #7) > (In reply to Pedro Amorim from comment #5) > > > I can definitely see how additional fields applied to ILL requests in this > > way makes sense. May be tricky how this interacts with illrequestattributes > > (or not), but definitely doable and valuable. > > Could we set up a plugin hook so a plugin could add it's > illrequestattributes to the additional fields and/or set it so the > additionalfields basically creates new illrequestattribute > type="additionalfieldcode"? I think we should actually "replace" one with the other in a way... not sure how feasable that is. The mechanism for adding illrequestattributes in the OPAC request form and in the ILL module is clumsy at best and not suitable for end users. We definitely need a way for the plugins to be able to define fields with labels and other criteria like the additional fields do. Maybe a way to link additional fields with corresponding illrequestattributes and only use those for the forms? |