Add a Confidential attribute

Prerequisite: You must be familiar with the Syntax used in Tutorials and have already created an extension.

Need: Some information on a particular object, must be restricted to some users only in term of visibility.

Constrains: Currently iTop handles read access globally by class and organization. There is no option to go down at the field level.

Proposal: This tutorial will propose a way to implement a confidential attribute

• Read access is limited to those having the right profile, others will just see *
• Write access is given by profile
• The confidential attribute can be of any type, it could be a cost, an html description, an image a caselog,…

• In order to ensure that the field can never be read by someone not allowed, we will put it in a separated class.
  

Side note: Hiding a field from an object details based on current user is a false security, by configuring the fields displayed on a list of those objects, anyone could gain access to this field values

• Create the confidential class
• Update the hosting class
• Connect the plumbing, to make it a one to one relationship

This new class will only contains:

• a hardcoded friendly name with ******
• a value field of the type corresponding to the confidential value you need to store
• an external key to the hosting class which should contain that confidential attribute

This class must be set with category = grant_by_profile,application

• grant_by_profile allow to control who will see it, so you need to create a Group including this new class and Profile(s) containing this new Group
• application will remove it from the read access provided by the Group All classes (*)

Define a summary card with the “value” and the friendlyname of the host object

Can be put in any module, but the module the hosting class seems coherent

• Prevent edition of the key from the confidential attribute class → read-only (2 events)

• Won't work !!! Prevent creation of such object with CheckToWrite when no external key are present (event)
• Hide the field from the form, but put “host_id_friendlyname” in the form to help rember what you are changing

Create an External Key to the newly created class

• Add a filter to list only confidential attribute not affected (to avoid proposing any in fact)

• Ensure AfterWrite →
  • Update ExternalKey of confidential attribute
  • Prevent edition of the external key when != 0, but you can still change its content

Create a LinkedSet attribute on Confidential class with the ext key host_id and display it as “properties”

Cf Add a 1:1 relationship

• Pure creation of a Confidential Attribute cannot be prevented, leading to orphan values
• Attribute edition cannot be done in pop-up