why dont you like declarative authorization or cancan? i dont see why you
cant do what you described with any of those
On Wed, Sep 15, 2010 at 5:50 PM, tom
<tomabroad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> hi, since im not fully satisfied with all the permissions-systems out there
> i was wondering if there is another way to handle the whole thing. Based on
> my experience on what i have seen in bigger systems, permissions are
usually
> handled a bit different.
> The Suggestion here (or my insanity) is coming from an ERP system which
> needs to handle *many* tables for *many* users with *many* different needs
&
> settings. im talking about
> userX who can do that and (NOT) see that and so and so forth. So here comes
> my suggestion as well with questions since im sure this is not fully
thougth
> through.
>
> Lets assume we have something like a Sales-Order:
>
>
> SalesOrderHeader
> -belongs_to: Customer
> -belongs_to: ShippingAgent
> -belongs_to: ShippingMethod
> -has_one: Comment
> -has_one: ShippingComment
> ...........
>
>
>
> SalesOrderLine
> -belongs_to: SalesOrderHeader
> -belongs_to: Stockkeepingunit
> -belongs_to: Item
> -belongs_to: ItemDiscountGroup
> -qty: integer
> ...........
>
> as u can see, a basic SalesOrder(SO) consists of 2 basic tables. The tricky
> part are the associations & the permissions:
>
> Suggestion A:
>
> Having a ''Security''-Table (call it whatever u want),
holding this data:
> - name_of _the_table(or an ID id the models are somehow enumerated): String
> (value: eg SalesOrderHeader)
> - can_create: boolean
> - can_read: boolean
> - can_delete: boolean
> - can_update: boolean
> - filter: string (a reegular (my)sql-statemnt) (Value: eg: where
> Customer.Name != ''Sony'')
> - user_id
>
> >>
> + this gives the ability to set permissions for each user on what he
> can(''t) do on that model, including a filter.
> - this would need to be done for each table / model defined by the
> association too
> q: just giving the user access to the salesorderheader would that be
> enough? because of all the associations the user would need (to have(?))
> access to the related tables / models too, right!?
>
>
> Suggestion B
>
> Lets define a ''virtual / verbal'' Permission-Model, eg:
> "SalesOrder".Obviously, we would need to store it somewhere too,
so lets do
> the same, but a bit differentlty:
> - name: String (value: eg SalesOrder)
> - can_create: boolean
> - can_read: boolean
> - can_delete: boolean
> - can_update: boolean
> - filter: string (a reegular (my)sql-statemnt) (Value: eg: where
> Customer.Name != ''Sony'')
> - user_id
>
> >> by giving him access to that he gets access (wr?) to all
associated
> tables / models too. This needs to be stored too then. but then somethign
> else pops into my head: some people should be able to maintain basic
> maindata and some not, which kinda redirects back to Suggestion A....
>
> >> But maybe there is a way finding a merged solution out of both
> Suggestions, havent really thought through the whole thing though.
>
> Summary:
> i know this topic is a painful one, but def an important one, especially
> when u look into erntperise-scaled apps.
>
>
> Before i go further i would like to hear whatu guys think of "one
cool"
> solutions which "just" fits. maybe we can come up with somehting,
if not -
> oh well.But i hope u guys got the drift.
>
>
>
> regards tom
>
>
> ps: forgot the other part: even if a user needs to have different
> permissions on different SalesORder, that would basically be covered by the
> merged in Y-Table, which represents the "security". but thats
part2 anyway
>
>
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.