'urls' property always undefined in the document workspace context (Umbraco 16)

[Luuk1983]

Which Umbraco version are you using?

16.0.0

Bug summary

In Umbraco 15 I use the urls on the document workspace context to determine if a node has at least one valid url. In Umbraco 16, the urls always seem to be undefined.

Specifics

I have a node that has 4 urls:

I also have a workspace context that's visible on that node:

For some functionality, I need to make sure the page has an accessible url, so I check the urls property on the document workspace context:

...
    constructor() {
        super();

        this.consumeContext(UMB_DOCUMENT_WORKSPACE_CONTEXT, (instance) => {
            if (!instance)
                return;
            this.#observeUrls();
        });
    }
...
    #observeUrls() {
        console.log("Observing URLs in the workspace context");
        this.observe(
            this.#workspaceContext?.urls,
            (value) => {
                console.log("URLS set", value, this.#workspaceContext);
                this.documentUrls = value ?? [];
            },
            'aiAnalysisUrlsObserver',
        );
    }

I can see that the console logs getting hit:

I see that urls is undefined and they stay that way, they are never updated. In Umbraco 15, this worked perfectly and I got the urls that were on the document.

To me, this really seems like bug.

Steps to reproduce

See specifics

Expected result / actual result

Obviously I expect the urls property to contain the urls of the document, just like in Umbraco 15.
See specifics for more details.

[github-actions]

Hi there @Luuk1983!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[AndyButland]

This is actually expected @Luuk1983. We had some performance issues to address with the document response model, that was being slowed down by the population of the URLs once route validation was introduced mid-way in the 15 cycle. It's discussed here in a comment on the issue where the performance issues were raised. The URLs were removed from population in this PR.

We have a dedicated management API endpoint to retrieve the URLs for a document, and so that's what we use when you navigate to the "Info" workspace view and see the URLs. This allows us to speed up the retrieval of the document details needed for editing, which is loaded by default when you navigate to a document.

To get the URLs, you should be able to use the UmbDocumentUrlRepository. As examples, you can see it used here for the population of the URLs on the "Info" workspace app, and here for the URL picker.

I'll close this as expected, but will make sure to call it out on the documentation page where we call out breaking changes.

[AndyButland]

PR for docs is here: umbraco/UmbracoDocs#7171

[Luuk1983]

@AndyButland thanks for the response! I'll check out the solution for this. At first glance it shoudn't be too difficult, although I'm not sure (yet) if it's observable since in need my interface to react on the fact if there are valid urls on publish.

So we're left with a property that will never be set? Javascript doc blocks allow for marking stuff as obsolete, just like in C#, perhaps this is a good approach to implement?

[AndyButland]

Yes, I believe that's in place. We've obsoleted the property on the server-side, and when that generated types on the client it comes through as deprecated there. Are you seeing this somewhere else or in some other way?