Hobo permissions. How complicated can the get?

[Nathan Peters]

I'm starting a new Hobo project that is going to have a very complicated (to my experience) permission structure. It is a process control app. Visibility on some things will be controlled both by date and by active user. Users will not even be able to see certain things until a target date, at which point they will have edit rights which should be removed after a second target date. In short, it is heady stuff.

Any tips as I delve into this type of thing? Are there some examples out there (on GitHub or other) that would be a good reference as I think about more complicated process permissions in Hobo?

Thanks,
Nathan

[Nathan Peters]

I meant the subject to read: "How complicated can they get."

[kevinpfromnm]

They're full ruby methods so they can get as complicated as you want, but if you're expecting really complex stuff spend time keeping it clean.  Abstract parts out into helper methods with clear method names.  Use early termination for higher priority permission checks.

[Stefan Haslinger]

I also use the lifecycle actions heavily with their permission system, see: http://hobocentral.net/manual/lifecycles#the-availableto-option 

Some code: https://github.com/informatom/mercator/blob/c33c9ba3de6e3c3900711d32f08a8bf9be06162b/app/models/conversation.rb#L35

where collaborators are defined in the same file lines 66-68

And I use before filters for subsites.

Cheers,

Stefan

[HuBandiT]

My best advice is to plan it as cleanly and thoroughly as you can before you start tinkering with tools and inadvertently paint yourself into a corner.

On Hobo's part the whole thing boils down to "can this user create/edit/update now?", with the addition of per-field "is this user allowed to see this field?" permissions as well. You put behind this as simple or as complex a logic as you find it makes sense for your situtaion, To reduce your work, I suggest you look at capapbility/permission frameworks, e.g. cancan/cancancan or look around for others. There's plenty of boilerplate you could spare that way, time better spent on focusing on what's really specific to your application.

[Henry Baragar]

Hi,

The nice thing about hobo is that it is easy to test complex permission situations through your model tests.  take a look at https://groups.google.com/d/msg/hobousers/XMpolsF5Ty8/63wLKVw-5mwJ for how I do it.

Regards,
Henry

--
You received this message because you are subscribed to the Google Groups "Hobo Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hobousers+...@googlegroups.com.
To post to this group, send email to hobo...@googlegroups.com.
Visit this group at http://groups.google.com/group/hobousers.
For more options, visit https://groups.google.com/d/optout.

-- 
Henry Baragar
Instantiated Software Inc.
http://www.instantiated.ca

[Nathan Peters]

Thank you for the info and examples. That clarifies how Hobo does things. In particular I have a better grasp of how lifecycles and instance methods are handled.

With view_permitted?, can I reference a field name and also another field in the same record? So if, for example, I have a 'user' object that has a tasker boolean and a 'project' that has a review text and lifecycle state that I am checking is "Finished". I only want the tasker to see the review field when the lifecycle state is "Finished" So:

def view_permitted?(field)
     acting_user.administrator? ||
     (field == :review && acting_user.tasker? && :state == "Finished")

end

I realize that the ':state == "Finished"' syntax is probably bad. But maybe you can see what I'm getting at: I want to be able to reference the :state field in the same record to determine visibility of the :review field. I imagine this is possible but it may not work the way I think, or there may be a better way to define that type of permission.

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "Hobo Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hobousers/JBnhy9Oau4s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hobousers+...@googlegroups.com.

[Henry Baragar]

Hi,

view_permitted is a normal ruby method, which has access to all of its other methods in the object, including the "state" variable (you need to drop the leading ":" in your example).

You are on the right track.  The example you gave (modulo syntax errors) follows a common pattern.

Henry 

[Ignacio Huerta]

A lot of good advice here! I second the idea of using model tests: they
really save a lot of trouble when the permission policies changes a year
later :).

Warm regards,
Ignacio

El 20-07-2015 a las 15:54, Henry Baragar escribió:
> Hi,
>
> The nice thing about hobo is that it is easy to test complex permission
> situations through your model tests. take a look at

> <https://groups.google.com/d/msg/hobousers/XMpolsF5Ty8/63wLKVw-5mwJ>https://groups.google.com/d/msg/hobousers/XMpolsF5Ty8/63wLKVw-5mwJ

> for how I do it.
>
> Regards,
> Henry
>
> On 17/07/15 12:05 PM, Nathan Peters wrote:
>> I'm starting a new Hobo project that is going to have a very
>> complicated (to my experience) permission structure. It is a process
>> control app. Visibility on some things will be controlled both by date
>> and by active user. Users will not even be able to see certain things
>> until a target date, at which point they will have edit rights which
>> should be removed after a second target date. In short, it is heady stuff.
>>
>> Any tips as I delve into this type of thing? Are there some examples
>> out there (on GitHub or other) that would be a good reference as I
>> think about more complicated process permissions in Hobo?
>>
>> Thanks,
>> Nathan
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Hobo Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to hobousers+...@googlegroups.com

>> <mailto:hobousers+...@googlegroups.com>.

>> To post to this group, send email to hobo...@googlegroups.com

>> <mailto:hobo...@googlegroups.com>.

>> Visit this group at http://groups.google.com/group/hobousers.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Henry Baragar
> Instantiated Software Inc.
> http://www.instantiated.ca
>

> --
> You received this message because you are subscribed to the Google
> Groups "Hobo Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hobousers+...@googlegroups.com

> <mailto:hobousers+...@googlegroups.com>.

> To post to this group, send email to hobo...@googlegroups.com

> <mailto:hobo...@googlegroups.com>.

[Nathan Peters]

So I am finally getting into the permissions. The following block for my projects model seems to work as expected. But there is going to be a bit more of this. I am concerned about doing things incorrectly and taking a performance hit. Is this the best way to do what I'm aiming for?

 def view_permitted?(field)
    if acting_user.administrator? then
      return true
    elsif (acting_user == self.owner || acting_user == self.tasker) then
      return true
    elsif (acting_user.sitetasker? && self.state == 'submitted') then
      return true
    elsif self.state == 'finished' then
      return true
    else
      return false
    end
  end

The logic is:

1. Administrators can view anything
2. If the acting_user is an owner or tasker on the project, they can view it
3. If the acting_user is one of the site's "site taskers" AND the project is in submitted status, they can view it. Tasker's have to be able to be able to see available projects so they can take them on
4. Once it moves to "finished" status, anybody can view
5. All other users and states should be blocked from view

Thanks,

Nathan

[HuBandiT]

It doesn't apply to this code, but if you happen to have expressions that do do a database query, you might want to memoize the result of the logic internally. E.g. my application handles financial forms with about two thousand fields; each form field had permissions to check during #update, #edit that the acting_user has permission to #update, #edit the form. Despite having specified inverse_of everywhere in my models, this still resulted in two thousand db queries per #edit/#update request - one per field - to check permissions on essentially the same thing for each individual field. So I decided to memoize the result of the check (into a hash indexed by acting_user) and it sped this part up considerably. Your code below does not need this currently if I read it correctly, so just an idea to consider for the future (but of course think through your permission logic to make sure it does not depend on side effects of previous operations within the same request).

It is another question what ruby style one likes, like this long if/elsif or some people like a series of posfix if statements ("return true if acting_user.administrator?"), others like a long boolean expression and let ruby short-circuit it.