Have the ablity to create aliases

[oanalavinia]

Right now, when you create a shortened URL (by using the Get shortened URL button), a random ID is associated to you page and is used for identifying it.

It would be nice to be able to associate a specific alias when wanted, to have a friendlier URL (e.g. http://localhost:8080/xwiki/rest/p/salesMeetingNotes instead of http://localhost:8080/xwiki/rest/p/1d83jf)

The difficulty of this task is creating a design that could incorporate this functionality, while also considering to not let users create duplicate aliases (same alias points to 2 or more pages)

[oanalavinia]

Note that there is the possibility to manually do this. It's not a very nice UX, but it might be helpful for specific cases

As stated in the documentation, the generated ID is stored on each page on an URLShortener.Code.URLShortenerClass object. So, a user that has edit rights can manually modify the pageID property of this object to any chosen value (or create directly the object if it doesn't exists and specify the alias). Just be careful that this is a manual operation and by doing so you might create duplicate aliases (you could manually check that the URL doesn't exists already)

[michitux]

You could add a listener for UserUpdatingDocumentEvent that checks if the alias is already assigned to another page and cancel saving (or modify or revert the change) if it is.

[oanalavinia]

You mean having this check in case users manually edit the pageID to add an alias? I think that could be confusing for users, unless they get some feedback about the operation being aborted. It also feels too much just for a workaround, the check will be done for the actual implementation

I would leave the manual operation as it is. Since it involves manually editing the object, I think it's save to say it's just a workaround and it's for advanced users, so I feel it's their responsibility to make sure the alias doesn't exist. But I'll document this process to make sure the issues are known.

[michitux]

I think that could be confusing for users, unless they get some feedback about the operation being aborted.

Cancelling the event should give the user a message that saving failed, though I fear no reason is displayed. The check could work regardless how it is implemented in the end and could make sure that the user doesn't end up in an "invalid" state.

If you want to make this less manual, a possibility would be to add a small UI for this in the page information tab. There is a UIXP.

[oanalavinia]

I think that for the actual implementation maybe we could do the check when we have the request to add the alias (we do this type of check for adding the generated pageID as well, to make sure that the random id is not already used), instead of listening to each UserUpdatingDocumentEvent. But I agree that even if the received response is not very descriptive, it would be nice to not let users get in an "invalid" state (most probably they won't read the documentation and won't know why the alias is not working right) We'll see if we prioritize the implementation (which shouldn't take too long) or making the workaround more stable

Thanks for the idea to use this UIXP, seems like a good place for adding this feature!