- Issue created by @Anybody
- 🇩🇪Germany Grevil
I vote against this. If no action is selected (aka when the module is installed), it is disabled by default.
Instead, we should describe this behavior in the description of "events".
- 🇩🇪Germany Anybody Porta Westfalica
Well I think it would be more clear UX to have that option. We could even use state to hide anything, if disabled.
Having an enabled / disabled switch is very helpful, as it can be very simply disabled without altering important settings. So there are good reasons, while I understand your point.
- last update
over 1 year ago 11 pass - @grevil opened merge request.
- Issue was unassigned.
- Status changed to Needs review
over 1 year ago 9:52am 28 July 2023 - Status changed to Needs work
over 1 year ago 9:52am 28 July 2023 - Open on Drupal.org →Core: 10.0.7 + Environment: PHP 8.2 & MySQL 8last update
over 1 year ago Not currently mergeable. - last update
over 1 year ago 11 pass - Status changed to Needs review
over 1 year ago 10:20am 28 July 2023 - Assigned to Grevil
- Status changed to Needs work
over 1 year ago 10:24am 28 July 2023 - 🇩🇪Germany Anybody Porta Westfalica
The details fieldsets aren't visible anymore at all, when switching to an active entry.
Also please rename to "Disabled (do not send any notifications)". "Disable the module functionality" is very technical.
- last update
over 1 year ago 11 pass - 🇩🇪Germany Grevil
Whoops, sorry put the negation inside the value instead of key "value". Fixed.
- last update
over 1 year ago 11 pass - Status changed to Needs review
over 1 year ago 10:52am 28 July 2023 - Status changed to Needs work
over 1 year ago 10:54am 28 July 2023 - 🇩🇪Germany Grevil
Ok for some reason 'and' doesn't work, even if 'or' does... No idea why,
- last update
over 1 year ago 11 pass - Status changed to Needs review
over 1 year ago 11:06am 28 July 2023 - 🇩🇪Germany Grevil
We can just define both inputs for the visible states, as "and" is used as standard. Still weird, that 'or' with the exact same syntax just works...
- 🇩🇪Germany Grevil
Wow this is really ****ing stupid:
https://www.lullabot.com/articles/form-api-statesFor OR conditions, use an non-associative array by wrapping each group of conditions in the array() function
Meaning if we wrap the inputs in their own arrays, it will automatically use or, even if "and" is defined....
- last update
over 1 year ago 11 pass - Issue was unassigned.
- 🇩🇪Germany Anybody Porta Westfalica
Thanks @Grevil, works fine now! Does it also stop the notifications from being sent, IF the checkboxes are still set (but hidden) in the background?
If yes, perfect and RTBC.
I agree #states API has some flaws...
BTW please remember to always think about the "hidden, but still there" form items risky, when using #states API and outside of Drupal. The UI easily leads to the conclusion the values are "reset". So the disabled state itself should be used. It's good to keep the other values in the background to allow temporary disabling without losing configuration, on the other hand.
- 🇩🇪Germany Grevil
Ok, I won't waste any more time on this.
If using or you NEED to wrap the inputs inside their own array, meaning:
'visible' => [ [':input[name="type"]' => ['value' => 'role']], [':input[name="type"]' => ['value' => 'both']], ],
uses "or" implicitly
'visible' => [ [':input[name="type"]' => ['value' => 'role']], 'and', [':input[name="type"]' => ['value' => 'both']], ],
also uses "or" implicitly (which is really dumb)
'visible' => [ ':input[name="type"]' => ['value' => 'role'], 'or', ':input[name="type"]' => ['value' => 'both'], ],
Doesn't work at all
'visible' => [ [':input[name="type"]' => ['value' => 'role']], 'or', [':input[name="type"]' => ['value' => 'both']], ],
Does work, but thows phpcs error
- 🇩🇪Germany Grevil
Thanks @Grevil, works fine now! Does it also stop the notifications from being sent, IF the checkboxes are still set (but hidden) in the background?
Yes, see adjustments in module file, it returns early, when "disabled" is set.
- Status changed to RTBC
over 1 year ago 11:36am 28 July 2023 - last update
over 1 year ago 11 pass - Status changed to Fixed
over 1 year ago 11:36am 28 July 2023 Automatically closed - issue fixed for 2 weeks with no activity.