:ubernostrum - :shobson has a few pull requests and changes that need this for testing before we can merge. Can you start on it this week?
I can start on it tomorrow.
So, final things that need deciding: 1. Do we want to add some faked users in a fixture to be the authors of the revisions that will be imported? 2. If so, are we OK with randomly choosing one of them as an author for each revision?
1. Yeah 2. Yeah. Locally, I've used ./manage.py loaddata kuma/users/fixtures/test_users.json to get the 'testuser', 'testuser01', and 'testuser2' accounts into my box. Then I update my document dumps to make all revision "creator" properties to be "testuser".
Can I hand craft users with actual profile data to throw in the mix?
I need some demos too, will the script be okay handling those?
Users and data will be tricky to download - there's no ?raw=1 or API endpoints for them. Our best path for those is probably to create more/better fixture data and load it with `./manage.py loaddata` ... which could be part of the `./manage.py download` command too.
I.e., users and/or *demo* data ...
OK, *actual* final question, since this affects the complexity/time involved and possibly the load on our servers... Do we need the *full* revision history of the document, or is it reasonable to just grab some small-ish number of revisions? i.e., would it be OK to just grab the last 5 revisions? Could we get away with fewer?
It may be worth making sure that, when available, there are enough history entries to enact pagination of the history, so that pagination-related effects can be tested. Just my 2¢.
We need to populate pagination on the revision page and on user profiles, it isn't necessary to get all the revisions for all the pages but we do need pagination. Not sure what the best solution for that is. It's also necessary to have some to properly populate the translation interface but certainly 5 would be enough for that.