I have built a similar funcionality for per-row permissions, but it is still a bit ugly. For now it does the following: 1. A new button called "permissions", appears on every object instance you edit. 2. When you clic that button it brings you to a list of permissions for the entry (new model in the auth app) . 3. There you can change permissions on that entry at group level, or user level, but it only states if the selected users can see this entry or not. However this is the part I call "ugly" because it is is restricted to a see/not see permission and there should be some customizable addional options. 4. The good thing is how this perform the access restrictions. Basicaly in the auth application definition I have made a replacement of the managers of all the models, by hacking the Django Manager Class, and replacing the default get_query_set method for every model and every app, so there i force a filter on evere call to the django database api, that hides the results for the current user, so he simply can't see forbidden instances as if they weren't in the database. I liked that approach because it seemed to be very secure and very isolated from your app implementation so you don't have to thing about that when building your apps.
Hope this gives you some clue, Good Luck. On 8 dic, 07:28, Antares <[EMAIL PROTECTED]> wrote: > Hello, In almost all my sites, I'm using a moderation zone, which it's > pretty much the same as the admin zone but I have per-row permissions. > Usually I build multiuser sites, and in my models I always add: > > from django.contrib.auth.models import User > > # This can be: Published, Pending, Rejected... > class state_of_publication(models.Model): > state = models.Charfield(max_length=40) > ... > > class my_model(models.Model): > user = models.ForeignKey( User ) > state = models.ForeignKey( state_of_publication, default="1") > ... > > And then I build moderating zones where moderators can change the > state of the entries, and people can send, edit and delete their > entries. A very small version of the admin zone. > > Now I'm planning to build a generic application that can do the same > in a similar way the admin does, but as I don't want to reinvent the > wheel, I'm thinking to hack the admin app. > > I thougth that this procedurre could work: > > 1-)Add a default permission to all the apps: "can_moderate" > > 2-)Create a model in the admin which holds the state_of_publication of > all the apps (perhaps using generic relations) > > 3-) Hack the admin. For example, we could define the field that is > related with the user > class Admin: > user_field = user > #user_fields has a list of fields that shouldn't be visible > for the > users that can't moderate ( state_of publication,...) > user_hidden_fields = ('state_of_publication',...) > > If the user field is set, then the admin only shows the entries > generated by that user, and can create/edit/delete objects of this > particular user. > A new zone for moderation where you can filter entries by the > state_of_publication and operate with them. > > This can be an initial approach to the problem, but I don't know much > about django yet, and I ask you for suggestions. > It would be great to have this functionality in the trunk in the > future. > Thank you. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---