Weceem

Oops, forgot to add the description, and now i can't edit it. The idea is that not all users should be able to change the status of content to any other status. For example, a user with a role of author should not be able to publish the content directly, before an editor reviews it. This of course should be configurable per project.

I am working on implementing this change for a project, and will hopefully add the patch in a few days. I am trying to extend the existing SecurityPolicy so that the permissions can be specified in WCSecurityPolicy.groovy under each role. The result will basically be a map which can be used to look up if a space/role combination is allowed to change from the current content status to a given status. Once this information is part of the SecurityPolicy, I'll think I'll need to change the editorFieldStatus tag to use it (then double check once the form is submitted).

I think that this functionality was planned for weceem, but I couldn't find a specific issue addressing it. Please let me know if this solution contradicts any plans that have already been made, as I would like to keep my local branch of weceem as close to the official version as possible.

This is a patch that adds the functionality. The modification was made on revision 58895 of the trunk.

It extends the SecurityPolicy to also handle permissions for transitioning content between statuses. The permissions are defined per space, for each role. If a permission is not explicitly granted, the assumption is that it is denied - with the exception that a transition to the same status (no change) is always allowed. The editorFieldStatus tag uses the permissions to determine what status transition options to present the user with when editing content, and they are also verified when updating content through the ContentRepositoryService. A policy configuration might now look like:

"ROLE_USER" {
        space '', 'test'
        view true
        
        "/blog" {
            edit true
            create true
        }
        
        allowedStatusChanges{
            '100' (200, 300)
            '300' (200)
        }
    }

The builder for status change permissions has quite a bit of room for improvement. The statuses are indicated using their IDs (since status names depend on the locale) which is a little ugly. Also, since the IDs are numbers, groovy does not look for "missing methods" unless the first status is written in quotes as a string. It is possible to grant a permission for any space, and then restrict it in a certain space by giving an empty list in the specific space like: '200' ().

I included some defaults for when there is no security policy, which grant all permissions for roles ADMIN and USER, so a default installation should continue to work as it did without this change.

Sorry, I've found a problem with the patch, I'm working on fixing it.

This patch replaces the previous one. I had stupidly forgotten to take into account that new content doesn't have a status. Since the statuses can be user defined, I couldn't just add a default status for new content either. I ended up adding another option in the policy builder that allows you to specify the possible transitions from no status. For example, maybe an author can only create content as a draft, but an administrator can create it in any status.

The config now looks like:

"ROLE_USER" {
        space '', 'test'
        view true
        
        "/blog" {
            edit true
            create true
        }
        
        allowedStatusChanges{
            none (100)
            '100' (200, 300)
            '300' (200)
        }
    }

A possible problem is that if a user doesn't have any transitions defined for none, they have no status options when creating content. This effectively means that it is a required configuration for any role that can create content.

I think we may need to use a different syntax for it in the builder, but thanks for your work on this. I'll review the patch and see what we come up with.

We need to support specific statuses for specific URIs also I think, and possibly by content type too, so there are some more parameters to consider here.