"Ownership" role for objects...
Jason Huggins
"ownership"... Here's my use case:
Lets say I have 3 users:
1) Superuser - that's me... I can create or edit anything
2) Bob - He only has permission to create, edit, or delete expense
reports that he owns. (He can "own" something he creates, but he can
also be granted "co-ownership" (aka "sharing") rights by someone else.
Bob also has access to view any projects or clients in Django, but not
edit or delete them.
3) Finance admin - She can create or edit any expense reports on behalf
of anyone else
In Django, there is no concept of "ownership"... You either have access
to edit objects or you don't... There is also no concept of read-only
permissions. (But I have a patch for this, that I'm testing now...)
So... does anyone have any thoughts on how to implement "ownership" in
Django? What would define "ownership"? (Any object you create and any
object you're granted permissions to edit? Do we need to track ownerhip
at the object level? How should we track 'sharing' permissions?
I'm kinda sad that Zope has what I need in this department, but I
prefer Django's object-relational mapping code. Are there any great
books on this topic? Or other projects to borrow ideas and learn from?
Would an ACL library (like phpGACL) solve my problem in this case?
Sorry, lots of questions here... Feel free to pick and choose and only
answer 1 of my questions if you have the time.
Ian Maurer
until Django appeared and blew mine away ;) was a "policy" structure
that allowed for ownership and other features that I liked.
I was going to pull it out and re-use it in the project I am working
on, but I figure it is worth posting the concept in this thread to see
if people like it enough to explore generalizing it for Django.
Here is a quick overview of the structure of the code:
- Applications have Organizations (e.g. projects, forums, folders)
- Resources belong to Organizations (e.g. bug in project, topic in
forum)
- Resources have States (e.g. locked, pending, closed, public)
- Users have roles within Organizations (e.g. manager, admin,
moderator)
- Users have relationships to Resources (e.g. owner, editor,
chairperson)
- Policies are defined by Role, Relationship and State combination
allowed or disallowed
- Policies has an "is_allowed" method that takes a User and Resource
object and returns true or false based on its role/rel/state rules.
Here is an example of how to "build" a policy using the Policy API...
but this probably can be abstracted to a config file somehow (these are
the rules for a topic display view for a forum app that has both
private and public forums):
policy = Policy(name="Topic Display Policy")
policy.add_allowed(Roles.Administrator)
policy.add_allowed(Roles.Member)
policy.add_allowed(state=States.PublicView)
policy.add_allowed(Roles.RegisteredUser,
relationship=Relationships.Owner,
state=States.PublicPost)
And then:
policy.is_allowed(user, topic)
would return true if any of the following are true:
- The user is an Admin of the Forum
- The user is a Member of the Forum
- The resource has a "public view" state which it actually figures out
by asking the forum
- The wacky case of a forum that allows "public posting" but only
viewing by those who create the post (for a private forum that
outsiders can post into, but only see the topics they start)
That's all, if there is any interest in this little project, let me
know... I think it could fit in along side of the current ACL
solution... although it is definitely more complex. If it could be
pushed into Middleware somehow, I'd love to do that as well... I just
can't figure out how to do that.
thanks-
Ian
Joshua D. Drake
Thought I would throw a bone out there and ask what it would take to get
transaction
support finished up?
Is there anything we can do to enhance the priority of the feature?
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Robert Wittams
We had the same discussion before.
The point is not anything as specific as ownership. It is authorisation
in general.
The only way to do this generically, without enforcing a horrendous
zope-alike nightmare of per-object acls, is to allow the authorisation
policy to be determined by the model itself.
This means that an instance of the object is asked "Can this user do
this operation to you?", and the object can go and look around any
number of related objects in the database to answer that question.
This means we don't enforce any particular permission system, when in
most cases what is wanted is "Can I reach this user object through these
joins", but some people may really need a massive acl system (for a
_subset_ of their model). Notice than in your example the permissions
are defined by the semantics of the model, your users do not need or
want to mess about with ACLs to modify this permission logic.
These questions have to be asked of the object in the view that is
attempting to do the operation, probably through the manipulator.
So the idea would be to define "special" methods in the model, which
would somehow be incorporated into the generated classes, manipulators,
or modules. These special methods could do anything they like to
determine if the operation should be allowed.
Robert Wittams
designed to try to take care of every problem, whilst proliferating
database entries like there is no tomorrow, and bewildering users and
administrators beyond belief.
There is *no* authorisation system that is going to satisfy everyone.
That is because the authorisation of principals to perform operations is
*part of the semantics of the model* . Whether I can add a CD to my
collection or add a transaction to your account is *part of the model*.
You are not making a filesystem, you do not need a general acl system!
In your model, for any class that you will need to authorise users for
will, through some relationship, have a link to the auth.User instances
that are able to modify it. If that link is direct, fine. If that link
is through a horrendous ACL system that confuses the hell out of your
users, fine.
Then, when you are authorising a user to perform an operation, you will
check against this bunch of links to see whether the user associated
with the request is authorised.
I am fine with people using ACL monstrosities *if they need them*, which
I doubt , but please, please, don't suggest they go in the core.
The open question is :
What can the framework do to make checking authorisation against the
model easier?
I think that the answer here is to make a scheme where particular
methods in model classes are either named or placed in a way that they
are noted as special authorisation methods. Then the default views and
manipulators can use these methods to determine if an operation is
permitted. I'm as yet what the methods should be named, or how/where
they should be called.
Robert
Ian Maurer
>
> This is another ridiculously overcomplicated system that has been
> designed to try to take care of every problem, whilst proliferating
> database entries like there is no tomorrow, and bewildering users and
> administrators beyond belief.
-ian
Ian Maurer
> designed to try to take care of every problem, whilst proliferating
> database entries like there is no tomorrow, and bewildering users and
> administrators beyond belief.
Laurent RAHUEL
> This is another ridiculously overcomplicated system that has been
> designed to try to take care of every problem, whilst proliferating
> database entries like there is no tomorrow, and bewildering users and
> administrators beyond belief.
> That is because the authorisation of principals to perform operations is
> *part of the semantics of the model* . Whether I can add a CD to my
> collection or add a transaction to your account is *part of the model*.
> You are not making a filesystem, you do not need a general acl system!
I'm not really convinced by your arguments because :
- You may be allowed to add a CD to your collection, but not mine.
- You may be allowed to add a CD to some categories of my collection
- You may be allowed to add a transaction to my account1 but not to my
account2 whenever you can add one to my sub-account2 (only if we are on
monday)
It sounds like managing all these use case in the model will store more logic
in those files than they should need.
Moreover, if you don't need a lot of permissions checking, then you just need
a few basic ACL rules to do the job.
BTW, you don't need to make a filesystem to use ACL's. Many MTA, or OpenLDAP
for examples use ACL's for permissions checking.
For example, I've been using Zope's ACL's for a while and I think this model
can cover most of everyone needs
User -> Roles
Roles -> Permissions
Objects needs permissions to be accessed
User can have extended roles (local roles) on some specific objects
> There is *no* authorisation system that is going to satisfy everyone.
Regards
Laurent.
Joshua D. Drake
> a few basic ACL rules to do the job.
>
of advanced development. It just depends on where you do it. You could
do it in PostgreSQL for example by using native database users and
permissions.
In 8.1 you have roles which even further extends the ACL model of
PostgreSQL.
> BTW, you don't need to make a filesystem to use ACL's. Many MTA, or OpenLDAP
> for examples use ACL's for permissions checking.
>
> For example, I've been using Zope's ACL's for a while and I think this model
> can cover most of everyone needs
and they are common place.
>
> User -> Roles
> Roles -> Permissions
> Objects needs permissions to be accessed
> User can have extended roles (local roles) on some specific objects
>
> > There is *no* authorisation system that is going to satisfy everyone.
ability to satisfy everyone because if done correctly it is granular
enough to handle pretty much any situation you will run into, but smart
enough for anyone to manage.
>
> Maybe django core doesn't need ACL's, maybe django users will need ACL's
to take off it is going to need some type of ACL otherwise people are
just going to develop their own and you will end up with a bunch of
different implementations.
Sincerely,
Joshua D. Drake
>
> Regards
>
> Laurent.
Robert Wittams
Simon Willison
On 4 Oct 2005, at 16:00, Jason Huggins wrote:
> So... does anyone have any thoughts on how to implement "ownership" in
> Django? What would define "ownership"? (Any object you create and any
> object you're granted permissions to edit? Do we need to track
> ownerhip
> at the object level? How should we track 'sharing' permissions?
the past) has been on the Django to-do list since early 2004! it
would require a pretty extensive redesign of the permissions system,
which I for one am in favour of as the current system is pretty
limited. Some kend of ACL support is probably a good way to go
although it would require a lot of work (and thought).
Cheers,
Simon
Jason Huggins
> > Maybe django core doesn't need ACL's, maybe django users will need ACL's
>
> I don't think it is a maybe for django users/developers. If Django wants
> to take off it is going to need some type of ACL otherwise people are
> just going to develop their own and you will end up with a bunch of
> different implementations.
Right, I think my original use case is common to lots of people, and
I'm looking for help on the simplest way to solve it... Django
already provides core code for users, groups, and permissions... I'm
now looking for concrete examples and solutions on how to cleanly and
simply "fill the gap" between what Django provides and how to solve my
particular case. I hope I can do this without having to wait for a
rewrite of the Django auth system.
Without implementing a full blown ACL system... I have done a simple
"row level security" scheme in my Django views... Right before I
retrieve an object from the db, I append an additional where clause
criteria ('created_by__exact='bob') ... This is how I ensure that Bob
can only retrieve the things he created. But this scheme doesn't yet
cover the case where Finance creats objects for Bob. This way of adding
additional where clause criteria in the view is probably close to what
Robert Wittams suggested I do anyway (instead of looking to an ACL
system as my savior).
I'm kinda left with the impression, though, that with the web
frameworks I've recently had experience with (Rails, CherryPy, and now
Django), fine-grained authorization is left to the developer to figure
out... And those developers try in their own ways to come up with a
workable solution and maybe post a half-working example to the project
wiki. (I've seen this already for Rails and CherryPy.) But I know that
"security is hard" and I'm sure I'll be missing something if I hack
together my own solution, too.
-jason
hugo
> I don't think it is a maybe for django users/developers. If Django wants
> to take off it is going to need some type of ACL otherwise people are
> just going to develop their own and you will end up with a bunch of
> different implementations
Sorry, but that's a strawman. Django _has_ taken off without a
complicated ACL. It might not take off with you personally, but it did
in a broad scale. Hey, it's already flying for two years without fine
grained permissions.
I'm much with rjwilliams here: please don't go down the route of
full-blown ACL systems. It's ugly, icky and allmost allways not worth
it. Most ACL systems are tied to the logged in user - he's in a group
and that group has rights. But that's wrong more often than right:
users can have rights to objects based on some model state, but not
necessarily just because they are in some group. Think of company
resources, the boss and his second guy: the boss has all access to all
resources. The second guy has all access if the boss is not around. Put
_that_ down in Zope ACLs or try to model a ACL system that can take
stuff like that into account!
No, I think what would be needed is a simple framework that makes
permission calculation easier, but that still should be activated by
the model and the views. Preferreable by the model, because then the
automatic admin can take advantage by it.
So don't build a full blown ACL system, build a library of ACL
functionality, instead. In a way that makes it a just-one-call to check
wether a given user has a needed permission, so that you can use _that_
in your model code to make checks. And add some predefined Exceptions
that will be understood as "not authorized", so that the model
functions can throw that when they discover some situation where a user
is wrongly there - that way the automatic admin can show messages
accordingly.
Add to that a good request/response based transaction support and you
can just bail out and rollback if you discover that the user reached
areas that where not allowed to him.
That would be much more helpfull than hooking some ACL monster into all
of djangos machinery.
bye, Georg
Laurent RAHUEL
Le Mercredi 5 Octobre 2005 09:30, hugo a écrit :
> No, I think what would be needed is a simple framework that makes
> permission calculation easier, but that still should be activated by
> the model and the views. Preferreable by the model, because then the
> automatic admin can take advantage by it.
- Security checking should NOT be done in models nor views. This is a separate
service and should maybe done in some king of a middleware. Objects should
require permissions, check for tose permissions but not contain the logic of
allowed/refused calculation.
Basically, when your little kid wants to cross the street, someone else should
be here to tell him wether or not. (Partially smart example because your kid
is supposed to understand after some hears of arguing ;-))
Regards,
Laurent
Robert Wittams
> Hi,
>
> Le Mercredi 5 Octobre 2005 09:30, hugo a écrit :
>
>>No, I think what would be needed is a simple framework that makes
>>permission calculation easier, but that still should be activated by
>>the model and the views. Preferreable by the model, because then the
>>automatic admin can take advantage by it.
>
>
> Maybe, but I disagree on some other points :
>
> - Security checking should NOT be done in models nor views. This is a separate
> service and should maybe done in some king of a middleware. Objects should
> require permissions, check for tose permissions but not contain the logic of
> allowed/refused calculation.
happen?
Middleware? What on earth does a bit of middleware know about the
*semantics of my application*? How can it?
Please explain either
a) Why authorisation is not a part of the semantics of the application?
b) Why you would want to put a bit of semantics somewhere else?
"This is a separate service" doesn't cut it.
Robert Wittams
> I'm not really convinced by your arguments because :
>
> - You may be allowed to add a CD to your collection, but not mine.
> - You may be allowed to add a CD to some categories of my collection
> - You may be allowed to add a transaction to my account1 but not to my
> account2 whenever you can add one to my sub-account2 (only if we are on
> monday)
>
with an ACL system. Hint: they are easier.
> Maybe django core doesn't need ACL's, maybe django users will need ACL's
fine to have an ACL system provided as an add on that people can link in
to their models if they like. The point is that this is almost always
overkill, so it should not be in the core. If we have a model controlled
authorisation system, you are perfectly free to make your decisions
based on an ACL system.
Robert Wittams
>>Moreover, if you don't need a lot of permissions checking, then you just need
>>a few basic ACL rules to do the job.
>>
>
> I know I am new here but a basic ACL is pretty common place in any kind
> of advanced development.
>
> Well I can't speak to Zope's version but I can speak to ACL's in general
> and they are common place.
>
VB if you want commonplace.
>>
>>
>>>There is *no* authorisation system that is going to satisfy everyone.
>
>
> I don't agree with this sentiment.
statement of positions. Why not have a system that allows them but does
not force them into every situation?
>An ACL model actually provides to the
> ability to satisfy everyone because if done correctly it is granular
> enough to handle pretty much any situation you will run into, but smart
> enough for anyone to manage.
permissions that does not hold the inherent possibility of unmanageability.
> If Django wants to take off
I agree django needs a more powerful authorisation system than currently
exists. I don't agree with shoehorning horrible ACL systems into every
tiny application, when the authorisation is easily expressed in a far
simpler way.
There are a lot of different ways to approach authorisation, we do not
need to limit ourselves to one. For example look at capability systems.
We should not preclude other approaches.
Laurent RAHUEL
> Joshua D. Drake wrote:
> >>Moreover, if you don't need a lot of permissions checking, then you just
> >> need a few basic ACL rules to do the job.
> >
> > I know I am new here but a basic ACL is pretty common place in any kind
> > of advanced development.
>
> Hm, this sounds strangely like "advanced development needs static types."
sounds like "advanced (or not) development needs multiple conditionnal like
switch or case synthax"
Regards
Laurent
Laurent RAHUEL
stopped answering to orders. I really dislike the way you're talking to
everyone. I'm sorry not to be a Guru as you seem to be.
Regards,
Laurent
Paul Bowsher
apps, as it's purely run on the command line so you'd need to ssh in
anyway. Why should I have ACLs forced upon me? Putting this in each
model is by far the sanest and fairest way of doing it.
Paul Bowsher
IT Systems Developer
Simply Stuck Ltd
Laurent RAHUEL
but : Do django need a better permissions managment ?
You can do wathever you want if you're root on your server but you certainly
don't wan't any user to be able to do the same.
Regards,
Laurent
Robert Wittams
change my opinion. Also, someone asking you to justify a development
route/plan is not normally considered an order.
I have no idea how you can enforce security in a model without
knowing/affecting the semantics of the model, and I have no idea why you
would believe that this subset of semantics is a "separate service".
Robert Wittams
a system that would allow ACLs for masochists, as an easy to use add on,
but would not enforce them.
Robert Wittams
> The question is not : Do I want to use ACL's ?
> but : Do django need a better permissions managment ?
>
> You can do wathever you want if you're root on your server but you certainly
> don't wan't any user to be able to do the same.
>
right now.
However, ACLs are not the be all and end all of authorisation. They are
overkill for the vast majority of applications, so they should not be
enforced as the one system that must be used.
Under my proposal, a separate app containing the ACL system would be
added by people who need it ( as django.core and django.auth are added
now).
Then you would use some mechanism that I don't want to commit on* to
link in your model to the ACL model.
* Possibilities include : copy classes (current subclasses) or real
subtypes ( one-to-ones) of an ACL type relating to your model, a
different base type (than meta.Model), or maybe allowing apps to extend
what attributes can be stuck in class META in other apps, meaning they
get a chance during meta construction to add classes, methods to
existing classes, manipulators, and modules. All of these mechanisms are
also relevant for other things people are doing, eg comments that can
apply to anything.
I don't know which of these mechanisms would be best for this kind of
extension. It'll need some thought.
Paul Bowsher
framework, the only access to it is via ssh. I am the only user on the
box, it's not exposed on the web, it's purely command line, so why do
I need ACLs ANY auth framework? ANY proposed auth framework should be
completely optional, and not even added in if not required.
Laurent RAHUEL
> Laurent RAHUEL wrote:
> > The question is not : Do I want to use ACL's ?
> > but : Do django need a better permissions managment ?
> >
> > You can do wathever you want if you're root on your server but you
> > certainly don't wan't any user to be able to do the same.
>
> We can certainly agree on that. Djangos permission system is too limited
> right now.
> However, ACLs are not the be all and end all of authorisation. They are
> overkill for the vast majority of applications, so they should not be
> enforced as the one system that must be used.
> Under my proposal, a separate app containing the ACL system would be
> added by people who need it ( as django.core and django.auth are added
> now).
>
> Then you would use some mechanism that I don't want to commit on* to
> link in your model to the ACL model.
>
> * Possibilities include : copy classes (current subclasses) or real
> subtypes ( one-to-ones) of an ACL type relating to your model, a
> different base type (than meta.Model), or maybe allowing apps to extend
> what attributes can be stuck in class META in other apps, meaning they
> get a chance during meta construction to add classes, methods to
> existing classes, manipulators, and modules. All of these mechanisms are
> also relevant for other things people are doing, eg comments that can
> apply to anything.
>
> I don't know which of these mechanisms would be best for this kind of
> extension. It'll need some thought.
Another directory structure:
myproject/
/apps
/views
/security
And I guess something could be done with Mr Eby security point of view and
generic functions.
Jason Huggins
Robert Wittams wrote:
> Kindly explain how these cases are harder to manage in the model than
> with an ACL system. Hint: they are easier.
Okay, I'm hearing lots of arguments and assertions without proof (from
anyone). Let's try to tone down the emotion here. I simply have a
business requirement that I need to figure out, and I'm kind of stuck
on how to proceed. Nothing more, nothing less.
A restatement of my original problem:
1) Bob has full access to "his" expense reports? (How do we define what
"his" reports are?)
2) Pam (A project manager) has view access to Bob's reports.
3) Fran (A finance department clerk) can create reports on behalf of
Bob. (After they're created, the reports are 'owned' by Bob.
4) Anyone in the AccountPayable group has full access to Bob's reports.
5) Bob only has view access to his reports if they are submitted. (This
is object-state dependent... and yes, perhaps ACL can't handle this.)
6) Here's another "really-nice-to-have" preference. I'd like to be able
to edit my fine grained permissions through the Django admin site. This
way, a security administrator wouldn't have to edit source code if/when
some new group needed access to someone's objects. And Bob could use
the web interface to select additional users that have access to his
reports.
Perhaps it's better if I write up some Django model code and then we
dissect *that*... Instead of dissecting the theory of ACL vs model
methods... If doing the auth in the model is easier to setup, use,
*and* maintain, then I'll do it... But, as you can tell because I asked
the original question... I need some help on *how* to do it. I started
with ACL because that is the "pattern" I can find the most
documentation on and the most real-world examples of. If there are
better examples, I'd like to *see* them.
-Jason
Robert Wittams
>
> Robert Wittams wrote:
>
>>Kindly explain how these cases are harder to manage in the model than
>>with an ACL system. Hint: they are easier.
>
>
> Okay, I'm hearing lots of arguments and assertions without proof (from
> anyone). Let's try to tone down the emotion here. I simply have a
> business requirement that I need to figure out, and I'm kind of stuck
> on how to proceed. Nothing more, nothing less.
>
> A restatement of my original problem:
> 1) Bob has full access to "his" expense reports? (How do we define what
> "his" reports are?)
right? Then this is the owner. This would be exposed by an additional
method.
> 2) Pam (A project manager) has view access to Bob's reports.
representing Pam, and the auth.User instance representing Bob? Maybe an
intervening Project that Bob is a member of and Pam is manager of?
> 3) Fran (A finance department clerk) can create reports on behalf of
> Bob. (After they're created, the reports are 'owned' by Bob.
> 4) Anyone in the AccountPayable group has full access to Bob's reports.
> 5) Bob only has view access to his reports if they are submitted. (This
> is object-state dependent... and yes, perhaps ACL can't handle this.)
> 6) Here's another "really-nice-to-have" preference. I'd like to be able
> to edit my fine grained permissions through the Django admin site. This
> way, a security administrator wouldn't have to edit source code if/when
> some new group needed access to someone's objects. And Bob could use
> the web interface to select additional users that have access to his
> reports.
permissions on *anything* (in which case universally applying an ACL
system to this particular app would work) or just on particular model
classes?
> Perhaps it's better if I write up some Django model code and then we
> dissect *that*...
to do this.
Note that I don't believe that it will necessarily be "nice" doing it in
any way right now : the point of this exercise is to see how to extend
django to make this stuff possible without burdening every app.
Eugene Lazutkin
message news:1128522691.9...@z14g2000cwz.googlegroups.com...
> Okay, I'm hearing lots of arguments and assertions without proof (from
> anyone). Let's try to tone down the emotion here. I simply have a
> business requirement that I need to figure out, and I'm kind of stuck
> on how to proceed. Nothing more, nothing less.
>
> A restatement of my original problem:
> 1) Bob has full access to "his" expense reports? (How do we define what
> "his" reports are?)
> 2) Pam (A project manager) has view access to Bob's reports.
> 3) Fran (A finance department clerk) can create reports on behalf of
> Bob. (After they're created, the reports are 'owned' by Bob.
> 4) Anyone in the AccountPayable group has full access to Bob's reports.
> 5) Bob only has view access to his reports if they are submitted. (This
> is object-state dependent... and yes, perhaps ACL can't handle this.)
> 6) Here's another "really-nice-to-have" preference. I'd like to be able
> to edit my fine grained permissions through the Django admin site. This
> way, a security administrator wouldn't have to edit source code if/when
> some new group needed access to someone's objects. And Bob could use
> the web interface to select additional users that have access to his
> reports.
7) Delivery guys could see some fields from Bob's report but not the full
report.
8) HR guys could see some fields, and modify fields #53 and #94.
8a) Boss of HR can set field #53 to "A", "B", and "C".
8b) Jill of HR can modify #53 to "B", only if #68 was "train tickets".
8b) The rest of HR can set field #53 to "A" or "C".
9) Pam cannot see Bob's report, but can make a reference in her report to
his report.
We can go on ad nauseam. General problem of permissions is huge. It cannot
be solved for all possible scenarios. More than that: permissions are part
of some global consistency schema. There is no questions that any potential
solution should be optional.
I suspect that codebase of any generalized solution would be bigger than
Django's one. Consequently I don't think it can be part of Django. But
Django should be able to be a part of such system. :-)
Thanks,
Eugene
Joshua D. Drake
>
> You want ACLs, I don't. This isn't actually a sentiment, but a bald
> statement of positions. Why not have a system that allows them but does
> not force them into every situation?
you shouldn't have to.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Jason Huggins
> The reports probably have an "owner" foreign key to the auth.User class,
> right? Then this is the owner. This would be exposed by an additional
> method.
Would this be trickier if I want to allow a particular user or a group
to have access?
> 6) needs a little refinement - do you want to be able to change
> permissions on *anything* (in which case universally applying an ACL
> system to this particular app would work) or just on particular model
> classes?
I was thinking that it would be nice if Bob could "delegate" or "grant"
some rights that he has to others... If he can edit expense report #3,
he should be able to "grant edit" on #3 to a
> > Perhaps it's better if I write up some Django model code and then we
> > dissect *that*...
>
> Maybe if you stuck a model up on the wiki we could hash out the best way
> to do this.
>
> Note that I don't believe that it will necessarily be "nice" doing it in
> any way right now : the point of this exercise is to see how to extend
> django to make this stuff possible without burdening every app.
Hmmm... I might hold off on posting my model just yet... After some
more googling, I think I may have found what I'm looking for:
Fine Grained permissions with mod_authz_svn:
http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2
A Python implementation of mod_authz_svn for the Trac project:
http://projects.edgewall.com/trac/wiki/FineGrainedPermissions
http://projects.edgewall.com/trac/ticket/157
http://projects.edgewall.com/trac/changeset/1450
The fine grained permissions configuration is relatively simple.
See the doctests for how easy it is to setup and use the scheme:
http://projects.edgewall.com/trac/browser/trunk/trac/versioncontrol/tests/svn_authz.py?rev=1450
I'm wondering what it would take to make this available as standalone
Python library... If it was standalone, I could use it (or not) in my
Django code, but I could also use it in my CherryPy code... or even
Plone!
-Jason
Robert Wittams
> Robert Wittams wrote:
>
>>The reports probably have an "owner" foreign key to the auth.User class,
>>right? Then this is the owner. This would be exposed by an additional
>>method.
>
>
> Would this be trickier if I want to allow a particular user or a group
> to have access?
>
would be hard.
>>6) needs a little refinement - do you want to be able to change
>>permissions on *anything* (in which case universally applying an ACL
>>system to this particular app would work) or just on particular model
>>classes?
>
>
> I was thinking that it would be nice if Bob could "delegate" or "grant"
> some rights that he has to others... If he can edit expense report #3,
> he should be able to "grant edit" on #3 to a
>
The point is, anything is doable, but the information you are basing
your decisions on would normally go into the model.
>>>Perhaps it's better if I write up some Django model code and then we
>>>dissect *that*...
>>
>>Maybe if you stuck a model up on the wiki we could hash out the best way
>>to do this.
>>
>>Note that I don't believe that it will necessarily be "nice" doing it in
>>any way right now : the point of this exercise is to see how to extend
>>django to make this stuff possible without burdening every app.
>
>
>
> Hmmm... I might hold off on posting my model just yet... After some
> more googling, I think I may have found what I'm looking for:
> Fine Grained permissions with mod_authz_svn:
> http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2
>
> A Python implementation of mod_authz_svn for the Trac project:
> http://projects.edgewall.com/trac/wiki/FineGrainedPermissions
> http://projects.edgewall.com/trac/ticket/157
> http://projects.edgewall.com/trac/changeset/1450
>
> The fine grained permissions configuration is relatively simple.
> See the doctests for how easy it is to setup and use the scheme:
> http://projects.edgewall.com/trac/browser/trunk/trac/versioncontrol/tests/svn_authz.py?rev=1450
>
> I'm wondering what it would take to make this available as standalone
> Python library... If it was standalone, I could use it (or not) in my
> Django code, but I could also use it in my CherryPy code... or even
> Plone!
>
one way of doing it. If we had appropriate hooks, I think it would be
pretty easy to link this (or a database backed acl system) up for
projects that wanted it, without mandating it. I just hope we can get
the hooks right.
Rob