Automate submissions

[tacitus]

Edit @loicteixeira:
The actual proposal (scope) is linked below.

---

Rough plan:

• Let users add their own dev pages
• Let users add their own sites, including snapshots (eeek! file uploads essentially public - Could partially be mitigated by s3 hosting for images)

[thibaudcolas]

On site screenshots – at the moment the site's layouts only work if the image is an annoying 1440x1200 (those exact numbers or that ratio, unsure). If we do expect third-party users to upload their own images, we should make sure that:

• There is an indication of the expected size(s) / ratio(s).
• The site's UI can handle images of varying sizes / ratios.

See #31 (comment) for an analysis of screenshot size requirements.

[loicteixeira]

So users need:

• To be able to register
• A developer page pre-created (but not published)
• A dedicated permission group, only allowing them to add/edit their dev page and its children but not publish it (so we can moderate, not 100% automated, but much better than what we have)
• A dedicated collection so they don't see/modify other users images

As for images size, surely we can setup the image filter to crop to those dimensions? So if the user don't respect it, it might not look the best but it doesn't break the layout.

[thibaudcolas]

From @johnanders123's input over Slack, we will also need:

• Password policy enforcing (https://github.com/springload/wagtailenforcer)
• Captchas (https://github.com/praekelt/django-recaptcha) - determine for which form(s). Account creation?
• Consider not enabling account on creation, requiring separate admin action.

Edit: IP whitelist is easy to disable

Edit: I intend to trial this whole user registration flow manually and see what happens.

[thibaudcolas]

Here is the permission set up I made manually:

• 1 collection with name = Developer profile name
• 1 group with name = Developer profile name
• Object permissions = None
• Can access Wagtail admin = Yes
• Page permissions = Add, Edit, Lock over the Developer profile
• Document permissions = None
• Image permissions = Add, Edit over the dedicated collection
• n user accounts as part of this group

It doesn't take me much more time to do this once than to set up the usual pages, so I'll look for volunteers to try this out.

[loicteixeira]

A solution is currently being discussed and estimated at Springload, and will hopefully be resourced shortly.

[tacitus]

@mojeto - please speak to @loicteixeira about the current state of the solution for this one.

[loicteixeira]

At a high level, the work will happen in steps:

1. Create a sign-up form so which will create a use, a developer page, a collection (for images and documents) and a group with limited permissions to those elements.
2. Create a script which, with the old submission data (form the existing form), will try to retroactively create users, collections and groups and match them with the existing pages (as much as possible).
3. Communicate the account to developers.

See the full proposal and estimate for more background and details.

[mojeto]

Current WIP solution:

• creates:
  • a new user
  • a new developer unpublished page
  • a new image collection
  • a new permission group with all necessary permissions
• signs in the new user
• redirects user to wagtail admin

Pros:

• all in one go

Cons:

• User forced to choose a unique username.
• User email isn't unique
  • Easy solution - validate email uniqueness in the sign up form
  • Hard solution - migrate django user model to our own version
• User email isn't verified
• A new user can't join existing Company/Developer

Solution discussed offline with @tacitus

• Use django-allauth to do sign up through social accounts only (Twitter, Facebook, Google, Github to start with)
• Workflow would be
  • User signed up by social account
    • a new user created (done by allauth)
    • user signed in (done by allauth)
  • User redirected to a new Company/Developer create page
    • a new developer unpublished page created
    • a new image collection created
    • a new permission group with all necessary permissions created
  • User redirected to wagtail admin

Pros:

• social login is easier to use
• email verification can be easily turned on

Cons:

• Sign up and automate submission isn't a single step for user.
• A new user can't join existing Company/Developer
  • The same problem as before, but can be harder to get around it as it's harder to share user's social account within company than username/password credentials.

[mojeto]

django-allauth can't be used together with Wagtail till the clash between Wagtail Site and Django Site resolved. Some work is being done, but it's a blocker currently.
related issues here and here

[loicteixeira]

As discussed offline, we should not forget that we will need to create accounts for the developers pages which already exist so we might need to keep the email login for them.

[drummonds]

Thanks I have just run into this clash as I added allauth to my project.