Addons: allow users to opt-in into the new addons

[humitos]

We have deployed the new addons for projects using build.commands and it has been working fine. We haven't received any complain and I've already saw users jumping into build.commands because they have the flyout there as well (see readthedocs/readthedocs.org#10706)

Also, we've found a way to "migrate old projects/builds using the old integrations to the new one" dynamically using a Cloudflare Worker (see https://github.com/readthedocs/readthedocs-ops/pull/1402).

However, we can't do this migration automatically for all the projects because it won't look exactly the same. We will be moving the flyout from the bottom left being integrated into the navbar, to the bottom right being fixed in a floating position. I created an issue in the theme to make this integration to look exactly the same at readthedocs/sphinx_rtd_theme#1523 -- but it needs a non-trivial amount of work for that to define the exact addons API, work on JS/CSS, release a new version, wait for people to migrate to this version, etc.

We can follow a simpler path here: "allow users to opt-in into the new addons". When opt-in we can communicate these differences (look&feel changes and extra features) and they can disable if they don't like it. This will give users the features we already have in the new addons immediately to them, it will allow us to gradually roll this out and fix issues as we go and also give us feedback about that integration into the theme should be.

Related:

• Addons: create project admin page to configure addons #211
• https://github.com/readthedocs/readthedocs-ops/pull/1402
• Integrate the new addons flyout into the theme sphinx_rtd_theme#1523

[agjohnson]

This would be an easy UI to get started on. The template work will be minimal, we just need the Form and View instances. After that, templates would add a Project -> Admin -> Addons UI, basically just showing the initial Form instance.

There is definitely a long term plan here and a short term plan. I talked about this in another issue that I am not finding now.

In the short term our Form would be a simple form with "Enable addons beta", or maybe even "Enable flyout beta". But we wouldn't reuse this Form long term, so it wouldn't be a good candidate to build on top of.

Long term, the goal would be to have a Project -> Admin -> Addons -> Flyout sub-admin page, with separate Form class for each addon configuration. I'd want to probably try with using a tabbed interface and multiple form instances first, as otherwise we need to create a lot of redundant views/templates/etc.

So, I'd say it's 100% okay to start with a basic form for "Enable this beta", understanding we won't build on top of this.

But, also, if we feel we already want per-addon configuration this may not be too much more work, so could be a place to start as well.

[agjohnson]

For assignment, I'm happy to help with the ext-theme changes, but they will also be very small to start, and mostly just duplicating existing templates. @humitos would you like to start with the form/view/url additions here first? I've assigned us both for now, but it might be easy enough to add all at once too.

[humitos]

I see two different approaches here:

1. add a Project.force_addons_enabled (bool) with a simple project's form that only exposes that field and template that shows it
2. add a Projects.addons (foreign key) to a new model AddonsConfig that contains all the configs for each addon. Then we create one Form per addon

[humitos]

I went ahead and opened readthedocs/readthedocs.org#10733 and #213

[agjohnson]

add a Project.force_addons_enabled (bool) with a simple project's form that only exposes that field and template that shows it

This sounds like what we are wanting immediately, for this issue -- just the beta opt in/out.

add a Projects.addons (foreign key) to a new model AddonsConfig that contains all the configs for each addon. Then we create one Form per addon

And this sounds like the continuation of this work that we'll want for #211. Or we can continue thinking how we'll lay this out in code more, I don't have strong opinions on the modeling structure.

Does that match what you're thinking too?

[humitos]

Yeah, but I went ahead already and implemented both of them: the immediate requirement (enable/disable beta addons) and the underlying modeling needed to allow users customize the addons --which is currently not exposed to users yet.