Currently it is possible to create several references to the same object (process and VBO) resulting in having to 'names' in different locations in the tree view. Following example assume there is one object (process or VBO) XML that is referenced by two names, objectA and objectB This causes several issues:
objectA is in a restricted group preventing any modification but it is still possible to import objectB to another group and will allow to change the XML by changing objectB although this should be prevented by restrictions on objectA. This is a security hole.
It is not obvious if or how many references exist to one object XML. Applying 'delete object' action on one reference actually deletes the XML and all depending references. Deletion of objectA also deletes objectB without warning.
Creating a release adds all references to an object and will be imported accordingly, messing up organization by groups. Assuming objectA is in group projectA and there is this other reference objectB in group projectB. If I create a release for projectA and add the objects from this group into a release, also the other references are added from group projectB. When importing the release for projectA there will also a group created named projectB
There is no distinction if there are X references or if there is only one reference to an object XML. So it is possible to remove a reference to an object in tree view making it inaccessible, although the XML is still in DB.
It is not obvious when a reference is created. For example objectA is exported. Afterwards the objects is relocated to another group and renamed to objectB. The previous export of objectA is imported again which results in having two references to the same object. There will be notification if the object should be replaced during the import but the replacement only refers to the XML but not to the references/names.
In contrast I cannot think of any case to have references to the same object.
... View more