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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-talk%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
