Add a publish access control to disable publish button and only allow to save versioned documents

[ghost]

Hi 👋🏻

As discussed in the Discord it could be cool to have a new access control for managing who can publish a document. This way we could create roles such as editor and publisher with this kind of scenario:

• The editor can create a document and save it (like blog post) but can't publish to make it live on the website (the button should not be visible if publish: () => false)
• The publisher can check what the editor did (verifying typos, whatever else) and publish the document if everything is good.

For further ideas, it will be really useful for creating workflows inside the CMS (like a state machine X has done this, then Y can do that, with notifications like "John finished to write the post "PayloadCMS is amazing!!", could you review and publish?")

[jmikrut]

Thank you for the feature request!

I just had a thought. This may be possible in a better way than adding another publish access control function just to show / hide the button.

On the frontend, we are going to update the way that we execute access control and we could work in a smarter way to determine if someone can publish simply by attempting to execute the existing update or create access control, and passing _status: 'published' as data. This would be a dummy execution of the existing access control, but if we receive false as a result from the create or update access control, then we would simply automatically hide the button.

I think this is a better way to handle this, because then you handle everything in one place.

So let's take create access control for example:

const restrictEditorsToDraftsOnly: Access = ({ req: { user }, data }) => {
  // Only logged in users can create or update
  if (user) {

    // Let's say we have a 'roles' field
    // If the user is an admin, then they can do whatever
    if (user.roles.includes('admin')) {
      return true;
    }

    // Otherwise all other users can only create or update
    // if they have NOT passed data._status === 'published'
    return data._status !== 'published';
  }

  // Not logged in? No user? Can't do it
  return false;
}

This is how your access control should be written anyway, so if Payload can smartly reuse this access control function on the frontend to determine if the user can submit data._status === 'published', as a dummy "test", then we can show / hide the publish button!

What do you think? This would be super seamless.

[ghost]

I agree with you, it would be a really cool way to go this way just by the fact it feels overall "logic" that control access may behaves like this.

On another hand the publish control access make it more straightforward to set and understand who can publish, and who can't, without having to process the document status in the reflexion.

Moreover, it seems to be limited for the time we need to update the document after publication and redo the process editor write, admin review and publish without un-publishing it first, but maybe it is not a big deal neither.

Other idea: an approve system like the one we have when we create pull requests in Github.

out of scope/topic
This make me think it could be cool to have small examples in the repo with how to do this or that, the same way Vercel are doing in their repo, like the with-typescript for example but it could be with-publication-access in this case (or a better name I'm not good at giving names 💀)

[jmikrut]

Hey @antoine-lin - this is all gold.

Moreover, it seems to be limited for the time we need to update the document after publication and redo the process editor write, admin review and publish without un-publishing it first, but maybe it is not a big deal neither.

I think that my suggestion will still handle this, as editors can create newer drafts of already published posts. They would be able to save drafts, but just not publish changes. I think this would work well!

Other idea: an approve system like the one we have when we create pull requests in Github.

This is possible to build right now with Payload's existing functionality, but it would take some manual effort. We do plan to release a plugin to handle this though.

PS - we are absolutely going to be building a suite of examples. This is on our list of things to accomplish. We're about to scale up the team and do exactly that!

[cerize]

Hello! First, congratulations on this project, our team in doing a lot in a short period of time!

@jmikrut I am wondering if there is any update in this feature request? Or any work around we could use? Our MVP requires that a creator can create recipe drafts but only an editor can publish them.

[jmikrut]

Hey @cerize — thank you for the kind words!

We have added this to our roadmap and marked as priority 2. This means it will likely be launched in Q2 2023, because we have a lot of super exciting stuff marked as Priority 1 at the moment.

Here's the thread:
#1324

For now, as a way forward, you need to write access control like the above - where you restrict who can update based on the data that they pass. This won't change the Publish button, but it will prevent users from actually being able to published. It will throw an error that says that they are not allowed.

[jmikrut]

Hey all, this has been completed!

if you have access control that limits the update or create operation based on incoming data, say data._status !== 'published' or similar, we are now automatically deducing a user's ability to publish by “faking” a submission to the /api/[collectionSlug]/access/[id] endpoint.

If the access control allows it, great, but if it blocks it, then we know the user can’t publish and then we dynamically hide the publish button for those cases!

Related PR

[linus-ha]

Hey @jmikrut, thanks for letting us know. This is in general a great Idea, but there is a small problem associated with that approach. When a user wants to update a published article, the UI test with _status = "published" instead of draft. When having access control set up in a way that update operations with _status = "published" are not allowed, the user now has no way to create a new draft, even though he is allowed to.

  access: {
    update: ({ req: {user, data} }) => {
      if (user) {
        return data?._status !== 'published';
      }
      return false;
    }
  },

In addition:
I do not see how you could prevent someone from publishing an old version (from the versions list).

I am on v3. Sorry for mentioning your handle, was not that smart in hindsight. I will create an issue.

[karlguillotte]

@linus-ha

I am facing the same issue, curious to if you have found a solution ?

Thanks!