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

RESOLVED WONTFIX

Status

Mozilla Developer Network
Setup / Install
--
enhancement
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: groovecoder, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(URL)

(Reporter)

Description

3 years ago
https://etherpad.mozilla.org/Er4GiPZxbb
(Reporter)

Comment 1

3 years ago
: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?
Assignee: nobody → jbennett
Flags: needinfo?(jbennett)
I can start on it tomorrow.
Flags: needinfo?(jbennett)
\o/
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?
Flags: needinfo?(shobson)
Flags: needinfo?(lcrouch)
(Reporter)

Comment 5

3 years ago
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".
Flags: needinfo?(lcrouch)
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?
Flags: needinfo?(shobson)
(Reporter)

Comment 8

3 years ago
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.
(Reporter)

Comment 9

3 years ago
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?
Flags: needinfo?(shobson)
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.
Flags: needinfo?(shobson)

Updated

3 years ago
Severity: normal → enhancement

Updated

2 years ago
Assignee: jbennett → nobody
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.