[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Templates Issue submitted to C019: Assigning_approvals
|
Hi Tim See below
Regards ------------------------------------------- -----Original
Message-----
Currently there are two templates for Approvals. One assigning_approval_person (asg_apr_pers) assigns a person, and organization to an instance of Person_in_organization, which is the person_organization referenced from an instance of Approving_person_organization. There are 5 optional characterizations to this template which must be attributed outside of the template usage for which three variables are declared (^organization [the Organization], ^pers_in_org [the Person_in_organization] and ^app_pers_org [the Approving_person_organization]). The second template assigning_approval (asg_apr) provides the instances of approval, approval_status and approval_assignment entities. The instance of approval provides a target for an occurrence of the template assigning_approval_person (see above). The arrangement is such that one template is used within another. This is no problem. However, *as I understand it*, only those variables exposed can be referenced from outside the template. Hence, the latterly defined "enclosing" template only exposes 3 locally defined variables for characterization outside of this definition (^app_status [Approval_status], ^approval [Approval] and ^approval_assignment [Approval_assignment]). [RBN>] Correct Given the current definition, if one uses the assigning_approval template, it is not possible to characterize the instances created by the internal (enclosed) template as the variables are not explicitly exposed by the second (enclosing) template. [RBN>] This is true Hence, it is impossible to assign the optional reference_data or calendar dates etc., to the authorization defined. There are several options, either; 1. expose the three variables declared (^organization [the Organization], ^pers_in_org [the Person_in_organization] and ^app_pers_org [the Approving_person_organization]) from within assigning_approval. This results in a total of 6 (cumulative) for the assigning_approval template. [RBN>] This would be my preferred approach. The EPXRESSG diagram needs to be updated and the path 2. enforce the population of the optional attributes in assigning_approval_person (& therefore, in assigning_approval, from where it is called). 3. Create a new template, possibly a combination of the two currently defined which provides access to the 6 optional characterizations. 4. Someone put me right. Kind regards,
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]