[5.3] - Allow fancy-select renderSelectedChoices attribute to be overridden

[travisrisner]

Pull Request for Issue #45536 .

Summary of Changes

This PR introduces support for a new optional data-render-selected-options XML attribute in <field type="list" layout="joomla.form.field.list-fancy-select" />. This allows developers to customize the rendering behavior of selected options by passing the value directly into the underlying data-render-selected-options attribute used in the fancy-select JavaScript, rather than relying on a hardcoded option. If the data attribute does not exist, it will default to a value of "always".

I've also went through the source and identified and modified the flat lists I believe could benefit from this attribute, and left it off of the lists that have "nested" behavior (like categories). It's possible I might have missed some.

I'm truly unsure if utilizing an data-* attribute in this way is a good solution, but thougth I'd go ahead and submit this and see what feedback I get.

If this is a valid solution, I do think it might still be beneficial to implement some CSS similar to the quick example I added to that initial issue, so that if the options are retained there is at least some easier visual feedback for which items are selected.

Testing Instructions

• Edit a user on the administrator portal
• Click the User Actions Log tab
• Toggle on the Email Notifications option
• On the list of extensions, select an item from the list and it should disappear from output
• After that is verified, navgiate to Content -> Articles and toggle on the Filter Options on the search
• Select a parent item from the category filter selection and the parent item should still be listed

Actual result BEFORE applying this Pull Request

All fancy-select lists retained the selected options

Expected result AFTER applying this Pull Request

Just specific fancy-select lists will retain the selected options

Link to documentations

Please select:

• [ ] Documentation link for docs.joomla.org:

• [ ] No documentation changes for docs.joomla.org needed

• [ ] Pull Request link for manual.joomla.org:

• [ ] No documentation changes for manual.joomla.org needed

[ceford]

I can't follow the testing instructions! I am using J5.3.2-dev (a clone). In the user edit form there is no User Actions Log tab. In the User Actions Log / Options page there is no Email Notifications option in the list. In the filtered list of articles I don't really know what I am looking for! Some screenshots might help.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45558.}

[travisrisner]

I can't follow the testing instructions! I am using J5.3.2-dev (a clone). In the user edit form there is no User Actions Log tab. In the User Actions Log / Options page there is no Email Notifications option in the list. In the filtered list of articles I don't really know what I am looking for! Some screenshots might help.

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45558.

That's my mistake. I forgot a step, the User Actions Log plugin has to be enabled for that tab to be visible when editing a user. System -> Plugins -> search for "log" and enable the System - User Actions Log.

The testing for the category filter is more so to make sure I didn't mess with what was previous done to resolve the visual error on that.

I'll see if I can work up some screenshots and maybe some better instructions for a place to test that doesn't require a plugin to be enabled.

[HLeithner]

This pull request has been automatically rebased to 5.4-dev.

[HLeithner]

I'm not convinced that using data attributes for this is the way to go, we have many many choices js and fuse js options we might want or need to set (came about this my self 2 weeks ago...).

I think a json object as attribute would be a more generic way to provide options to choices js.

[HLeithner]

This pull request has been automatically rebased to 6.1-dev.

[travisrisner]

I'm not convinced that using data attributes for this is the way to go, we have many many choices js and fuse js options we might want or need to set (came about this my self 2 weeks ago...).

I think a json object as attribute would be a more generic way to provide options to choices js.

Agreed. I'm going to close this out and go back to the drawing board on it.