Bug 20689

Summary: Improve usability of Item search fields administration page
Product: Koha Reporter: Patrick Robitaille <patrick.robitaille>
Component: SearchingAssignee: Katrin Fischer <katrin.fischer>
Status: CLOSED FIXED QA Contact: Martin Renvoize <martin.renvoize>
Severity: enhancement    
Priority: P5 - low CC: fridolin.somers, jonathan.druart, katrin.fischer, kyle, m.de.rooy, martin.renvoize, nick, severine.queune
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28892
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
22.05.00
Attachments: Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689 Follow - tiny typo fix
Bug 20689: (follow-up) Correct scope of template variables
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: (follow-up) Tiny typo fix
Bug 20689: (follow-up) Correct scope of template variables
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields
Bug 20689: (follow-up) Tiny typo fix
Bug 20689: (follow-up) Correct scope of template variables

Description Patrick Robitaille 2018-05-01 16:05:13 UTC
Hi, 

when you add a new subfield in a marc bibliographic framework and that subfield is not in the marc format normally, you can not add it as a item search fields. It would be useful to be able to use these new subfields for item search for exemple.

Thanks, Patrick.
Comment 1 Katrin Fischer 2018-05-01 16:23:22 UTC
Do you mean capital letter subfields?
Comment 2 Patrick Robitaille 2018-05-07 12:21:05 UTC
Hi Katrin, 

It is exactly what I mean. 

Thanks, Patrick.
Comment 3 Katrin Fischer 2018-08-09 23:12:28 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2018-09-27 22:13:37 UTC Comment hidden (obsolete)
Comment 5 Séverine Queune 2018-10-01 19:45:36 UTC Comment hidden (obsolete)
Comment 6 Séverine Queune 2018-10-01 19:47:03 UTC
Great enhancement Katrin !
Thanks a lot !
Comment 7 Katrin Fischer 2018-10-01 20:48:44 UTC
(In reply to Séverine Queune from comment #6)
> Great enhancement Katrin !
> Thanks a lot !

Thx for testing!
Comment 8 Jonathan Druart 2018-10-02 12:02:05 UTC
I may be a bad person but, ofc, I tried to find a bug. So I filled field="~" and subfield="€"
The search did not like it :)

I think we should keep the list of field/subfield exhaustive, and maybe add select2 to these 2 selects? Or at least add validation code to catch possible problems.

