You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A weak spot in TG is the lack of row-level permissions. We have URL based, but row level is non-existent. Having a method which would allow for a user to have ownership and/or permission for a given specific database row would be incredibly helpful.
With the advent of (and expanding use) NoSQL databases like Mongo, this is becoming even more of a requirement.
I'm not sure of the best answer, either. With RDBMS setups, the way to define such permissions is not clearly done. Should we add them as a field at the end of the row? Should we have an associated table for each possible table? Should we have a separate table which handles nothing but permissions? It's awkward.
With Mongo, it's easier: Have a separate set of fields in the document that encapsulates the permissions.
With that in mind, I'm leaning towards having the permissions be a json encoded object at the end of the row, and having something that simply knows how to handle that object. What does everybody else think?
The text was updated successfully, but these errors were encountered:
I'm interested in this feature. I believe a separate table managing permissions on each row whould be very flexible: it decorrelates right management from business logic / stuff. Supposing you manage ACL on several table objects, you may be able to get all your rights through one single query (and really do "what you want" for acl management, for example manage acl on compound objects).
Hopefully, this link will work:
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/turbogears/J-LHtyjJh_0
A weak spot in TG is the lack of row-level permissions. We have URL based, but row level is non-existent. Having a method which would allow for a user to have ownership and/or permission for a given specific database row would be incredibly helpful.
With the advent of (and expanding use) NoSQL databases like Mongo, this is becoming even more of a requirement.
I'm not sure of the best answer, either. With RDBMS setups, the way to define such permissions is not clearly done. Should we add them as a field at the end of the row? Should we have an associated table for each possible table? Should we have a separate table which handles nothing but permissions? It's awkward.
With Mongo, it's easier: Have a separate set of fields in the document that encapsulates the permissions.
With that in mind, I'm leaning towards having the permissions be a json encoded object at the end of the row, and having something that simply knows how to handle that object. What does everybody else think?
The text was updated successfully, but these errors were encountered: