Actions

[DanRibbens]

This is a proposal on building a way to extend the admin UI to allow custom workflows for collections and it can also be adapted to work for globals too. By using this built-in configuration option for handling actions, the UI would be able to show button in the multi-select workflow as pills and also on the collection edit view.

The idea is that for every item in the collection list, or on the edit view of a document, the config should allow for adding controls seemlessly with the rest of the admin UI. The new controls would be useful for things like:

• Syncing data between Payload and 3rd parties
• Building custom workflows
• Importing data

With this idea you would configure each action to have:
label (required) - text or UI component, or keyed object of these for i18n in the admin UI, used for displaying the button.
endpoint - The Endpoint added to the collection endpoints and is called by the action handler, not required when onClick is supplied. The handler function must work with an array of document IDs.
confirmModal - true by default, set to false to remove the workflow step and fire the action immediately. Can be an object to customize further.
confirmModal.title - Set the title of the confirmation dialog in one or more languages.
confirmModal.body - Customize the body of the confirmation dialog in one or more languages.
confirmModal.fields - Render inputs below the body to collect additional data to send to the endpoint handler.
confirmModal.submitLabel - Set the save button text in one more languages.
onClick - A function that is used as a handler on the frontend to customize the click action behavior, ignoring the confirmModal and endpoint use.
showOnList - Set to false to remove the control from the list view, default to true.
showOnEdit - Set to false to remove the control from the collection edit view, default to true.

In additon to these I'd like to have some kind of type property to designate between one of the following three:

• A selection agnostic button at the top, near Create New that can be clickable even if you haven't made any selections.
• Default behavior which would show the button in multiple select button area in the list (next to Edit, Delete, Columns, Filters, etc) as well as on the Edit view, with the other buttons in the top of the sidebar.
• Individual document button that is not available when making multiple selections from the list and instead appears within a new column to the right.

This proposal could be used would give us a starting point on handling multiple file uploads as the confirmModal.fields would give us an entrypoint to place the upload collection fields inside an array for each file.

One UX challenge is what to do if a collection has a lot of these buttons, we may need to overflow into a toggle (kebob/hamburger) menu.

Edit 6/22/2023:

It would be helpful if there was a way to override existing actions, which would help in situations like this: https://discord.com/channels/967097582721572934/1121326148832473218

[gamellis]

I was about to write about to start a discussion about "Saving filters" on collection lists, but this might work. I wonder if it would be possible to add more render slots throughout the list view component to place actions near what they control/do. Similar to BeforeDashboard, AfterNavLinks

@DanRibbens, we could use this feature today, hands down. We created a flag collection to decorate documents with more workflow moments. It would be amazing if we could create UX allowing those flags to be applied without using the filter UI, which gets old when you're opening and closing documents searching for something. Each time you need to reset your filter.

Some flag examples:

• Ready for review
• Ready to publish
• Needs changes

Not sure how I'm the only commenter on this thread. Maybe "Actions" is too ambiguous as a concept? 😄 Custom Workflow Actions for better UX might be a little more eyebrow-raising.

Very excited to see this come alive.

[DanRibbens]

Great feedback, thanks @gamellis!

In case you didn't see, we did add more render slots to the list in v1.9.1. See the notes here: v1.9.0...v1.9.1 and the PR has more info on it #2792.