Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add allow_publish flag for editorial workflow #1298

Closed
erquhart opened this issue Apr 20, 2018 · 11 comments · Fixed by #3467
Closed

Add allow_publish flag for editorial workflow #1298

erquhart opened this issue Apr 20, 2018 · 11 comments · Fixed by #3467

Comments

@erquhart
Copy link
Contributor

- Do you want to request a feature or report a bug?

enhancement

- What is the current behavior?

Publishing can't be disabled in the editorial workflow. You generally wouldn't want to, but for folks that use multiple cms instances to approximate a roles based setup, it would be beneficial to switch editorial workflow off on certain instances so that users of those instances can only open pull requests, but can't merge them.

This would help (but not fix) #2 and #1268.

- What is the expected behavior?

Allow publishing to be disabled.

@erquhart
Copy link
Contributor Author

cc/ @futuregerald

@springdo
Copy link

Hello team! we were up until recently hiding the button for publish using some CSS but now that the styles are inline we cannot remove the button. I would like to see a flag or config as described here to show the button or hide it based on some config file param.

Is there a good development guide or would this be an easy issue to start with if you would accept a PR?

@Destroy666x
Copy link

Destroy666x commented Nov 7, 2018

Ability to at least disable it is pretty much necessary IMO, for security reasons. What would be great is basing it on roles, but I see there's a separate issue for that and similar cases, e.g. blocking access to gallery for everyone except admins.

@Yttrium-tYcLief
Copy link

Yttrium-tYcLief commented Dec 1, 2018

This feature request would 100% cover what I want to do with my website, where I want anyone to be able to sign up and then edit content and submit it for review, but not be able to publish it themselves, sort of like how pull/merge requests work by default on Github/Gitlab respectively.

Currently I'm not using any external CMS, but just pointing them at the Gitlab edit button, which automatically takes users through the account/fork+commit/merge request workflow. The problem is that, while it's still pretty user friendly compared to asking them to learn Git in the first place, it could be a lot more friendly. Netlify CMS looks perfect for what I'm after, but without this feature it's unfortunately useless to me.

It should be noted that while this feature request would work for me, #1268 or #2 would also work. The difference is that #1268 would limit attribution to just 'visitor' instead of giving edit credits to the contributor, and #1298 would mean that reviewers would either need a separate CMS instance, or would have to accept PRs manually through either Git or the Gitlab web interface (and by extension be granted universal write access to the repo). #2 would be the cleanest solution for all of these problems, but it's much more extensive of an undertaking.

(Adoption of Netlify CMS in my situation is also being held back by the fact that Gitlab is not yet supported in the editorial workflow feature, but that's currently being remedied by #1817 which looks like it'll move upstream within a month or two)

@erquhart
Copy link
Contributor Author

erquhart commented Dec 3, 2018

@Destroy666x note, security is a big part of why we haven't done this. It's a superficial barrier, as anyone that has the necessary write access to use the CMS will also have write access to merge PR's in the underlying service. We want to avoid a false sense of security.

That said, I'm still in favor of doing it, just know that it doesn't improve security at all.

@Destroy666x
Copy link

Destroy666x commented Dec 4, 2018

@erquhart Hmmm, right now you can setup Netlify to use a git-gateway GH account that pushes changes from CMS. I'm not sure I understand how that provides repository merge permission to other GH accounts, assuming Netlify Identity users would have publishing disabled. Can the authorized account be used outside of available CMS actions?

@erquhart
Copy link
Contributor Author

erquhart commented Dec 4, 2018

Git Gateway is the exception, true.

Sent with GitHawk

@Destroy666x
Copy link

Yeah, and for making that type of workflow secure the only thing that's missing is this.

I might try working on a solution this weekend.

@stale
Copy link

stale bot commented Oct 29, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@andy-mcdonald
Copy link

We're using the "multiple instance" method alongside Git Gateway to approximate roles, exactly as @erquhart described. Unfortunately, not being able to restrict publishing to certain users is a non-starter for our client so I'm keen to know if any work has already been done, and where the best place to start would be?

@erezrokah erezrokah self-assigned this Mar 19, 2020
@erezrokah
Copy link
Contributor

erezrokah commented Mar 19, 2020

Hi @andy-mcdonald, I don't think there has been any real progress regarding this issue.
We've had a comment on slack of someone that managed to use protected branches to simulate roles:
https://netlifycms.slack.com/archives/CPRR0PQ9E/p1583355032112000?thread_ts=1582829171.065500&cid=CPRR0PQ9E
but that's more related to #2 and even less relevant for git-gateway and multiple instances.

I think a quick and easy fix we can do for now is add a flag on a collection and use it here:
https://github.com/netlify/netlify-cms/blob/ab7ba435baf07862e7adbfaf0f6cd9950af7ad52/packages/netlify-cms-core/src/components/Workflow/WorkflowList.js#L217

to disable/hide the publish button.

We can make it clear in the docs this only disables the UI button and in order to enforce it one would need multiple instances setup or something similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment