Agile is designed to follow some basic rules of item interchangeability (form, fit, and function) regarding item numbers and revisions.    When a new revision is released for an item – all BOMs that use that item are automatically updated to use the latest revision.  New revisions should be created if the revised item remains completely interchangeable in all applications with the previous iteration.  If the modified item  is not completely interchangeable to previous iterations – a new item number should be created instead.

It sounds like Doc-A (rev1) and Doc-A (rev2) are not completely interchangeable since they need to be tracked separately (tied to different items and/or revisions) –  as such, it is best practice to create a new Document that can be tied to the new part/revision.

Delaney – 
1- In order to tie a document to a specific part revision – I think you might find it better to Add documentX to the BOM of Part A (rev 1) instead of the Relationships tab.  
The BOM is rev specific so when you change Part A to rev 2 – you can redline the BOM to replace documentX with documentY.  These changes to the BOM will be remain tied to each revision and can be viewed by changing the rev dropdown on the part record.  To differentiate the Doc from the rest of the BOM – it is best to add the document with a quantity of zero or “REF” and to use a zero as the find num for the document so it always shows at the top of the BOM.  

2- As mentioned above – changes to the BOM are rev specific, but changes to Item Attributes are not.  The history tab will capture attribute changes, but the latest change will appear on the Title Block regardless of what rev you are viewing.

I do not believe there is any way to check the server time zone through the Java Client.

Easiest way I know to check is to type date in the server unix prompt.  The time zone is included in the returned date/time.

James – 
It sounds like the individual users have sufficient privileges to receive the Object you are sending, but the Manufacturing User Group itself does not.
I would check the Roles that are assigned to the Manufacturing User Group object.  In order to send to a User Group – the User Group needs to have sufficient Roles/Privileges assigned. If a User Group is selected in the “Notify:” field – the system only checks the roles/privileges assigned to that object and does not drill down to the members of that group.

“…some user groups work fine and some gets the message above…” –  This is likely because some User Groups have sufficient roles/privileges applied at the User Group object level and some do not.

One other thing small thing to note – The “Send User Groups” privilege is probably giving the ability to send User Group objects to other users/user groups rather than sending objects TO user groups.

Carlos –   Open Gates cannot be modified.  If the Root Parent is not 100% complete – the gate can be moved back to closed status and then modified, but it cannot be modified (regardless of privilege/criteria) when in Open status.

You can achieve this by creating a new workflow status criteria for “affected items where [ P2 attribute] = ‘Yes'” – then set the 2nd field as exit required for that specific status criteria only.

You can get pretty close to what you are looking for through the Event Management node without custom scripts, but I don’t think you will be able to replicate the behavior of this particular type of notification exactly.

For default notifications – the “To” field is blank.  The system automatically picks  up the appropriate “To” users to receive the notification.   When  you create a custom notification – you have to tell the system who should receive the notification in the “To” field.  $APPROVER inserts the names of the workflow approvers, but it would then be sent to all approvers, not just the ones that need to be reminded.

To expand on Antonio’s answer – Attachments are tied to a specific item revision and can therefore only be modified at the ECO revision level. 

An ECO creates a new revision for the affected item allowing rev-specific changes to be made.  MCOs do not create a new revision and therefore only non-rev specific changes can be made to the affected items.

With sufficient privileges – Attachments can be modified on a released item record directly (without an ECO),  but this can also only be done at the ECO revision level (The ECO released rev must be selected in the rev dropdown).

I don’t know that there is a specific “Standard” for this, but one option is adding the replacement details to the part record (perhaps the Page Two “Notes” field) as the lifecycle phase is being changed to Obsolete.
You may also want to create a Relationship between the two parts to provide quick access to the replacement part from the Obsolete Part record.

Tony – 
As you have seen – Team.Resource is not available for Activity Criteria and even if it was – I think you would find that Agile doesn’t handle that sort of join very well when it comes to table data.

You might want to create a separate “PPM Resource Team Member” role to be shared/granted only to team members  that are added with resource allocation while non-resource team members are granted a standard Team Member role. This additional role mightbe a copy of your default Team Member role, but with an added CS privilege for Activities the user is a team member of.  

It is slightly more manual that the criteria you were hoping for, but it should provide a way to only give resource team members the CS privilege rather than all team members.  Using criteria alone, I think you would only be left with giving CS privilege to all team members.

Best of Luck!