feat: Simple publishing beginning and end dates

[fsbraun]

Description

Based on the discussion #340 this PR uses the power of djangocms-versionings' abstraction and introduces an option to limit the visibility of a published content object in time.

UX

• New option to publish from the versioning menu (The "Publish" button does not change behavior.)
  

• The menu brings up a modal allowing to select time limits for the visibility of the to-be-published version:
  

• Technically, the time limits do not affect the published status but only the visibility. This means, dates on published versions cannot be changed any more. You'd need to create a new draft and publish that to make a change.

• Versioning menu shows pending or expired visibility dates. "pending" is a word for a published version that is not yet visible. "expired" is a word for a published version not visible any more:
  

• View published button for PageContents is only offered for pages which are currently visible (since otherwise they'll show a 404)

• Pending or expired aliases render empty.

Tests

This is a proof of concept for discussion. Tests will need to be added and also some informaion on the changelist for versions.

Tests fail since the version admin's publish_view now also accepts a GET request which renders the form for time limits. Tests have now been adjusted, yet

Issues

• Missing tests
• Menu caching

Related resources

• Publish begin- and end-date #340

Checklist

• I have opened this pull request against master
• I have added or modified the tests when changing logic
• I have followed the conventional commits guidelines to add meaningful information into the changelog
• I have read the contribution guidelines and I have joined #workgroup-pr-review on
  Slack to find a “pr review buddy” who is going to review my pull request.

[Aiky30]

The biggest concern I have with this is that over time people will raise issues with how they want the publishing to work, with the sponsor of V4 this feature escalated quickly.

I believe that this should be a separate package that extends versioning. Reasons for this:

1. I can see the featureset for this escalating quickly from community feedback.
2. It shows others how it can be done if they want it to work radically different, by giving them an example of how they can create something radically different in a 3rd part package.
3. Provides a separate package where the feature set can be configurable / extendable without poising the versioning codebase.
4. It separates the concerns and prevents versioning getting even more complex than it already is
5. It follows the philosophy of V4 closer by having many simple things do something complex, the simple things being packages.

I realise it's more of a challenge to make things as separate packages, but it does then require design and thought to make it work properly, I've seen on many occasions that you have good imagination and the ability to make it work.

Proposed package: djangocms-versioning-scheduled-publishing

[marksweb]

Yes, that point about it providing an example of how to extend functionality is real key one thay we should be able to demonstrate at launch.

And I don't actually know how it's done yet. I'd have a stab at it if I did.

I've got more thoughts but little time. The spiral of complexity is a big one. And nobody has even brought up timezones yet. 😬

[jrief]

Thanks for adding this important missing piece to djangocms-versioning.
I just tested this pull request, but there are some issues:

• If an anonymous (or non-editing) user access a page which has status="pending", in my opinion it should either send status 404, or better 410 - Gone. Instead the user receives a page without content.
• The list view for versions should also display status="pending" rather than "published", otherwise it becomes very confusing for the editor because he doesn't recognize that a designated "published" version in reality is still pending. This information is only available when visiting the page directly.

@Aiky30 I get your point about separating this feature into another package. However, how would you implement it? And since it seems that some work has already been done, is this available?

I probably will implement this PR into our installation anyway, because it's a feature our users expect since it was available in CMS3. And I can't wait until a new package emerges anytime.