Log Output

Whether it is part of the UNIX syslog or the Windows Event Log, the information logged on each type of object varies as shown in the tables below. The capitalization in the formats indicates a substitution from ENOVIA Live Collaboration.

Related Topics
About the Access Log
Enabling the Access Log
Error Log and Disk Space
Access Log Data: Business Objects
Access Description Access on business objects is determined by policy and state.
Granted Log Format POLICY::STATE::ACCESS allowed for USER[,AUTH] in GROUP/ROLE [as GRANTOR] on TYPE NAME REV in VAULT (based on policy),owner=PERSON,ALTOWNER1,ALTOWNER2
Denied Log Format POLICY::STATE:ACCESS denied for USER[,AUTH] on TYPE NAME REV in VAULT,owner=PERSON,ALTOWNER1,ALTOWNER2
Sample Output Production::Released::checkin allowed for Des in Designers on Assembly MTC1 A in Parts;
Access Log Data: Relationships
Access Description Access checks on relationships involves two steps:
  1. The first is to check whether the requested access is allowed on the business objects to which the relationship is connected. Success or failure is logged for business object access.
  2. If successful, the existence of an access rule assignment on the relationship type is checked. If the rule exists, success or failure is logged as described below.
Granted Log Format ::RULE::ACCESS allowed by USER[,AUTH] in GROUP/ROLE [as GRANTOR] on RELTYPE (OID)
Denied Log Format ::RULE::ACCESS denied for USER[,AUTH] on RELTYPE (OID)
Sample Output Production::Released::todisconnect allowed for Des in Designers on Assembly MTC1 A in Parts;

Production::Released::fromdisconnect allowed for Des in Designers on Assembly EZ45 A in Parts;

::DesignedRule::disconnect allowed for Des in Designers on AsDesigned
Access Log Data: Attributes
Access Description Similar to the behavior on relationships, attribute access is first checked on the business object or relationship to which the attribute is assigned. These access checks are logged as described above. If successful, a second check is made against an optional access rule assigned to the attribute type. If the rule exists, success or failure is logged as described below.
Granted Log Format ::RULE::ACCESS allowed for USER[,AUTH] in GROUP/ROLE [as GRANTOR] on ATTRIBUTE (OID)
Denied Log Format ::RULE::ACCESS denied for USER[,AUTH] on ATTRIBUTE (OID)
Sample Output Production::Released::modify allowed for Des in Designers on attribute Assembly MTC1 A in Parts;

::CostAttr::modify allowed by Des in Designers on TargetCost
Access Log Data: Programs and Forms
Access Description Programs and forms are nearly identical in how access checking is performed. An access rule can be assigned to a Program or Form object that is checked whenever a user attempts to execute the Program or open the Form. Such access checks are logged as shown below.
Granted Log Format ::RULE::ACCESS allowed for USER[,AUTH] in GROUP/ROLE [as GRANTOR] on PROGRAM/FORM
Denied Log Format ::RULE::ACCESS denied for USER[,AUTH] on PROGRAM/FORM
Sample Output ::MGRCount::execute allowed by Des in Designers on CountParts
Additionally, if a user reaches the maximum number of consecutive failed login attempts before lockout occurs, this information is recorded in the Access Log.