Bug 39057

Summary: Add additional fields common to all ILL requests
Product: Koha Reporter: Mathieu Saby <mathsabypro>
Component: ILLAssignee: 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
There is currently a kind of additional fields for ILL request, but it can be different for each request. This is not the behavior we have elsewhere in Koha.

A library should have the ability to define additional fields in /admin/additional-fields.pl with the same options as ERM additional fields (searchable or not, repeatable, linked to a authorized value...)
Comment 1 Pedro Amorim 2025-02-13 14:33:08 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.
Comment 2 Mathieu Saby 2025-02-13 15:56:39 UTC
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?
Comment 3 Pedro Amorim 2025-02-13 16:30:27 UTC
(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.
Comment 4 Mathieu Saby 2025-02-13 16:57:27 UTC
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.
Comment 5 Pedro Amorim 2025-02-13 17:16:50 UTC
(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.
Comment 6 Mathieu Saby 2025-03-06 15:51:27 UTC
New remark : some additional fields could only be visible in the request detail, other in the table with all requests.
Comment 7 Lisette Scheer 2025-03-13 16:20:11 UTC
(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"?
Comment 8 Katrin Fischer 2025-03-13 16:22:59 UTC
(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?