|
| Description: |
Some macros take a list of tags, and the Edit Macro dialog shows it as a plain text field: the user has to type each tag exactly, case included, and a tag that no page carries is accepted silently. The tags of a page are already entered with suggestions of the existing tags, but no displayer offers them to a macro parameter.
h2. Where it is needed
||Macro||Parameter||Value||Ticket||
|[ activity|https://design.xwiki.org/xwiki/bin/view/Proposal/WYSIWYGusabilityofXWikimacros/Macros/activity/]|{{tags}}|tags, several values|none|
|[ notifications|https://design.xwiki.org/xwiki/bin/view/Proposal/WYSIWYGusabilityofXWikimacros/Macros/notifications/]|{{tags}}|tags, several values|XWIKI-23834|
h2. Proposal
* Add a {{Tag}} type, with its converter, so that the macro editor can tell a list of tags apart from a plain list of strings.
* Add a {{#tagPicker}} Velocity macro, which suggests the existing tags and takes several values, and an HTML displayer edit template for {{List<Tag>}} that uses it.
* Declare {{List<Tag>}} as the type of the two parameters parameter above, so that the Edit Macro dialog shows the picker, and turn the typed value back into the comma-separated list that the macro expects.
An implementation is proposed in [PR #5999|https://github.com/xwiki/xwiki-platform/pull/5999] of XWIKI-23834, for the notifications macro. The activity macro would then only need the type of its parameter is left out: it is a legacy macro, to be deprecated in XWIKI-25515 .
h2. Impact found on macro fluidity
These 2 KOs come This KO comes from the [WYSIWYG usability audit of the macros|https://design.xwiki.org/xwiki/bin/view/Proposal/WYSIWYGusabilityofXWikimacros/Macros/], under the criterion C4 input-assistance of its [usability criteria|https://design.xwiki.org/xwiki/bin/view/Proposal/WYSIWYGusabilityofXWikimacros/Usability%20criteria/]. The page of each the macro, linked in the table, has the full notes. |
|
