| Agile Product Lifecycle Management Administrator Guide Release 9.3.3 E39286-04 |
|
 Previous |
 Next |
| Agile Product Lifecycle Management Administrator Guide Release 9.3.3 E39286-04 |
|
Previous |
Next |
This chapter discusses how to determine your company's file management policy and configure settings for attachments.
As with other areas of Agile PLM administration, the most important step comes before setting properties in Administrator. You have to determine an overall "policy" that supports your company's uses of attachment files, file folders, and design models.
As you decide about company objectives, these are a few factors you might evaluate:
Does your company produce CAD design and graphic files? If so, you will build from the Designs class. Refer "Administering Designs."
Does your company need to organize and track attachments and bundles of attachments? This may indicate building from the File Folder subclass.
Are there other special purposes or uses of Agile's attachment capabilities to take into account?
Invisible or Visible file folders?
How should attachment files be named? Are such files to be named in a dictated or organized system? Or is it all right to allow users to name attachment files and count on users to use file folders to search and find specific attachments?
This section collects various Administrator settings—SmartRules, systemwide Preferences, and a user preference—for convenience. Roles and privileges that pertain to attachments are discussed in a subsequent section. Refer to node-specific chapters for more information about the capabilities in Administrator.
Administrator settings on the Server Settings > Locations > File Manager tab are important in relation to attachment files and where originals and copies are found. See "File Management in Agile PLM."
The Checksum internal utility is a security measure against improper handling of files. Reset privilege and Checksum Computation preference are described in "Handle File Checksum."
Copy Files To Rev
The Copy Files To Rev smartrule controls automatic copying of attachment files to a new revision; that is, the pending item revision that is created when an item is added to the Affected Item table of a change. The system checks this SmartRule only when a pending change is created and not when attachments are added. Possible settings are Copy, Reference (the default), Disallow, Copy with Warning, and Reference with Warning.
The following table illustrates how each setting works in the following example:
Part 55, Revision B, Attachments tab table lists attached file Test.txt, version 3; that is:
File Name = Test.txt, File Folder = Folder004, Folder Version = 3.
Part 55, Revision B is added to the Affected Items tab of a change object, thus creating pending revision C.
Table 37-1 Copy Files to Rev SmartRule settings
| Setting | How it works |
|---|---|
|
Copy |
For the item's new pending revision, Agile creates a new file folder and creates a new copy of the attachment file, which is placed in the new file folder. So, when pending revision C is created, the Attachments tab table lists the same attachments as revision B, with a new File Folder, that is, revision C inherits the same attachments as revision B: File Name = Test.txt, File Folder = Folder005, Folder Version = 1 |
|
Reference |
Agile uses the existing file folder and creates a new reference to it on the item's pending revision Attachments tab. |
|
Disallow |
When pending revision C is created, the Attachments tab table is empty. No attachment references are copied. |
|
Copy with Warning |
The same as the Copy setting, with the option of choosing no attachments for the new pending revision. When you add items to the pending ECO, you are presented with a warning dialog that includes a row for each item you are adding. To add the item and to copy the attachments, check both the Add check box and the Attachments check box. To add the item with no attachments, check only the Add check box. |
|
Reference with Warning |
The same as the Reference setting, with the option of choosing no attachments for the new pending revision. When you add items to the pending ECO, you are presented with a warning dialog that includes a row for each item you are adding. To add the item and to reference the existing attachments, check both the Add check box and the Attachments check box. To add the item with no attachments, check only the Add check box. |
If you set this smartrule to Disallow, files that were added to the Introductory revision after the object was associated with a change (that will result in released Rev A) will not be copied to subsequent revisions. Also, when a new Change is created, all the files that were added to the Introductory revision won't be added to the newly created revision.
This smartrule determines whether an attachment file that is being checked in can have a different file extension than the file that was checked out. This smartrule applies to all business objects.
This rule is overridden when a business object's attachment is Latest-x and the file extension in the attached file folder is changed and is therefore different than the extension of the business object's checked-out file.
Systemwide preferences are documented in "Default Systemwide Preferences."
Agile File Manager uses a prefix that is attached to each file that is stored in the file vault. You can type in the identifier that will be automatically added to every attachment file. The default is "agile".
When there are more than two File Managers, this preference allows the PLM system to keep track of the File Managers that contain each file. During replication, the requesting FM only contacts other FMs that contain the file, and downloads a given file from the nearest FM (which is determined by shortest 'ping' to all the FM servers).
Settings are Enabled or Disabled. Disabled can be set to troubleshoot problems with the optimizations.
Here are further details on the available choices for the Save As Attachments preference. When Save As is used to create a new business object will include the same attached files; your choice is whether to create new copies of the files (which includes new file folders), to reuse the same file folders attached to the original business object, not to copy any files, or to allow the user to choose one of these methods at the time he performs the Save As operation.
Select the setting that best suites your company's business practices.
This preference does not apply to File Folder objects themselves, except as outlined in the table below.
For Product Portfolio Management objects, this preference applies only to attachments in the current object; it does not propagate down to all children tasks. The preference does apply when creating a new project from a PPM template.
The following table illustrates how each setting works in the following example:
Object ABC includes the following attachment:
File Name = Test.txt, File Folder = Folder004, Folder Version = 3.
A user opens Object ABC and uses Save As to create Object XYZ.
Table 37-2 Save As Attachments preference settings
| Setting | Example of how it works |
|---|---|
|
Create new copy of file(s) |
When Object XYZ is created, a new copy of the Test.txt is attached in a new file folder. Object XYZ's Attachments tab lists:
A new copy of Test.txt is created in the file vault, and a new file folder (Folder014, Version 1) is created. The end result (new copy of the file, new file folder, at Version 1) is the same as if the user had added the attachment Test.txt by using the Add | Files button on the Attachments tab of Object XYZ. |
|
Reference existing file(s) |
When Object XYZ is created, it reuses the same attachments as the original Object ABC. Object XYZ's Attachments tab is the same as Object ABC's Attachments tab, and lists:
The end result (the file folder attachments are reused) is the same as if the user had added the attachment Test.txt by using the Add | By Search button on the Attachments tab of Object XYZ, searching for Object ABC and selecting its attachment: Test.txt, Folder004, Version 3. |
|
Do not copy file(s) |
When Object XYZ is created, no attachments are copied from the original Object ABC. The end result is that the newly created Object XYZ has no attachments; its Attachments tab is empty. |
|
Prompt |
The user is prompted to select one of the Save As Attachment methods:
Agile PLM always prompts each user whenever a Save As operation is performed. However, if the original Object ABC does not have any attachments (the Attachments table is empty), the prompt will not appear. |
This preference controls whether your users — specifically Web Client users — will have access to Java applets that permit advanced features.
When this preference is set to Yes:
Allows the Microsoft Excel-based Client to be integrated with Agile PG&C, which allows supplier users to provide compliance information to buyers while using Microsoft Excel.
In Web Client, allows the use of an Open Plug-in that opens an attached file in its native application. This plug-in is used when:
The user selects one or more file rows and then clicks the Open button.
The user clicks the filename link in the attachment table, and the file extension has not been defined as a viewable file. See "Specifying Supported File Types for AutoVue for Agile."
When this preference is set to No, the Web Client file Open action is the same as the file Get action.
Agile PLM uses the File Uploader when users add files as attachments in Web Client. Supported web browsers are Safari, Chrome, Firefox and IE.File sizes up to 16 GB are supported. Pausing and restarting file transfers—both downloads and uploads—are is supported. Get and Checkout file transfer downloads can be restarted. The file Open action uses a plug-in; for more information, see "Allow Download of Productivity Components."
|
Note: For Microsoft Internet Explorer (IE), the upload file size limit is 2 GB. |
The File Upload Manager displays the progress of file uploads as they occur, allows users to pause and resume a file upload in progress, and retains a list of completed file uploads. The Agile preferences that associated with file upload are:
Attachment file actions that involve file downloads (Get, Open, Checkout) are separate HTTP sockets handled by the browser. File download capabilities are configured with Agile preferences:
File transfers can be paused and restarted.
The Agile preference Upload Max Chunk Size (bytes) determines the maximum size, in bytes, of each chunk or portion of files that are uploaded during the file upload process. If the file upload is paused or interrupted, when the file upload is resumed, Agile PLM resumes uploading with the last chunk that had not been completely uploaded when the file upload process was stopped.
Valid settings are 1 - unlimited; default is 10485760.
Maximum specified setting: 9999999999 (9,999,999,999)
See also "Download Max Chunk Size."
The Agile preference Upload Max Concurrent Transfers determines how many concurrent file transfers of multiple files to one client that one user is allowed. Valid settings are 1 - 20; default is 10.
This limit is applied per user, regardless of how many browsers sessions the user has open at one time.
See also "Download Max Concurrent Transfers."
The Agile preference Max File Upload Histories Displayed determines the maximum number of historical file transfers that are displayed in the File Upload Manager in Web Client. Valid range is 0 - 500; default is 250.
When the number of file transfers exceeds the number set in this preference, the histories of the oldest file transfers are removed from the list.
The user is able to use the Clear All button in the File Upload Manager to clear the list.
File transfers can be paused and restarted.
The Agile preference Download Max Chunk Size (bytes) determines the maximum size, in bytes, of each chunk or portion of files that are downloaded during the file download process. If the file download is paused or interrupted, when the file download is resumed, Agile PLM resumes downloading with the last chunk that had not been completely downloaded when the file download process was stopped.
Valid settings are 1 - unlimited; default is 1048576.
Maximum specified setting: 9999999999 (9,999,999,999)
See also "Upload Max Chunk Size."
The Agile preference Download Max Concurrent Transfers determines how many concurrent download transfers one user is allowed. Valid settings are 1 - 20; default is 10.
This setting applies regardless of how many browsers or Agile sessions the user has open at one time.
See also "Upload Max Concurrent Transfers."
The Agile preference Download Token Max Resumes Allowed determines the maximum number of times a user may resume a download transfer. Valid settings from 0 - no upper limit. Default is 10.
Each file transfer is Agile PLM is treated as a separate File Manager session. If this preference is set to 0, then no resumes are allowed after the File Manager session has timed out.
See also "Download Token Use Duration."
The Agile preference Download Token Use Duration is the time (in minutes) that the user is allowed to restart a paused file download transfer. Valid settings begin at 0 and there is no upper limit. Default is 1440 (one day).
The time starts at the initiation of the file transfer. Once the set time period expires, transfer restarts are not allowed. If the transfer is in process, the file transfer is not stopped, even if the Download Token User Duration time limit has expired. For example, if the time limit is 1 hour (60 minutes), and the file transfer takes 2 hours, the transfer is completed if it is not paused. If the user pauses the transfer at 50 minutes, he can resume the transfer until 60 minutes has elapsed the initial download initiation. After 60 minutes, attempting to resume the file transfer returns an error.
Agile PLM roles are fully documented in "Roles" and privileges are fully documented in "Privileges and Privilege Masks." You should evaluate your objectives carefully before creating new roles and privileges. While customized roles and privileges may need to be created, it is always preferable if your objectives can be handled by ready-to-use roles and privilege masks.
The following section provides information about privileges that are constructed to realize attachment capabilities.
Some privileges allow users to perform actions on attachments; we will call them "attachment privileges" in this discussion. Users who are assigned Folder Administrator or Folder Manager roles may need to review the information below.
The following privileges allow users to perform actions on attachments:
Checkin
Checkout
Cancel Checkout
GetFile
PrintFile
ViewFile
Modify
Add to Table
Delete from Table
|
Note: GetFile privilege works in tandem with Checkout privilege to actually deliver the attachment file to the user's computer. A user with Checkout but not GetFile will see in History that the file is checked out, but it has not been downloaded to the user. The GetFile privilege (without Checkout) allows the administrator to permit a user to get a file—open it, read it—without being able to change it in the product record. |
You can create privilege masks and roles that allow you to provide users all attachment actions from the business object Attachments tab; direct access to the file folder object is not required. Thus, file folder objects are "invisible" to the user, even though the user has the capability to perform all attachment actions from the business object Attachments tab.
Attachment actions performed from the business object's Attachments tab are carried out on the referenced file folder object. For example, checking out an attached file on the Attachments tab actually checks out the referenced file folder. However, if the user has the correct attachment privileges, he does not also require file folder privileges.
However, if required, attachment privileges can apply directly to file folder objects, and privileges for file folder objects should be reserved for those users who will actively maintain those objects. These users can search for file folder objects, open them, check files in and out on the Files tab, get files, print files, and view files. But you do not want every user to have this range of permissions on the file folders, and those roles do not give users the correct functionality anyway.
What will be more useful for standard users is having attachment privileges for specific classes or subclasses of business objects (or, as needed, specific objects). A user who has attachment privileges for manufacturer parts can perform attachment actions on any manufacturer part's Attachments tab, provided that the Folder Version selected in the attachments table is the latest version. If a user's attachment privileges pertain to a subclass of manufacturer parts, say, Resistors, the user can perform attachment actions on any resistor's Attachments tab, again provided that the Folder Version selected in the attachments table is the latest version.
Provided that the latest version is selected, a user—from the Attachments tab of the current object—can check out and check in and perform the other attachment actions.
Therefore, a user with attachment privileges for only manufacturer parts can perform attachment actions from a manufacturer part's Attachments tab but not from an item's Attachments tab.
To summarize, users do not need privileges for file folder objects to work with attachments; however, they do need privileges for the business objects they will be working with (with the privilege specifying a class, subclass, or specific object). Users can create, check in, and check out file folder objects, but only in association with the Agile PLM class, subclass, or object for which they have business object attachment capability privileges.
Some ready-to-use roles have all of the above-named attachment privileges for the object types that role would usually work with, that is, the object types that the role is designed to create and modify. They may also have file capabilities (get, view, and print) for other related object types.
For example, the Item Content Manager role includes all seven attachment privileges for items and changes. It also includes GetFile, PrintFile, and ViewFile privileges (not Checkout or Checkin) for manufacturers, manufacturer parts, and price objects (that is, objects that are listed on the Manufacturers and Prices tabs of an item).
Following the Item Content Manager role as an example, you can create roles that allow users to get, print, and view attachments for all objects related to that user's Agile PLM system activities, and limit the checkin/checkout privileges to only those objects that the user can create and modify. A role that includes privileges for file folder objects does not allow you to control the user's attachment capabilities to the same level of granularity.
Attachment privileges are also applied to Thumbnails. A user must have either Read privilege and GetFile privilege, or have Read privilege and ViewFile privilege for an attachment row in order for Agile PLM to display the Thumbnail for that attachment on any tab or screen, including:
Item Title Block
Item BOM
Item Attachments
Item Where Used
Manufacturer Part Title Block
File Folder Title Block and Where Used
Design Title Block, Structure, and Where Used
Search Results
Quick View of objects
The Agile PLM pre-defined attachment privilege masks are based on broadly defined reusable criteria, for example, All Items. However, you can create custom privilege masks with reusable criteria that you fine tune to your needs.
When creating a reusable criteria for attachment privilege masks, in addition to the Attachment table attributes, you can specify read-through attributes on the business object Attachment table. That is, you can create a reusable criteria that uses read-through attributes from the Files table of the attached file folder object. In the Create Criteria dialog, these attributes appear in the attribute list with .Files as part of their name. For example: Attachment.Files List01 or Attachment.Files Date01.
This expanded list of Attachment table attributes allows you to define reusable criteria based on a list (for example "Internal" and "External"). You can choose to use a dynamic list of suppliers or user groups to define attachment privileges.
The Modify privilege allows a user to modify or edit fields on the tab of an object. Modify privileges are assigned using the AppliedTo attribute settings.
Agile PLM uses Modify privilege mask Applied To properties to determine and control certain specific user actions and attachment capabilities. For example, if a user has a role that includes a Modify privilege mask for parts and the Applied To property includes the Parts.Attachment.FileDescription attribute, then that user is able to modify the File Description field on the Attachments tab of a part object. This same modify action will also modify the File Description field on the Files tab of the referenced file folder object, however, a modify privilege mask for the file folder object is not required.
|
Note: When Attachments.Filename is selected in the Modify privilege mask Applied To property, the user is granted the ability to add files to the table and to delete files from the table and to update the file row on the table. If you need to give users different add file and delete file capabilities, then use the Add to Table privilege and the Delete From Table privilege. Add to Table and Delete from Table privileges take affect when Attachments.Filename is removed from the Modify privilege mask Applied To property. For more information, see "Add to Table and Delete from Table Privileges." |
The following table lists the Modify privilege mask Applied To properties and which attachment actions they control.
This table uses File Folder or Business Object as a placeholder for the class or subclass name in the Applied To attribute column. The actual class or subclass name in any privilege mask is determined by the reusable criteria specified in the privilege mask. (See "Privilege Mask Components"). If you view the example privilege masks mentioned in the Notes column, the Applied To properties will be appropriate for that specific privilege mask (for example, Manufacturer parts.Attachments.FileName).
The Notes column lists at least one example privilege mask that demonstrates a privilege mask that provides the user action; it is not a comprehensive list of example privilege masks. In cases where a Modify privilege mask is not required, only the needed privilege mask is listed (such as Example - Checkin for File Folders). If multiple privilege masks (in addition to a modify privilege mask) are needed to enable the user action, they are all listed.
File Folder attachment actions
Table 37-3 File Folder attachment actions
| User action | Privilege | Class | Applied to | Example Privilege Mask or Role / Notes |
|---|---|---|---|---|
|
Add file to File Folder |
Modify |
File Folder |
Files.Filename |
Example - Modify File Folders |
|
Checkin File from File Folder |
Checkin |
File Folder |
None. |
Example - Checkin for all File Folders (criteria = Example - All File Folders) Example - Checkin for File Folders (criteria = Example - All File Folders Checked Out By Me) |
|
Delete File from File Folder |
Modify |
File Folder |
Files.Filename |
Example - Modify File Folders |
Example file folder roles:
Example - File Folder Manager allows user to work with his own file folder objects.
Example - File Folder Administrator allows user to work with any file folder objects.
Business Object attachment actions
Table 37-4 Business Object attachment actions
| User action | Privilege | Class | Applied to | Example Privilege Mask or Role / Notes |
|---|---|---|---|---|
|
Checkin attachment on Business Object |
Checkin |
Business Object |
None. |
Example - Checkin for Mfr Parts |
|
Remove attachment from Business Object |
Modify |
Business Object |
Attachment.Filename |
Example - Modify Mfr Parts |
|
Edit File Description on Business Object Attachments tab |
Modify |
Business Object |
Attachment.File Description |
Example - Modify Mfr Parts |
|
Edit Folder Description on Business Object Attachments tab |
Modify |
Business Object |
Attachment.Folder Description |
Example - Modify Mfr Parts |
|
Show Version on Business Object Attachments tab |
Read |
Business Object |
Attachment.Filename |
Example - Read Mfr Parts |
Table 37-5 Add New File to Business Objects User Actions
| User action | Privilege | Class | Applied to | Example Privilege Mask or Role / Notes |
|---|---|---|---|---|
|
Add new attachment to Business Object |
Modify |
Business Object |
Attachment.Filename |
Example - Modify Mfr Parts |
|
Add attachment by search to Business Object (requires both Discover and Modify privileges) |
Discover |
Business Object (the business object being searched against) |
None. |
As an example, if the user is searching for item objects from which to add attachments to a Mfr Part, then he requires: Example - Discover Items |
|
Continued: Add attachment by search to Business Object (requires both Discover and Modify privileges) |
Modify |
Business Object |
Attachment.Filename |
Example - Modify Mfr Parts Example - Component Engineer role includes both these example privilege masks and would allow a user to add an attachment to a Manufacturer Part by using Add | Search to search for Items. |
|
Add multiple attachments in one file folder to business object and specify Folder Description (requires multiple Modify privileges) |
Modify |
Business Object |
Attachment.Filename |
Example - Modify Mfr Parts |
|
Continued: Add multiple attachments in one file folder to business object and specify Folder Description (requires multiple Modify privileges) |
Modify |
Business Object |
Attachment.Folder Description |
Example - Modify Mfr Parts |
Attachment redline markups and file folder Ad Hoc redline markups are created, modified, and viewed in the AutoVue for Agile.
The Markup subclass of the File Folders class is used to save attachment-file redline markups. By assigning the appropriate privilege masks to different kinds of users, specific users (for example, vendors) can see and modify only their own markups, but cannot see markups created by other users.
For detailed information about Markup subclass privilege masks, see "Redline Markup Default Roles and Privileges".
Markup subclass objects are visible in Agile PLM for any user that has Read privileges for Markup objects. For example, if a user searches for File Folders class objects, Markup objects are included in the search results. However, the redline markup file they contain can be viewed only when viewing the item attachment-file or the file-folder file with which the redlines are associated. Attempting to view the redline markup from the Files tab of the Markup subclass object displays an error message when the AutoVue for Agile opens.
See also "Discovery and Read Privileges."
Markup Promotion is a generic capability supported within AutoVue to "promote" (copy) markup files from one base file to another. The user can promote markups between versions within the same pending revision (for change-based markup) or previous versions (for ad-hoc markup).
This works with both File Folders class (therefore, objects from File Folder and Markup subclasses) and the new Designs class (objects from Design subclass). It works with both types of markup:
Change-based – from Changes Redline Attachments tab
Ad-hoc – from File Folders or Designs Files tab
Markups are selectable for promotion if they are on previous versions and the file extension is the same, for example, if Version 1 is file_v1.pdf and Version 2 is file_v2.pdf.
Agile PLM uses the file folder subclass Markup to store attachment redline markups created in the AutoVue for Agile. Agile PLM provides a default set of Markup subclass privilege masks and two default roles, Markup for Self and Markup for All. If you have upgraded PLM, you must create these roles by referring to the example roles Example - Markup for Self and Example - Markup for Others. See also "Markup Subclass."
|
Note: The Markup for Self and Markup for All default roles replace the Attachment Redlines for Self (ARS) and Attachment Redlines for Others (ARO) privileges. The privileges ARS and ARO are disabled; ARS and ARO privilege masks have no effect. However, any previously assigned custom ARS or ARO privilege masks are not deleted or removed; so, you can refer to the ARS and ARO privilege masks when creating and assigning redline capabilities with Markup subclass privilege masks or roles. |
A user with Markup capabilities can create and modify the following types of redline markups:
Create and modify attachment redline markups for the affected items of any change order object for which he has Read privileges.
Create and modify Ad Hoc file folder redline markups for any file folder object for which he has Read privileges.
The Markup for Self role allows the user to redline attachments from the Affected Items tab of a change order and to Ad Hoc redline files on the Files tab of a file folder, and he can modify or delete only those redlines he created.The privilege masks in the Markup for Self role are based on the Markup for Self criteria: Markup Page Two.Create User Equal to $USER.
The Markup for Others role allows the user to redline attachments from the Affected Items tab of a change order and to Ad Hoc redline files on the Files tab of a file folder, and he can modify or delete only those redlines created by other users. The privilege masks for the Markup for Others role are based on the All Markups criteria.
The following table lists the default privilege masks in each of the default roles for Markup subclass:
Table 37-6 Comparison of default privilege masks for Redline Markup default roles
| Markup for Self role | Markup for Others role |
|---|---|
|
Read My Markups |
Read All Markups |
|
Modify My Markups |
Modify All Markups |
|
Checkout My Markups |
Checkout All Markups |
|
Checkin My Markups |
Checkin All Markups |
|
Create Markups |
Create Markups |
The following rules and guidelines apply to redline markup capabilities:
If a user does not have Read privilege for a specific Markup object, the associated redline markup is not listed in the markup panel in AutoVue for Agile.
If a user does not have Modify privilege for a specific Markup object listed in the AutoVue for Agile markup panel, the AutoVue for Agile markup panel is disabled and the user cannot edit any redline markup for that viewed file.
If a user does not have a Create Markup object privilege mask, he cannot create new markups from the AutoVue for Agile.
In Admin > Settings > Data Settings > Classes, for File folders class, the Page Two attribute Create User must be enabled. The default value is $USER. This attribute is used to determine "ownership" of each redline markup.
In order to differentiate between privilege masks for Markup subclasses and all other file folder subclasses, Create, Read, Modify, Checkout, and Checkin privilege masks for file folders must use criteria that specify specific file folder subclasses (for example, Markup subclass and File Folder subclass). This enables you to use a set of privilege masks specific to Markup subclass. The Markup-specific privilege masks are assigned only to those users to whom you want to grant redline capabilities.
In contrast, privilege masks based on criteria that specify the File Folders base class or the File folders class will apply to all file folder subclasses, thus depriving you of the ability to restrict redline capabilities (by not assigning to users Markup subclass privilege masks). That is, privilege masks based on criteria for the File Folders base class or the File folders class will always apply to Markup subclass objects.
The default Markup subclass privilege masks are based on broadly-defined reusable criteria (All Markups and Markups for Self). However, you are not limited to these criteria when creating Markup subclass privilege masks. For example, you can enable a list attribute or a multilist attribute, then create criteria that will determine Markup capabilities based on the settings of that list attribute or multilist attribute.
A few recent enhancements concerning attachments are discussed below.
On the standard Actions menu, the most significant added Action is View All Versions. The View All Versions action is available in File Folder and Design objects.
The View All Versions utility is extremely useful as file-folder structures or design structures grow, as it tracks the versions of each design or file folder. Each version displays:
Approved (users who have approved file folder or design in workflow), including the Awaiting Approval icon (users who have not yet approved);
Checkin Date;
Checkin User (which captures the user who checked in the version, and also can read through to the design Structure tab and to Attachments tabs in designs or file folders);
Change Info and Label (as filled in by users); and,
Revision and Revision Date.
Many of these fields are pulled from the object's Title Block tab.
Using the View drop-down, you can have a quick View of a selected version of the design, or select two versions and Compare them visually.
Administrators can set the maximum file size that can be uploaded at System Settings > Viewer and Files > Upload File Size Limit (in MB). This setting defines the maximum size (in MB) of uploaded files for Java Client, Web Client, Portal Client, and SDK.
The default value, 0, indicates "No Limit"; any non-negative integer sets the size limit in MB. Users will see an error message in Java and Web clients if a file is too large. Files that successfully upload (before a failure occurs) remain uploaded, other files (after a failure occurs) will not be uploaded.
You can generate quick access Smart URLs that provide direct pointers to Agile objects, to Agile attachment files, or to Agile searches.
These quick access Smart URLs can be pasted into other applications or files such as spreadsheet files, word processing files, a company Intranet web page or WIKI page, or into an email. When a user clicks the Smart URL, an Agile PLM Web Client window opens and displays the object, attachment file or search window.
Attachment URLs allow you to do the following:
Generate a URL for an attachment on item objects.
Generate a URL for a file on file folder objects.
Generate a URL for a file on the Content tab of Project objects.
Paste URLs from Agile to another application
Externally open files outside of the Agile application.
You can generate attachment URLs from Items, Activities, and File Folders by two methods:
Using Agile PLM commands to copy a URL to your clipboard.
Manually typing an Attachment Smart URL in an easy-to-understand format:
The URL format enables you to identify which object and files are being referenced. Because of the easy-to-understand format, you can generate your own URLs to point to specific file attachments without logging into the Agile system, if you know where the files are located.
For detailed information about all types of Smart URLs, see Getting Started with Agile PLM, chapter "Working with Business Objects in Web Client", section "Smart URL Quick Access to Objects, Files, and Searches."
