Feature/cms 1091 ability to move entries to a new section

[i-just]

Description

Adds element index action to move entries between sections.

• select entries to be moved and trigger the “Move to” action

• see a modal with a list of compatible sections (sections that have the same entry type(s) as the entries we want to move)

• choose a section to move to

• entries are moved to the new section

Notes:

• it’s not possible to move to a single section
• for structures, entries are moved to the end of the new structure as root elements
• if the section entries are moved to has a lower maxAuthors limit, no data is changed/lost for the entries, but the next time they’re saved, a validation error will be shown
• when an entry is moved, its revisions and drafts are moved too; if their entry type isn’t allowed by the section we’re moving to, you will still be able to see the draft/revision but not apply/revert to it (the same applies to revisions and draft for entry types that were removed from the section); thanks @brianjhanson for adjusting the awesome craft-tooltip to work with disabled elements!

Related issues

cms-1091

[linear[bot]]

CMS-1091 Ability to move entries to a new section

[brandonkelly]

Rather than showing the “Couldn’t find any sections that all selected elements could be moved to.” message in the modal, ideally the “Move to” action is just grayed out ahead of time if there aren’t any other sections with the same entry type.

This should be doable via the validateSelection() method on the action trigger JS.

[i-just]

@gcamacho079, as per our chats, all items except the disabled button focus ring are actioned.

To get the last item from the list to work, I added the live region container and updateLiveRegion method to all modals (via Garnish.Modal) and started using it in my EntryMover, which means other modals could start taking advantage of it.

[gcamacho079]

A few accessibility improvements based on automated and manual testing:

• [x] The checkbox role doesn’t communicate the correct interaction pattern. Radio inputs would work better since the selections are exclusive.
  • [x] Radio inputs should be contained in a fieldset with a legend/aria-labelledby that references the title of the modal
  • [x] List markup should be removed as radio group markup should provide the necessary relationship information
• [x] The accessible name of the inputs should match the visible name (i.e., the section name). Right now, the label ID that’s referenced via aria-labelledby does not exist, so the name is coming from the input title.
• [x] Focus is dropped when an entry is moved. In these instances, focus should probably be moved to the .elements container. Ensure programmatic focus can be set by adding `tabindex="-1" to the container.