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

RFC 21: Scheduled publishing for revisions #21

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@hakjoon
Copy link

hakjoon commented Oct 13, 2017

This RFC proposes adding the ability to schedule page updates by not unpublishing pages when new revisions are scheduled.

Rendered Version

@hakjoon hakjoon changed the title RFC X: Scheduled publishing for revisions RFC 21: Scheduled publishing for revisions Oct 13, 2017

@tomdyson tomdyson requested a review from mvantellingen Oct 18, 2017

@tomdyson

This comment has been minimized.

Copy link
Contributor

tomdyson commented Oct 25, 2017

Thanks very much for this, @hakjoon. The core team's discussion of this was delayed by last week's sprint, but we're looking at it properly today.

@gasman

This comment has been minimized.

Copy link
Contributor

gasman commented Oct 30, 2017

Thanks @hakjoon! After much pondering and stepping through various permutations of page statuses / user actions, I can't see any issues with the logic here. I suspect the only reason we didn't allow simultaneously live and scheduled pages is that the scheduling feature was implemented before we had a 'page revisions' view in the admin, and without revisions as a user-facing concept it would have been too unclear what was going on.

I just have one addition to the open questions: once a page has been scheduled for publishing at a future date, how do we cancel that? To be fair, I think this question exists on the current implementation too - but having to make it work without clobbering an existing live revision would add an extra layer of complexity. I think the best answer we can offer as it stands is:

  • if it's a currently live page, roll back to the live revision (which should either have a go-live date in the past or an empty one) and publish that
  • if it's not a currently-live page, clear the go-live date, and publish then immediately unpublish the page

Responses to the open questions:

Currently there will be no status change to indicate a new revision is scheduled. Do we need another status like [live + scheduled + draft]?

Yes, this seems like a good idea. Generating this status string will not be particularly efficient, since we'll need to look for a revision with approved_go_live_at for each page in the listing, but we already do that for non-live pages anyway.

I think we also need some better messaging on the edit page to communicate the fact that a revision is scheduled, and/or the current draft revision has a future go-live date filled in, since these will cause the publish action to have unexpected effects. I'm happy with your proposed workflow for making changes to the current published revision while a scheduled revision exists, but I have visions of an editor in a mad scramble to fix some unacceptable content on the live version, not noticing that the go-live date is set to some future date, and finding that hitting 'publish' is having no effect on the live page...

Can we have multiple scheduled revisions?

No - I think this would introduce some altogether bigger snags to the logic, which would need extensive user interface updates to resolve. For example, when setting up a scheduled publish for a page that already has a revision scheduled, we'd need to distinguish between "schedule this version instead of the one that's already there" and "schedule this version in addition to the one that's already there".

Should Go live time be limited to certain permissions?

No, I think this should be specified as a separate feature. The interaction between scheduled publishing and moderation workflow is logically sound as it stands: any go-live / expiry date set on the draft version and submitted (rather than published) is treated as a request for the moderator to approve, rather than something that's binding immediately. As far as I can see, the current proposal would continue to work under this model.

@hakjoon

This comment has been minimized.

Copy link

hakjoon commented Oct 31, 2017

What's the procedure at this point, should I update the document with the answers to the open questions? Is one person's set of answers enough? Should I add the new question?

@gasman

This comment has been minimized.

Copy link
Contributor

gasman commented Nov 3, 2017

@hakjoon Yep, please update the document with my answers if you're satisfied that they resolve the questions. Once all the remaining open questions are crossed off, the RFC can go into "final comment" status where there's a week or so's window for anyone else to provide feedback - if no showstoppers come up at that point, it can be approved.

@loicteixeira

This comment has been minimized.

Copy link

loicteixeira commented Nov 5, 2017

@hakjoon Although it's only @gasman commenting, this has been discussed during the core meeting so you can take it as just more than one person's opinion., we all agree with his comments.

@tomdyson

This comment has been minimized.

Copy link
Contributor

tomdyson commented Nov 15, 2017

Hi @hakjoon - are you happy to update the document with @gasman's answers?

@hakjoon

This comment has been minimized.

Copy link

hakjoon commented Nov 15, 2017

@tomdyson I pushed a revision incorporating @gasman's answers. Sorry for the delay in getting this pushed.

To address the new question about cancelling scheduled publishes I think we can tackle
Once a page has been scheduled for publishing at a future date, how do we cancel that? and No indication of which revision is scheduled together.

Thought is if a revision has a go_live_date, which should only happen if it is scheduled we could display a (scheduled) indicator in the revision history. Along with that we could expose a new button along Preview, Review, Compare for [Cancel scheduled publish] which would remove the go_live_date. I'm probably missing a piece but that seems like it would leave the current revision as the live one, and on a non live page it would return to Draft. I have not tested this out yet though.

@tomdyson

This comment has been minimized.

Copy link
Contributor

tomdyson commented Nov 15, 2017

Thanks for the update, @hakjoon. @gasman do you have any thoughts on this?

On a different point, it would be great if development planned here was able to dovetail with @Gagaro's very interesting https://github.com/Gagaro/wagtail-calendar project.

@hakjoon

This comment has been minimized.

Copy link

hakjoon commented Nov 21, 2017

I added a PR with an initial implementation. It does not address everything yet but the main functionality is there.

@hakjoon

This comment has been minimized.

Copy link

hakjoon commented Dec 5, 2017

What needs to happen at this point for this to progress? Anything I missed from my side?

@gasman

This comment has been minimized.

Copy link
Contributor

gasman commented Dec 6, 2017

@hakjoon Nope, all good thanks - we'll pick up from here. I'll review your PR and deal with merging in the final version of the RFC text.

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