Add fieldsets collapsed default value option.

[fabiocaccamo]

Ideas:

• Default fieldsets collapsed value configured in settings.
• Default fieldsets collapsed value configured in the admin Theme options.
• Strictly Related to Add option for remember fieldsets.collapse state (visible/hidden). #160

[merwok]

I am using the collapse class provided by django in one admin class of one project, with a custom script to expand the fieldset as initial state (in other words, I need the fieldsets collapsible, not collapsed). I add a class show to the fieldsets that need it so that the script can look for it (it could be collapse-initial-show to be more explicit).

Recently the custom script stopped working, so after fighting a bit with DOM event collapsing and bubbling (ugh) I decided to copy django’s collapse.js to my project and change the behaviour directly. (This would also avoid the visual issue of fieldset being visible, then django’s script loads and collapses them, then my script expands them — now it will just add the buttons.)

So, what if django-admin-interface copied static/admin/js/collapse.js from django to override it?
Would be great if I could help get this feature in an upstream project!

[fabiocaccamo]

That would be great, and since there is JS involved for doing this I would add also:

👉 Storing locally each fieldset state (per model class), the cache key could be f"{app_name}-{model_name}-{fieldset_name}". #160

Could you work on this feature?

[merwok]

I’ll make a PR with the django script modified.

I will look at per-user state persistence in a separate commit. Is there an easy way to get the theme option from JS? Output it as a data attribute from a template?

[fabiocaccamo]

I don't think we need a per-user state persistence, I would store them using local storage (already did a similar thing for foldable apps feature).

Exposing theme options as JS variables could be good and useful thing.

[merwok]

I meant that local storage is per-browser persistence, not adding a model with foreign key to user!

[merwok]

Exposing theme options as JS variables could be good and useful thing.

I found the current technique in a template:

{% if theme.foldable_apps %} foldable-apps {% endif %}

Easy to use the same.

[fabiocaccamo]

I meant that local storage is per-browser persistence, not adding a model with foreign key to user!

True, but how often different users will use the same backend with the same computer/browser?
Considering also that we are not storing sensitive data, but just an accordion state...

---

I found the current technique in a template: ...

Yes, body classes are perfect for features on/off, no need to expose variables.

[merwok]

I don’t understand this sub-part of the discussion!

You requested to persist current collapsed state in local storage. I said I don’t need that for my project but will add it.
Then I called that per-user persistence by mistake instead of per-browser, I wasn’t making a different proposal 🙂

[fabiocaccamo]

Ahh ok, now I understand, sorry.

[fabiocaccamo]

@merwok have you planned to work on #160 in the next days?

I ask it to decide if publishing a new release with the latest features/bug-fixies today/tomorrow or waiting for this feature too.

[merwok]

If it’s very easy to make a release, then you could ship what’s already done now, then another one soon including the changes for #160 and #174 . If it’s trouble, then you could wait to release next week with everything.

[fabiocaccamo]

Released 0.21.0 version.