- Issue created by @coledev
- last update
about 1 year ago 130 pass - @coledev opened merge request.
- Status changed to Postponed: needs info
9 months ago 7:31pm 4 March 2024 - π«π·France dqd London | N.Y.C | Paris | Hamburg | Berlin
Thanks for the report and all the efforts in here.
I have to decrease the issue priority. Descriptions of the Priority β and Status β values can be found in the Drupal project issues β documentation.
Interesting issue. I think if this is a global issue in the scope of this project, then it is not for Date and Term fields only. Change the title accordingly. Apart from that the provided solution is not implementable this way because it a) fills very individual needs and b) is not the same as being really disabled. This should be called another state then and would need changes in the UI and form texts.
Please elaboate on if fields which are disabled are ALL losing its content and if this also happens in other scenarios out of Conditional fields. If that' the case - and I think so it is - then this is rather an issue for core "how to deal with content of disabled fields". But again, the other option would be to implement a new status feature maybe called like "Appear like disabled/frozen (no editing possible)" or something.
But again, that are two different issues and we need to decide which issue we want to handle here.
- Issue was unassigned.
- Status changed to Needs work
8 months ago 1:25pm 7 March 2024 - π«π·France dqd London | N.Y.C | Paris | Hamburg | Berlin
Side note: Date range is no core field. And disabled and readonly are two different HTML input behaviors. There is a readonly state attribute for HTML input fields doing exactly what you want, so you can REALLY make the field readonly without acting as disabled, not only simulate it with CSS. This part is missing in the patch.
Apart from that: The solution provided in this issue here is a great idea and actually should be a feature request since it implements an interesting new feature (originally as a work-around created by issue reporter but actually a great idea for a new feature). So let me sort the issues out and convert this issue here into a feature request with your patch as starting point. It also a great temporary work-around for the issue with dependency settings getting lost when a from field widget gets disabled under manage form display, like tracked in this issue: π Refactor the concept of how dependency settings are assigned to fields and entity bundles Active
Thanks for the report and hard work in here. Changed issue summary and title/scope accordingly.
- π«π·France dqd London | N.Y.C | Paris | Hamburg | Berlin
In fact I see now there is already a starting point @todo placed in the code of src/Conditions.php
// @todo Add support to these states: /* 'relevant' => $this->t('Relevant'), '!relevant' => $this->t('Irrelevant'), 'valid' => $this->t('Valid'), '!valid' => $this->t('Invalid'), 'touched' => $this->t('Touched'), '!touched' => $this->t('Untouched'), '!readonly' => $this->t('Read/Write'), 'readonly' => $this->t('Read Only'), */
- First commit to issue fork.
- last update
7 months ago 130 pass - Status changed to Needs review
7 months ago 7:58pm 29 April 2024 - πΊπΈUnited States bernardm28 Tennessee
This should be ready to be reviewed.
I tested it with DrupalPod 10.1.x and the standard theme.