Provides classes that are dedicated to the transient access paths data. These classes are mainly data containers which are used to transport view data between the processing classes of a view. However, the data transfer patterns are not fulfilled, because the classes integrate simple processing methods. This package is a part of the access paths search architectural pattern. The Gui2 package is the global manager of the data flows since it contains the GraphicViews and their event listeners. The Gui2 package calls the gWork packages. They are responsible to update the access paths data, as instances of the CNot classes, and this is the main result of their processing. This package contains non-serialized objects, and the access path data is never saved. The classes of this generic package are not designed to be subclassed in the ACS addons.
The two classes in this package are:
DisplayableLinkImpl models the access path from a source object to a target object, with intermediate nodes or not.
AccessControlLinkImpl models all the types of direct access path between two nodes. For instance, the access path may be provided by an access control list (ACL), or an owning relation.
The results of the access paths search methods are put in one map of DisplayableLinkImpls per view. This map is passed to and returned from these methods, in a static sequence of calls into the gWork packages. At the end, the map of DisplayableLinkImpls contains all the access paths of the view. They are displayed in the GUI by the Gui2.GraphicView, as a diagram and a text.
The interface AccessControlLink is responsible for defining 20 link types. They describe the relations between two base objects in a given access path. The main final results of the class AccessControlLinkImpl are provided by the methods isTrueForOneXXXLinkType(), getFilteredRights() and toSeeWhyText(). Only AclEntries and Privileges may define negative rights, in other words, may provide some access forbiddings. These negative rights are propagated into the link type GLOBAL. SPREAD is the 21th type without any rights, since its comment is used for the 'See why' text. REVERSE_DATA_EXCHANGE is the type of the unique reverse right to be applied to the access source (new in 0.7.3).
Into the class AccessControlLinkImpl, the link type value is true typically when there is a right which is defined for this link type, but not only. The right(s) are not always needed nor known when the value is true. For a structural or pseudo-structural type, there is a default static right or no right at all. However, the rights are managed in this class for all the types, except for the SPREAD type. The structural link types are IS_MEMBER, HAS_CHILD, IS_INDIRECT_MEMBER, IS_ALIAS. The strengthen link types are the structural types and OWNER, RUN_UNDER. The pseudo-structural link types are the strengthen types and HAS_VIRTUAL_MEMBER, LAUNCH, SOFT_RUN_UNDER, DATA_EXCHANGE, REVERSE_DATA_EXCHANGE. This list excludes the ACL, PRI and CONTAIN types. '[]' is displayed around the pseudo-structural links when there are rights.
This class DisplayableLinkImpl is responsible for modeling a displayable link in a GraphicView, to manage a path of base objects connected through link types and rights. A displayable link manages a chain of nodes where there is one node per base object. It manages also the link types and rights between each pair of nodes, by the way of AccessControlLinkImpl instances. When displayed, it starts with a view object (its so-called first end) and it ends with another view object (its so-called second end). Typically, it is associated to an item in a graphical view (an arrow or a line for instance) between two view objects. The intermediate nodes of the displayable link, if any, are not view objects. During the access paths search from the first end, a transient displayable link is extended step by step with all the possible nodes, until there is no node to add or a view node is found. A displayable link may be simple - it contains then only the 2 base objects as ends and one AccessControlLinkImpl between them - or it may be a chain of n base objects (or nodes) with n-1 links. The two ends are always immutable. It is possible to create a new link from a previous link with the static method valueOf().
The general attributes of a displayable link are defined into its properties map. The first use is the 4 generic map keys AG_CONTEXT_NODE_POSITION, AG_CONTEXT, ADDED_FROM_SECOND_END_AG_CONTEXT and PREVIOUS_ACS_AG_CONTEXTS, about the Accounts/Groups context of the link. The AG context is defined as a set of GroupIDMembers under which a path node works, taking account of the previous nodes in the access path. For instance, the second tutorial of Access Road explains how the 'See why' text of a full view may show an access path handling an Account/Groups context. This is an extract of the tutorial: “the generic comment '<Sets Owner>' indicates there is a switch under the Account/Groups context of the Actor 'function_one': 'tom' is the UserID under which 'function_one' runs as a stored function. This means that the initial current user 'jerry@localhost', with the MySQL syntax, has the rights to execute 'function_one', and this stored function runs under the UserID 'tom' which delivers to 'function_one' some ACL rights on the base 'BASE One'. In a very condensed form, this second path may be represented by 'jerry/ acl/ function_one/ run_under/ tom/ acl/ BASE One'. This is a generic feature of Access Road, able for example to simulate, in a GNU/Linux Ubuntu, the behavior of a program starting under a given Account/Groups context. The Account/Groups (AG) context is also used in an access path to apply, or not, the rights of a conditional AclEntry on the Actor which is the ACL source. The AG context of a node in an access path is a list that may contain, first, an optional couple (UserID, GroupID), second, a list of optional GroupIDs of the same ACS, and third, some UserIDs and the GroupIDs of another ACS which are the AG context of previous nodes in the same access path. The typical role of a ContextSwitch is to select the local AG context for a given income stream (as access path) in its ACS, after a reading of the AG context of the previous nodes in this access path (new in 0.7.3).
AG_CONTEXT_NODE_POSITION is so the index of the node in the DislayableLinkImpl for which the current Accounts/Groups context is applicable. Along the sequence of calls to the methods into the packages gWork, the Accounts/Groups context may be updated and the value of AG_CONTEXT_NODE_POSITION increases. In this process, the value of AG_CONTEXT_NODE_POSITION never decreases, while the number of elements in the Accounts/Groups context may decrease. The key AG_CONTEXT may return, as two first items, a couple (UserID, GroupID) the node at AG_CONTEXT_NODE_POSITION uses as Main_Account/Main_Group context. The key AG_CONTEXT may also return complementary groups and accounts. Some AccessControlLinkImpl instances are able to transfer the Account/Groups context. A first response is returned by the method isTransferingAGcontextWithoutACL(), that returns true when one of the following types is true: OWNER, CONTAIN, IS_MEMBER, IS_INDIRECT_MEMBER, HAS_VIRTUAL_MEMBER, IS_ALIAS, RUN_UNDER, SOFT_RUN_UNDER, LAUNCH. All the ACL provide such a transfert, in the generic algorithms. An ACS addon may change this behavior through its gWork.LinkRight implementation. An AcsAddon may also define some new properties into the displayable links. This would help the transfer of data between the gWork classes of this AcsAddon, or to cooperate with another AcsAddon.
The AccessControlLink types are generally associated to the ACS structure properties, like ACL or OWNER. However, the link types and the ACS properties are not always strictly consistent in an AcsAddon. For instance, the structural 'alias' link type is used for varied cases, from an alias to its reference. There are first the soft aliasing and the hard aliasing a generic ACS may manage as main structure properties. An AcsAddon may also handle some ALIAS relations without implying the methods ImmutableSource.getL_AcsOfSoftReferences() or Immutabletarget.getL_AcsOfSoftReferences(). Having empty values from these two methods, the generic methods of search do not detect any reference to the soft alias. The work has then to be done by the NodeRights instance of the AcsAddon. For instance, the AcsAddon MySQL uses an 'alias' relation from a ProxyMySQL and its reference, that is an UserIDMySQL. This is similar to a generic soft aliasing, but the MySQL ACS does not manage this ACS structure property. Finding this relation is the responsability of the class MySQL.gWork.NodeRightsMySQLImpl. This exemple is about an internal ACS relation, but it is also possible to create an external ACS relation. On the other hand, the 'alias' link type from a MySQL component and its Linux Ubuntu roots is an exemple of classical use of the ACS structure property 'soft alias'.
Ease-of-use: high, but the overview concepts have to be well understood.
Reliability: medium-high, through an intensive use in gWork and Gui2.GraphicView.