Re: Enabling Row Level Permissions
How would you handle multiple checkers? I'm designing RLP to work on
top of model level checking. Would it be:
checker = (RowLevel, ModelLevel,)
How is the order of permissions checking done if it is multiple? Is it
the order they are specified as?
One thing that will need to be done if it is decided to go this way,
is that RLP needs a relation to be generated in the ModelBase __new__
method, it would have to changedfrom what I currently have.
I think we need to have a conversation about this (on the mailing list
or IRC channel, to get more input). I'm at the point now where I need
to work on integrating checking of row level permissions and into the
admin interface. I'd prefer making any changes to have our two systems
work together now rather then redoing it after I've integrated it.
I've written up two wiki articles about what I've done so far.
http://code.djangoproject.com/wiki/RowLevelPermissions and
http://code.djangoproject.com/wiki/RowLevelPermissionsDeveloper
Any comments appreciated.
Chris
On 7/14/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> Sorry it took so long to respond. Busy week.
>
> On 7/8/06, Chris L <[EMAIL PROTECTED]> wrote:
> >
> > I've currently set up enabling row level permissions using the meta
> > class, e.g. to enable row level permissions for the Mineral model you
> > would have:
> >
> > class Mineral(models.Model):
> > name = models.CharField(maxlength=150)
> > hardness = models.PositiveSmallIntegerField()
> >
> > class Admin:
> > pass
> >
> > class Meta:
> > unique_together = (('name', 'hardness'),)
> > row_lvl_perms = True
>
> I was actually thinking of having a Meta attribute like 'checker' or
> something.
>
> from django.contrib.auth.checkers import RowLevel, ModelLevel
>
> class Mineral(models.Model):
> name = models.CharField(maxlength=150)
> hardness = models.PositiveSmallIntegerField()
>
> class Meta:
> checker = RowLevel
> # or use ModelLevel
>
> This should allow for other types of permission checking to be
> registered without adding a new attribute for each one. For now, the 2
> options for checker could just be basically flags to check... I forget
> what this is called at the moment, but something like:
>
> ModelLevel, RowLevel = 1, 2
>
> Later on, the checker attribute would actually cause something to get
> registered a la the generic authorization stuff I'm working on. If
> checker is not specified, it would default to ModelLevel.
>
> My ideas regarding this are pretty half-baked at this point, but it's
> something to consider.
>
> Joseph
>
> >
>
--~--~-~--~~~---~--~~
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: Re: Enabling Row Level Permissions
> I actually hadn't thought of that. I thought there would be one and > only one type of checking for each model. I can't think of a use case > for multiple checkers, but then again it's Friday and my brain is a > little fried :) No worries about the fried brain, I can understand that. It's been a long day for me as well. Main reason I pointed this out is just because of how I'm working towards having row level perms and model perms work together. I guess you could take two checking methods and combine them using another check method but it would be nice if it's built in. For example, if I want two models with both Model level and Row level I would add those two in as checker but if I want another model with only model level I would use just that. Rather then having three possible "checker" options, I can only use two and just combine them. > I think this part could be pretty simple. I'm planning on changing all > the permission checks in the admin system from (for example) > > if not request.user.has_perm(app_label + '.' + > opts.get_change_permission()): > raise PermissionDenied > > to something like: > > from django.contrib.auth import has_permission > permission_name = app_label + '.' + opts.get_change_permission() > if not has_permission(request.user, permission_name, obj): > # feel free to exclude obj arg for add perms, obj doesn't make > sense in that case > raise PermissionDenied > > I think if you wrote a has_permission function that only dealt with > model level and row level permissions, and then changed the admin > system to use it, integration later on with the generic auth stuff > would be almost trivial (at least as far as actual permission checks > are concerned.) Quite possibly, might have to look into it. How far from having a system which I can base my work on are you? Or review to have a better idea on what I need to do. > You could exclude the obj argument for things like add permissions > where obj really doesn't make sense. This will only work for checking > individual objects however. For the change lists, a custom manager is > a better option than checking permissions on each individual object > after it has been returned. You would have to explicity pass the user > or the user's id into that manager method though. There won't be any > kind of implicit security, which is really how django works now anyhow > and is fine with me. I thought about excluding the add permission by default, but it's not really my place. What permission is assigned to a row level permission is the responsibility of a developer. I don't really want to limit it because of something that doesn't make sense to me, but it might make sense for them (given in this case w/ add, it doesn't make sense at all, but don't want to set a trend). Not sure if a custom manager would be the best option, probably better for the developer to check the permissions within the view code before calling the manipulator to save the object (or even before they see the view screen). > Hmm... (random thought here) what if managers all grew a resrtict > method that took a user object and a permission? (The admin system > would only need to worry about 'change', but arbitrary permissions > should be possible) Row level resrictions on QuerySets could be > localized there. Later on other types of restrictions could be added > via registration (similar to the generic has_permission function I'm > working on.) Maybe you can expand on this a bit more, my brain's feeling a bit slow on this Friday. :D 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 -~--~~~~--~~--~--~---
Generic Authorization Questions
Hi, I'm the SoC student working on row level permissions. Just a few questions about generic authorization for Joseph, and any one else who has input. 1) Will there be any support for the previous method of checking permissions? (e.g. will users.has_permission work?) 2) How are the two of us going to integrate our two systems? I mostly have final testing and making the admin interface for editing row level permissions left and then it's integrating them into the permission/auth system. I have a few ideas, but we should really have a long conversation about this and decide who si doing what and how so we can maximize both our features. Sooner rather then later. :D 3) More a little mistake, in your patch you have in the main admin views file: if not has_perm(request.user, app_label + '.' + opts.get_delete_permission(), obj): probably meant has_permission. I'm off for a bit, went to see LOTR the play last night - good but long, I need to go recover some energy. ;) Cheers, 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: Generic Authorization Questions
I'll try to be on tonight between 7 and 11 MT, I just finished off a 4 hour meeting and need to finish off some work then head home. I might be too tired to make it on tonight, but I'll certainly try. If not, I'll be around tomorrow from 9am to 3:00pm EST (7am to 1pm MT), or on Sat any time past noon. If I'm not on the channel, send me an email and I should pop on soon after that. Nickname for me would be clong. 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: Generic Authorization Questions
As an aside, if anyone is interested in this conversation, please let us know when you are available (on this topic) and we'll try working out a time for everyone. Otherwise, we'll post a log/summary of our conversation and decisions to keep everyone up to date. 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 -~--~~~~--~~--~--~---
Generic Auth and Row Level Permissions
Hi, Joseph and I had a discussion today about how to work our two projects together. Here is what we decided upon. Because Joseph is currently implementing default_has_permission by using user.has_perm. I will be adding row level permissions to the user.has_perm method. To allow for this, user.has_perm will be given an optional "object" attribute that will by default be set to None. If the object is specified and row level permissions are enabled for that object, row level permissions will be checked. In the end, this won't break any functionality for developers using user.has_perm. In the cases where developers want to utilize row level permissions, it is probably best to rewrite the user.has_perm to be the has_permission method Joseph has created. Please feel to comment or ask questions. I'll be rolling out the updated code this weekend, and maybe middle to late next week, Joseph and I can merge branches to make sure that testing is done with the systems integrated rather then find out at the end that there are bugs. 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: JavaScript and Changeset 3541
Hi, I'm the developer working on the branch. A few things, hopefully to answer your concerns. 1) The HTML and JS is written that the AJAX can be turned off very easily(currently it works better with JS disabled then enabled). And I plan on implementing a method of selecting if you wish to use the AJAX or not. I might even implement it so you have to install the YUI toolkit seperately rather then increse Django's size (though w/ the YUI toolkit it works out to about 50-75kb increase in size). 2) The current way I have the interface set up, I find it improves the interface greatly to have AJAX send the request to the server and update the page. I plan on adding some "Apply selected" and "Delete selected" buttons in the next few days but the AJAX does help. 3) The Admin interface already uses a lot of javascript code, I'm just the first to use a toolkit rather then bits and pieces. Hopefully that answers some of your concerns. I'm curious as to the communities take on it, if in general the opinion is to remove it then I will. I personally think the admin interface would work well with some AJAX built into it, but I know that isn't the case with everyone. Comments? Concerns? 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: JavaScript and Changeset 3541
The main reason why I switched was more timing then anything else. I wanted to try a few different toolkits to practice with them and find out the differences. I have never touched AJAX before this summer. I tried Dojo first and did like it, and wrote some working code, which I should be able to rewrite to be more efficient (or the other option I stated below). When I started with YUI I had a much better understanding of what I wanted to do and AJAX/Javascript itself, so I found the code I wrote with YUI working a bit better. The work can be moved to Dojo fairly easily, as it mostly is rewriting the actual AJAX communication, the animations (which can easily be removed, mostly there from me practicing with them, and the DOM commands). The remaining JS is outputting the return message, creating a new row, etc. which is non-toolkit specific. If the opinion is to remove the AJAX code totally, I can do this in such a way that it can be easily reinserted at such a point where we want to implement AJAX into the admin interface. For now, I'll separate the AJAX JS and the non-AJAX js and it can be decided what remains and what goes. Cheers, 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 -~--~~~~--~~--~--~---
Checking Permission Template Tag
Hi,
Joseph and I were talking earlier this evening about how to replace the
permission wrapper context to allow for his generic auth and my row
level permission. We could not determine a way to expand the current
context processor to allow an object to be passed (if you have any
ideas, please let us know).
So what I have done is create a template tag to check for permissions.
It is basically an if statement focused on permissions.
The syntax is
{% load auth %}
{% if_has_perm [not] (permission_codename) [object] %}
{% end_if_has_perm %}
The params in square brackets are optional, you do need to pass on the
permission codename. Right now, the permission codename has to be in
the format that is accepted by user.has_perm (which is
app_label.codename). It can also have an {% else %} tag imbetween the
start and end. I did not implement any AND or OR into it, I think it
would be too busy if they were put in. The user is assumed to be the
current user
Any thoughts on this? Do you think this is an ideal way of checking for
permissions? Or do you know a method we can use to pass the object to
the perm wrapper?
Thanks,
Chris
PS: To see the actual code, check revision 3589 in
per-object-permission branch.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Row Level Permissions Update
Hi, I'm the GSoCer working on row level permissions. Row level permissions are now implemented and, in my test cases, are working. I wanted to find out if anyone has had an opportunity to try the row level permissions (per-object-permission) branch or read my wiki pages on it. Are there any comments on RLPs? Any features that are missing that you wish to be added? 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: Row Level Permissions Update
I'm considering doing what you describe, it shouldn't be too hard to
implement and will probably be updating the branch with the code
tomorrow depending on any unforeseen problems.
Chris
Joe wrote:
> I'm not sure if this is more relevant to the Generic Authorization
> branch, but has anyone looked at implementing the owner permissions
> (the user who creates the object automatically has delete/modify
> permissions)? For example, a META field sort of like the following:
>
> class Meta:
> row_level_permissions = True
> grant_creator = (('edit'),('delete'),)
>
> This way we can specify what permissions the creator of an object has
> on objects he or she creates through the Django administration
> interface.
>
> Chris Long wrote:
> > Hi,
> >
> > I'm the GSoCer working on row level permissions.
> >
> > Row level permissions are now implemented and, in my test cases, are
> > working.
> >
> > I wanted to find out if anyone has had an opportunity to try the row
> > level permissions (per-object-permission) branch or read my wiki pages
> > on it. Are there any comments on RLPs? Any features that are missing
> > that you wish to be added?
> >
> > 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: Row Level Permissions Update
It's determined by the settings under the admin options. By default both are set to false, so no permissions will be creation. To do what you want: ... class Admin: grant_change_row_level_perm = True ... That should just set the change row levle permission and not set any delete row level permission. 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: Row Level Permissions Update
My pleasure :D --~--~-~--~~~---~--~~ 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: Django.contrib applications modifying Django to work properly?
Hi Mart, I'm the per-obect-perm developher. Depends on what magic you are looking for it to do. The row_level_permissions option in the meta class does two things that can be rewritten in a way that doesn't need to involve the db.options (meta class). The first thing the option does is create a generic relationship between the object and row level permisisons, it could have been done manually for each object by using the relation: row_level_permissions = models.GenericRelation(RowLevelPermission, object_id_field="model_id", content_model_field="model_ct") The second thing the option does is check if row level permissions are enabled and does various things with that info. I could have handeled this by checking if the relationship row_level_permissions exists on the object. Hopefully that answers some of your questions. What exactly are you looking to do? I might be able to help, or give some suggestions. As an aside, there have been a few ideas floating around for an application repository and packaging method. For that, I think it would be great if there was a way to have a method of extending the options(meta) model to include some custom options for an application. But that is something for the future. 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: Row level permission problem in admin for inline edited objects
Hi, With the select list, I am hoping for some general public opinion on how to handle this. If the user does not have change permissions on this, does this mean they can not see the object in the select list? I'm not sure if that would be a workable solution. A proposal: Create an additional "admin" permission called "view_object" that would handle this case. It would work just as a read does, the only problem with this is that it might conflict with the change permission. To handle this, we will just check for one or the other permission (if the user is changing/editing something, then it is a change, otherwise it is a view). In the admin interface, this will probably only be used in the above case. Any thoughts? 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: Row level permission problem in admin for inline edited objects
It would work, but there it's not very flexible. The current show_all_rows setting uses the change permission to determine if the object should be shown on the change list. Which makes sense, since the objects listed on the change list are those the user is able to edit. For a related object in a select field it might require a bit more flexibility. For example, if we had a CMS where users can add articles, and there was a category model related to the article model. The administrator might create a list of categories that he does not want to be modified by other users. But he does want it set up so only certain users can post to certain categories and can not modify those given categories. It would work where the user has change permission or view permission. Maybe it's an addition that would only be used in a few extreme cases, if so there isn't much point in having it. For now, I'm working on modifying the code to use hte change permisison, but I'll allow it open to be extended to include a view permission depending on the feedback. Cheers, 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: generic-auth and per-object-permission integration
Joseph Kocherhans wrote: > So I should probably get started on the generic-auth and > per-object-permissions (hereafter pop) integration soon. I've had > problems trying to merge changes from the trunk into the generic-auth > branch, so I'd just assume call that branch dead. The actual > generic-auth code is just a patch to the trunk [1] The easiest way > integrate the two would probably be for me to patch the > per-object-permissions branch. > > I suppose the other option, for the anal-rentively inclined, (which > very often includes me ;) would be to start a new-auth branch, merge > the pop changes to it (or even copy the existing pop branch, yeah, > ick.), and apply the generic-auth patch to it. This sounds like a > total pain in the ass to me. > Probably the better option, we can merge the latest trunk into POP branch then copy it over to another branch and work on that to merge the two together. Might be easier to do testing, especially since I'm still adding features to the POP branch (mostly to do w/ the admin interface) but I want to refactor a lot of my code in the user model for checking permissions. > /me grumbles something about his love/hate relationship with svn, > specifically merge > > I am presupposing that gen-auth and pop should be merged together > before they get merged to the trunk. If you disagree, let me know. Agreed. > > So there's the logistics. Here are the rest of the plans for getting > this into the trunk. > > After the two codebases (gen-auth/pop) are integrated, I plan to > refactor out a couple of functions from the > django.contrib.models.User.has_perm method in the pop branch. After > that, the has_perm method should die. (Some other User methods may > suffer a similar fate) I'll put in some backwards compatibility code > (that *doesn't* support pop), but I think it should be gone by 1.0. I > also want to take a look at how the Meta attributes work for > activating this stuff. I'd like to make it a little more generic, but > I'll bring it up again after I've taken a look at the code. > Sounds good to me. There are a few methods, as I said, I want to refactor in the user model and probably rewrite or remove. The current user has_perm method is fairly backwards compatible, I'm making sure to always make the object parameter for any perm checking to be optional. Also saves on some time if you know you don't want any POP checking for an object. Once I've redone some of my permission code, we can figure out what goes where, etc. Let me know how you think we should rewrite the meta attributes. I'm also considering changing the admin attributes and POPs. After you've had a look at the code maybe we can have another IRC conversation about what should be changed, etc. I'm finishing off some other work this week and starting school right after that, but hoping to get some time this week or next week to work on the POP branch, just depends on how efficient I am. ;) Sorry if the above doesn't make sense, had a long week and last night was a bit hectic...suffering for it today. Cheers, 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: generic-auth and per-object-permission integration
Already had a few people point out some bugs and some features they want. Community involvement is key to get this moving ahead as quickly as possible. Chris Joseph Kocherhans wrote: > On 9/1/06, Linicks <[EMAIL PROTECTED]> wrote: > > > > Once (gen-auth/pop) are merged, what are the major barriers in getting > > that branch merged into trunk? > > Probably just review by Jacob and Adrian. There are several branches > from summer of code that will be competing for their attention over > the next few months. The best thing people can do to speed up the > process is test the branches and report your successes and problems. > > Joseph --~--~-~--~~~---~--~~ 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: generic-auth and per-object-permission integration
Sometime over the next few days when I feel a bit more organized I'll merge it to trunk. Moving into a new house so everything has been a bit chaotic. 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: authentication data
The generic auth branch should allow you to create your own custom permission checking system easily. 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: RowLevelPermissions SQL error
I'll take a look at it today. 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: RowLevelPermissions and OneToOne problem
Nope, not a correct assumption. Fixed in the latest version, I did try it with the model you have given and it does work, but the test was not as indepth (lack of time this week). So please give it a try and see if it fixes this problem. 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: RowLevelPermissions SQL error
Latest changeset should fix it. 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: RowLevelPermissions and OneToOne problem
Fixed in the latest revision. 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: RowLevelPermissions and OneToOne problem
> I'm going to keep lobbing them at you, until it all works :) Perfect, keep them coming. :) Appears to be something related specifically to MySQL. Have it fixed by Monday. 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: RowLevelPermissions and OneToOne problem
Hey, Latest release should fix both. The user_id problem is related to the generic relations used in the POP branch, I've written up a ticket #2749 about it, but it has been fixed in my branch. Let me know how it goes. 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: RowLevelPermissions and show_all_rows
The problem appears to be related to the same stuff we've been dealing w/ earlier. This line(django.contrib.admin.main.ChangeList line 695): qs = self.manager.filter(id__in=RowLevelPermission.objects.get_model_list(self.user, self.model, self.opts.get_change_permission())) Is using "id" instead of "user_id". Fixed in the latest changeset, though I'm not sure if it's the best fix...I'll have to revisit it soon. 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: RowLevelPermissions and show_all_rows
I'll take a look at it and (if all goes well) fix it. Cheers, 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: RowLevelPermissions and show_all_rows
Fixed in latest revision. Chris schotm wrote: > Hi i just started with django yesterday and was testing RLP today. > > In the order it says this in the documentation: > The order of checking permissions will work in the following order: > User Row Level Permission -> Group Row Level Permission -> User Model > Level Permission -> Group Model Level Permission. > > So for a certain row i set a group up with negative permisions for > changing. and i set up a user with permissions to change that row. if > show_all_rows = True it is fine but if it is set to False it gives the > same error as Jay Parlar had. > > (i took the user of the group and everything was fine) > > I don't know if this is a bug or if i am doing something wrong. > > schotm --~--~-~--~~~---~--~~ 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: "Edit Row Level Permissions" showing up everywhere in Admin
Fixed, though not exactly sure how that error was introduced. The file where the bug was, I haven't touched in a while. Strange and random...but it is fixed now. 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 -~--~~~~--~~--~--~---
Merged Per Object Permissions (RLP) Branch
Hey Everyone, I know I've gone missing the past few months, been busy finishing off my last semester at school and recovering from some surgeries. I hope to start working on the RLP branch once again, I've merged the RLP branch to the latest trunk. I've gone through and fixed up some stuff (generic relations being moved, and changing the import for forms, etc) but I need to put some more work into it. I have only started to review the newforms and will look into integrating them into RLP and hopefully improving the RLP admin interface. Please let me know of any problems, complaints, compliments, etc. with the RLP branch. I apologize for my absence and disappearance. Cheers, 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?hl=en -~--~~~~--~~--~--~---
