Was custom links recently changed? variables and url encoding seem different

[purgeitall]

I noticed today that all our custom links are broken. We have custom links created for our sites and it's a dropdown with different links (backups, docs, pictures, ect) and I noticed that all of them had a warning sign saying that 'obj' is undefined.

Here is how we had it setup and 100% working, the site name was plugged in and I used powershell to blast folders in sharepoint that matched the netbox site names.

custom link: https://company.sharepoint.com/sites/EnterpriseNetworksFiles/Shared%20Documents/Sites/{{obj.name}}/Documents

To fix the warning sign, I changed it from {{obj.name}} to {{object.name}} and now the warning sign goes away but the link is invalid. Now I see that the URL encoding is not acceptable. Our site names are in this format "Seattle (US WA)" so sharepoint would expect "https://company.sharepoint.com/sites/EnterpriseNetworksFiles/Shared%20Documents/Sites/Seattle%20%28US%20WA%28/Documents" or "https://company.sharepoint.com/sites/EnterpriseNetworksFiles/Shared%20Documents/Sites/Seattle%20(US%20WA)/Documents" both of which are valid when I test.

The links on netbox seem to url encode the spaces with + for example: "https://company.sharepoint.com/sites/EnterpriseNetworksFiles/Shared%20Documents/Sites/Seattle+%28US+WA%28/Documents" and this does not seem to work for sharepoint. Is there a way to change how space is url encoded in variable links? AFAIK nothing was changed on our end and I tried in chrome and firefox.

[candlerb]

In the release notes:

• v3.2.0: "Change custom link template context variable obj to object (backward-compatible)"
• v3.5.0: "The obj context variable is no longer passed when rendering custom links: Use object instead."

The links on netbox seem to url encode the spaces with +

That might be a bug, according to https://stackoverflow.com/questions/2678551/when-should-space-be-encoded-to-plus-or-20 - which says only the query string can be encoded this way, not parts of the URL path. But %20 is valid both in URL paths and query strings.

[candlerb]

This should now be fixed in #12894