About Show Access
Without show access for an object, the user cannot see the object or any information
about that object in any app, or in MQL. Specifically, the user will not see the object
displayed under these circumstances:
- Evaluating a query in MQL.
- Running the
expand businessobject command in MQL.
- Running the
print set command in MQL.
- Running the
expand set command in MQL.
- Running the
print connection command in MQL.
- Reading an email message sent by 3DSpace that includes a business object.
- Opening the revisions dialog.
- Opening the History of an object that references a "no show" object.
Usually it makes no sense to remove show access from a Person definition access mask.
In the History of an object, other objects are sometimes referenced. The performance
impact of determining whether the current user has access to see the Type, Name and
Revision of such objects is significant and unavoidable. To workaround this issue,
you can delete industrial history records using the Delete History clause of the
modify businessobject or modify connection
command. This can be used in action triggers to remove such records.
Additionally, a user who does not have show access for an object will not see
references to the object when these operations occur:
- Running the
evaluate expression command in MQL. This command evaluates an expression
against either a single, named business object or against a collection of
them specified via some combination of sets, queries, and/or expansions. In
the former case, when a user does not have show access, the command behaves
as if the object does not exist. In the latter case, it simply leaves the
object out of the collection.
- Running any of the
businessobject commands in MQL. If a user has no show access to an
object, then the object is not presented as the next or previous revision of
an object to which the user does not show access. Such objects are simply
left out of the revision sequence. So if there are three objects in the
revision sequence with revisions 1,2, and 3 in that order and the user has
show access only to 1 and 3, the next revision of 1 will be represented as
3.
- If the user tries to create an object that exists, but they cannot see, they
will receive an error message indicating "Access denied."
With show access, you have access to the type, name, and revision fields of the
object. If you only have show access and print an object in MQL, you can select the type, name, and revision
but will receive #DENIED for any other select. If you include selectables in the
where clause other than type, name, and revision, the object will not be found even
if the where clause evaluates to true, because you do not have access to the fields
in the where clause (for example, vault, policy, state, or attributes.)
Do not use show access as an access strategy for objects 3DSpace Service searches. If you have only show access
on an object, all searches from the web app UI will never show the object in the results
list. This applies to all searches done through the web interface, not only searches
that use emxFullSearch.jsp. The search component automatically inserts elements into
the where clause of a query that are not available to a user with only show access.
If you want to use show access for searching in the web UI, you need to create a
custom tool.
Checking Show Access
The MQL command set checkshowaccess
[ON|OFF] sets or unsets the global flag to indicate whether the new
access checking required by show access is to be executed or not. Because this is a
one-time-only command, it is provided only via MQL. If set to OFF, the software will not perform
the checking, and the feature will not be enabled. If set to ON, the software will
always perform the checks.
By default, the database is upgraded with a global setting that indicates that show
access should NOT be checked, and therefore the feature will not actually be enabled
until this flag is changed. Since show access will not be checked, all users, states
and rules will have show access. This guarantees upward compatibility.
Until the checkshowaccess flag is explicitly set to ON, all the new
access checks required for this feature will be skipped. Even after the
checkshowaccess flag is set to ON, the only effect will be the
negligible time spent in the new access checks since all users will have Show access
to all objects by default.
Show access status is included in export and imports. However, the access of the
global flag is not included.
Show Access and Inheritance
The situation can occur where a user has access to an object, such as a Document,
but that user's name does not show in the list when viewing the Sharing page
(previously called the Multiple Ownership Access page). This situation could occur
because the user inherited access to the object from another object, but the user
does not have access to that other object.
For example, a Bookmark Root can be created and configured with Bookmarks and Documents, and a user added to the Bookmark Root. Until the owner of that Bookmark Root activates it, no other user can see that the
Bookmark Root exists and cannot see any information about the
Bookmark Root. A Document in a Bookmark in the Bookmark Root, however, still inherits access from the Bookmark Root. The user can search for and access the
Document because of the inherited access from the Bookmark Root, although that user could not navigate to the
Document through the Bookmark Root and Bookmark.
The Sharing page lists the people who have been granted access to that object. The
information about the access includes the object the access was inherited from.
Inherited accesses only show in the list if the user has access to the "Inherited
From" object. In the above example, the user does not have access to the Bookmark Root, so the inherited access does not show in the list even though the user can
access that Document. When the Bookmark Root is activated, the user can then see their name in the Sharing page for the
Document.
Show Access in Sorted Sets
The checks for show access do not occur for all set commands for the following
reasons:
- A performance penalty is paid for evaluating show access on each object in a
set.
- The only information that is hidden by show access is an object's type,
name, and revision, but that very information had to be known to the set
owner at the time the set was created.
- The primary use case for Sorted sets is to support efficient pagination in
html applications using the following technique:
- Perform a query/expand into a temporary set.
- Optionally sort that set.
- Print the set with start/end indices to page through it.
Since in this case show access is applied during the query/expand evaluation,
re-applying it for the print set command is unnecessary.