Currently mappings in between compliance packages work in the following way:
- you have a source and destination
- whatever solution is linked to the source, its automatically linked to the destination
- the destination is “blocked”, meaning you can not edit what it has been inherited
You can tell what will be sync, when you edit the “source” you see the sync icon:
once the asociation of solutions to problems is done, you see the following:
if i try editing the destination, items are grayed out:
If i remove the mapping, what was mapped stays mapped:
We need a few changes:
- we need to be able to map more than two packages (remember, today we have source and destination), imagine the following situation:
Today if we want to map requirement 1a, 1b, 2c, 3c together we simply cant. the new feature should allow us to define something as shown below, were you have a description and some form of array with the mapped items:
When a mapping is created the user must also set if the mapping will be “active” or not when they “Save” it, if they keep it “active” then each one of these mappings will inherit all their solutions automatically:
-
Imagine you have two internal controls, A and C linked to 1a and 2c before you do the mapping, then after I create the mapping, all four requirements will have Control A and C
-
if i delete internal control A from any of these compliance items and save, the system needs to ask me “do you want to remove it from this item alone or from all others as well” ?
-
if I add an internal control D to any of these compliance items and save, the system needs to ask me “do you want to add this control to this particular item or all other mapped items as well” ?
note: the internal control mentioned above applies to any item you can associate in the compliance analysis module
TBC