Note: You will need the patch I have just submitted on bug 13618 comment 261 to test it correctly.
Comment 9 Katrin Fischer 2018-10-02 14:05:08 UTC
We don't do this in the MARC frameworks and I think some odd characters would be allowed in the standard... I've thought about it and tried to implement an HTML filter, but didn't succeed. But we are not that strict in other places and I think a list with 999+ elements is not the solution :) As I said, we even fields with letters in our database.
Comment 10 Jonathan Druart 2018-10-02 14:54:10 UTC
So maybe just a JS check for \d | \w ?
Comment 11 Martin Renvoize 2018-10-12 15:06:06 UTC
Checking for digits and word characters as per Jonathans suggestion sounds sane to me... is there really a case out there where a field may contain another character outside that range?
Comment 12 Owen Leonard 2018-10-12 16:31:41 UTC Comment hidden (obsolete)
Comment 13 Katrin Fischer 2018-10-12 16:43:20 UTC Comment hidden (obsolete)
Comment 14 Marcel de Rooy 2018-10-12 16:59:43 UTC
Not sure if we should facilitate MARC deviation ?
Comment 15 Katrin Fischer 2018-10-12 17:02:51 UTC
We could also start supporting other ASCII characters like ;/% for subfield codes, that would give us more subfields for items to use - but it won't work right now and the upper case letter use is a reality not only for us but other libraries too (see Severine's comment).
Comment 16 Martin Renvoize 2018-10-17 14:05:13 UTC Comment hidden (obsolete)
Comment 17 Martin Renvoize 2018-10-17 14:05:18 UTC Comment hidden (obsolete)
Comment 18 Martin Renvoize 2018-10-17 14:06:24 UTC
(In reply to Marcel de Rooy from comment #14)
> Not sure if we should facilitate MARC deviation ?

I don't think this is too terrible a deviation, especially as it appears to already be widely in use.
Comment 19 Martin Renvoize 2018-10-17 14:06:53 UTC
It all works as expected for me and I can't find any regressions.

Passing QA
Comment 20 Jonathan Druart 2018-10-17 15:08:06 UTC
Sorry but... the validation does not work when a new field is added, only when it is edited.
Comment 21 Owen Leonard 2018-10-25 12:32:52 UTC Comment hidden (obsolete)
Comment 22 Mark Tompsett 2018-10-25 13:19:48 UTC
Created attachment 81150 [details] [review]
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config

The pull down for marc subfields on the item search fields config page is
long and hard to use. It also doesn't include the commonly used
upper case letters for custom item subfields.

Also hard to use with its 999 entries is the marc field list. It doesn't
allow for tags like 01e, which exist in our MARC21 default framework.

To test:
- Go to Administration > Item search fields
- Add different mappings with and without subfields
- Verify the entered values are stored correctly
- Edit mappings
- Verify editing works and changes save correctly

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Comment 23 Mark Tompsett 2018-10-25 13:19:51 UTC
Created attachment 81151 [details] [review]
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields

This patch adds some custom validation to the MARC tag and subfield
fields so that they are limited to alphanumeric characters.

Both templates (the main view and the edit view) have been modified so
that item_search_fields.js can be included in both.

To test, apply the patch and test the form by entering a variety of
different character combinations. The "MARC field" and "MARC subfield"
inputs should only accept alphanumeric entries.

Test both "new" and "edit" operations.
Test other operations like delete and cancel.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Comment 24 Martin Renvoize 2018-10-31 09:29:19 UTC
Maybe I'm being stupid.. but this doesn't seem to be working for me.

First off the validation doesn't seem to be activating on edit or new for me ( managed to enter 1~$ for example)

Second, when I go to edit, I'm faced with an empty form rather than one that contains the existing data for me to edit.

What am I doing wrong ?
Comment 25 Owen Leonard 2019-01-11 14:38:26 UTC Comment hidden (obsolete)
Comment 26 Owen Leonard 2019-01-11 14:38:29 UTC Comment hidden (obsolete)
Comment 27 José-Mario Monteiro-Santos 2019-01-11 20:20:42 UTC Comment hidden (obsolete)
Comment 28 Jonathan Druart 2019-02-27 18:12:02 UTC
Owen, I see

 pattern="[a-zA-Z0-9]+

and

 jQuery.validator.addMethod("marcfield", function(value, element) {
     return this.optional(element) || /^[0-9a-zA-Z]+$/.test(value);
 }, _("Please enter letters or numbers") );


Should not we have only 1 check?
Comment 29 Owen Leonard 2019-02-27 18:29:05 UTC
(In reply to Jonathan Druart from comment #28)

> Should not we have only 1 check?

The pattern attribute in the markup is a non-JS fallback to the jQuery validation. It's not strictly necessary since we require JS, but it feels like good practice to me.
Comment 30 Jonathan Druart 2019-02-27 18:43:53 UTC
My concern it that they must be identical, but nothing indicate it (reading the code).

In that case why the JS check when the patterns is enough?
Comment 31 Katrin Fischer 2019-02-27 18:54:02 UTC
It gives us a nicer error message in the correct GUI language I guess?
Comment 32 Owen Leonard 2019-02-27 19:13:58 UTC
(In reply to Jonathan Druart from comment #30)
> My concern it that they must be identical, but nothing indicate it (reading
> the code).

Similar to how the maxlength attribute on input fields should match the size of database columns and those get out of sync. I can submit a followup which adds comments if you'd like.
Comment 33 Chris Cormack 2019-04-14 21:59:37 UTC
Created attachment 87955 [details] [review]
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config

The pull down for marc subfields on the item search fields config page is
long and hard to use. It also doesn't include the commonly used
upper case letters for custom item subfields.

Also hard to use with its 999 entries is the marc field list. It doesn't
allow for tags like 01e, which exist in our MARC21 default framework.

To test:
- Go to Administration > Item search fields
- Add different mappings with and without subfields
- Verify the entered values are stored correctly
- Edit mappings
- Verify editing works and changes save correctly

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 34 Chris Cormack 2019-04-14 22:00:27 UTC
Created attachment 87956 [details] [review]
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields

This patch adds some custom validation to the MARC tag and subfield
fields so that they are limited to alphanumeric characters.

Both templates (the main view and the edit view) have been modified so
that item_search_fields.js can be included in both.

To test, apply the patch and test the form by entering a variety of
different character combinations. The "MARC field" and "MARC subfield"
inputs should only accept alphanumeric entries.

Test both "new" and "edit" operations.
Test other operations like delete and cancel.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jose-Mario <jose-mario.monteiro-santos@inLibro.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 35 Chris Cormack 2019-04-14 22:00:53 UTC
Created attachment 87957 [details] [review]
Bug 20689 Follow - tiny typo fix
Comment 36 Nick Clemens 2019-04-18 11:07:00 UTC
I had two issues here:
1 - When editing the Item search fields the values set previously don't populate to the form i.e. create a new fsearch fields for 520$A - edit it and you must set the field/subfield again
2 - While other fields worked, setting 520$A and searching for a unique value in that field failed, not sure why
Comment 37 Owen Leonard 2019-04-18 12:21:49 UTC
Created attachment 88294 [details] [review]
Bug 20689: (follow-up) Correct scope of template variables

The removal of the <select>s should have been accompanied by a
correction to the scope of tagfield and tagsubfield. It is also
unnecessary to conditionally include the "value" attribute.

To test, apply the patch and test the process for editing an item search
field. All the correct values should appear in form fields during edit,
and all values should save correctly.
Comment 38 Owen Leonard 2019-04-18 14:46:49 UTC
My patch doesn't address this issue:

> 2 - While other fields worked, setting 520$A and searching for a unique
> value in that field failed, not sure why

I was unable to reproduce the problem. I modified a framework to include 520$A, added a value to a record, did an item search for that value, and the correct result was returned.
Comment 39 Nick Clemens 2019-04-19 10:58:34 UTC
The problem seems to be in ExtractValue:

SELECT 
    ExtractValue(metadata, '//record/datafield[@tag="520"]/subfield[@code="A"]')
FROM biblio_metadata 
WHERE 
    ExtractValue(metadata, '//record/datafield[@tag="520"]/subfield[@code="A"]') !="";

This returns both 'A' and 'a' subfields

We need to figure a method to make the query case sensitive
Comment 40 Fridolin Somers 2019-04-24 10:05:29 UTC
(In reply to Nick Clemens from comment #39)
> We need to figure a method to make the query case sensitive

Looks like we can set COLLATE like :
select city_name from cities where city_name='Paris' COLLATE utf8mb4_bin;
Comment 41 Owen Leonard 2019-05-08 15:56:42 UTC
(In reply to Nick Clemens from comment #39)
> The problem seems to be in ExtractValue:
...
> This returns both 'A' and 'a' subfields

Should this be considered another bug, which this bug should be made dependent on?
Comment 42 Nick Clemens 2019-05-09 13:55:03 UTC
(In reply to Owen Leonard from comment #41)
> (In reply to Nick Clemens from comment #39)
> > The problem seems to be in ExtractValue:
> ...
> > This returns both 'A' and 'a' subfields
> 
> Should this be considered another bug, which this bug should be made
> dependent on?

I think it can be done here or on another bug - it should be sorted before this is pushed though
Comment 43 Katrin Fischer 2020-01-06 14:08:29 UTC
*** Bug 13561 has been marked as a duplicate of this bug. ***
Comment 44 Katrin Fischer 2020-01-08 22:23:26 UTC
*** Bug 15384 has been marked as a duplicate of this bug. ***
Comment 45 Katrin Fischer 2021-08-23 23:17:57 UTC
(In reply to Fridolin Somers from comment #40)
> (In reply to Nick Clemens from comment #39)
> > We need to figure a method to make the query case sensitive
> 
> Looks like we can set COLLATE like :
> select city_name from cities where city_name='Paris' COLLATE utf8mb4_bin;

I believe that is not quite the solution yet, as it would affect the strings we compare to instead of only the subfield codes, as we intend.
Comment 46 Katrin Fischer 2021-08-23 23:40:22 UTC
Created attachment 124056 [details] [review]
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config

The pull down for marc subfields on the item search fields config page is
long and hard to use. It also doesn't include the commonly used
upper case letters for custom item subfields.

Also hard to use with its 999 entries is the marc field list. It doesn't
allow for tags like 01e, which exist in our MARC21 default framework.

To test:
- Go to Administration > Item search fields
- Add different mappings with and without subfields
- Verify the entered values are stored correctly
- Edit mappings
- Verify editing works and changes save correctly

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 47 Katrin Fischer 2021-08-23 23:40:27 UTC
Created attachment 124057 [details] [review]
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields

This patch adds some custom validation to the MARC tag and subfield
fields so that they are limited to alphanumeric characters.

Both templates (the main view and the edit view) have been modified so
that item_search_fields.js can be included in both.

To test, apply the patch and test the form by entering a variety of
different character combinations. The "MARC field" and "MARC subfield"
inputs should only accept alphanumeric entries.

Test both "new" and "edit" operations.
Test other operations like delete and cancel.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jose-Mario <jose-mario.monteiro-santos@inLibro.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 48 Katrin Fischer 2021-08-23 23:40:33 UTC
Created attachment 124058 [details] [review]
Bug 20689: (follow-up) Tiny typo fix

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 49 Katrin Fischer 2021-08-23 23:40:37 UTC
Created attachment 124059 [details] [review]
Bug 20689: (follow-up) Correct scope of template variables

The removal of the <select>s should have been accompanied by a
correction to the scope of tagfield and tagsubfield. It is also
unnecessary to conditionally include the "value" attribute.

To test, apply the patch and test the process for editing an item search
field. All the correct values should appear in form fields during edit,
and all values should save correctly.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 50 Katrin Fischer 2021-08-23 23:52:10 UTC
I've fixed a little conflict, signed the patches off, filed bug 28892 for the search issue and... would like to throw them back into the queue.

I feel like we should still push these patches, even with the search issue:

* To me this patch set provides a great usability improvement to the item search fields form as it gets rid of the mighty long pull downs that were hard to handle.

* The search issue already exists right now: if you are using capital subfields you will find their contents already mixed with the configurable lower case subfields. It doesn't work correctly now - that's why I made bug 28892 a "see also" instead of a "blocks" or "depends on".

* At the moment you could get around the form limitation by configuring the lower case letter for your upper case subfields. But as the MARC field and subfield are part of the displayed search option description, I think it will be nicer to allow the correct thing to be entered in the first place here.

* The search issue is probably only going to 'hit', when upper case subfields are used in bibliographic records. The more common use case for this kind of subfield are item fields, as all the lower case letters and numbers are already used up in MARC21. This also means, that there is a really high chance that only the capital letter subfield will be queried via more_subfields_xml, as the lower case one is very likely to be mapped to a database field. So in this case, the results will be accurate.

* The new form allows entering capital letter subfields, but it doesn't advertise it. If people think it's better we could change the bug title to highlight this as a usability improvement ... or we could add a hint explaining the limitation to the configuration page.
Comment 51 Katrin Fischer 2021-08-23 23:58:20 UTC
Note: only the first patch was from me - as that had been signed off, I felt I could for the follow-ups.
Comment 52 Marcel de Rooy 2021-10-27 11:26:23 UTC
(In reply to Katrin Fischer from comment #15)
> We could also start supporting other ASCII characters like ;/% for subfield
> codes..

Does not sound like a good plan to me.
Comment 53 Marcel de Rooy 2021-10-27 11:27:17 UTC
I have the feeling here that we took the wrong road and now we are on it, lets just continue following it.
Comment 54 Jonathan Druart 2021-10-27 13:51:04 UTC
(In reply to Marcel de Rooy from comment #53)
> I have the feeling here that we took the wrong road and now we are on it,
> lets just continue following it.

Why? Can you detail?
Comment 55 Marcel de Rooy 2021-10-27 14:51:15 UTC
(In reply to Jonathan Druart from comment #54)
> (In reply to Marcel de Rooy from comment #53)
> > I have the feeling here that we took the wrong road and now we are on it,
> > lets just continue following it.
> 
> Why? Can you detail?

Something like:

We are in a hybrid situation where we actually left MARC for our items to a certain degree, but we stick to the subfields stuff. And still mimic some kind of MARC compliance. While obviously the capital letters are not MARC compliant.

If we need more item columns and want to leave MARC here, we c/should do a better job than adding capitals and even other chars as subfields. We dont need them anymore. We should just use the real column names. No need for whatever character to point to a new item column, just use its name. Refactor instead of staying in between? And provide another way to export to MARC.

Etc.
Comment 56 Jonathan Druart 2021-10-27 15:18:53 UTC
> Refactor instead of staying in between?

The first step took 10 months to be pushed... It's not very motivating to continue.
Comment 57 Katrin Fischer 2021-10-27 21:40:22 UTC
(In reply to Marcel de Rooy from comment #52)
> (In reply to Katrin Fischer from comment #15)
> > We could also start supporting other ASCII characters like ;/% for subfield
> > codes..
> 
> Does not sound like a good plan to me.

I was suggesting it only because I thought I had run into this at some point in documentation - but might have been a nightmare :)

I am not sure how we could support that much information easily within MARC. With Zebra, we need to stick to some conventions to have indexing work, so using a totally outside of MARC solution will probably not work. Also a lot of the code and modules we use expect a one character subfield code. 

The only thing I could think of is something like using some subfield with prefixes for different content... adjust indexing etc. I really believe using capital letters is a reasonable compromise to keep things easy to handle.
Comment 58 Martin Renvoize 2022-02-23 14:49:50 UTC
Created attachment 131038 [details] [review]
Bug 20689: Replace marc (sub)field pull downs with input fields on item search fields config

The pull down for marc subfields on the item search fields config page is
long and hard to use. It also doesn't include the commonly used
upper case letters for custom item subfields.

Also hard to use with its 999 entries is the marc field list. It doesn't
allow for tags like 01e, which exist in our MARC21 default framework.

To test:
- Go to Administration > Item search fields
- Add different mappings with and without subfields
- Verify the entered values are stored correctly
- Edit mappings
- Verify editing works and changes save correctly

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 59 Martin Renvoize 2022-02-23 14:49:55 UTC
Created attachment 131039 [details] [review]
Bug 20689: (follow-up) Make it possible to add capital letter subfields to item search fields

This patch adds some custom validation to the MARC tag and subfield
fields so that they are limited to alphanumeric characters.

Both templates (the main view and the edit view) have been modified so
that item_search_fields.js can be included in both.

To test, apply the patch and test the form by entering a variety of
different character combinations. The "MARC field" and "MARC subfield"
inputs should only accept alphanumeric entries.

Test both "new" and "edit" operations.
Test other operations like delete and cancel.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jose-Mario <jose-mario.monteiro-santos@inLibro.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 60 Martin Renvoize 2022-02-23 14:50:00 UTC
Created attachment 131040 [details] [review]
Bug 20689: (follow-up) Tiny typo fix

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 61 Martin Renvoize 2022-02-23 14:50:05 UTC
Created attachment 131041 [details] [review]
Bug 20689: (follow-up) Correct scope of template variables

The removal of the <select>s should have been accompanied by a
correction to the scope of tagfield and tagsubfield. It is also
unnecessary to conditionally include the "value" attribute.

To test, apply the patch and test the process for editing an item search
field. All the correct values should appear in form fields during edit,
and all values should save correctly.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 62 Martin Renvoize 2022-02-23 14:54:20 UTC
I think the compromises here are reasonable and the timescale it's taken for this to work through makes me feel it's time to let it get in and if someone wishes to work on it further they can do in another bug.

Passing QA
Comment 63 Katrin Fischer 2022-02-27 00:30:26 UTC
If it makes things a little easier, we could change description to:
Improve usability of Item search fields administration page
Comment 64 Fridolin Somers 2022-03-02 08:48:23 UTC
Pushed to master for 22.05, thanks to everybody involved 🦄