feat: Add management command to create version objects

[fsbraun]

Description

This PR adds a management command to create (usually draft) Version objects for versioned content that lacks a Version object. This is relevant if one adds versioning to a project after unversioned content has been created.

usage: manage.py create_versions [-h]
                                 [--state {draft,published,archived}]
                                 [--username USERNAME] [--userid USERID]
                                 [--dry-run] [--version] [-v {0,1,2,3}]
                                 [--settings SETTINGS]
                                 [--pythonpath PYTHONPATH] [--traceback]
                                 [--no-color] [--force-color] [--skip-checks]

Creates Version objects for versioned models lacking one. If the
DJANGOCMS_VERSIONING_DEFAULT_USER setting is not populated you will have to
provide either the --userid or --username option for each Version object
needs to be assigned to a user.

optional arguments:
  -h, --help            show this help message and exit
  --state {draft,published,archived}
                        state of newly created version object (defaults to
                        draft)
  --username USERNAME   Username of user to create the missing Version
                        objects
  --userid USERID       User id of user to create the missing Version objects
  --dry-run             Do not change the database

Related resources

• #...
• #...

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.

[codecov]

Codecov Report

Merging #304 (46daead) into master (e880798) will increase coverage by 0.12%.
The diff coverage is 95.65%.

@@            Coverage Diff             @@
##           master     #304      +/-   ##
==========================================
+ Coverage   89.75%   89.87%   +0.12%     
==========================================
  Files          67       68       +1     
  Lines        2196     2242      +46     
  Branches      293      299       +6     
==========================================
+ Hits         1971     2015      +44     
- Misses        170      172       +2     
  Partials       55       55              

Impacted Files	Coverage Δ
..._versioning/management/commands/create_versions.py	95.55% <95.55%> (ø)
djangocms_versioning/conf.py	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Aiky30]

No test coverage, this is by far the leading package for anything created with the CMS, it could be a shame to lose that. Needs tests hence marking as needing changes.

A comment added for the version states.

[Aiky30]

I don't think that the state should be set, I think this needs to be calculated. The reason I think this is that you could have a grouper object (Page) with many content objects (PageContent), if you blindly set them all to draft you'll get an error where you can only have one draft, it could be that the state machine handles this and forces the existing version to archived, but it could be that the content objects are not in the correct order.

There's some additional complexities when filtering to find what other versions a grouper has because it can have grouping filters such as language.

[fsbraun]

This would be necessary for a "recovery". I was more thinking about a situation where you added versioning for a first time. Then there should only be one "Version" per grouper.

If we're thinking about recovery I only see one option:

• Only "published", "draft", and "archived" are valid as target states.
• If a draft or published version already exists the target state will have to be "archived"
• If multiple content objects per grouper (and grouping filters) exist without a Version object they are processed from highest pk to lowest pk.

As a result either all recovered Versions will be archived (if "archived" is selected) or all recovered Versions will be archived except the one created latest (by pk) which will be either draft or published.

[fsbraun]

What do you think?

[Aiky30]

To be fair, that would be a fair assumption what you have proposed. I was thinking more a corrupt setup.

If there ever as such an occurrence I guess we could point to documentation in the code that this solution is based on that assumption / scenario that you propose. There will be a day where someone comes with such a corrupt setup, maybe they manually deleted Version objects or something (I once did it trying to remove a package, this could be improved by fixing the deletion where you can delete things, a separate issue that I always wanted the time to fix, needs to simply change the source version).

My biggest fear of getting more people involved with V4 was just that, corrupt Version history. Maybe fix it when someone comes with it. I had done something similar although it doesn't handle other contenttypes i.e. Page / Pagecontent only, that was in the 3 to 4 migration package where the version states were kept.

[fsbraun]

I think I'm almost there. But the added complexity will require some tests. Will push an update later. :-)

[fsbraun]

@Aiky30 I've updated the PR. It will successfully recover missing Version objects even if there are multiple content objects per grouper. It also reflects additional grouping fields. A test is added that runs on models with (Poll) and without (Blog) additional grouping field.

[Aiky30]

Minor comments regarding the management command tests, the tests normally follow the AAA standard, this makes the test easier to follow. Minor and not blocking.