Our fake data plan will throw some random apps into all of the review queues in various states. That's great from a development point of view, but it's hard to train new reviewers on because the data is random. This bug is about creating a script which, using the API, will upload several known apps for use as training tools. Andrew is going to attach a half dozen apps with assets and metadata to this bug. I'm assuming something like: > manage.py seed_onboarding_data --api-key=xxx which will just automatically upload all the apps and put them in the review queue with the appropriate screenshots, titles, etc. Running the command multiple times should put multiple copies of the apps in the queue (now that we allow duplicate origins this shouldn't be a problem).
Created attachment 8526392 [details] facebook.zip This is a sample of one of the apps we would want adding. Feedback on the format/content of the metadata would be useful (I just copied from the app details page and reformatted). When the feature is close to implementation we can provide the complete selection of apps.
I've got an initial version done here: https://github.com/mozilla/Marketplace.Python/pull/35 Right now it expects to run on a server that accepts 0 as an IARC code. Any thoughts on where this code ought to live? Might should put it in its own repo.
Don't the other fake data scripts live in zamboni? Wouldn't it live next to them?
They do; the difference is that this one uses the submission API rather than directly modifying the database. Who is expected to run this tool, and for what deployments? The other fake data script was primarily intended to be run as part of setting up a new database.
Interesting. Even if it's using the API, why would it live elsewhere? This tool is expected to be run by ops at the request of senior reviewers. The other fake data script is intended to be used by developers setting up a new database, but it's also intended to replace our production->stage/dev sync, eventually allowing us to generate large amounts of fake data to use on our staging and development instances.
OK. I'll move this into the zamboni repo; I thought the intent was for senior reviewers to run it themselves.
(In reply to Allen Short [:ashort] from comment #6) > OK. I'll move this into the zamboni repo; I thought the intent was for > senior reviewers to run it themselves. They still could, I just think keeping everything in the same spot helps people keep track of all the scripts and know their options. Thanks.
After you upload to zamboni can you modify one of the templates to show all supported fields so I know what to provide (and if anything is missing)
Moved to zamboni. https://github.com/washort/zamboni/compare/1101096 The issue of getting IARC ids for these apps is unresolved so far. Supported fields for app submission are listed here: http://firefox-marketplace-api.readthedocs.org/en/latest/topics/apps.html#app-response-label
Random idea in the middle of the night: How about adding a permission that bypasses IARC (generates random, I guess?) and then checking that the user with the --api-key that is passed in has permission to use it that way. Someone come up with something better, that sounds a little complex. :)
We already allow on local deployments to use 0 for IARC keys. We could extend that to certain users, yes.
Redid this using the existing fake-data loading tools, expanded to cover reviewer needs. https://github.com/mozilla/zamboni/commit/8d45ad962b1940edbcc6bfddc3eac343b893c7f4
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2015-03-17
You need to log in before you can comment on or make changes to this bug.