DOORS Next Gen Access Control Workarounds

I am going to take a look at two aspects of user access controls in DOORS Next Generation that frequently come up.

The first is how to restrict read access for some team members to some parts of the project area.

The second is how to limit who can make changes to individual attribute values.

Both of these require a little creativity in workarounds, but, in my opinion, the business needs can be met with the tool.

Restricting read access for some team members to some parts of the project area.

We can selectively restrict edit access to folders with Team Areas, but not read access. Many organizations do not need this level of control, but there are also many who operate on some form of need-to-know basis. The most common situation is one of fairly coarse grained restrictions. For occasional viewing of limited data, an exported report of some kind is an unsophisticated, but relatively simple solution. For more sophistication, including where users need to be able to edit the part of the data that they can see, something more creative is required.

I propose that the simplest solution to this with the 6.0.2 capabilities is to create multiple project areas. This is not as horrible as it sounds. You can import definitions from one project area in to another to keep them in sync. There is still some administration overhead, most notably on the team management, but that is the whole point of using a separate project area in this case. Links between the two project areas can be custom link types if the project areas are on the same server The screenshot shows a custom link type between an artifact in Test Project two and an artifact in Test Project one. The link constraints can also be made to work across projects if the definitions are present in both projects.

Limiting who can make changes to individual attribute values

Limiting changes to individual attribute values is again a much requested process control, and again, one that requires a workaround. This occurs for two reasons, one is that some attributes are only to be edited by a small group of people, and the other is that some users are only permitted to edit a small number of attributes. Whichever case, the effect is the same. There is no easy, out of the box, switch to restrict edit access to selected attribute values.

If the reason for the request is control of a status attribute being limited to a small number of people, then this can be achieved through the requirements workflow. A workflow can be defined in the ‘Manage This Project Area’ section. The workflow has statuses and the transitioning between one status and the next is controlled. The workflow is then selected for an artifact type.

If there are multiple attributes, or something that does not behave like a status, then a different approach is needed. Users can be assigned read only access to artifacts, but this does not allow selective edit access to individual attributes.

I propose that use of the configuration management functionality will give a reasonable workaround. When configuration management is turned on, it is possible to set the project area up such that changes can only be made within a change set. It is also possible to restrict who can deliver change sets in to the main stream, or work space. The users with limited edit access can work in a change set, and an owner, manager or other gatekeeper, will then deliver the changes. At the point of delivery of the change set, the changes are reviewed, and any changes to other attributes will cause the change set to be rejected.

This proposal adds a layer of human effort into the process, but does achieve the business aim. It may also be feasible to set up custom reporting to highlight any disallowed changes, but that does not prevent them from occurring in the first place.