Connection Links or Pointers

[drlandau]

Connection objects are sorted into Folders for logical ordering, but some times a server (connection) would be nice to show in different Folders, fx. because a database-server is used as backend for different applications, that alle have their own Folders in the tree.

You don't want to duplicate the Connection object, because then you have to manage more connections.

Instead I propose the ability to create Connection Links or Connection Point, that is essential a link to another Connection object in the tree, fx signified with a different icon.

You can perform the same actions on the Connection Link as you can on the Connection object + you can rightclick and "Jump" to the original Connection object in the tree.

If you delete a Connection object you should be asked if you want to remove all the connected links, select another Connection object to use as "master" for the links, or to convert the connected links to "real" connection objects.

[loetmann]

I would like to opt for this, urgently.

E.g. We have a bunch of network printers here. I would like to show them up in a folder called "Printers" but also in folders representing the complete network accessible asset of a given room.

Btw. thanks for a great product. ;-)

[Systemstarter]

I'd love to have this feature!!!!

[KaiHauptmann]

I would appreciate this feature as well.
As we are running several multi-environment servers, we are having a bunch of redundant connections at the moment, as our connection tree is having the customer's name as the first hierarchy. Machines that are used for more than one customer are kept multiple times in the Database, increasing maintenance work.

So basically: +1 !

[Monoman]

I'm pretty sure this would be covered by implementing tagging which is mentioned in another thread. Tags by themselves and in combinations would allows some very flexible organizing. By OS, by role, by department, by location, etc

[JRJ]

I agree (and had requested this for previous versions as well).

It even needs to go one step further - allowing different users to set up their own folder structure and connection parameters (including defaults).

My ideal setup is this (regarding a database environment only):

• Multiple users connect to a single database that stores connections, credentials, etc.
  
• Each user can define default connection parameters. When launching a connection, have a context menu option (or Tools > Options setting) to launch with my default connection parameters instead of parameters attached to connection object. (You could even go further and allow multiple connection profiles to be defined and then allow a user to connect to a server with a specific connection profile.)
  
• Folder objects can be set as Public or Private. Public folders show for all users. Private folders show only for the user who created it.
  
• Connection objects can be set as Public or Private. If a connection object is public, it shows for all users in a "Connections" folder. If a connection object is private, it only shows for the user who created it (either in the same "Connections" folder or a "Private Connections" folder).
  
• Users create connection links to connection objects. Connection links are organized in a tree structure. If the connection link is in a public folder and points to a public connection object, it shows for everyone. Otherwise, the connection link only shows for the user who created it. This allows for multiple connection links in different folders to a single connection object.
  
• Connection links contain the mapping to the connection parameters. Therefore, a public connection link by default uses the same parameters for all users (but can be overridden by context menu option described above).
  
• Expanding on the connection profiles idea, from an architecture standpoint, separate the connection profiles into a separate table(s) and allow the connection profile to be set on a folder object, connection object, or connection link. At runtime, a selected connection link would use the most specific setting (context menu selection first, connection link second, folder object third, connection object fourth, user-defined default connection parameters fifth, and shared default connection parameters last) - to take this to the extreme.
  

Lack of settings like these prevent us from switching to using a database for vRD. Different users have different preferences - both from a connection properties standpoint and a connection organization (tree structure) standpoint. So we're stuck with local settings and modifying the XML export files before importing them (since connection parameters are stored with each connection object and an import keeps what's defined in the XML rather than apply my configured defaults).

EDIT: I missed the multi-edit connections feature, so we don't have to edit an XML file before importing. However, that just makes importing easier, it doesn't address connection management issues.

[drlandau]

Is there no one from ASG / visionapp support that wants to comment on this suggestion?

[RWesterman]

I agree (and had requested this for previous versions as well).

It even needs to go one step further - allowing different users to set up their own folder structure and connection parameters (including defaults).

My ideal setup is this (regarding a database environment only):

• Multiple users connect to a single database that stores connections, credentials, etc.
  
• Each user can define default connection parameters. When launching a connection, have a context menu option (or Tools > Options setting) to launch with my default connection parameters instead of parameters attached to connection object. (You could even go further and allow multiple connection profiles to be defined and then allow a user to connect to a server with a specific connection profile.)
  
• Folder objects can be set as Public or Private. Public folders show for all users. Private folders show only for the user who created it.
  
• Connection objects can be set as Public or Private. If a connection object is public, it shows for all users in a "Connections" folder. If a connection object is private, it only shows for the user who created it (either in the same "Connections" folder or a "Private Connections" folder).
  
• Users create connection links to connection objects. Connection links are organized in a tree structure. If the connection link is in a public folder and points to a public connection object, it shows for everyone. Otherwise, the connection link only shows for the user who created it. This allows for multiple connection links in different folders to a single connection object.
  
• Connection links contain the mapping to the connection parameters. Therefore, a public connection link by default uses the same parameters for all users (but can be overridden by context menu option described above).
  
• Expanding on the connection profiles idea, from an architecture standpoint, separate the connection profiles into a separate table(s) and allow the connection profile to be set on a folder object, connection object, or connection link. At runtime, a selected connection link would use the most specific setting (context menu selection first, connection link second, folder object third, connection object fourth, user-defined default connection parameters fifth, and shared default connection parameters last) - to take this to the extreme.
  

Lack of settings like these prevent us from switching to using a database for vRD. Different users have different preferences - both from a connection properties standpoint and a connection organization (tree structure) standpoint. So we're stuck with local settings and modifying the XML export files before importing them (since connection parameters are stored with each connection object and an import keeps what's defined in the XML rather than apply my configured defaults).

EDIT: I missed the multi-edit connections feature, so we don't have to edit an XML file before importing. However, that just makes importing easier, it doesn't address connection management issues.

+1

[drlandau]

*bump*