Custom domains: don't allow adding a custom domain on subprojects #8953
Conversation
| <p class="help_text"> | ||
| {% blocktrans trimmed with docs_url='https://docs.readthedocs.io/page/custom_domains.html' %} | ||
| Configuring a custom domain allows you to serve your documentation from a domain other than "{{ default_domain }}". <a href="{{ docs_url }}">Learn more</a>. | ||
| {% endblocktrans %} |
There was a problem hiding this comment.
so, not sure if we should show both messages when this is a subproject.
There was a problem hiding this comment.
I think it makes sense to just show one block. We have discussed on another issue that a better UX would be to show the form as disabled, but we can come back to this as well. There are maybe a few patterns to figure out there.
| </p> | ||
| {% if superproject %} | ||
| {% url "projects_detail" superproject.slug as superproject_url %} | ||
| <p class="help_text"> |
There was a problem hiding this comment.
don't think we have something like a class for a "warning" banner.
There was a problem hiding this comment.
We do not, not yet at least!
|
I haven't had a chance to pull this down locally to test, what does the UI look like with this addition? I'm assuming looking at the code that this doesn't alter the actually domain form UX, it just adds a warning block to the page. I feel this is a good compromise, even though good UX here would probably be to block this scenario entirely and only allowing subprojects to remove existing domains. I assume if we dug into the data here, we'd only have a handful of projects in the particular state. |
|
Actually, on second thought, is there a reason we don't want to do something like block the creation of new project custom domains if the project is a subproject? |
I think they are still useful as a "short link", subproject.domain.com/en/latest/foo.html -> main.domain.com/projects/subproject/en/latest/foo.html. Maybe even to not break existing links if a project is being converted into a subproject (but the domain would be already there in most cases). |
|
It looks like this, a little opaque, but that's how it looks like right now.
Also, just saw that we are completely overriding this template on .com, so I'd need to port the changes or see if we can just use the same from .org (I think we should be able to do this now). |
Hmm, looks like the listing is better on .com, but it has specific classes that only exists on .com, so when porting those to .org it doesn't look right.
|
If these are the only use cases we have in mind at the moment, I'd say to not allow creating a domain on a subproject as Anthony mentioned already, and explain that in the UI and documentation. I think allowing this just adds more confusion to our users and more complexity to our codebase with little winning. |
|
Yeah, that's a good niche use case. But might be a bit confusing for most users, who would probably expect the subproject domain to take precedence or at least show in the request. |
|
Opened #8985 to discuss about removing that "feature". But if you all agree, then I can just change this PR to do that. |
|
If you'd rather get this merged, that sounds fair. I will say I think the better user interaction will just be blocking domain creation. I've never been convinced that adding words to a UI makes any difference with what users do with the UI, so I'm skeptical that users will read this new block. But, no reason we can't split this into two chunks of work. I'm impartial on the order, whether we disable now and try to rework your use case back in, or we leave it enabled and eventually disable creation altogether. |
|
I have changed this PR, so users aren't allowed to create/edit domains on subprojects, they can delete existing ones only. |
stsewd
changed the title
|
Looks like this is waiting on @agjohnson to review to move forward? |
Needs #8945.