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.

2015. július 24., péntek 17:22:25 UTC+2 időpontban Nathan Peters a 
következőt írta:
>
> 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
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to hobousers@googlegroups.com.
Visit this group at http://groups.google.com/group/hobousers.
For more options, visit https://groups.google.com/d/optout.

Reply via email to