When I provide training for Content Manager I always start with security. It doesn't matter if security is a major concern for the organization or not. The main reason I do this, besides just needing to explain how it works, is to minimize the occurrences of security breaches. A security breach is a system flag indicating that the objects associated with a record are not in alignment with the security paradigm.

There are two places that you can define the behavior of security breaches within the software: the security tab of the system options and on the properties of a record type. If I use the out-of-the-box configuration of Content Manager, the former is set to "Display Warning" and the latter is set to "Ignore". For the moment I'll focus on the first.

Here's the option I'm talking about:

If you press F1 you'll see a description for the setting, shown below.

“When changing Assignee, Home or Owner for a Record to a less secure Location - set the method of Location change when a selected record has a lower security classification than the Location. See also Security breaches.

The options are
•Ignore
•Display Warning - default
•Prevent”

If I lookup "Security breaches", as it recommends, I get this description:

“This function enables a HPE Content Manager administrator to view and print occurrences of security breaches that may have occurred.

Security breaches appear in an Historical Events dialog box with all other events that have occurred, for example, Location and container changes and movement history.

By default, the security breaches function will only show security breaches for the current day.

For events to be logged, the relevant event must be selected in the Audit tab of the Record Type.”

The end result is a pop-up message like this:

Funny! I have the "Display warning" option selected but it still won't let me save it. I feel bad for developers at times... having to maintain this complex web of features and then having silly bugs like this. In a non-buggy build I would be able to click OK and continue on saving the record. For now I'll work around the bug by assigning it to myself and then reassigning it to Elmer.

Once I've done that I can go check out the online audit log. It will show me all the activity for today, including the right-most column that indicates if a security breach was detected. The screenshot below shows a series of assignments. Note the assignments to Elmer are breaches but the one to myself is not.

To resolve this I need to find out what's missing from Elmer's profile. Now you might think I could use the View Rights feature whilst impersonating Elmer, but you'd be wrong! As shown below, the UI is indicating the security profile is met by Elmer... but I suspect this is another bug

Instead, I look at the security profile of the record. I see that it has a security caveat of "HR"...

Now if I look at my location structure I can see the problem...

When I on-boarded Elmer I didn't give him a security profile. So it makes sense that assigning something to him would breach the security of the record. Elmer is completely unaware because he can't even access the record. So this notification is the administrator's opportunity to fix the problem. To resolve it I need to add the HR caveat to Elmer's profile.

The situation happens anytime you've elected to use a mixture of security levels and caveats. The best example is a secured facility's mail room, where they may be indexing incoming correspondence and assigning it to the wrong person accidentally. For that scenario they should be prevented from continuing, because we can't deliver the item as we register it officially. In other environments it's not the end of the world... it's something to manage.

If you take a look at this question over on the forum, you'll see a common situation. Imagine how much time he's going to have to spend fixing this problem! For a 50 user or less implementation it's a quick task; but for a 5,000 user site, good luck. He might want to engage a developer within his organization or a knowledgeable consultant.

I thought I'd be creative and write a powershell script to sort this out for him, but no such luck. It executes fine but doesn't actually save the updated security profile. Maybe a developer will read this and fix it! :)

Add-Type -Path "D:\Program Files\Hewlett Packard Enterprise\Content Manager\HP.HPTRIM.SDK.dll"
$db = New-Object HP.HPTRIM.SDK.Database
$db.Connect
$breaches = New-Object HP.HPTRIM.SDK.TrimMainObjectSearch -ArgumentList $db, History
$breaches.SearchString = "breach"
foreach ( $breach in $breaches ) 
{
    $location = ([HP.HPTRIM.SDK.History]$breach).MovementLocation
    $unit = $location.Unit
    $recordProfile = ([HP.HPTRIM.SDK.History]$breach).Record.SecurityProfile
    if ( $unit -ne $null -and $unit.SecurityProfile.CanAccess($recordProfile) ) {
        $location.SecurityProfile.UpgradeTo($unit.SecurityProfile)
        $location.Save()
        Write-Host "Updating $($location.FullFormattedName) to security profile of $($unit.FullFormattedName)"
    }
}

Executing this will at least give me a report of all the users that should be updated. The example below lists Elmer Fudd twice, exactly as shown in the online audit log.