Advanced ARMing

dummy objects

:dummy => :id
:dummy => Proc.new { }
:dummy => Fixnum
:dummy => <some object>

While the dummy object provides an object with some meaning it will always be set read-only: you cannot update the dummy object in the database when it was returned because of the :dummy parameter. This does not apply if the dummy object is not or not only returned because of the :dummy parameter: while the following code snippet

Klass.create :id => 1, :name => “The dummy object”
Klass.find :all, :roles => :whatever, :dummy => 1

does return the dummy object created for the class, it is not set read only if the current user has the :whatever role on it. A returned dummy object implements a marker method, which can be used to determine its dummy object status via

Permission.is_dummy_object?

If multiple dummy objects are needed at once, find always returns the same object. This does somewhat violate the original find's contract: if

Klass.find(1,2,3)

returns (i.e. if it doesn't throw) it returns three different objects with different id's. The armed call

Klass.find(1,2,3, :roles => :whatever, :dummy => 1)

returns an array of three objects (given they exist in the database), which might contain the dummy object up to three times.

System permission objects

To guard non-AR-models against unauthorized access we implement what we call a “system permission objects”. To create a permission object you use

Permission.object(<parameter>)
Permission.object()

If you want to implement permission object for a specific object it must implement a to_permission_object_id method, which should return a string (preferrably) or a number. For simply controlling access to a certain code block in a predefined way simply use a symbol like that:

Permission.object(:backend)...

Note that you must delete permission objects manually to get rid of them:

Permission.delete_object(id,id,id,...)
Permission.delete_object(id,id,id,...)

System permission objects implement the permitted! and permitted? methods.

Predefined system permission objects

Instances of these classes automatically act as system permission objects

• Class
• ActionController

Temporarily disabling roles

...might come sometime. It is good it is written here, though, isn't it?

Composed roles

In a first draft of ARM we wondered: should we allow to pass more than one role to find? The syntax question was easily solved: just pass in an array of roles. The semantics of that were harder to decide. What would the user expect? Should find :role =>=> [ :read, :write ] return all objects that can be read and be written? Or should it return all that can be read and throw in all writable objects?

After giving this some thought we decided (currently) not to allow this, but to implement “composed roles” instead, that requireinstead: the user has to state more explicitly what he really wants. To return all objects that are readable and writable ask for

:role =>=> :read_and_write 
 

For all readable and all writable objects – including writable objects that are not readable and vice versa – you ask for

:role =>=> :read_or_write 

You can even combine more than two roles, as long as you don't mix “and” and “or”. And like before you may pass the role as a string or as a symbol – that is up to you.