The code changes look good to me, but a couple of questions/notes:

1. Should we not also prevent the selection of the base theme for the other UIs?
2. Perhaps a better approach would be to filter these options out at an API level (including the setting of a theme)?
3. Should we provide a database migration to unset the base theme if it has been set by the user?

1. Other themes like email and login can still use base as a starting point for theming. So it still needs to be there.
2. I'm not sure if that's a good idea or not. The base theme still technically exists for admin and account. I'm not sure if there would be some side effect of filtering it at the API level.
3. Maybe. But the base theme was really never meant to be used on its own. So I don't see how anyone would have it set to base in a migration scenario. I do admit it's possible though. This PR is just to prevent catastrophic failure if someone sets the theme to base by mistake. I think providing migration would be a wasted effort.

1. Other themes like email and login can still use base as a starting point for theming. So it still needs to be there.

Ok, good to know, that might change in the future, but indeed is not relevant for now. Let's leave this as-is.

2. I'm not sure if that's a good idea or not. The base theme still technically exists for admin and account. I'm not sure if there would be some side effect of filtering it at the API level.

Not sure what the fallout would be, but I think this would still be the best place to solve this. In the spirit of keeping the front-end as 'dumb' as possible, which is something I believe @stianst feels strongly about. Also this would prevent us (or others) from having to re-implement this in the future for other/newer UIs.

3. Maybe. But the base theme was really never meant to be used on its own. So I don't see how anyone would have it set to base in a migration scenario. I do admit it's possible though. This PR is just to prevent catastrophic failure if someone sets the theme to base by mistake. I think providing migration would be a wasted effort.

There are already users that have ended up in a situation where they have set the theme to base (including reports from the issue this PR closes), so I don't this this is an extremely unlikely scenario. In any case, setting the theme to base for the new Account and Admin consoles should be considered harmful, so I think a migration might be sensible here.

I am approving this since it addresses a quite critical problem, but I still feel we need a more complete solution in the future. But perhaps that is better addressed somewhere else.

Definitely agree. That's why I opened #22671.

There are already users that have ended up in a situation where they have set the theme to base (including reports from the issue this PR closes), so I don't this this is an extremely unlikely scenario. In any case, setting the theme to base for the new Account and Admin consoles should be considered harmful, so I think a migration might be sensible here.

This PR only addresses the situation where they set the theme to base and it locked them out. It is extremely unlikely that anyone has set their theme to base in a production situation that would need migration.

Some may have extended the base theme. But there is no migration available without re-introducing AngularJs or fixing #22671. And come to think of it, even if someone did use base theme in production they would have the same problem. There is no way to safely migrate at the moment.

Passing run #8645 ↗︎

0

527

48

0

0

Details:

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}