On Mon, Mar 5, 2012 at 5:04 PM, Daniel Nouri <[email protected]> wrote:
> On Tue, Mar 6, 2012 at 1:56 AM, Mike Orr <[email protected]> wrote:
>> On Mon, Mar 5, 2012 at 4:13 PM, Daniel Nouri <[email protected]> wrote:
>>> On Mon, Mar 5, 2012 at 9:27 PM, Jasper van den Bosch <[email protected]>
>>> wrote:
>>>> I have a question for the traversal users:
>>>>
>>>> do you
>>>>
>>>> a) load your model from data (i.e. sqla) and add the resource properties
>>>> (request, __parent__) in the parent?
>>>
>>> There's no reason your models can't just implement __parent__ and
>>> __name__ as properties themselves. These have nothing to do with
>>> HTTP. (No need to know about the request for traversal!)
>>>
>>> An example using SQLAlchemy:
>>> https://github.com/Pylons/Kotti/blob/master/kotti/resources.py#L108
>>
>> So how would you apply this to a normal SQLAlchemy database, that may
>> have the concept of name and parent but not in the resource structure?
>> In particular, an ordinary 1:many relationship where the parent has
>> several children with a backref to itself, but not using the words
>> "name" and "parent".
>>
>> class Main(Base):
>> id = sa.Column(sa.types.Integer, nullable=False, auto_increment=True)
>>
>> subs = orm.relationship("Sub", backref="main")
>>
>> class Sub(Base):
>> id = sa.Column(sa.types.Integer, nullable=False, auto_increment=True)
>> main_id = sa.Column(sa.types.Integer, sa.ForeignKey("Main.id"),
>> nullable=False)
>>
>> In this case, the 'id' fields can serve as the .__name__, converting
>> them to a string if necessary. And the 'main' backref is equivalent to
>> .__parent__. So would the name and parent simply return these
>> properties?
>
> Yes, they would.
OK. Any tips for attaching an ACL to them? Especially in the case
where permissions are record-specific. For instance, I have a
situation where one group can view and edit all records, another group
can only view, a third set of users (not a group) can view/edit only
this record or a few records, and a fourth set of users can view this
record or a few records but not edit them. Would I just specify:
[(ALLOW, "g:manager1", "view"),
(ALLOW, "g:manager1", "edit"),
(ALLOW, "g:manager2", "view"),
(ALLOW, "user1", "view"), #... user2, user3 ...
(ALLOW, "user1", edit"), # ... user2, user3...
(ALLOW, "user4", "view), # ... user5, user6..
].
How do these interact with the permission arg in the view
configuration, and with the strings coming from the authenticator?
What does a DENY element mean, and how does it interact with the view
config? Does ALLOW mean this permission string is included, and deny
means it's excluded? So the permission arg causes a check whether that
string is excluded? Why would you need DENY at all then if the default
is deny?
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en.
