Product families

Collection Explorer ◢ General group ◢ Product Families collection

Purpose §

Specifies the users who can or cannot view selected product data.

Product families are used for access permissions, not for simply categorizing items. If you want a searchable tag for item categories, use the item description text or a custom attribute.

Where used §

Parts, documents, changes

Data fields §

General §

Name §

This is the complete name for the product family.

Description §

This gives the product family.

Active: users can select
Default member of collection
Permanent member of collection §

See the Managing collections: Common attributes help topic.

Denied Access list §

You may deny users, groups and organizations access to items in the product family. When the product family is added to an item, persons on this list cannot open the item.

The denied list is ignored for these cases:

• The product family's product team list overrides its denied access list. Users listed on the Product Team always have access to items in the product family.
• Analysts always have access to the items specified by their role.
• Trustees always have access to their items.

Product Team §

When the product family is assigned to a part or document, team members can modify selected attributes. Marking the Product team on a Change Types member workflow includes team members on workflow emails.

To set up the Product Team members and permissions:

1. Unlock the Product Family record.

2. From the Persons collection, drag and drop persons onto the team members list.

3. In the Manage... groups, set the access these persons have on items (parts and documents) and change forms.

An item's product team settings are summed to get the complete set of user permissions. For example, if an item has PF1 with Attributes and Custom marked, while PF2 has Custom and Tasks marked, then a person assigned to both product teams will have permissions to Attributes, Custom and Tasks on that item.

The product team settings allow more users to modify the item. This may increase editing conflicts with the item trustee and other team members. Always add the fewest possible Product Team persons, and enable the minimum set of permissions, to accomplish your goals.

Product families can be added or removed throughout an item's life, whether pending, released, or canceled. This may affect access to attributes on the item, as well as on related change forms.

A document's or part's Trustee, a change form's Originator and change form's Analyst are always treated as members of the product team, regardless of whether they've been explicitly listed on the Product Team list.

Product team members must have a Role that allows normal editing permissions on items. Adding a person with a read-only user account or role will not provide full-function permissions.

In some cases, the product team member has more permissions than the item Trustee or change Originator. For example, a trustee may be assigned a Role that does not allow editing custom attributes after the item's first release; however, a product team member may have a Role with this permission.

Manage as item Trustee §

When a checkbox is marked, the product team persons have permissions equal to the item trustee. For example, when the Custom checkbox is marked, a product team member can edit the item's attributes on the Custom page.

Product team members do not have permission to delete a pending iteration. This must be done by the trustee or an analyst.

General §

Allows edits to item-level fields on the item's General page: Owner, Number, Trustee, Product families list, part Name or document Title, and Name{x} button (when shown). On a part's Attributes page, the Default unit of measure can also be modified until the part is released.

This permission is affected by the user role Edit after first release: Item description setting.

Be cautious allowing product team members General permissions. This allows users to re-assign the Trustee, and to add or remove Product families. This can affect permissions to all other item attributes.

This setting does not allow edits to iteration-level attributes on the General page; see the Attributes setting below.

Iteration §

Allows edits on all editable attributes within the — Iteration — section on the item's General page.

Attributes - Notes §

Allows edits to all attributes on a document Attributes page; on a part, all Attributes values except a part's Default unit of measure (this is managed by the General setting); and on a document or part, the Notes page.

Custom §

Allows edits to the part or document Custom page attributes.

This permission is affected by the user role Edit after first release: Custom attributes setting.

Part: Materials §

Allows edits to the part Materials page attributes: the Part mass setting and the Materials list.

This permission is affected by the user role Edit after first release: Mass and materials setting.

Part: BOM §

Allows edits to the part BOM page Markup list.

Part: Sources §

Allows edits to the part Sources page Markup list.

References §

Allows edits to the document or part References page Markup list.

Revision Files §

Allows edits to the document or part Files page Revision Files list.

Item Files §

Allows edits to the document or part Files page Item Files list.

Tasks §

Allows edits to the document or part Tasks page list.

Manage as change Originator §

When a checkbox is marked, the product team persons have permissions equal to the change form's originator. For example, when the Related checkbox is marked, a product team member can add and remove change forms on the Related page list.

Without originator or analyst permissions, product team members can't delete the change form. Product team members with General permissions can submit and route the change form.

General §

Allows edits to the change form's General page, and permits processing the change to Submitted or Routed workflow states.

Be cautious allowing product team members General permissions. This allows the product team to modify the Originator and Analyst, which can affect permissions to all other item attributes.

Attributes - Notes §

Allows edits to the Attributes page, and to the Notes page.

Custom §

Allows edits to all Custom page attributes.

Affected §

Allows edits to the change form's Affected page list, including disposition rows.

Be cautious allowing product team members Affected permissions. This allows users to add new items and new Product Families that may substantially expand the available permissions to all persons on the added product teams.

Related §

Allows edits to the change form's Related page list.

Reviewers §

Allows edits to the change form's Reviewers page list.

Observers §

Allows edits to the change form's Observers page list.

Files §

Allows edits to the change form's Files page list.

This permission is affected by the system rule Unlock change form Files setting.

Tasks §

Allows edits to the change form's Tasks page list.

This permission is affected by the system rule Unlock change form Tasks setting.

Setup §

The Batch Importer tool can import and update Product Families collection members and persons.

Setting exclusions on the Denied Access list can be valuable if you have users that can see most things, but you want to prevent them from seeing a few selected items. If all of your users are trusted, then not excluding anyone is the easiest option to manage.

PDXpert's underlying security model is "permissive" rather than "restrictive", and all users are assumed to enjoy at least viewing access to the vast majority of items. This makes typical permissions very simple to administer, but it gets complicated when restricted access becomes a major goal across the database. Thus, the Product Families are only useful to deny access to a limited set of items; the vast majority of items won't be denied by a Product Family.

Product Families are separately assigned (and perhaps later removed) on whichever items need the restricted or extra permissions. There's no inherited behavior from related parent items; for example, an assembly's Product Families won't affect the components on its BOM.

Search results always include both normal and denied-access items so users know about, and can request access to, restricted items. Thus, protected items should not contain any secrets within the search results fields (Owner / Type / Number / Lifecycle / Description). Similarly, all item fields are indexed, so a user can search for a secret to test if the system has a match, even if the secret record can't be opened.

When a person needs access to a small number of items, exporting a PDX package is often simpler and more secure than a user account with denied access.

2039