Reversal Lookup TODO Needed
I know this is a big/difficult TODO, but the Reversal Lookup needs to handle nested parentheses. I'm talking about (urlresolver.py): # TODO: Handle nested parenthesis in the following regex. result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs), self.regex.pattern) (r'^foo/(?P(/d+)*)/$', ...) will cause it to freak out --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
Hi Ian, Wrote up a summary on the wiki page: http://code.djangoproject.com/wiki/RowLevelPermissions Please let me know what you think, if anyone else has any input please let me know. Right now, I'm working through the source code in more depth then my previous exploration of it, and will be modifying the wiki page to expand and modify what is written there during my journey into it. Any mistakes you notice, please let me know. Thanks, Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
Hi Chris... great write up. my only thought was: why do you need multiple tables to store the row level permissions? Luke has recently submitted a 'GenericForeignKey' in http://files.lukeplant.fastmail.fm/public/python/lp_tagging_app_0.1.zip which may be of interest. it would allow you to store all the information in a single table then. (it stores the content-type of the table as well) other questions to ponder: are you going to allow 'blanket' permissions user/group X is allowed to do Y on ALL rows? are you going to allow negativity ? ie.. person X is NOT allowed to see row Y. regards Ian On 28/05/2006, at 4:47 AM, Chris L wrote: > > Hi Ian, > > Wrote up a summary on the wiki page: > http://code.djangoproject.com/wiki/RowLevelPermissions > > Please let me know what you think, if anyone else has any input please > let me know. > > Right now, I'm working through the source code in more depth then my > previous exploration of it, and will be modifying the wiki page to > expand and modify what is written there during my journey into it. Any > mistakes you notice, please let me know. > > Thanks, > > Chris > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
I think that multiple tables are better because its easier to manage - you can use foreign keys inside the DB, thus it can be faster and clearer plus its easier to drop a table than delete many rows. I gave this feature a lot of thought (I thought of applying for it myself ;) ), here are some of my ideas (feel completely free to ignore them ;) ): Use the category-level permissions as a default, when row-level permissions are not set. If they are, they override the generic (so that you can say, that CODERS can modify all PROJECTS, except project X). The problem with this approach is that it is not compatible with django's auth subsystem where you cannot (please correct me if I am wrong) revoke a privilege once a user has gained it (via group), you can only grant, so that the user ends up with the strongest privileges posiible for him. It would be great if you could also specify a negative permission (as Ian proposes), so that the hierarchy would be: GROUP(s) - USER - GROUP(s) (row level) - USER (row level) and the rightmost permission applicable for a given object (row) would be used, be it positive or negative. Honza On 5/28/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > Hi Chris... great write up. > > my only thought was: why do you need multiple tables to store the row > level permissions? > > Luke has recently submitted a 'GenericForeignKey' in > http://files.lukeplant.fastmail.fm/public/python/lp_tagging_app_0.1.zip > > which may be of interest. it would allow you to store all the > information in a single table then. (it stores the content-type of > the table as well) > > other questions to ponder: > > are you going to allow 'blanket' permissions user/group X is allowed > to do Y on ALL rows? > are you going to allow negativity ? ie.. person X is NOT allowed to > see row Y. > > regards > Ian > > On 28/05/2006, at 4:47 AM, Chris L wrote: > > > > > Hi Ian, > > > > Wrote up a summary on the wiki page: > > http://code.djangoproject.com/wiki/RowLevelPermissions > > > > Please let me know what you think, if anyone else has any input please > > let me know. > > > > Right now, I'm working through the source code in more depth then my > > previous exploration of it, and will be modifying the wiki page to > > expand and modify what is written there during my journey into it. Any > > mistakes you notice, please let me know. > > > > Thanks, > > > > Chris > > > > > > > > > > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
Hi Chris, I have a little feedback if you are interested. [Just so you know, I'm a "heavy user" of Django but have yet to make a substancial contribution to the project] In general I think your proposal is fine but I have a few points: -Lots of tables there! Can you acheive the same without the extra tables? I would guess you can come pretty close. I think by narrowing your functionality to *only* deal with the example you provided you can greatly simplify your implementation and the management of the db. -(Somewhat contrary to the suggestion above!) An alternative approach for the group-level changes: a new permission type that allows you to assign a group that can access that object. i.e. permissionA = access for every user in groupA. Then every user that belongs to groupA can access objects created by any user in groupA. You would then, obviously, add the permission to groupA only -How do you deal with those permissions in the generic and admin views? You may need to change the returned lists to show only those things that the user has created? I'm not sure. I know it would be an issue in the admin pages but the generic lists might be used in various ways (and perhaps the option to choose would be nice). Anyway, that's just what came to me when I was looking. Thanks for taking this on! -rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
> How do you deal with those permissions in the generic and admin views? To be clearer, I meant: How do you deal with those permissions in the generic and admin *list* views? -rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: introduction
one more nit to add to my growing pile, while I use integer's as my keys (which is they default django way), others override this and use strings and other weird things. I'm not sure how my previous suggestion would work when you take that kind of thing into account. On 28/05/2006, at 9:04 AM, Ian Holsman wrote: > > Hi Chris... great write up. > > my only thought was: why do you need multiple tables to store the row > level permissions? > > Luke has recently submitted a 'GenericForeignKey' in > http://files.lukeplant.fastmail.fm/public/python/ > lp_tagging_app_0.1.zip > > which may be of interest. it would allow you to store all the > information in a single table then. (it stores the content-type of > the table as well) > > other questions to ponder: > > are you going to allow 'blanket' permissions user/group X is allowed > to do Y on ALL rows? > are you going to allow negativity ? ie.. person X is NOT allowed to > see row Y. > > regards > Ian > > On 28/05/2006, at 4:47 AM, Chris L wrote: > >> >> Hi Ian, >> >> Wrote up a summary on the wiki page: >> http://code.djangoproject.com/wiki/RowLevelPermissions >> >> Please let me know what you think, if anyone else has any input >> please >> let me know. >> >> Right now, I'm working through the source code in more depth then my >> previous exploration of it, and will be modifying the wiki page to >> expand and modify what is written there during my journey into it. >> Any >> mistakes you notice, please let me know. >> >> Thanks, >> >> Chris >> >> >>> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Reversal Lookup TODO Needed
And another problem. I can't seem to get it to reverse on a url that's in an app urls.py (referenced by the main urls.py, of course). bradford wrote: > I know this is a big/difficult TODO, but the Reversal Lookup needs to > handle nested parentheses. > > I'm talking about (urlresolver.py): > # TODO: Handle nested parenthesis in the following regex. > result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs), > self.regex.pattern) > > (r'^foo/(?P(/d+)*)/$', ...) will cause it to freak out --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
