Refactor ContentClassificationService#hasClearance so that it calls out to
SecurityClearanceService#isCurrentUserClearedForClassification. Restrict
isCurrentUserClearedForClassification so that it only applies to the current
authenticated user (we don't need to use it for anything else). Also
extract classification level comparison to a new class.
+review RM-58
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@104568 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
Make sure this is executed as a patch and also bootstrapped into a clean
system using the BootstrapImporterModuleComponent.
Also restrict access to the classification levels (via the get API) to
only the levels that the user has clearance to.
+review RM
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@104376 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
Move methods to do with content from the ClassificationService and the
SecurityClearanceService into the ContentClassificationService.
Remove the dependency of SecurityClearanceService on ClassificationService
which will allow us to reverse this dependency in the next commit. This is
needed in order to filter classifications by the current user's clearance.
Nb. This included adding a method in the SecurityClearanceService called
isClearedForClassification, which looks quite similar to a new API Roy
created hasClearance (see ContentClassificationService). In the future we
should look to see if we can consolidate these.
Remove dependency of ClassificationServiceBootstrap on the services, so that
it can be passed into them. This allows us to provide access to the POJO
managers in the services (this is made harder as the POJO managers aren't
Spring beans). In order to initialise these objects, change the POJO
managers to use setters rather than constructor arguments. This allows us
to store a reference to the manager before the data has been loaded.
Move the attribute service keys for classification levels and reasons into
the ClassifiedContentModel.
Expect NO_CLEARANCE to be passed into the ClearanceLevelManager, as
otherwise we have to have logic to exclude it (see initialise in the old
SecurityClearanceService) and then more logic to include it again (see the
old constructor for ClearanceLevelManager).
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@104375 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* relates to RM-2129 & RM-2130
* added 'getCurrentClassification" method to ClassificationService
* added concept of system classification level "Unclassified" .. it no longer is required to be specified in the JSON bootstrap since this is a well known and alway required basic classification level
* added concept of system security clearance level "No Clearance" .. automatically added and relates to unclassified classificaiton level
* unit tests updated and added
* started to move some of the logic out of unit test base class and into helper library called 'AlfMock'!
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@104229 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
Created a notion of clearance level distinct from (but related to)
classification level. A clearance level references the highest
classification level it has access to. A SecurityClearance now contains a
ClearanceLevel, which in turn contains a ClassificationLevel.
Created a ClearanceLevelManager and initialise it at the same time as the
ClassificationLevelManager.
+review RM
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@103929 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
I have changed the SecurityClearanceService query API so that it accepts a single Java object containing all the configurable options for such a query. Sensible default values are set where possible. The query object follows the Builder pattern so it should be easier to use the defaults in a query and still possible to change those defaults ifnecessary.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@103471 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* added configuration property that allows existing DoD RM site to be converted to standard RM site
* added deprecated properties back into rma namespace to avoid loss of data
* patches to move properties into DoD namespace not executed if not required
* removed a couple of references to moved properties that still existed
* ensure address properties are moved if required
+review RM
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/BRANCHES/V2.2.1.x@103185 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
