Make the tag edit box on the body admin page bigger

[HelenWDTK]

Replaces #7801, deleted in error

On 30 June 2023 @HelenWDTK wrote:

When a body has a lot of tags, it is hard to scroll through these to edit them, as the text field is quite small.

https://github.com/mysociety/alaveteli/assets/120410992/254a841f-3b5c-40fc-b7b6-79f029cda2c5

It would be good to make this box bigger, or to display the tags in some other way which makes them easier to remove

---

On 3 November 2023 @garethrees wrote: Swap to 'textarea'. Same width, but make it ~5 lines tall.

[laurentS]

For what it's worth, we don't use tons of different tags yet, but I added some code to ease tag editing. It looks like this, the little black cross deletes a tag as expected, you can type a new one and then delete the old one if needed (it would be great to have a better tag editing logic, haven't figured out a nice UX for it yet).

It even suggests the most common ones for autocompletion!

The code is here and the backend api endpoint to list tags.

The logic is pretty basic, and the API endpoint in particular might suffer a bit when the number of tags grows too much (I have no idea how big that number is on WDTK, but certainly bigger than on madada, which is just about to hit 100k). It should be fairly easy to cache its output or limit it to the N most common values to prevent slow downs.

I think this should be pretty easy to upstream into alaveteli core.

[garethrees]

That looks awesome! The UX looks good enough to me!

I'd try to look at whether we can get rid of having to manually add in different model types, since we want to make more records taggable. Could it just use the model_type value rather than the shortened version so that no hard-coding is necessary? Alternatively could drop that bit altogether to keep it simple.

Limiting to N most common/recent if it gets bogged down sounds like a good idea. Would also make the controller admin-only (Admin::TagTypeaheadController#index or something).

For reference, we only have ~3x more tags currently, but that may well expand quickly as we look in to automation of generating topic pages. Would be pretty easy for us to generate a load of nonsense tags to test out with 10x-100x more to find the point at which it grinds to a halt.

HasTagString::HasTagStringTag.count
# => 332871
HasTagString::HasTagStringTag.select(:name).distinct.count
# => 2314

[laurentS]

I'd try to look at whether we can get rid of having to manually add in different model types, since we want to make more records taggable. Could it just use the model_type value rather than the shortened version so that no hard-coding is necessary? Alternatively could drop that bit altogether to keep it simple.

Yes, I think using model_name directly is fine. I suffered from premature optimisation syndrome here :sweat_smile: The endpoint returns only ~200 items at the moment, so the impact would be minimal. I think the model is quite useful to show more relevant suggestions to users, so I'd keep it.

Limiting to N most common/recent if it gets bogged down sounds like a good idea.

I'm thinking now that stripping rarely used tags might be a good way to limit the number of results:

count(*) as cnt,
...
WHERE cnt >= 5 -- or whatever makes sense

Caching the result for a few minutes/hours is probably the best way to limit load on server.

Would also make the controller admin-only (Admin::TagTypeaheadController#index or something).

I didn't go down the admin-only route because this was part of an effort to allow users to apply certain tags to their own requests. I haven't completed that in a way that makes use of the endpoint, so it should be fine for us.

I've kept the name:value pairs, as we have tried to namespace our tags a bit.