Suggestion regarding permissions & co

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

why dont you like declarative authorization or cancan? i dont see why
you
cant do what you described with any of those

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs