users breaking the article.URI field

[sdumetz]

I had a lot of non-technical users trying to use voyager to create scenes using Voyager and an issue that came up a number of times was "disappearing articles".

Afaik 100% of them are user-errors. Some internationalization issues might compound into this but I couldn't reproduce the reported cases myself). Nevertheless, the UI should (try to) prevent this from happening at all.

What seems to happen is they edit the "Article.URI" field in ArticleTaskView (for unclear reasons) and can't ever find their article back.

I've put together a POC restricting the URI to known html assets. It works fine using an option property for URI selection but it's not very reliable (among other things, options list isn't dynamically linked to existing assets).

I only needed to know the article URI a few times (for manual edits where the editor was a bad fit) and never needed to manually edit the field. Are there any known cases where a user would want to edit the URI?

(note: this does not rename the file, that's done in the "media" view)

Considering only my needs, I would make this field read-only and be done with it. Would that be ok?

[gjcope]

The only case that comes to mind is if an article was created outside of Voyager and a user wanted to attach it to a Voyager article object. It has come up before, but we generally recommend to users that they just copy and paste the content into the article editor. (Side note, we've also considered enabling the 'source' view for the article editor for this same reason to make copying a full page easier...)

I think the value of the UX improvement outweighs that use case so I'm fine just making it read only. As you pointed out users still have the ability to rename the file to something more human-readable.