[MGNLUI-3381] Reorderable MultiValueField Created: 19/Mar/15 Updated: 28/Nov/19 Resolved: 14/Sep/15 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | forms |
| Affects Version/s: | 5.3.7 |
| Fix Version/s: | 5.4.3 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Stefan Jahn | Assignee: | Espen Jervidalo |
| Resolution: | Fixed | Votes: | 6 |
| Labels: | multifield, support, ux | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 1h | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||
| Sprint: | Basel 10 | ||||||||||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||||||||||
| Description |
|
MultiValueField should allow reordering its entries, to avoid having to mass-delete/re-add entries when order matters. This is considered a usability flaw, no need to make it configurable.
Original description
For example, if you have a full editable main navigation with many links you either can use an area with single link components or you can use the MultiField. Both isn't optimal for this case, because: The SortableMultiField combines both types and allows to order the field, so the authors can easily switch the order of the entries. The SortableMultiField can also be used with CompositeField etc. I added two new properties (sortable, maxComponents) into the definition so you can decide if you want to have the MultiField sortable or not and you also can limit the number of entries in the MultiField. I included the necessary Java files and some small styling. |
| Comments |
| Comment by Casper Biever [ 12/Jun/15 ] |
|
We would love to see this incorporated into Magnolia! It would make the lives of our editors that much easier. |
| Comment by Erich Ruf [ 25/Jun/15 ] |
|
This is a great feature! Exactly what we need for our customer. Please integrate this and make it the standard. |
| Comment by Adi De Masi [ 21/Jul/15 ] |
|
We used MultiValueFiels a lot in our project, but this was always a downside of it. We would love to see this in the standard. |
| Comment by Mikaël Geljić [ 13/Aug/15 ] |
|
And this was validated on UX level as a good first step. Thanks Stefan for contributing this! |
| Comment by Sigurd Rolfes [ 15/Aug/15 ] |
|
Great. We also need this for our customer. What we also need is a minComponents/required and standard validation. https://jira.magnolia-cms.com/browse/MGNLUI-3227 For this link example the expected behaviour would be: required: click "add" at least once (=minComponents=1) minComponents=3 and maxComponents=5 (self explaining) I could not find any validator class. Anyway, thanks a lot for this feature. |
| Comment by Mikaël Geljić [ 18/Aug/15 ] |
|
min/max entry concerns were split into a separate ticket ( |
| Comment by Thomas Weckert [ 18/Aug/15 ] |
|
Works like a charm! |
| Comment by Ian Cervantez [ 12/Oct/18 ] |
|
This appears to have been removed in 5.7 with the shift to fieldType: multiValue in the dialog definitions rather than specifying the class directly. |
| Comment by Moritz Kraus [ 28/Nov/19 ] |
|
That is not a problem. Simply define a new fieldType as described here: https://documentation.magnolia-cms.com/display/DOCS61/Custom+fields and use this. |