When I have ‘a new test notebook’, and I add content to it, then trash it (I learned I cannot emptying my trash), I still get an existing URL conflict message and a red button saying ‘Reset’.
To me, this ‘Reset’ is more like ‘Cancel’, because does not ‘reset’ the used URL to the new notebook. All it does is cancel my request and keeps me on the same unique ID. You might consider renaming the button to avoid confusion.
“Reset” does not force a URL to be set to the current notebook. It clears all existing aliases of the current notebook. I’m fairly certain that you’ll have to reset the URL in your (previously trashed) notebook.
If at any point you wish to clear the custom URLs associated with a notebook, you can click the Reset button on the bottom left of the modal, which will clear all links and restore the notebook URL back to its default.
Thanks Fabian. I caught this bit of the documentation, but still found the language confusing (hence raising this message). I created (and trashed) the conflicting named notebook as a test for what happens in that case. When I face a conflict, I can’t ‘rename’ to a conflicting URL… and the ‘Reset’ option stays active… yet all it does is close the modal windows and kicks me back to my ‘original’ URL. As you point out, this is a form of ‘reset’ that didn’t come to mind before, my experience of the interface provides no change (hence no reset). I’ll try again after re-naming the new notebook, then trying to rename it again to a used notebook name… and see if ‘reset’ boots me all the way back to the non-named URL… But I still think it’d be helpful to distinguish between action and non-action.
That is correct. If you change the notebook’s custom URL, then the previous custom URL will still be valid, but will redirect to the current custom URL. In order to free up a previous custom URL you have to clear (reset) all of the notebook’s custom URLs.
I agree that this solution is not ideal, and even the API doesn’t appear to provide a way to list a notebook’s previous slugs).
Which is exactly right. Because you’ve just cleared all custom URLs, the notebook can no longer be accessed through them, and thus you’re being redirected to the internal URL.
A confirmation step would be nice though, especially since there’s no way to review which custom URLs just got removed.
Remember: a custom URL (“slug”) is always bound to the notebook for which it was created. It cannot be modified or removed from within another notebook.
If you want to reassign the custom URL that is occupied by a trashed notebook, you have to:
Thanks for the feedback, and for the advice offered here. I’ll send this thread to the team who worked on the custom URL feature and they can bear it in mind for future work on it.
@mootari - thanks for this discussion. you helped me learn something that was not apparent: that the URL-slug will be reset to the internal URL-slug, where there’s instead a small grey x to mean cancel. I didn’t think about this or catch it initially, b/c I hadn’t actually changed the slug to something custom (I was just checking on conflict handling). My take-away from the UI when getting the conflict message was that hitting ‘reset’ was the same as ‘cancel’ (which you clearly demonstrated it is not).
I still think a ‘cancel’ button that is similar in size and on the same level as ‘reset’ would be preferable. It takes up more space to have more buttons, but it would mitigate inadvertently clearing a custom URL that is already set.
