More playing with the per-object branch, and just received this error:
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response = callback(request, *callback_args, **callback_kwargs)
File
"/Users/jaypa
I decided to try out the RowLevelPermissions branch today, and apply
it to some code I haven't put into production yet.
My model is essentially this:
class UserProfile(models.Model):
home_address = models.TextField(blank=True,null=True)
user = models.OneToOneField(User)
class Admin:
Other open source projects seem to have success with Bug Days. Anyone
have experiences with bug days?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Malcolm Tredinnick wrote:
> Raw statistics like this can be misleading and I think they are in this
> case. Yes, it's slightly disappointing to see the number creep up from
> month to month, but it's not a tragedy. Django still works, it's still
> usable in serious applications.
I agree it's still
On Mon, 2006-09-11 at 17:23 -0700, SmileyChris wrote:
> I greatly appreciate the hard work of the current committers, but I am
> starting to wonder if there are too few of them to handle the number of
> tickets being entered into Trac.
>
> Closed tickets with resolution of fixed: 1382 (invalid, w
I greatly appreciate the hard work of the current committers, but I am
starting to wonder if there are too few of them to handle the number of
tickets being entered into Trac.
Closed tickets with resolution of fixed: 1382 (invalid, wontfix,
duplicate or worksforme: 699)
Open tickets: 501
Open tic
Joseph Kocherhans wrote:
> Hmm... looking into this more, Ivan was right... kind of (and maybe
> this is what he meant, but it's not how I read it, sorry if I
> misunderstood).
Or it's rather me being a bit sloppy explaining... I saw the __get__
thing but I know how it works only theoretically.
I've did some quick check of the full-text search. It needs to be
polished (a simple syntax error in lucene indexer) and all backends
finished or droped. I couldn't do more tests as compiling lucene needs
some ricer thinking (on a amd64 linux/gentoo). I'll try to do more real
test when I get some
On 9/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> >
> > I've just found out that request.user is an attribute of request's class
> > not of an instance. Which means that in the environment with multiple
> > requests (threaded or not)
When creating a HttpResponse the headers are mutatable by treating the
object as a dictionary. However, setting the 'Content-type' after
creation does not override the constructors default mimetype.
Is this as designed or a bug?
--~--~-~--~~~---~--~~
You received
On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> I've just found out that request.user is an attribute of request's class
> not of an instance. Which means that in the environment with multiple
> requests (threaded or not) every request.user always points to a single
> LazyUser instance wh
I've just found out that request.user is an attribute of request's class
not of an instance. Which means that in the environment with multiple
requests (threaded or not) every request.user always points to a single
LazyUser instance which is obviously a bad thing. What was the reason
for this
On 9/11/06, Joe <[EMAIL PROTECTED]> wrote:
> Any progress on this? We should make a timeline.
Well, it's hard to have a timeline for this sort of thing. What we
need right now is *not* developer time, what we need is *user* time.
In other words, we need people to:
1. Check out the SoC branches
Any progress on this? We should make a timeline.
--~--~-~--~~~---~--~~
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 fro
Gary Wilson wrote:
> using the example model:
>
> class Name(models.Model):
> name = models.CharField(maxlength=100)
>
> when making a new Name object...
a=Name()
a.save()
a
>
a.name
> ''
>
> The name field does not have blank=True or null=True set, but yet I am
> able
On 9/11/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Are you guys also planning on
> removing the admin application's dependence on
> contrib.auth.models.User?
That's my long-term goal, but generic-auth isn't enough to get there.
is_staff, is_superuser, is_active, get_and_create_messages, and
p
using the example model:
class Name(models.Model):
name = models.CharField(maxlength=100)
when making a new Name object...
>>> a=Name()
>>> a.save()
>>> a
>>> a.name
''
The name field does not have blank=True or null=True set, but yet I am
able to create a new Name object using no paramete
Chris Long wrote:
> The generic auth branch should allow you to create your own custom
> permission checking system easily.
Well, I'm fine with the system that's already there (or the system that
generic auth will be replacing it with). Are you guys also planning on
removing the admin applicatio
Hi Russ
Thanks for your reply
I picked option 1 which worked perfectly :-)
--~--~-~--~~~---~--~~
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@googlegr
sure I could do that.
not DRY though.
anyway, thanks for the hint.
patrick
Am 11.09.2006 um 17:21 schrieb Rob Hudson:
>
> patrickk wrote:
>> 2. when using a custom manipulator for letting the user change his
>> personal values (first name, last name, address, zip_code ...), I
>> have to change
patrickk wrote:
> 2. when using a custom manipulator for letting the user change his
> personal values (first name, last name, address, zip_code ...), I
> have to change 2 different tables (user and userprofile). that doesn
> ´t seem to be clean ... ???
Can you not put first name, last name, and
Done: http://code.djangoproject.com/ticket/2698
--Ned.
Russell Keith-Magee wrote:
On 9/10/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
No filtering allowed.
Hrm. I think you might be right. Taking a closer look, it seems that
the deletion algorithm is fairly conservat
On 9/10/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> No filtering allowed.
Hrm. I think you might be right. Taking a closer look, it seems that
the deletion algorithm is fairly conservative; I can't see a way of
constructing a non-default related manager that would exclude an
object from delet
On 7/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> To all Django committers --
>
> Please don't change any code within django.db.models over the next few
> days. Stimulated by ticket #2306, I took a look in there (particularly
> the file query.py) and was a bit taken aback by how monstrous
The generic auth branch should allow you to create your own custom
permission checking system easily.
Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send ema
25 matches
Mail list logo
