1075135 - Create manage.py "download" command for local development data

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Setup / Install, enhancement)

Description

[Luke Crouch [:groovecoder]]

https://etherpad.mozilla.org/Er4GiPZxbb

Comment 1

[Luke Crouch [:groovecoder]]

: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?

Comment 2

[James Bennett [:ubernostrum]]

I can start on it tomorrow.

Comment 3

[Stephanie Hobson [:shobson]]

\o/

Comment 4

[James Bennett [:ubernostrum]]

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?

Comment 5

[Luke Crouch [:groovecoder]]

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".

Comment 6

[Stephanie Hobson [:shobson]]

Can I hand craft users with actual profile data to throw in the mix?

Comment 7

[Stephanie Hobson [:shobson]]

I need some demos too, will the script be okay handling those?

Comment 8

[Luke Crouch [:groovecoder]]

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.

Comment 9

[Luke Crouch [:groovecoder]]

I.e., users and/or *demo* data ...

Comment 10

[James Bennett [:ubernostrum]]

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?

Comment 11

[Eric Shepherd [:sheppy]]

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¢.

Comment 12

[Stephanie Hobson [:shobson]]

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.