Michael Radziej wrote:
> DavidA wrote:
> > I've been having a problem rebuilding my database from scratch via
> > syncdb. I've tracked it down to duplicate constraint name. Here is the
> > output from manage.py sql for my app:
> > ...
> > This used to work, I'm pretty sure, but I haven't rebuilt
As long as you're using RequestContext however, the user would always
either be an anonymous user or an authenticated user.
But I guess you don't have to use RequestContext, therefore I'm
answering my own question...
So Adrian (or other submitters), do you need any more work done to
Gary's patch
I can see a use case where you use 'anonymous' as a kind of temporary account for users who access the site in some way other than the usual means.For example if a user gets an invitation to something, like an evite or calendar, an url could be generated that auto-authenticated them into the 'anony
Hrm...
Will there ever be a difference between "user.is_anonymous" and "not
user.is_authenticated"?
If not (and I can't think of a reason), do we really need to keep
is_anonymous?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Go
On 7-jul-2006, at 17:50, Bill de hÓra wrote:
> This is my point. Cut what exactly? "No good" for what exactly? We
> could file patches to see what sticks, but it might be better to
> figure
> what's wanted first, instead of playing fetch me a rock.
This is handled by Unicode standard and is
> 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
DavidA wrote:
> I've been having a problem rebuilding my database from scratch via
> syncdb. I've tracked it down to duplicate constraint name. Here is the
> output from manage.py sql for my app:
> ...
> This used to work, I'm pretty sure, but I haven't rebuilt the whole DB
> from scratch for a lo
On 7/14/06, Chris Long <[EMAIL PROTECTED]> wrote:
>
> How would you handle multiple checkers? I'm designing RLP to work on
> top of model level checking. Would it be:
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
I mistakenly posted this in django-users so reposting here...
--
I've been having a problem rebuilding my database from scratch via
syncdb. I've tracked it down to duplicate constraint name. Here is the
output from manage.py sql for my app:
ALTER TABLE `data_rawinst` ADD CONSTRAINT
`inst_id_refe
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
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 = mo
On Jul 14, 2006, at 10:33 AM, Adrian Holovaty wrote:
> On 7/14/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> And so are we keeping is_anonymous or deprecating it? I guess it
>> would
>> still be useful for determining whether on not your object is an
>> AnonymousUser instance, which seems to be
On 14 Jul 2006, at 03:05, Malcolm Tredinnick wrote:
> Is there any alternative to creating an escaped_unordered_list tag?
> (Any
> better name for this tag? It's too long)
Yes. Implementing the auto escape proposal.
> [Note: useful responses to this question do not include "auto-escaping
> wo
On 7/14/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> And so are we keeping is_anonymous or deprecating it? I guess it would
> still be useful for determining whether on not your object is an
> AnonymousUser instance, which seems to be it's original intent. We can
> keep it and just change the do
> I completely agree -- having a testing framework that depends on an
> external package being installed is almost as bad as not having one
> at all.
>
> Batteries included, and all that...
Very true. I like the approach that Russell has taken in the patches
attached to the ticket. Having a confi
And so are we keeping is_anonymous or deprecating it? I guess it would
still be useful for determining whether on not your object is an
AnonymousUser instance, which seems to be it's original intent. We can
keep it and just change the docs to use is_authenticated.
--~--~-~--~~-
I think I will first attempt to allow order_by to accept related
objects, like order_by('user__last_name'). Could someone please point
me in the right direction? I am not too familiar with django's db
code. What all would need changing?
--~--~-~--~~~---~--~~
Yo
On 7/14/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
Now, what's the license of nose? Perhaps we could bundle it withDjango (as we've done with PyDispatcher and Simplejson)? In my(limited) messing with Django & nose I've been pretty happy so far(but I've not played with Russell's patch for com
Gary Wilson wrote:
> Please look at my original post, I am not trying to use a
> get_last_name() method.
Yes, sorry, I realised this just after I wrote that e-mail and wrote a
better reply.
Luke
--~--~-~--~~~---~--~~
You received this message because you are su
I am working in the localization. It is in developing but I need some
help, by now I would comments. Please read the next thread:
http://groups.google.com/group/django-ecommerce/browse_thread/thread/ed90b6f909964621/0a04618cec26ad21
I started to show the correct addresses of every country in Satc
Bjørn Stabell wrote:
> I was wondering if anyone has made a field for managing hierarchical
> data in Django?
>
> For example, a TreeField that manages "parent" relationships and gives
> the model parent and children object managers:
>
> class Category(model.Model):
> tree = TreeField()
>
>
I was wondering if anyone has made a field for managing hierarchical
data in Django?
For example, a TreeField that manages "parent" relationships and gives
the model parent and children object managers:
class Category(model.Model):
tree = TreeField()
>>> a = Category()
>>> b = Categor
22 matches
Mail list logo
