[5.x] Run actions from publish forms

[jacksleight]

This PR allows you to run all actions from the entry, term and user publish forms and the asset editor.

Some implementation details:

• Because the word "actions" is already taken by the action URLs these actions are referred to as "item actions" in all publish forms, except for the asset editor which already has these actions under "actions".
• There's a new view key in the action context which will either have a value of list or form. This allows actions to display or behave differently depending on where they’re being used.
• The form values are synced after actions run using the same approach as Update entry publish form values after saving #6842, but at the moment I've had to duplicate the extractFromFields methods. Maybe they could be refactored so both controllers can use them?
  • I also implemented the value update feature from that PR for terms and users. It just made sense to add those since actions need the same thing.
  • I also noticed that the extractFromFields methods return meta values, but they’re not being passed back to the publish forms after save. I have copied that behaviour for actions, but I think they should be included so that all values display correctly?
• The title, permalink and actions themselves are also synced after actions run.
• Things that are already possible from the publish forms are filtered out from the actions menu eg. publish entry, assign user roles, most asset actions.
• Currently the asset editor closes whenever an action completes, which may not be desirable for all actions, but I didn’t want to mess with that in this PR. This could be looked at in a future PR.
• This PR does not add actions to form and submission show/edit pages, since they work a bit differently and don’t currently have their own publish form components. This could be looked at in a future PR.
• I've updated the divider styles so they're hidden if they come first, last or directly after another. This is required to avoid unnecessary dividers in the menu when you don’t have permissions for all options.

• Entries
• Terms
• Assets
• Users

Closes statamic/ideas#712

[what-the-diff]

• Added a new action to the entry publish form.
• The list actions are now fetched from an endpoint, instead of being hardcoded in the view file.
• When running an action on one or more entries, we return some data about those items (e.g., their values). This is used by PublishForm when it's rendered as part of another component (like EntriesIndex) so that it can update its own state with this information after successfully completing an action like "Duplicate".

[edalzell]

Hey @jacksleight, there's a merge conflict now. If you're still interested in this, can you rebase off 3.4 and resolve?

I've mark this as draft in the meantime.

[what-the-diff]

PR Summary

• Added mixin to PublishForm for list actions
  A new mixin is now included in the PublishForm component to enable list actions.

• Updated EditEntry view with initial data, URL and event listener
  The EditEntry view now has an initial data setup and URL for list actions. An event listener was added to update the state when needed.

• Enhanced DeleteAction with a redirect method
  The DeleteAction now offers a redirect method to return to the collection listing page when required, improving user experience.

• Improved DuplicateEntry action for handling multiple items and correct redirection
  DuplicateEntry action now handles multiple items selection better and ensures proper redirection to the correct site when necessary.

[laradevca]

I ended up on this PR while Googling. Just to make sure that I understand, the PR will allow us to run action within an entry? Will it allow us to restrict an action to be run only on 1 entry instead of the list view?

[jacksleight]

the PR will allow us to run action within an entry?

Yep.

Will it allow us to restrict an action to be run only on 1 entry instead of the list view?

Yes, within the action's visibleTo() method you could check for the publish_form key in the action context and filter based on that.

[duncanmcclean]

Would love this one to be merged - just wanted the same thing but for users!

[jacksleight]

Yeah I think it'd be a nice feature to have. At the moment this PR only covers entries, the intention is to add the other types as well but there are a few implementation details I'm not too sure about right now.

[jasonvarga]

Isn't naming tough?

The entry edit view is using the same InlineActions component as the listing page uses, but its own HasListActions mixin.

I'd just call it HasActions too. The existing one is in the data-list directory and the new one is in the publish directory.

Because the word “actions” is already taken by the publish actions I’ve used “list actions” for these new properties (because they’re copied from the listing page). There’s probably a better name.

Naming it just actions makes the most sense, but I don't want you to have to mess with the existing stuff all over the place. Let's call them item actions instead of list actions. Yes they're copied from the listings but on the publish form that doesn't really makes sense IMO.

I’ve included a new publish_form key in the action context which allows actions to behave differently if they’re being run from the form. This is used by the delete and duplicate actions to redirect elsewhere after the action runs.

Can we have a view key with a form value instead?