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
-~----------~----~----~----~------~----~------~--~---

Reply via email to