Migrate all Sponsor data to the database.

[ewdurbin]

What's the problem this feature will solve?

Currently due to copyright and trademarks that are incompatible with the license of this repository, PyPI uses a private repository pypi-theme to store Sponsor logos.

These logos are rendered on the sponsors page using this template and this include.

We also render them in the footer using this include which references the dataset in the aforementioned include.

And finally we render a subset of sponsor logos in the sidebar again using the same aforementioned include.

At this point, the only reason we have the pypi-theme repo is to house the Sponsor logos.

This makes @di and myself a bottleneck in updating sponsors and their logos on pypi.org.

Describe the solution you'd like

We should create a Sponsor model in the warehouse database that stores all of the various information encoded into the sponsors include, as well as the ability to store an image in our object store that can later be referenced when rendering the page.

Then, we should update the rendering of sponsor logos throughout the site to use this model.

Additionally a new is_sponsor_admin column should be added to the User model which we will use to grant a new permission sponsor_admin in the admin views to a newly created admin panel to manage Sponsors. Users with sponsor_admin permissions should only be able to make changes to the Sponsor objects. You can see a similar behavior for the moderator/is_moderator permission/column in the admin app.

[ewdurbin]

This work will be done on behalf of the Python Software Foundation by @berinhard.

[ewdurbin]

These views currently render the "static" parts:

• sidebar includes view
• sponsors page template view.

They will need to be updated to query the database.

[ewdurbin]

For storing the Images, I think that will be blocked by me adding a new static bucket. In the meantime, please get started moving ahead simply storing a URL for the color and white logo options.

Also admin permissions may be a bit complex or difficult to handle, in the meantime, assume that all views can be guarded similar to the existing admin views so that only 'super user's can access the Sponsor panels. This may need input/review from @dstufft.

Other feature notes:

• We probably want an is_active flag for each Sponsor so that they can be added prior to a "go live" date.
• We probably want to leverage our cache purging feature to make updates render on next page load.

[dstufft]

Super user only is a pretty safe default. We'd only need to worry about anything more fine grained than that if we have a desire to grant someone the ability to manage sponsors without giving them full admin privileges.

[berinhard]

Hey @di, how are you? The next thing to improve the new Pypi sponsors admin is to have this specific sponsors_admin permission to manage only sponsors data. @ewdurbin told me you would be the best person to guide me through this and that's why I'm pinging you =)

From my initial research, I've wrote down a few changes I think I'll have to do to add this. Can you review them and point me to anything else I'm missing or things I should be aware of?

1. Add a new is_sponsor_admin boolean column to the User model;
2. Add a new (Allow, "groups:sponsor_admins", "sponsor_admin") security policy to warehouse.config.RootFactory.__acl__;
3. Update the _authenticate method to check against sponsors admin. An admin is both a moderator and sponsor admin;
4. Update admin's sidebar view view_config decorator to allow sponsor_admin users to access it;
5. Only displays "Sponsors" section in the sidebar HTML for a sponsor admin;
6. Update view_config decorators for every sponsor admin view by changing permissions;
7. Update admin's UserForm, detail.html and list.html the with the new is_sponsor_admin boolean;
8. Unit test everything, of course =)

Thanks for your time!

[ewdurbin]

I think @dstufft might be more helpful with the authorization bits. Sorry if I misspoke.

[ewdurbin]

Otherwise, might want to generalize the permission name from sponsor_admin to something more like psf_staff since I believe #9525 will need the same access level.

[di]

I'm not @dstufft but that sounds like a good plan to me 🙂

I agree with @ewdurbin that we should generalize this to psf_staff.

[berinhard]

Thanks for your comments! Certainly I was the one making confusion about the @ =}

[di]

@ewdurbin Is this done now that #9794 is merged?

[ewdurbin]

Indeed!