User tests: Successful: Unsuccessful:
Many extensions currently use custom status fields (PluginStatusField, RedirectStatusField, TaskStateField (from #35143)), mainly because it makes more contextual sense to use Enabled/Disabled as states at some places instead of Published/Unpublished.
This also increases scope for inconsistencies which can be seen as an example in the forms for com_workflows
(reference #35056).
This PR adds alternative labels the status
field which can be used with the alt_labels
field attribute. This can be used in conjunction with optionsFilter
at places where a list field or a custom field might be needed right now.
For example, if you want to support the enabled, disabled and trashed state for an item, you could use:
<field
name="state"
type"status"
label="JSTATUS"
optionsFilter="-2, 0, 1"
alt_labels="true"
/>
Right now, you'd have to contend with a custom field, a list field everywhere or a language override (#35743 (comment)).
You can test that StatusField (field type="status") behaves the same as before in all existing forms.
I can also add the alt_labels
attribute to the workflow forms and some more places in this PR so those could be tested here and perhaps some redundant field classes removed.
StatusField only supports "publish" type labels.
StatusField supports alternative state labels needed by a number of existing core extensions.
Update to the Form Fields/StatusField documentation on JDocs.
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
Could you give an example please of where this would be used
Workflow forms (I linked a PR for reference), replacing PluginStatusField, RedirectStatusField and TaskStatusField (from Scheduler).
Labels |
Added:
?
|
Personally I have always done this with just a language string
For example (together with your fix for workflows) it will look like this image
Just by adding two language string overrides to com_workflows.ini image
That's a good solution! I think this change should still be worth considering as it might be easier perhaps to use an attribute for the safe effect as its used in quite a few places.
Category | Libraries | ⇒ | Unit Tests Repository Administration com_content com_finder com_joomlaupdate com_tags com_users Language & Strings Modules Templates (admin) NPM Change |
Labels |
Added:
?
Language Change
NPM Resource Changed
|
Category | Unit Tests Repository Administration com_content com_finder com_joomlaupdate com_tags com_users Language & Strings Modules Templates (admin) NPM Change | ⇒ | Libraries |
Rebased to 4.1-dev
Title |
|
Labels |
Added:
?
?
Removed: ? Language Change ? NPM Resource Changed |
I have tested this item
I tested the alt_labels attribute in several filters like categories and the patch worked. Enabled and Disabled showed up.
This pull request has automatically rebased to 4.2-dev.
This pull requests has been automatically converted to the PSR-12 coding standard.
Labels |
Added:
?
Removed: ? |
Labels |
Added:
?
Removed: ? |
This pull request has been automatically rebased to 5.0-dev.
Looking at this again and I realise now the benefits. Together with the optionsFilter this PR would allow us to remove several fields as they would become redundant.
could someone change the title to say [5.0] instead of 4.1 please
I have tested this item
Title |
|
The proper way would be to create an addition field with other default values, then you don't need an extra attribute.
Something like StateField instead of StatusField.
I have tested this item ✅ successfully on bd41106
Tested on 5.0.0-beta2-dev. I added an extra dummy Option to see it in the filter list and also stepped through the applied code. I added two lines from the state field to the articles published field to see the effect of the alt_labels option. All works.
Although it has 2 successful human tests I don't set it to RTC because it has a conflict in file "libraries/src/Form/Field/StatusField.php".
And @HLeithner 's comment above suggest a different solution.
as said own field instead of additonal attribute please. I'm closing this but can be reopend when we get it's own field or a more flexible way to change the label of the options (maybe swapable language constants)
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-09-12 11:19:00 |
Closed_By | ⇒ | HLeithner | |
Labels |
Added:
Feature
Conflicting Files
?
PR-5.0-dev
Removed: ? ? |
Could you give an example please of where this would be used