ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

[Proposal] Global Roles

Added by Chris Woerle at 2011-09-26 10:33 am

Background

  • We currently have Roles (per Project) and Groups plus the admin - flag to organize users
  • We will want less hardcore superusers instead of only admins
    • e.g. people who have the right to see issues
      • e.g. the general project managers of a company, they should not be admins
  • We want to do this easy

What we've done

We added to every group the ability to configure
  • one or
  • none
    Role as a default role.

The current permission system works like this

  1. is there a project
  2. is the project public
  3. is there roles for the current user in the project
  4. or is the current user admin

(right?)

The permissions for a role are basically checked with

user.roles_for_project

and
user.project_by_roles

If we know have

group.default_role

we can merge that in.

That's what we did.

If a user is in a group and she tries to access a project, we don't only check their memberships, also her groups and assume the same rights.

make it more precise

Currently Roles can be flagged as 'builtin', which makes them not 'givable' and other way round.
We added 'global', to distinguish between 'givable' per project and roles, that artificial and only for meta-purposes (such as 'account manager', 'sales director')

Usecases

  • show things out of project scope based on roles
  • have some 'invisible' users in projects (such as admins)
  • use the same workflows for roles implicitly for groups, instead of defining a lot of new things.

Replies (2)

RE: [Proposal] Global Roles - Added by Chris Woerle at 2011-09-27 10:44 am

What about this code:


 # Return true if the user is allowed to do the specified action on a specific context
  # Action can be:
  # * a parameter-like Hash (eg. :controller => 'projects', :action => 'edit')
  # * a permission Symbol (eg. :edit_project)
  # Context can be:
  # * a project : returns true if user is allowed to do the specified action on this project
  # * a group of projects : returns true if user is allowed on every project
  # * nil with options[:global] set : check if user has at least one role allowed for this action,
  #   or falls back to Non Member / Anonymous permissions depending if the user is logged
  def allowed_to?(action, context, options={})
    if context && context.is_a?(Project)
      # No action allowed on archived projects
      return false unless context.active?
      # No action allowed on disabled modules
      return false unless context.allows_to?(action)
      # Admin users are authorized for anything else
      return true if admin?

      roles = roles_for_project(context)
      return false unless roles
      roles.detect {|role| (context.is_public? || role.member?) && role.allowed_to?(action)}

    elsif context && context.is_a?(Array)
      # Authorize if user is authorized on every element of the array
      context.map do |project|
        allowed_to?(action,project,options)
      end.inject do |memo,allowed|
        memo && allowed
      end
    elsif options[:global]
      # Admin users are always authorized
      return true if admin?

      # authorize if user has at least one role that has this permission
      roles = memberships.collect {|m| m.roles}.flatten.uniq
      roles.detect {|r| r.allowed_to?(action)} || (self.logged? ? Role.non_member.allowed_to?(action) : Role.anonymous.allowed_to?(action))
    else
      false
    end
  end

  # Is the user allowed to do the specified action on any project?
  # See allowed_to? for the actions and valid options.
  def allowed_to_globally?(action, options)
    allowed_to?(action, nil, options.reverse_merge(:global => true))
  end

There is a similar behaviour like 'global roles', specifically this idea:
  1. Is the user allowed to do the specified action on any project?

I don't like this. If a user has a role received as global, that's okay but assuming like that, no.

Can anyone tell me, what the usecases are, for what resources this behaviour will be used?

RE: [Proposal] Global Roles - Added by Felix Schäfer at 2011-10-02 05:09 pm

As discussed on IRC: Holger/meineerde is probably the one to talk to about this, as far as I understood he has plans to change the groups to be more like what you'd expect groups to be, and has poured some thoughts into making the permissions object-level instead of controller+action-level ones, those wouldn't necessarily need to be tied to projects either.

(1-2/2)