There is an interesting requirement in a project I am working on. For
lack of a better term, I'll call it Namespace Security. Basically,
there are arbitrary namespaces that can be defined, and every object
belongs to a namespace. Then, users only have access to certain
namespaces. So if a use
El 11/01/10 13:46, Tim escribió:
> There is an interesting requirement in a project I am working on. For
> lack of a better term, I'll call it Namespace Security. Basically,
> there are arbitrary namespaces that can be defined, and every object
> belongs to a namespace. Then
On Jan 12, 2010, at 8:04 AM, Gonzalo Delgado wrote:
>>
>
> I'm facing similar requirements and came across this app:
>
>http://packages.python.org/django-authority/
>
> but haven't tried it out yet.
>
> --
> Gonzalo Delgado
>
Thanks, I'm looking into it now. It looks like we won't hav
On Jan 12, 2010, at 8:04 AM, Gonzalo Delgado wrote:
>
> I'm facing similar requirements and came across this app:
>
>http://packages.python.org/django-authority/
>
> but haven't tried it out yet.
>
Well, I just read most of the docs, and it looks like this won't work for our
requirements
There's some good stuff in here. My requirements are a little
different than straight-up row level security.
I have a working prototype that I'm going to post on github later
today. It was a lot easier than I thought it would be.
It uses all the standard django permissions (create/change/delete
o
Tim,
I look forward to seeing what you've put together. I'm not so much hung up on
terminology (group versus namespace) as functionality. I mentioned the
specifics in my last post, regarding not having to change the Django queryset
syntax in every view in the application. Does your solution sup
There are a few changes to the filter syntax if you want to get
records that a certain user has access to. So lets say Cars are
"namespaced". To get all the cars that are colored blue, you can still
do this.
Cars.objects.filter(color='blue')
But to get all the cars that are color blue that only t
I had a similar requirement for a current project. Users in the admin
needed to be able to see ONLY the objects that they had created.
My solution was:
1) http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
2) Add foreign key to model to track which user created the object.
3) Use the T
On Wed, 2010-01-13 at 10:20 +1100, Justin Steward wrote:
> I had a similar requirement for a current project. Users in the admin
> needed to be able to see ONLY the objects that they had created.
>
> My solution was:
> 1) http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
> 2) Add fore
On Mon, Jan 11, 2010 at 10:46 AM, Tim wrote:
> The issue is getting Django admin to recognize this. Has anyone seen
> or done anything like this? I have a few ideas where to begin, but
> figured I would ask first so I don't end up re-inventing the wheel if
> something has already been started.
Th
This is something we've been thinking a lot about recently. The direction we
are considering is something like this:
http://github.com/paltman/django-logicaldelete
This code, "logical delete," overrides the delete() method of models so that
they are simply marked as deleted, and not returned in
That looks like a pretty good starting point. It's a little different
in that for my scenario, UserA and UserB would both be accessing
django admin, but would get different results based on what Namespaces
they have access to.
Seems like it should be pretty easy to create a Model Admin that
overwr
Tim,
I think that if you replace the term "namespace" with "group," we can do what
we both want with the same solution. Or, in other words, we're kind of saying
the same thing but using different words.
In my scenario, each user would be in one or more groups. Each user could read
or write any
13 matches
Mail list logo
