Ah, yes I see the problem. Good catch. I hadn't tested that
functionality. Luckily it is a simple change to admin.py. It's a
matter of removing line 25:

form.base_fields["namespace"].queryset =
Namespace.objects.user_can_access(request.user)

And replacing it with the following 3 lines. This basically checks to
see if any related fields are also namespaced, and limits the options
available if so.

for name,value in form.base_fields.items():
    if hasattr(value,"queryset") and issubclass(value.queryset.model,
(NamespacedModel,Namespace)):
        form.base_fields[name].queryset =
value.queryset.model._default_manager.user_can_access(request.user)

Let me know if you have any feedback. I'm glad this little project is
useful to someone else :)


On Mar 22, 6:55 pm, Sven Richter <[email protected]> wrote:
> Hi Tim,
>
> I just tried your app and, wow, this is exactly what i was looking
> for. It works instantly, but, as always, there must be a but.
> One thing doesnt work. I did all as you said, and, like i wrote, it
> worked out of the box, except my ForeignKeys.
>
> In my example i have:
> class Task(NamespacedModel):
>    name = models.CharField(max_length = 250)
>    parent_task = models.ForeignKey('self',  related_name='Parent
> Task',  blank=True,  null=True)
>
> Now, when a user from GroupA with Namespace A accesses the tasks it
> only sees the tasks from namespace a. But, if he wants to add a new
> task, he can choose tasks from other namespaces as parent tasks.
>
> I tried that with a different model combination, with the same result.
> As soon as a model refers to a foreignkey the user is able to choose
> from ever other namespace.
> Can that be resolved somehow?
>
> Greetings and thanks
> Sven
>
> On Mon, Mar 22, 2010 at 10:31 PM, Tim Shaffer <[email protected]> wrote:
> > Django doesn't support that out of the box. I searched and couldn't
> > find anything. Self plug: I created an app that does exactly this.
>
> >http://code.google.com/p/django-namespace/
>
> > Only difference is I called the model Namespace instead of Domain.
> > Just download it, then add it to your INSTALLED_APPS.
>
> > You can then create different Namespaces in the admin, and give either
> > users or groups access to them. Then their builtin django privileges
> > apply only to those namespaces.
>
> > Then for any model that needs to be in a domain/namespace, subclass
> > the NamespacedModel like so. Basically this just adds a foreign key to
> > the Namespace model.
>
> > from django_namespace.namespace.models import NamespacedModel
>
> > class Task(NamespacedModel):
> >    name = models.CharField(max_length = 250)
> >    parent_task = models.ForeignKey('self',  related_name='Parent
> > Task',  blank=True,  null=True)
>
> > Then when you register the model for the admin, use the
> > NamespacedAdmin class (or you can subclass it). This takes care of
> > making sure users in DomainA can only see/edit/delete tasks in that
> > domain.
>
> > from django_namespace.namespace.admin import NamespacedAdmin
>
> > admin.site.register(Task, NamespacedAdmin)
>
> > See the usage for some examples. I think it's pretty straight forward
> > if you're familiar with Django. I've been using it in an internal
> > project with great success.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to 
> > [email protected].
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to