Why wouldn't a AnonymousUser have permissions?
Imagine a site where can create photo albums.
User A creates two photo albums, one to share with a specific set of
users and one that's public.
So Album A has no guest permissions, Album B has viewing permissions.
Now let's say you can also comment
On Jan 16, 9:17 pm, Ivan Sagalaev wrote:
> The main point that I'm trying to argue is that having handlers and
> loggers *separate* is not needed in real world scenarios. If you want
> your logging in several files you will have to define several handlers
> and several
On Sun, Jan 17, 2010 at 5:17 AM, Ivan Sagalaev
wrote:
> Russell Keith-Magee wrote:
>>
>> That said - I really do want to see logging in Django's trunk. If we
>> can sort out the details in the background and get a good
>> implementation ready, it could easily be the
On 17 Jan., 05:36, Russell Keith-Magee wrote:
> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
>
> wrote:
> > On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com wrote:
> >> I'm not really a developer on Django itself, but I
Why wouldn't a AnonymousUser have permissions?
Basically, this is senseless.
For some photo's you might want to disable rating and/
or commenting.
How often it is required to the user? In 99% of cases it is enough
specify in an album "can" or "can not". It's really overkill of
On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee
wrote:
> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
> wrote:
>> On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com wrote:
>>> I'm not really a developer on Django
Hello Django Dev,
this is just a quick note to let you know that we're going to have a
small translation sprint here in Montréal on Monday:
http://montrealpython.org/2010/01/15/django-translation-sprint-on-2010-01-18/
http://code.djangoproject.com/wiki/Sprint201001Montreal
Best regards,
--
Russell Keith-Magee wrote:
You've also defined a production server that uses just two loggers -
exception and info - for the entire server. Again, this isn't
especially realistic - in practice, you have a large number of fine
grained loggers for different parts of the system.
In fact, most of
On Sun, Jan 17, 2010 at 9:56 PM, Waldemar Kornewald
wrote:
> On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee
> wrote:
>> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
>> wrote:
>>> On Sat, Jan 16, 2010 at 10:35 PM,
Hi all,
I'm new to the group, so my apologies if this has been discussed
already.I have some serious reservations about the implementation
of the "default" database in the new multi-db support feature.
Anytime you obtain a model from a given database (with the "using"),
shouldn't any
Thrown together a first attempt at adding multi column indexes and just want
some comments on the syntax used, for example.
from django.db import models
class Poll(models.Model):
question = models.CharField(max_length=200, db_index=True)
pub_date = models.DateTimeField('date published')
I had considered designing something like this last week. It does seem to be
a common requirement -- any situation where a simple field would be almost
suitable but for the fact you'd like to avoid duplicates and allow fast
selection of existing values. A Field shortcut could be commonly used to
Hi Harro,
Just create a special "AnonymousUser" as User with id=0, and set it up
with backend/middleware.
You'll have your permissions.
On Sun, Jan 17, 2010 at 2:45 PM, Harro wrote:
> Why wouldn't a AnonymousUser have permissions?
>
> Imagine a site where can create photo
On Mon, Jan 18, 2010 at 1:21 AM, Bill Hubauer wrote:
>
> Hi all,
>
> I'm new to the group, so my apologies if this has been discussed
> already. I have some serious reservations about the implementation
> of the "default" database in the new multi-db support feature.
>
>
On Mon, Jan 18, 2010 at 2:03 AM, Mat Clayton wrote:
> Thrown together a first attempt at adding multi column indexes and just want
> some comments on the syntax used, for example.
> from django.db import models
> class Poll(models.Model):
> question =
Hi Łukasz, Mikhail,
You can go further and create DictionaryField.
But I see the problems you will get with it:
1) You won't be able to refer to the model afterwards, since it's not
defined in models.py as global.
2) I prefer to make DictionaryModel key the primary_key when
appropriate, you'll
16 matches
Mail list logo