We create PI Vision Displays in a Test environment, before Migrating them to Production. The Main display has many Hyperlinks to other Displays (and those Displays have Hyperlinks back to Main). When we propagate Displays from Test to Prod, all the links are broken and we spend quite a bit of time updating all of them. Is there a way to have the Hyperlink to another Display in the environment be independent of the Display number in the environment? Or is there a way to manually set Display's number? Related to that, is there a way to propagate a new version of an existing Display from Test to Prod without generating a new Display number for the Display in Prod?

When adding a URL navigation link to a text object, the asset context of the link switches based on the current display. It would be an improvement to allow a navigation link to be locked to a specific context so that the link consistently takes you to the desired context. When a link is created as though this feature is already there and the context of the current display is changed, the percieved destination of that URL navigation link will change and the display is considered edited, giving the user the option to save the display. This is also undesired, as the navigation link should have the option to either hard code a context or to use the display context.
In a previous request, there was created a route for using collection criteria:
https://feedback.osisoft.com/forums/320517-pi-vision/suggestions/10780719-navigation-link-to-a-display-with-asset-context
But this may require much additional work depending on the display and AF Hierarchy. This request is made to respond to the current configuration of URL navigation links, which allow you to set a destination context and then when the asset context of the current display is changed so is the destination context of that URL navigation link object requesting a save of the display.

Our client uses two different PI Vision servers - a 'protected' internal server that is used within their network, which allows for manual entry, and another Read-Only instance which can be used from outside the network. Both access the same AF server.

Our problem is that the URI builder can't handle the complexity of this system layout, and so users of both servers will be pushed by links to whichever server (in this case, internal) has been specified in AF.

The current URI builder functionality is limited because it requires the designer to specify which Vision server it should link to, and so needs you to write the address into the AF attribute, and then to update it when publishing to another server.

Proposal:
Introduce a set of rules for determining the 'implicit' Vision server if none is specified in the URI Builder:
1) If the URI link is called from PI Vision and no server is specified, direct to the same server the request has been received from
2) If the URI link is called from another source (System Explorer, Email, external link) then direct to the default PI Vision server assigned at the Database level (similar to how each database can have a PI Server assigned)