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

Purpose of 'Approve only' option for publishers? #170

Open
MoritzLost opened this issue Nov 30, 2022 · 4 comments
Open

Purpose of 'Approve only' option for publishers? #170

MoritzLost opened this issue Nov 30, 2022 · 4 comments
Labels
feature request New feature or request

Comments

@MoritzLost
Copy link

MoritzLost commented Nov 30, 2022

Question

We're having trouble understanding the purpose of the 'Approve only' option that publishers have. We're using the plugin for a simple workflow where external editors can only submit new entries and changes to their own entries, but not publish them. Publishers can approve or decline those submissions. We don't use the reviewer role at all. Usually, the submissions are either approved immediately (Approve & publish) or declined (with a note asking for changes). However, the dropdown for publishers also offers an option to Approve only. This marks the submission as approved, but does not apply the draft.

From the editor's perspective, this is confusing. They get a notification that their changes have been approved, but the live entry hasn't changed and the draft still exists. Furthermore, the draft again gives them the option to submit changes for review, which they've already done at this point.

What is the purpose of the Approve only option, i.e. how is it supposed to be used? Does it only make sense if you also have reviewers that can approve but not publish? Is it possible to disable this option if it's not in use?

Thanks!

Additional context

No response

@MoritzLost MoritzLost added the question Further information is requested label Nov 30, 2022
@engram-design
Copy link
Member

I believe this was originally from #84 and #120 (comment)

And in particular:

Editor: "Am I going in the right lines with this page?"
Admin: "Yes, looks good - keep going" - "Approve only"
At that point they've been given the thumbs up on the draft, and can continue making changes, but it's not public yet.

Applying a draft will apply the changes in the draft on the entry, and deleted the draft entry. If this entry is already live, then those changes will appear immediately as live. Having the option to "Approve only" handles the case where changes have been made and reviewed, but it's not ready to go live. Or maybe the publisher is happy with the changes, but not ready to publish it (waiting for a date, etc).

In terms of letting the editor know about this difference, I'll agree maybe we should have different emails setup for those cases.

@MoritzLost
Copy link
Author

@engram-design Thanks for the explanation! I can see that this can make sense for some editorial workflows. It doesn't occur in our use-case, so my publishers were a bit confused about the differences. I agree, having different email templates would be an option. Is the difference between the two options somehow accessible in the email template through the submission or review objects? This would make it easy to add some explanation in the email template.

Maybe an option to disable the Approve only option for use-cases where it's not needed would be useful as well, what do you think?

@engram-design
Copy link
Member

We don't store the submitted state for whether it's been approve only or approved. I think adding all 3 of these things (store approve state, separate email templates, setting to show or not) would work best.

@engram-design engram-design added feature request New feature or request and removed question Further information is requested labels Dec 1, 2022
@MoritzLost
Copy link
Author

@engram-design That would be great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants