Groups of accessable objects

[a...@ish.com.au]

I am looking to use this plugin for an open source project (
https://github.com/ari/clockingit/tree ) but have a question about how
it might work for a large number of accessable objects. I want to add
another level of abstraction between the accessable objects and the
roles. That is, groupings of objects. So roles might be:

* customer
* administrator
* project manager
* support engineer

Access levels might be:

* secret
* internal
* public

Each object (in this case a task tracking system) will be given an
access level. So a task or comment might be 'public', (which makes it
draw with a green background in the GUI). That then joins to the
appropriate rights and roles so that access can be determined. This
gives the administrator a separate layer of access rather than
assigning each role to each object.

Does this sound achievable within the scope of this plugin?

http://wiki.clockingit.com/dev:access

Ari Maniatis

please cc a...@ish.com.au on replies

[Tim]

Hey Ari,

How would the access levels used to restrict access to parts of the
app? Would a customer only be able to access public objects, while a
support engineer would be able to access internal and public objects?

-Tim

On May 2, 2:59 am, "a...@ish.com.au" <a...@ish.com.au> wrote:
> I am looking to use this plugin for an open source project (https://github.com/ari/clockingit/tree) but have a question about how

[a...@ish.com.au]

Yes, that's exactly right. So for a task management system, two tasks
might be linked to customer A. But one is marked as public and the
other as private, so customer A has no access to see one task but can
see the other. Internal engineers can see both. That way we can create
tasks which track internal processes, still link the to the relevant
customer for tracking reasons, but hide access.

Sorry for my delay replying... I don't seem to get any email from
Google when this thread is updated.

Ari Maniatis

[a...@ish.com.au]

Does anyone have feedback about whether this plugin might be used in
this way, or should I try and explain the use-case again in more
detail?

Thanks

Ari Maniatis

[Ian Terrell]

If I understand your use case correctly, rephrased below, this plugin could be used for that.

Tasks belong to a client, but are internal or external.  External ones the client can access, but internal ones only your staff can access, and the belongs_to relationship indicates that the task still "relates to" that client.

You could set up this plugin to use hardwired roles and write your own accepts_role?(role, user) method to be something like this:

class Task < ActiveRecord::Base
  belongs_to :client, :class_name => "User"
  def accepts_role?(role, user)
    return true if user.is_staff?
    case role
    when "manager": user == client
    else false
    end
  end
end

Then you could do

permit "manager of :task"

Anywhere you need to check for authorization.  Read the docs for more details on that one.

Naturally if your client is a company which has_many users, or anything else, you'll need to change that implementation sketch.

Ian