Christopher Lenz wrote:
Am 16.04.2006 um 17:38 schrieb Alec Thomas:
On Sun, Apr 16, 2006 at 04:34:06PM +0200, Christian Boos wrote:
...
Then, for the "resource" itself, I think we should pass the "type"
information as well as the "id" only. Relying on the action to
decide what kind of resource to we handle seems a bit kludgy.
I see your point, though my reasoning was that the type is implicit in
the permission. However I guess we already have 'meta' permissions like
TRAC_ADMIN, so maybe it won't be as implicit in the future.
How about passing the resource *object*, e.g. the Ticket or WikiPage
instance?
Of course, that's even better.
The current permission system indeed combines resource-type and
action... if we start adding actual resources/objects to the
permission system, then the resource-type part should be removed,
because it's (in theory, at least) part of the resource specification.
In practice all it takes would be that each object class should define a
'type' property,
and 'id' property, e.g.
class WikiPage(object):
"""Represents a wiki page (new or existing)."""
+ type = 'wiki'
+
def __init__(self, env, name=None, version=None, db=None):
self.env = env
- self.name = name
+ self.id = self.name = name
if name:
self._fetch(name, version, db)
else:
...and so on. Not even a need for a common base class.
Meta permissions and groups should IMHO be replaced by a recursive
role system. And the terminology needs a good cleanup :-P
This stuff of course requires more work than what your patch does,
which is part of the reason why we've been postponing this whole story
to after 1.0.
Well, I'm sure a full fledge "recursive role system" must be worth
waiting for post-1.0.
However, if someone comes with a simpler approach for this, which seems
to be sound,
simple and appears to be a step forward from what we have, then why not
adopt it?
Still, I'd be in favor of you creating a sandbox branch for this work
(but only if it doesn't distract you from the workflow work too much ;-)
Yes, and targeting it for 0.11...
...
def has_permission(action):
self.req.perm.has_permission(action, self.type, self.id)
Making model objects aware of web-layer stuff... not exactly my idea
of a clean design ;-)
I think it wasn't clear enough with what I implied by this.
I think we should have a generic representation of a 'client' request on
the system.
So far, it's the 'req' which approximates this best, but the concept of
a client request
should not be limited to the web-layer (see my other mail ''About env,
req, db,
and repos...'' for a more in-depth discussion of this).
Then, I think it's common practice to have the objects created in the
lifespan of
some context object to keep a reference to that context.
The model objects are actually nothing more than 'proxy' objects for the
'real' data,
that are used by some client operation (perhaps a web request, perhaps a
script).
So I don't see what's so bad about having those objects keeping a
reference to
the context in which they were created and are used.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
