* capability for inplace user no longer defined by dynamic authorities (inheritance was incorrect)
* default roles added to allow capabilities of reader and writer inplace users
* record permission inheritance broken .. was on the todo list for a long time, but needed to be done now to ensure the correct inplace permissions where evaluated at the record level
* unit tests
* TODO ... patches to migrate to 2.1 for new roles and record permission inheritance change
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@49215 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* record service extended with isPropertyEditable method .. indicates, based on the capabilities of the current user and the nature of the property, whether it can be edited
* the record service monitors record aspect property updates and throws ModelExceptions if a user tries to update a record or non-record property if they don't have the appropriate capability
* form filter updated to protect record properties the current user may not be able to edit
* unit tests
So what does this all mean?
It means we can control the write permissions of individual properties on a record based on capabilities. In this case we slice the capability to edit a record in two .. you can either edit the content properties (ie the normal meta-data) or the record properties .. or both of course!
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@49041 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* RM-631 (The records management team can create a rule to request information about an undeclared record)
* RM-632 (The records management team can use an UI action and custom UI to start a "request for information" workflow about an undeclared record)
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48854 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* moved policy implementations out of RMEntryVoter and into separate classes
* rather than being a hard coded list, policies are now registered via spring allowing others to be easily added
* re-arrange some of the support implementation
* RMEntryVoter is now significantly smaller and most of the logic that was once encapsulated in here is spread over supporting classes and services
* TODO .. need to review policies and determine which are appropraite .. much easier to do now!
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48815 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* consolidate the groups capabilities are within (rename and try to simpify)
* 'deprecate' classification related capabilities into the dod specific package .. these capabilities didn't do anything so will be removed until such a time comes when we consider classified records.
* remove legacy unit test .. becomming too difficult to maintain and is covered by newer tests
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48750 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* refactor how we extend the rule's UI
* existing rule's UI is left uneffected .. config no longer needs to be overriden .. so custom config will not effect RM
* web scripts overriden to use RM specific action and condition UI config
* actions and conditions not added to general pool of those available from the rules service ... means no filtering is required on the main UI
* module filter used to override component and redirect to the overridden webscripts
* server side support of records management conditions added
* isFiled and isDeclared conditions added
* TODO .. still a couple of lose ends to tie up
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48659 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
RM-642: A records manager can create a rule with a "Is Declared" condition
RM-641: A records manager can create a rule with a "Is Filled" condition
RM-638: A records admin can choose from a specialised list of RM relevant conditions when defining a records rule
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48587 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* add additional user/group management methods to FilePlanRoleService java API
* add file plan retrieval methods to FilePlanService .. including retrieving file plan node reference from RM site id
* deprecate file plan retrieval methods on RecordsManagementService
* add FilePlanService unit tests
* refactor role web service API implementations to allow the file plan (or rm site) to be specified
* GET roles can optionally include information about the assigned users and groups
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48438 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
* ensure all the record information is removed from a rejected record (seeing issue with ID being reset)
* rejected records are ignored by the create record action
* note: there are still some features we need to add to expand the rejected records use case
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/modules/recordsmanagement/HEAD@48064 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
