Best So Far (BSF) Minor RevisionThe system manages revisions and minor revisions as families of revisions. For content, each revision can have any number of minor revisions, but only the BSF minor revision is used as the current revision. The BSF revision is the most recent minor revision in the RELEASED state. RELEASED is the published state, so when a minor revision reaches that state, it replaces the previous revision of the content and becomes the BSF revision of that content in the product structure. Each type of content has a defined revision sequence and minor revision sequence. For example, the revision sequence can be alphabetic (A,B,C,...) and the minor sequence can be integers (1,2,3,...). When content is created, it has the first revision and minor revision, such as Part ABC A1, where A is the revision identifier and 1 is the minor revision. If you create a minor revision, it would be Part ABC A2. If you create a revision, it would be Part ABC B1. When that minor revision reaches RELEASED or OBSOLETE (the published states), a new minor revision can be created from the released revision. For example, revision A has these minor revisions:
The BSF revision is Part ABC A2 because it is more recent than A1, and A3 has not reached a published state. As long as content is accessible (read access) to a user, the BSF content is used for major content resolution. Content maturity and security rules apply to each minor revision as shown in this table. The BSF revision remains the same regardless of content access or collaboration space visibility.
Security Ownership ManagementUsers with the Author and Contributor roles can create evaluation, definition and resource content. The creation of a revision implies creating the first minor revision in that family. Users can create revisions for content in the IN_WORK, FROZEN, or RELEASED states. Users can only create a minor revision from content in the RELEASED state. The user that creates a revision or minor revision becomes the owner of that revision. By default, when users create a revision or minor revision, the new revision is created in the IN_WORK state. These defaults can be changed so that either a revision or minor revision (or both) is created in the PRIVATE state. The user who creates a minor revision has read access to all minor revisions in that family except those in the PRIVATE state created by a different user. No minor revision operates across collaborative spaces. The business logic applied when creating objects enforces these authoring rules. A user cannot create minor revisions across collaborative spaces. Other access rules can also affect access. By default, an AUTHOR user can create minor revisions for content owned by other users, but this access rule can be changed so that only the user that owns the content can create minor revisions. For more information, see Allow Write Access Only to the Author Who Owns the Content. Another default allows users from other organizations to modify content. If this access rule is changed, then only users within the same organization can create minor revisions. For more information, see Consider User's Organization Assignment on Content Category. Depending on the various access rules and security ownership of the minor revisions, two minor revisions in the same family might not be visible to the same readers. It is not recommended to have different minor revisions with different collaborative space or organization ownership. To guarantee read access predictability, ensure that two minors with the same maturity status also have the same collaborative space and organization ownership. The ability to transfer ownership can also change the access to minor revisions. |