Record settings

You can use system-wide settings for record types to help manage, categorize, and apply security policies to work processes.

The following types of system-wide settings are for managing both projects and work:
  • Category

    The project categories you define are available system-wide. This allows for reuse and consistent classification across multiple projects. CategoryType labels are also available system-wide. Categories can be secured by a Security Policy and so they are available or hidden from a particular user. Categories and category types allow you to model your classification system for projects. You could also define a set of hierarchical categories to decompose large systems into smaller more manageable units.

  • Security Policy

    Security policies are defined by adding one or more HCL VersionVault groups to an ALM Security Policy record. Once set, project managers can create new projects and choose the existing security policy needed for that project. You only need to define a security policy if a new policy is needed.

  • ALMAdmin

    The Admin record type determines who can create projects, categories, and labels.

  • ALMType

    Types are used to identify the nature of the work. Types apply to Request, Task, and Activity records. You set the types system-wide. Project teams then configure which types to use by creating a Work Configuration. Some examples of a Type include, but are not limited to, Enhancement, Defect, and New Feature.

ALMSecurityPolicy records are associated with a Category, and are also associated with Projects, as Projects are created that reference the Category. For teams doing component development, there can be several Components, each with its own Categories and Releases, as part of one or more Offerings. In this case, a one to one relationship between a Category and a SecurityPolicy may cause some records to be not visible to people that need to see them. To prevent visibility issues, a SecurityPolicy should include either one large HCL Compass user group as its ratl_context_groups reference or it should have a user group for each component with all of the user groups referenced by the SecurityPolicy that would be shared by all of the development teams working on components. There are also performance benefits by maintaining a set of smaller groups rather than using one large group (or setting a SecurityPolicy to the Everyone group), and organizing groups and SecurityPolicy records by the structure of the components.

Component development example

Each versioned piece of new development work can be a Project with a Category that specifies the component and a Release that specifies the version of that Category.

A customer finds a problem in a major product produced by your development team. This Product (referred to as an Offering) includes several Components each of which is developed by separate teams. When the customer sees the problem, they think of the Offering as having the problem rather than the Offering's Components. When the team lead follows the triage process for a Request for that Offering and reviews the Request, they will note that:
  • The problem is in a Component that is included in the Offering and needs to be fixed there not in the Offering which may be nothing more than a collection of Components and not have any of its own code apart from what comes in the Components it includes
  • The Offering needs to include the new version of the Component once its been fixed and a new version of that Offering needs to be provided to at least the customer that discovered the problem and probably all other customers.
The triage team creates two ALMTask records that are associated with the ALMRequest entered against the Project for a given Category and Release (for example, Category='OfferingA' and Release = '1.0'):
  • ALMTask with Project Category='OfferingA' and Release = '1.1'
  • ALMTask with Project Category = 'ComponentZ' and Release= '3.4'
The triage team first reviewed the ALMBaseline record for Project Category='OfferingA' and Release = '1.0' because these values are what the ALMRequest identified as the FoundInProject, and they can see that the Release of 'ComponentZ' that is listed in the ALMBaseline ComposedOfBaselines field is Release = '3.3'.

Activities are created for the ALMTask for 'ComponentZ' and the solution is developed, documented and tested. An ALMBaseline record is created when the actual baseline is created for Project Category = 'ComponentZ' and Release = '3.4' and a second ALMBaseline is created for Project Category = 'OfferingA' and Release = '1.1' and that ALMBaseline record has a ComposedOfBaselines value (another Baseline record) that has a Project Category = 'ComponentZ' and Release = '3.4'.

A BTBuild is created for the ALMBaseline whose Project Category = 'OfferingA' and Release = '1.1'. Testers can see that a BTBuild is displayed in the Build column and the Composite.Build column of the 'Dev' Activity displayed in the Task's Activity Form control whose Project Category = 'OfferingA' and Release = '1.1'. They can see that there is at least the ID of a Build produced from the composite baseline and in the result set of the query they can see the name of that Build. Component testers and Offering testers can both see that there is a Build based on the Composite Baseline.

In the Composite Baseline record the Component is listed in the ComposedOfBaselines field.