Advanced Search: remembering which fieldset collapse preferences per-user

Following PR31226, where one person expressed that they heavily use the "Display results as" feature, @nicol suggested that perhaps we could save this preference on a per user basis. We could even save this preference for all fieldsets.

Maybe someones uses "display results as" a lot, others are probably annoyed because they heavily use Activities, Relationships or various Custom Fields. Maybe they never use the Basic Criteria. (and it's honestly the first time I hear about someone using that feature - nice feature, but really mind-bending for most users)

In other words:

• We keep the current Advanced Search behaviour of collapsing the Search Settings initially, and only show Basic Criteria
• If the user uncollapses the Search Settings, then it becomes a sticky preference in the future. Whenever they go to the Advanced Search (on new searches), the Search Settings will be uncollapsed.
• This same behaviour would apply to other fieldsets as well, such as Address, Events, Custom Fields (and groups of fields in them).

In a sense, users setup their UI preferences once, and then it's sticky.

Technically, it might be implemented as a localstorage setting in the browser (simpler, and we can improve later if necessary).

In theory, this could lead to getting rid of the "Collapse this set in Advanced Search" setting on Custom Groups, but that can be decided later. That could be upsetting to uses with a lot of custom fields, and we have previously done some rather big changes in the past, such as always displaying all custom fields (when we renamed the "optimize for search" setting).

I found one possible bug: in most situations, if we uncollapse the fieldsets without selecting anything, it's fine. One exception: relationships. If we uncollapse relationships, it automatically filters by contacts who have an active relationship. I think that's a bug? It's definitely not coherent with other search sections.

changed the description

FWIW - I really like the idea of this being a sticky preference, especially if it could be applied only to those with a utility class, ie <details class="crm-expand-light crm-expand-sticky/remember/store"> so that areas where it's not helpful can avoid it.

I'm assuming from a privacy/cookie law perspective local storage is totally ring-fenced from other sites so isn't an issue. ie other sites can't ever know that I once opened an FAQ accordion on my-private-health-issue.org.

Sounds good to me.

@colemanw Any concerns you might think of, with regards to SearchKit / FormBuilder?

And where should this JS live?

No concerns here. Probably could make it a web component. We don't currently have any of those in our codebase so a bit of new territory. @ufundo was working on one though, so he might know where to put it.

Sounds neat.

I'm not sure if it would make sense as its own component?

I'm imagining you'd have a global listener, somthing like:

document.addEventListener('DOMContentLoaded', () => {

  Array.from(document.querySelectorAll('.crm-container details.crm-expand-sticky')).forEach((expander) => {

       // check if my id exists in local storage and open/close me accordingly


       // listen for open/close on me and update local storage accordingly


  });

});

Could it go in crm.searchForm.js? Or add a js file in Riverlea?

^ note you'd need a MutationObserver if you want it to work for <details> inside angular components

Or add a js file in Riverlea?

It's more function than theme tho? crm.searchForm.js makes sense if that's available everywhere? Just need to make sure it doesn't clash with Advanced Search's logic around opening/closing collapse regions based on results.

I would say it's "UI-goodness" so could belong in theme layer...

clash with Advanced Search's logic around opening/closing collapse regions based on results.

Yep, don't know how that works but sounds potentially clashy...

added triaged label