Re: Added support for Database Level Cascades

[Harro]

I have just one question, will this still trigger on delete signals for 
cascaded models?
That's the main reason the cascade happens in Django and not in the 
database.

On Saturday, 13 May 2023 at 16:35:01 UTC+2 Akash Sen wrote:

> *Added support for Database Level Cascades*
>
> *PR link *: https://github.com/django/django/pull/16851
>
> *Ref discussion : *
> https://groups.google.com/g/django-developers/c/Sxj7eS7-8SQ/m/jaM1rPbZEQAJ
>
> *Approach :*
> The on_delete argument for ForeignKey class now supports an extra option 
> DB_CASCADE this will behave like DO_NOTHING in Django, but leverage  the 
> Database level cascading options supported by SQL.
>
> A new optional ar gument named  on_delete_db is also passed to the 
> ForeignKey. This will specify the type of database level cascading we are 
> looking for if the on_delete is set to DB_CASCADE. Supported values of the 
> on_delete_db argument can be the following:
>
> ON_DELETE_DB_CHOICES.DO_NOTHING_DB : Does nothing, used as default value.
> ON_DELETE_DB_CHOICES.CASCADE_DB : Deletes the child on parent deletion.
> ON_DELETE_DB_CHOICES.RESTRICT_DB : Prevent the deletion if child exists.
> ON_DELETE_DB_CHOICES.SET_NULL_DB : Set the value to null in child table.
>
> This will modify the SQL query during foreignkey generation.
>
> *Checks performed :*
> 1. on_delete = DB_CASCADE and the model containing the field has a non 
> abstract parent model. As inherited the model contains a parent_ptr with 
> in-python cascading options,(OneToOneField with on_delete=models.CASCADE) 
>  both cannot be used  together.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1041
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L93
>
> 2. on_delete = DB_CASCADE and the model containing generic foreign keys or 
> generic relation. In that case we prevent using DB_CASCADE too.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1060
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L144
>
> 3. Both on_delete and on_delete_db are specified. In order to specify the 
> value of on_delete_db, on_delete must be set to DB_CASCADE.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1137
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L11
>
> 4. on_delete_db is set to SET_NULL_DB but the field is not nullable.
> *Code :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1150
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L66
>
> 5. Restricting the use of normal cascading if the foreignkey parent uses 
> DB_CASCADING as this will generate untracable integrity errors.
> *Code :*  1. 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1104
>   2. 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/django/db/models/fields/related.py#L1162
> *Related testcase :* 
> https://github.com/django/django/blob/04df10e20853c8e549deddf46fac8c289e265225/tests/db_cascade_checks/tests.py#L33
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fef26391-c9ec-49d6-9ce9-a1d4fc52b1a3n%40googlegroups.com.

Re: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

[Harro]

I assume that just localhost still works with the above change?

If so then the fact that IE edge does not support it is no reason to not change 
it because nothing changes with the current usage.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dbed920a-cedd-4e15-ab9b-1ffc6247ffe6%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Harro]

Yes, it's a complicated issue, but isn't the SQL query the ultimate 
representation of which methods are called or not?

Having the query evaluated during debugging has been shown to be harmful in 
certain situations, isn't that the most important thing to fix?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/282c78ce-bcbe-4b74-ad8a-5d49cd2662e9%40googlegroups.com.

Re: Django security releases issued: 2.2.3, 2.1.10 and 1.11.22

[Harro]

Awesome, but the tags are missing on github, could someone please push them?

On Monday, 1 July 2019 09:50:19 UTC+2, Mariusz Felisiak wrote:
>
> Today the Django team issued 2.2.3, 2.1.10, and 1.11.22 as part of our 
> security process. These releases address security issues, and we encourage 
> all users to upgrade as soon as possible:
>
> https://www.djangoproject.com/weblog/2019/jul/01/security-releases/
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/432c3cb8-8514-4191-a94a-219aa761e38f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Harro]

I'm against, there are lots of cases where a modelform is used to edit an 
exitsting object and thus the required fields are already set and you don't 
want them to be editable.

If it's a trivial patch then you should think about extending modelform in 
your own project enforce it there and then use it instead of the normal 
modelform.

I also think a good test setup/protocol will catch missing fields pretty 
quickly as you won't be able to actually create the object.

On Wednesday, 17 April 2019 02:34:12 UTC+2, Will Gordon wrote:
>
> In the same way that editable fields are forced to not be included in a 
> ModelForm (
> https://github.com/django/django/blob/master/django/forms/models.py#L146), 
> I would like to propose that "required" fields (`blank=False`) be forced to 
> be included in a ModelForm.
>
> While I understand that a developer can force this inclusion themselves, 
> but on a large project, it should not be necessary to always ensure that a 
> Model and ModelForm are in sync.
>
> Since this is probably a non-trivial patch (
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#non-trivial-patches)
>  
> I need to provide evidence that this has been discussed. As such, I'm open 
> to any and all opinions!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a51d1c72-c724-448f-b804-344cb33d176f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Harro]

The problem is that you can't just use it everywhere, like mentioned 
earlier it only works if the other side of the relation is also available 
in the admin (which might not be the case, or only for some of the fields.)

I would say add it to the good old djangosnippets 
 website. 

But that's just my 2 cents.

On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>
> If we were happy with that particular implementation, then I'd prefer 
> adding it as an official subclass thats importable for users rather than 
> just dumping the code to the docs. But I guess the issue is a slippery 
> slope - how many subclasses do we add for various ModelAdmin use cases. 
> It's definitely an issue that bites many people, and I'd like to see some 
> way forward.
>
> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>
>> Ok, sorry for the Fake News, seems like it's not so complicated to make 
>> one ModelAdmin parent class that provides this behavior. Here's a working 
>> example:
>>
>>
>> from django.contrib import admin
>>
>> from django.contrib.admin import widgets
>>
>>
>> class RawFieldModelAdmin(admin.ModelAdmin):
>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>> db = kwargs.get('using')
>> if 'widget' not in kwargs:
>> if db_field.name not in (self.get_autocomplete_fields(request
>> ), self.radio_fields):
>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field
>> .remote_field, self.admin_site, using=db)
>>
>>
>> return super().formfield_for_foreignkey(db_field, request, **
>> kwargs)
>>
>> Do you folks think we should add this to the docs? I still think that 
>> having a one-off setting for the "default foreign key" widget would be 
>> valuable, at least for me as a user.
>>
>> What do you think?
>>
>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto 
>> wrote:
>>>
>>> I think the proposed solution of "you can just extend/subclass 
>>> ModelAdmin" doesn't work, because the fields on different models can have 
>>> different names. I can't just write one global ModelAdmin and then use it 
>>> for all my models, because they'll have different names for their fields. 
>>> Or if it works, it'll need A LOT of introspection (to dynamically check 
>>> which fields are FKs and making them part of raw_id_fields).
>>>
>>> Maybe I'm wrong and I'm missing the point, do you folks have an 
>>> implementation of that ModelAdmin superclass to show?
>>>
>>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:



 On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>
> One problem with any of the alternatives (besides making it readonly 
> by default) is that it requires the other model to be registered in the 
> admin
>

 Off-hand I don't follow you here. Can you explain. 

  

> I hope there's _something_ we can do to somehow improve the situation. 
> Maybe we could at least improve the examples in the documentation? Maybe 
> give an example in the docs of a ModelAdmin subclass that defaults to 
> using 
> raw_id?
>

 An example definitely.

 Maybe we could add an attribute to ModelAdmin with a number: More than 
 this use raw_id — but what would that look like? 
 (Easy subclass rather than a setting...)

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f888916c-78b9-4a06-aa83-c880a114d034%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[Harro]

How would the raw_id_fields then work? Would that then turn them into 
selects again or would that be another setting?

If you want it in your whole project you could just extend the ModelAdmin 
and make the raw_id_fields a property that returns all the fields then use 
that as a base class for all your ModelAdmins, 
looking at the code the check if it is a foreignkey happens before that in 
all cases, so having non foreignkey fields in the list shouldn't matter.


On Wednesday, 16 January 2019 23:02:57 UTC+1, Santiago Basulto wrote:
>
> Hey folks, I was about to submit a ticket but i thought it might be better 
> to ask everybody for opinions on the matter first. I am running a couple of 
> medium (not even large) Django websites (around +20K users) and we rely on 
> the admin heavily. We have multiple models pointing to Users (or other 
> derived models) and every time we create a new model, we MUST remember to 
> include User in `raw_id_fields` for that model. If we forget to do so, the 
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include 
> in their `__str__` both the User + something else. Think about the model 
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example. 
> If you open the `Inquiry` add/change page on the admin, the whole thing 
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on 
> the admin when starting a new Django projects (specially for beginners), 
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET = 
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think? 
>
> Thanks for all the support, this community rocks 落!
>
> PS: I can create a ticket if that's a better medium of discussion, just 
> let me know?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d043e53-c8c5-4e14-a2d3-404164093625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: use SQLAlchemy Core for query generation

[Harro]

Ehhm,

version numbers aren't decimal numers. 2.0 doesn't have to wait for 1.9.

Maybe even drop python 2 for django 2.0?

Harro

On Saturday, 30 June 2012 21:25:07 UTC+2, Jacob Kaplan-Moss wrote:
>
> Wow. There's really a lot to think about here, and I'm only just 
> starting. Thanks for putting this together, Luke: I know it's been 
> something that's been discussed a ton, but until now nobody's really 
> done the due diligence to figure out exactly what the process and 
> ramifications would be. 
>
> Before we do get too deep into this, however, I want to talk about 
> this "Django 2.0" thing: 
>
> Clearly there will be something called "Django 2.0" at some point -- 
> after 1.9, if we get there, comes 2.0. However, I think it would be a 
> mistake to make "Django 2.0" backwards-incompatible. We've seen 
> countless examples -- Perl 6, Python 3, Rails 3, ... -- that these 
> sorts of "breaks from the past" really alienate and frustrate the 
> community. Over the years we've actually gotten really good at 
> balancing forward motion with stability. Our reputation as a stable, 
> reliable platform is something I'm intensely proud of. 
>
> It's going to take a lot of work to convince me of the value of a 
> "break from the past" sort of approach. If this can't be done in a way 
> that promises a smooth upgrade path... I'm not sure it's worth doing. 
>
> Now, that's not a vote against (at least not yet); I think we can find 
> balance here. I'm certainly not arguing that any backwards 
> incompatibilities sink the proposal. There's a certain level of 
> incompatibility that'll be OK, especially when the upside's so great. 
> External dependencies? If the ecosystem's ready (and it's getting 
> there), then we can adopt them without affecting most users. Changed 
> internals? We've already been pretty clear that the internals of the 
> model system is off-limits, and I think we can tolerate some changes 
> there. 
>
> So: if we're going to go down this path -- and your reasons for why we 
> should are spot-on -- I say we have to figure out if we can minimize 
> the upgrade path. 
>
> Jacob 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qlGNeeZ9x94J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Form Rendering API Proposal

[Harro]

1.Disk hits can be avoided using the django.template.loaders.cached.Loader.
We have a form rendering system that uses a lot of templates and it's being 
used in some pretty big websites, so far I haven't notices performance 
issues because of form rendering and we haven't use the cached loader as of 
yet.
Also waiting for them to build it so it can be performance tested and then 
shooting it down seems a bit harsh ;-)

2. I dunno if renaming row to field is a good idea, a row can contain 
multiple fields.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ykLdO_ppSX0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Form Rendering API Proposal

[Harro]

Two things:

- Will the as_* methods on forms be deprecated? They seem to be a nice 
shorter version then the new way to do it.

- I assume the formconfig calls are for the current context, but can I set 
them in the base.html and then automatically have them used in all templates 
extending the base.html and templates included in a template?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/cjIdpD-Fu7EJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC #12823

[Harro]

Made some comments about the bug and the patch.
The patch gives the right result, but the JOIN there is a bit weird.

On Dec 15, 7:54 pm, Philippe Raoult 
wrote:
> I have produced a patch for this [1] long-standing SQL bug.
>
> The SQL produced with the patch is correct AFAIK, but my understanding
> of the sql code is rather poor so I'm hoping that someone who knows
> better will give it a look. There might be a more correct/elegant way
> to fix this.
>
> [1]http://code.djangoproject.com/ticket/12823
>
> Best regards,
> Philippe

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

Re: Models.py not loaded at server startup ?????

[Harro]

Is this mod_python specific or does it also happen with mod_wsgi or
gunicorn?

On Dec 13, 3:47 pm, Carl Meyer  wrote:
> Hi,
>
> On Dec 12, 4:40 pm, Pakal  wrote:
>
> > Why, then, isn't it specified that all models.py files should be
> > loaded by each starting worker ? That would solve the whole problem
> > and hidden errors around startup code like signals and startup checks.
>
> This is a real issue for me as well; not necessarily that models.py
> isn't loaded at startup time, but the crucial difference in behavior
> between runserver and a live deployment in terms of when apps' models
> are imported, due to runserver performing model validation and thus
> importing all models immediately. I have more than once seen code that
> worked perfectly under runserver fail in subtle ways on real
> deployment for this reason. (In fact, the most popular Django search
> solution, haystack, is particularly susceptible to problems of this
> type, as it does some dynamic importing immediately when its models.py
> is imported).
>
> So this is certainly on my radar screen as something I'd like to look
> at in the 1.4 timeframe. I'm not sure yet what a good solution would
> look like, and I'm not entirely convinced that importing all models.py
> at startup time is the right answer. In any case, the Google Summer of
> Code work by Arthur Koziel on app-classes will impact this area, and
> is scheduled for merge in the 1.4 cycle, so I'm kind of waiting for
> that to land before looking at this closely.
>
> Carl

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

Re: Need some feedback for a fix for #14249

[Harro]

Shameless bump to get some attention for 1.3 :)

Would be really nice to have this for 1.3 as it puts us one step
closer to making the User model replacable !

I think it might be a good idea to move all the checks to the
authentication backend so it works consistently for User.has_perm,
User.has_perms and User.has_module_perms; They all leave the checking
of is_active and is_superuser to the backend.

Then the question becomes if the model backend should use the current
behaviour or should be "fixed" to always return the same expected
result:
get_all_permissions returns all permissions for superusers and no
permissions for in_active users.

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

Re: call_command retval

[Harro]

If it does not exist; create a ticket.

+1 on both points

On Dec 7, 4:13 pm, Marco Paolini  wrote:
> I think call_command should return something significant
> to let the caller know if the command was successful or not.
>
> Another issue ralated to this is: having an error retcode when calling
> management commands from
> commandline
>
> The problem now is that for instance loaddata swallows all exceptions
> and only spits them out to stderr
> without exiting sys.exit(1)
>
> that's not good if you use loaadata command from a script.
>
> Do you agree?
>
> should I submit a ticket (I could not find any on django trac)?
>
> Marco

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

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Harro]

I agree with Jacob on the bake/baked thing.. but maybe it's just
CakePHP coming to haunt me :S


On Nov 29, 1:09 pm, Ivan Sagalaev  wrote:
> On 11/29/2010 02:58 PM, Russell Keith-Magee wrote:
>
> > My counterargument would be this -- if you use TemplateResponse,
> > there's no need to use a shortcut at all.
>
> Yes, this is what I understood from your reasoning. I'm concerned more
> with documentation. Namely, what are we going to suggest for usage in
> the tutorial. The nice short `render()` shortcut lacks the power of
> TemplateResponse and TemplateResponse is not *that* nice and short.

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

Need some feedback for a fix for #14249

[Harro]

I have a patch for #14249 [1], but I ran into a problem with inactive
superusers.

Right now the active check is done before the superuser check. If we
move the inactive check to the authentication backend, the superuser
check get's executed before the is_active check, resulting in
in_active superusers having all permissions while before they had
none.

I could fix this one of two ways:

1. Add an extra check in the user class where I check for is_active
and is_superuser before returning True.
2. Move the superuser check to the backend too

The first is a quick fix that will make everything work as it should.

The second is a much more consistent option, as you can then also make
it so get_all_permissions and get_module_permissions return the right
permissions for the superuser. On the other hand, this changes the way
the system works for a superuser.

What are your thoughts?

[1] http://code.djangoproject.com/ticket/14249

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

Re: Call for review and comment: #7539 (ForeignKey on_delete)

[Harro]

_/-o_ \o/

On Nov 9, 5:59 pm, Carl Meyer  wrote:
> This is committed as r14507:http://code.djangoproject.com/changeset/14507
>
> Carl

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

Re: contrib.staticfiles app concerns

[Harro]

I agree, if you want to compress/combine css javascript whatever it's
up to the app/tool that does this to fix relative paths and other
issues that arrise when compressing/combining files.
It has nothing to do with the serving of the files.

On Oct 29, 12:04 pm, "burc...@gmail.com"  wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
>
>
>
>  wrote:
> > Hi Yuri,
>
> > On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com  
> > wrote:
> >> Hi Waldemar,
>
> >> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
> >>  wrote:
> >>> Hi Carl,
>
>  As I read it, your option 4 means putting URLs into CSS files that
>  will not resolve correctly if static files are served directly,
>  unmodified, from their source locations (after being collected from
>  apps) under STATICFILES_URL (because the URLs you give don't begin
>  with a slash, so they will be interpreted as relative to the current
>  location; and if they did begin with a slash, that would break anytime
>  STATICFILES_URL is not a path-less domain). In other words, you are
>  proposing to write CSS files that _depend_ on being run through some
>  kind of combiner/compressor/filter that will intelligently rewrite all
>  their URLs relative to STATICFILES_URL. As a proposal for a
>  "standard," this is a non-starter for several reasons:
> >> Do you agree with that "you are proposing to write CSS files that
> >> _depend_ on being run through some kind of combiner/compressor/filter
> >> that will intelligently rewrite all their URLs relative to
> >> STATICFILES_URL"?
>
> > I keep getting misunderstood, so I'll just simplify it. Forget all my
> > proposals. My primary proposal is:
> > "Let's have exactly one official standard, no matter if it's (2) or (4)."
> > What I don't want is (1), (2), and (4) living side-by-side as they do now.
>
> > Do you agree that we should have a standard?
>
> Just a standard? Or standard for some problem related to django?
>
> > If the answer is "yes", then which one should it be?
> > A: (4) for CSS and Sass/etc.
> > B: (2) for CSS, (4) for Sass/etc.
>
> >> If you do, then you understand that you're trying to impose a standard
> >> for django users that is really unnecessary for them?
> >> You're free to allow such perversion with your app, but please don't
> >> try to put this into django.
>
> >> Why can't you read css files, transform their paths to absolute, merge
> >> files, and then write paths back as relative to merged files?
>
> > That's method (2) which only works well for CSS.
>
> Django doesn't support Sass.
> Django doesn't support media compression.
> Why django should have this stupid standard?
>
> Related to your media compressor, i'd prefer not (2) or (4), i prefer
> this one I described above:
> 1. Your compressor starts after media is gathered with staticfiles
> into a single place. (All relative paths are valid at this moment!)
> 2. You read css files, transform their url paths to absolute, merge
> files, and then write back into user specified directory with paths
> rewritten as relative to merged files location.
> 3. If you're copying images, you can put images to whatever folder you
> want, but they should still work.
> Your compressor should make it possible to work after your compression
> if you'll just put that folder to media server.
>
> That way, every compressor is compatible with each other if their
> output is set to compressor-specific folder.
> This doesn't impose any standard of writing urls in their files on
> django users -- they do what they did before they have any staticfiles
> support.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com

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

Re: Ticket #7817: Extending "with" and "include" tags.

[Harro]

I would suggest also adding a way to exclude all context except items
specified with the with syntax.
(nocontext keyword or something like that).

Because sometimes I have certainly named items in my context which can
also be used in the included template but I don't want there. Sure you
can overwrite them one by one, but the faster and cleaner way would be
to exclude the whole context.


On Oct 29, 3:22 am, Russell Keith-Magee 
wrote:
> On Wed, Oct 27, 2010 at 3:46 PM, SmileyChris  wrote:
> > On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
> >> I would like to bring this up again, because this is something that
> >> would really improve readability of my templates. I'm mainly
> >> interested in ticket #7817 (the include tag changes), but extending
> >> "with" tag (ticket 9456) would keep things consistent.
>
> > Here's a link to the ticket for the lazier ones among us:
> >http://code.djangoproject.com/ticket/7817
>
> > The main decision which needs to be made is one of syntax.
>
> > The current proposal uses:
> > {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
> > but this introduces an inconsistency with the {% with %} tag.
>
> > Consistency would be nice, but I think this starts to look a bit
> > confusing, static tokens outnumbering actual functional ones:
> > {% include "name_snippet.html" with name as "Joe" and greeting as
> > "Hello" %}
>
> > My proposal is that the current {% with name as "Joe" %} format
> > becomes the legacy format, and that the new format becomes (also
> > allowing for multiple arguments):
> > {% with name="Joe" greeting="Hello" %}
>
> > Other tags which currently use the "as" token are: cycle, regroup and
> > url. These all introduce a new variable into the current context,
> > which does differ slightly from how {% with %} alters a variable in a
> > contained scope. So my secondary (perhaps somewhat feeble) argument is
> > that this actually helps to keep the "as" token's behaviour more
> > consistent. :)
>
> > Thoughts?
>
> Repeating what I said to Chris in IRC for the benefit of posterity:
>
> I don't have any strong preference either way, but whatever style we
> pick, we need to be consistent.
>
> I can certainly appreciate the clarity and terseness of the "foo=bar
> pork=ham" syntax. My only concern would be whether it is too
> "programmery" for the intended audience of the template language. We
> have existing uses of the 'x=y' syntax -- such as in the {% url %}
> tag, so I don't think this should be a major concern.
>
> As David points out, the fact that {% blocktrans %} already does 'with
> X as Y and A as B' would seem to set a precedent for the verbose
> syntax. This verbose syntax is also syntactically consistent with what
> the {% with %} tag already does, so there's no need to introduce a
> 'legacy' format.
>
> I could swing either way on this. If we were starting with a clean
> slate, I'd prefer the terse syntax, and I think Chris provides a
> reasonable argument for how the usage of 'as' can be explained
> conceptually. However, the legacy issue and the precendent set by {%
> blocktrans %} provides a compelling argument to use the more verbose
> syntax.
>
> If we can introduce the terse syntax while maintaining the old syntax
> (including the analogous change in  blocktrans), I think it would be a
> worthwhile change. However, I certainly won't complain if public
> opinion sways the other way.
>
> Yours,
> Russ Magee %-)

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

Re: Smart extends

[Harro]

I wrote an extends tag once that changed the extending template based
on a get variable..
The idea was that we could then simply get a part of the website in a
lightbox popup without all the "outer content".
I removed it afterwards and we did it properly.. it felt dirty.

On Oct 15, 3:29 pm, Luke Plant  wrote:
> On Fri, 2010-10-15 at 14:41 +0200, J. Pablo Martín Cobos wrote:
>
> > To perform something like this, we should copy all the change_list
> > template (i.e. 100 lines of code), in order to add this two changes.
>
> Have you seenhttp://code.djangoproject.com/wiki/ExtendingTemplates?
>
> Thanks,
>
> Luke
>
> --
> "I asked mom if I was a gifted child. She said they certainly
> wouldn't have paid for me." (Calvin and Hobbes)
>
> Luke Plant ||http://lukeplant.me.uk/

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

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[Harro]

Authentication = verification
Login = saving the authenticated user so we remember them.

Putting login on the user model is a bad idea.
That will only make the whole auth app less flexible than it already
is.
What if I have another model which isn't a user but is able to login.

Besides.. is_active does not mean you're not allowed to log in.. I'm
currently on a website where a user can register and do things on the
website right away and they won't be active till they have verified
their e-mail address. So the in active user can login and start using
the basic features right away.



On Sep 24, 6:58 am, Yo-Yo Ma  wrote:
> Thanks for the replies David. I didn't mean to sound brash with the
> Joel stuff. It's just that the API didn't doesn't feel right. Perhaps
> changing login to a method or User would fix both problems (explicit
> better than implicit avoids confusion) because only a User logs in. A
> User derived from authenticate() already has permission (almost) to
> log in, so why not let them do it, and raise an exception if they try
> when they're not .is_active?
>
> user = authenticated('mike', 'openSesame')
> user.login(request)
>
> This prevents the problem from arising, without having to define a
> __gettattr__ on User for some edge case. It also cleans up the smell.
> I assume something like this could be changed in 1.4, no?
>
> On Sep 23, 5:43 pm, "David P. Novakovic" 
> wrote:
>
>
>
> > To take something constructive from this.. perhaps backend could be a
> > property that raises a more meaningful exception when it is called the
> > wrong way?
>
> > I'm not particularly for or against the idea.. but I know raising more
> > meaningful exceptions is an issue that has received some attention
> > previously.
>
> > Thoughts anyone?
>
> > On Fri, Sep 24, 2010 at 9:32 AM, David P. Novakovic
>
> >  wrote:
> > > Apart from being slightly offended at you posting a Joel Spolski link
> > > to make a point, I'll address the actual issue at hand :P
>
> > > These docs pretty clearly show authenticate happening before login.
> > > Both in examples and the actual docs.
>
> > >http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in
>
> > > Notice in particular:
>
> > > """
> > > Calling authenticate() first
>
> > > When you're manually logging a user in, you must call authenticate()
> > > before you call login(). authenticate() sets an attribute on the User
> > > noting which authentication backend successfully authenticated that
> > > user (see the backends documentation for details), and this
> > > information is needed later during the login process.
> > > """
>
> > > The only time I could see this being a documentation issue is when
> > > someone is implementing their own authenticate function but this
> > > breaks the django convention if simply implementing a backend and
> > > adding it to the list of auth backends and letting authenticate()
> > > provide the actual authentication.
>
> > > So yep, unfortunately this is an issue for django-users.
>
> > > David
>
> > > On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma  
> > > wrote:
> > >> It is a problem with Django. I thought it was a problem with the code
> > >> but it isn't. It's a problem with the documentation, or worse. An
> > >> function of an API that requires running of another function to alter
> > >> an object behind the scenes is an architectural problem that needs
> > >> fixing. Seehttp://www.joelonsoftware.com/articles/LeakyAbstractions.html
> > >> - and furthermore, if the choice is made to leave problems like this
> > >> unfixed, they should be documented as so. The current documentation
> > >> here says, "It takes an HttpRequest object and a User object.". This
> > >> isn't true, as as simple User object will not suffice. It should say,
> > >> "It takes an HttpRequest object and a User object that has been run
> > >> through the function authenticate() first to alter the auth backends
> > >> that are attached as attributes to it.".
>
> > >> This has very bad code smell, IMHO.
>
> > >> On Sep 23, 3:47 pm, "David P. Novakovic" 
> > >> wrote:
> > >>> This probably should have been posted to django-users anyway.
>
> > >>> Chances are, getting a stacktrace like this one or the last error you
> > >>> posted are actually problems with your code and not django itself.
>
> > >>> Unless you can show that it is actually a problem with django and not
> > >>> the way you are using it, it'd be better addressed on django-users
> > >>> first.
>
> > >>> David
>
> > >>> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss  
> > >>> wrote:
> > >>> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma  
> > >>> > wrote:
> > >>> >> Hey Jacob, understood. Here's some more details that might help:
> > >>> > [snip]
> > >>> >>                if user.check_password(request.POST.get('password',
> 

Re: Imports in the tutorial

[Harro]

I agree, and while we're at it also change the settings.py template to
just point to urls instead of project_name.urls


On Jun 10, 7:21 pm, Andrew Godwin  wrote:
> Hi all,
>
> I noticed today that the tutorial still does imports like "from
> mysite.polls.models import Poll", and URLs like "(r'^polls/$',
> 'mysite.polls.views.index')".
>
> At least in the places and projects I've worked with, the standard has
> been not to use the project name as part of the import, for various reasons:
>
>   - It makes apps more reuseable and not tied to the one project
>   - It means you can't run two copies of the same application if they're
> direct neighbours (as, to get the imports running, you need to add the
> directory the project is contained in to the Python path, and thus you
> can't rename the directory from its import name).
>
> I realise both of these can be worked around (and I do a lot), but it
> would seem common sense to start encouraging people to do imports like
> "from polls.models import Poll" from day one. There might well be
> something I'm missing - please say - but this has bugged me for ages.
>
> (The previous threads I can find on this topic seems to end pretty
> inconclusively, and were in 2007 and 2009, so I feel partially justified
> in bringing this up again.)
>
> I'm happy to write a patch for the docs to change it to match should
> people agree - I just feel like I'm missing something here, as it's not
> been done yet.
>
> Andrew

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

Re: Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Harro]

Also ON DELETE RESTRICT

On Jun 10, 8:53 am, Thomas Guettler  wrote:
> The documentation says django emulates "ON DELETE CASCADE":
>    http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
>
> But it is missing how to emulate ON DELETE SET NULL.
>
> In this thread Kevin Howerton posted an abstract base class to emulate ON
> DELETE SET NULL. But this does not work if you bulk delete with a query set.
>
> I opened a new ticket:
>
> http://code.djangoproject.com/ticket/13731
>
>   Thomas
>
>
>
>
>
> Russell Keith-Magee wrote:
> > On Wed, Jun 9, 2010 at 3:53 AM, Peter Bengtsson  wrote:
> >> On 8 June 2010 13:09, Jeremy Dunck  wrote:
> >>> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson  wrote:
>  I've now had to learn this the hard way by having real live data
>  deleted from my database on two production projects and it pisses me
>  off big time every time.
>
>  I can accept that NOT nullable foreign relations cascade the delete
>  but not if they have null=True on them. Example:
> >>> Actually, this looks to be fixed in 1.2.  What version are you
> >>> running?  Closed ticket (with test cases) here:
> >>>http://code.djangoproject.com/ticket/9308
>
> >> I'm running Django 1.2.1 so perhaps it's not fixed.
> >> Sigh. I have to make a test case to prove it.
>
> > Looking at Trac, #9308 was fixed in r10822, so it should be fixed in
> > 1.1, and it was ported back to 1.0.X as well.
>
> > We pretty clearly document that our deletion scheme emulates "ON
> > DELETE CASCADE"; if you can provide evidence to the contrary, please
> > open a ticket.
>
> > Yours,
> > Russ Magee %-)
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de

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

Re: Decision required: PostgreSQL minimum versions

[Harro]

+1 on option 3.

Oldest postgresql we have is 8.2.
I pity the fool who didn't upgrade !


On Jun 9, 2:38 pm, Antoni Aloy  wrote:
> +1 on Drop 7.4 PostgreSQL support. Postgressql 8.x series has lots of
> performance and utility features and it would be a pity to remain in
> 7.4.
>
> --
> Antoni Aloy López
> Blog:http://trespams.com
> Site:http://apsl.net

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

Re: Proposal: Replace django.contrib.formtools.wizard

[Harro]

+1 on the storage backend. Can the current filestorage backend be
reused for this?


On May 31, 10:44 am, Gert Van Gool  wrote:
> MEDIA_ROOT isn't a good solution. It should use a StorageBackend.
> For instance, when you use a load-balancer there is no guarantee that
> your session hits the same server twice.
>
> -- Gert
>
> Mobile: +32 498725202
> Web:http://gert.selentic.net
>
>
>
> On Mon, May 31, 2010 at 10:36, Gregor Müllegger  wrote:
> > Storing the file in a temporary directory is elegant but brings up
> > some new problems.
>
> > IMO it's critical - if you want to support file uploads - to put these
> > files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
> > of uploaded images etc.
>
> > 2010/5/30 TiNo :
> >> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>
> >>> I already discussed this ticket with Jannis during the sprints and hope to
> >>> start a discussion here to find the right way to allow file uploads and 
> >>> see
> >>> if my approach takes the right direction.
>
> >> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
> >> file will get cleaned by the filesystem itself, unless you move it 
> >> somewhere
> >> else in your ``done`` method. If you pass delete=False, you will be able to
> >> open the file again in the last step, as long as you properly closed it
> >> before.
> >> TiNo
> >> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Django developers" group.
> >> To post to this group, send email to django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Proposal: Replace django.contrib.formtools.wizard

[Harro]

We had a site where we needed a wizard with the ability to go back and
forward and store files.
Only allowing files in the last step really isn't an option imho, that
just avoiding the problem ;-)

What we did was simply store the files in a temporary folder and have
a management command to clean them up when needed. (The files where
stores with a timestamp in the name so we knew when they where old).

I'm for having a better form wizard in django. +1



On May 30, 11:15 am, Jacob Kaplan-Moss  wrote:
> Hey Steph --
>
> I've had a chance to play with your code, and I'm impressed and
> generally +1 on replacing formwizard with yours.
>
> I couldn't tell from my quick play, though, if there were any
> backwards-incompatible changes. There's a fair bit of code churn (in a
> good way :), so before we could merge this I'd like a sense of what
> any backwards-compatibily concerns would be.
>
> Thanks!
>
> Jacob

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

Re: djangocon.eu sprints (was Re: Class based generic views in 1.3?)

[Harro]

Ah crap.. now you've done it.. now I want to be at the djangocon.eu
sprints too..
Why do all the fun things always happen at the same time..
I guess I could stay the thursday. and then go home on friday.

Ah well.. I'll have till monday to think about it.

On May 14, 4:27 pm, Jeremy Dunck  wrote:
> On Fri, May 14, 2010 at 9:12 AM, Reinout van Rees  wrote:
> ...
>
> > I'm used to Plone sprints and there's usually some "make sure you have svn
> > access to x and y" stuff best handled *before* the sprint, that's why I'm
> > asking :-)
>
> This might help:http://code.djangoproject.com/wiki/Sprints
>
> If you have questions after that, let me know -- I'd be happy to
> improve that page.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Advice on #13260 - '%' in args to urlresolvers.reverse()

[Harro]

The thing is, quoted get variables will get unquoted, quoted url
parameters won't be unquoted automatically. That's up to the developer
to handle.

Ran into the same issue today, and for me it made sense to do the
quoting before passing it to the reverse function, but for me it was
an URL which was passed to another url which clearly needs escaping
(apache doesn't like double / by default :D)

I can however see how you might not know the input and thus forget to
quote it. The example above is a very good one for that.
You can't just start escaping everything without breaking code in
unexpected ways.


On Apr 22, 4:53 pm, Thomas Guettler  wrote:
>  reverse('special', args=[r'+\$*'])
> > '/special_chars/+%5C$*/'
>
> > It would have to output:
>
> > '/special_chars/%2B%5C%24%2A/'
>
> Hi,
>
> I think the current test case is broken. All args/kwargs should
> be quoted.
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: logialogin_required does not check User.is_active

[Harro]

I think the problem isn't the login_required, but it simply does what
it says it does: Check if the user is logged in.

For me a user with is_active set to false shouldn't be allowed to
login, they either just created an account and still need to verify it
or they indicated that they wanted their account "removed", in which
case it's marked inactive so it doesn't cascade delete all their
related items too.

As the login view and the authentication middleware both use the
backend to get the user, this is is the place to implement the check
or not.

Which isn't that hard, the quick fix is to simply point out that the
is_active doesn't check this and if people want this they should
simply extend the ModelBackend's authenticate and get_user functions
and add the checks there.




On Apr 15, 5:20 pm, "subs...@gmail.com"  wrote:
> Thanks for breaking it down.
>
> On Mar 17, 7:45 am, Russell Keith-Magee 
> wrote:
>
> >  1) Don't touch the code. It's an annoying edge case, but it can be
> > caught by shortening session timeouts and making more use of
> > permissions. However, we should document the edge case with
> > login_required, as it is certainly contrary to obvious usage.
>
> This isn't appropriate in situations where HR wants to do a hard cut-
> off of a user's access, in the event they are terminated.
>
> >  2) Add a specific "requires_active_user" decorator (and maybe a
> > decorator that combines the login_required and requires_active_user
> > check)
>
> Eh.
>
> >  3) Allow login_required to take an argument that customizes the
> > 'active' check. However, the default value for this argument would
> > need to be equivalent to the current behaviour; once you start down
> > this path, there really isn't much difference between a call to
> > login_required with an 'is_active' argument, and a call to
> > user_passes_test that does the authentication and active check.
>
> Seems strange: "I want a user to be authenticated to use this view,
> but I don't care if they're active." I'm not sure I agree that the
> default should be the current behavior. I think in most cases this is
> an oversight that most programmers simply don't account for in their
> code--and closing this hatch is a favor and not an incompatibility
> issue. Could be wrong.
>
> >  4) Work out if there is a way to refactor the login process so that
> > the decision of whether is_active is checked is deferred. I don't have
> > any great ideas how this could be done, though.
>
> Would it be too ugly or simplistic to have a callable
> Backend.is_active() which these backends could manipulate to their
> liking? Its flexible in the same way as get_profile(). Also, is it
> possible we're expecting too much perfection given that, as you say,
> there are legitimate proposals to refactor auth.User either way? (and
> present solutions are more or less trivial).
>
> -Steve

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

Re: Model validation outside of ModelForms.

[Harro]

Just my brainfart when looking at this: Can't you simply add a pre
save signal to call the full clean method?

Dunno if that will work or not, just the first thing I would try.


On Mar 16, 5:12 pm, James Bennett  wrote:
> On Tue, Mar 16, 2010 at 10:36 AM, orokusaki  wrote:
> > It doesn't seem that the core team is interested in working on Model
> > validation at the moment:http://code.djangoproject.com/ticket/13121
> > (my failed ticket)
>
> Stop right there and actually go back and *read* all the feedback
> you've gotten, because right now you're just flat-out lying. Russell
> has, on multiple occasions, asked you, begged you, and pleaded with
> you to get proper discussion going on the things you've proposed.
> You've refused and instead adopted a method of opening duplicate
> tickets and screwing around with the metadata on existing ones,
> apparently out of a desire to annoy as many people as possible rather
> than get anything useful done.
>
> If you'll actually pay attention to what others say and actually put
> in the time to learn how the Django development process works, you may
> be a lot happier with the results. If instead you just continue what
> you've been doing, well, I for one will be happy to direct you to some
> other framework that's willing to put up with such antics.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Small "bug" in inline_formsetfactory

[Harro]

See ticket: http://code.djangoproject.com/ticket/13095


Just posting the used code here:


# models.py

class Choice(models.Model):
"""
A choice in a poll
"""

poll = models.ForeignKey(Poll, related_name='choices',
verbose_name=_('Poll'))
choice = models.CharField(_('Choice'), max_length=100)
position = models.PositiveIntegerField(_('Position'), default=0)

class Meta:
verbose_name, verbose_name_plural = _('Choice'), _('Choices')
ordering = ('position',)
order_with_respect_to = 'poll'

def __unicode__(self):
return u"%s -%s " % (self.poll.title, self.choice)

# forms.py
class ChoiceForm(forms.ModelForm):
"""
For to create/edit choices
"""
class Meta:
model = Choice
widgets = {
'position': forms.HiddenInput(),
}

ChoiceFormSet = inlineformset_factory(Poll, Choice, form=ChoiceForm)


Btw.. debugging lamba functions can be tricky :)

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

Re: contrib.Auth

[Harro]

Good suggestions, I think removing username and email from the user
might be a good idea.
Right now I authenticate with the email address stored on the profile
and the username is a random hash :)

As for breaking data and migrations; it shouldn't be that hard to
write a management command that does this.


On Feb 9, 5:54 pm, Vitaly Babiy <vbabi...@gmail.com> wrote:
> Vitaly Babiy
>
> On Tue, Feb 9, 2010 at 3:16 AM, James Bennett <ubernost...@gmail.com> wrote:
> > On Tue, Feb 9, 2010 at 2:09 AM, Harro <hvdkl...@gmail.com> wrote:
> > > - Make email unique and username non-required on the model. That would
> > > make implementing something that authenticated by email a lot
> > > easier :)
>
> > 1. It's *extremely* unlikely that changes will be considered which
> > require every Django install on the planet to undergo a DB schema
> > migration.
>
> James this is true. Another reason it would be nice to have a
> migration framework for Django.
>
>
>
>
>
> > 2. The appropriate time to discuss possible 1.3 features is when the
> > feature-discussion window for 1.3 comes up. That will happen sometime
> > in April, probably. Suggestions made now are likely to be forgotten by
> > the time that happens.
>
> > Yeah I plan to bring this up again, around that time frame.
>
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of
> > correct."
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2Bunsubscr 
> > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.

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

Re: contrib.Auth

[Harro]

- Make email unique and username non-required on the model. That would
make implementing something that authenticated by email a lot
easier :)

On Feb 9, 1:34 am, Russell Keith-Magee  wrote:
> On Tue, Feb 9, 2010 at 8:15 AM, Justin Lilly  wrote:
> > To add another point, this doesn't mean that the day 1.2 hits release that
> > everyone is gung-ho on 1.3. If past releases are any indication, there is
> > usually a refactory period of a few weeks when everyone is basking in
> > post-release bliss.
>
> I believe the post-release period is typically referred to as "sobering up" 
> :-)
>
> To address Vitaly's original point - contrib.auth is on my list of
> things I want to address in 1.3.
>
> Yours,
> Russ Magee %-)

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

Re: 1.2 Beta tomorrow (Friday)

[Harro]

Hope you feel better today :)

On Feb 5, 3:35 am, James Bennett  wrote:
> Due to a combination of exhaustion and illness on the part of the
> release manager (me), I'm going to slide the 1.2 beta release one day;
> that means beta tomorrow (Friday, February 5, probably evening-ish US
> Central time). If anyone's got last-minute commits, get 'em in.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Re: 1.2 beta?

[Harro]

I would also like to point out: http://code.djangoproject.com/ticket/12600

It does break existing code however, because it will look for the
preview template somewhere else.

On Jan 28, 2:25 am, Ben Firshman  wrote:
> On 27 Jan 2010, at 22:50, Ben Firshman wrote:
>
>
>
> > On 27 Jan 2010, at 15:36, Russell Keith-Magee wrote:
>
> >> However, my initial impression: one way to dramatically increase your
> >> chances is to make sure the patch applies to trunk, and passes all the
> >> tests. Neither of these things are true at present. Using the most
> >> recent patch on the ticket, I currently get 4 patch failures. Once I
> >> fix those the way I suspect they are meant to be fixed, I get a failed
> >> test case (SyndicationFeedTest.test_add_domain).
>
> > Oh gosh, sorry, I thought I fixed all those problems. I'll get it fixed 
> > against trunk this evening.
>
> http://code.djangoproject.com/ticket/12403
>
> I've added syndication-view-6.diff which should apply cleanly against r12313, 
> fixes that test and has a few documentation tweaks. You can see a working 
> pretty diff on github:
>
> http://github.com/bfirsh/django/commit/1fac8441b49f690094026fb06189d4...
>
> Ben

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

Re: Any change this could make it in for 1.2?

[Harro]

+1

Sick of explaining to dutch customers that I can't translate those
texts in the admin.

It's a simple patch which doesn't break backwards compatibility at
all.

On Jan 27, 3:54 pm, Alex Robbins 
wrote:
> This ticket adds label and verbose_name to apps. I know this would be
> very useful for lots of people.http://code.djangoproject.com/ticket/3591
>
> Is it too late for it to make it into 1.2? What can we do to make sure
> it makes it in for 1.3?
>
> Thanks,
> Alex

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

Added a patch to the ticket.

some documentation should also be added.

[1] 
http://code.djangoproject.com/attachment/ticket/12557/supports_anonymous_users.diff
[2] http://code.djangoproject.com/attachment/ticket/12557

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I think the `supports_anonymous_users` thing is the best and most
simple solution.

The anonymous user should then only call has_perm/has_module_perms on
backends that have that set.

I would then write a simple decorator which checks the backends for
that flag to determine if we should do a login_required or has_perm
check.
Because a real pluggable app would want to support both :)



On Jan 26, 4:01 pm, Florian Apolloner <f.apollo...@gmail.com> wrote:
> On Jan 26, 3:19 pm, Harro <hvdkl...@gmail.com> wrote:> - If the default 
> backend always returns false for anonymous users then
> > pluggable apps have to either expect some row level permission system
> > is installed and used or don't check permissions for things that an
> > anonymous user can access.
>
> Why do they have to expect a row level permission system to be
> installed? The ModelBackend would always return False for anonymous,
> so everything would stay as it is…
>
> > I think the best solution is to add anonymous user permissions as
> > proposed by me a bit up, but only actually check them if a settings
> > flag is set to True (with a default on False). If it's not set it will
> > simply return False for anonymous users, otherwise it will check the
> > permissions.
>
> I am -1 on that, using `supports_anonymous_users` is way better and
> allows a cleaner upgrade path (as every backend will have to support
> anonymous users sooner or later)

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I think so far we agree that we need to add something for anonymous
users, because the added enhancement currently doesn't add enough to
integrate row level permissions as they should be.
The problems are:

- Anonymous users should check the authentication backend for
permissions, so it is possible to implement anonymous user permissions
- If the default backend always returns false for anonymous users then
pluggable apps have to either expect some row level permission system
is installed and used or don't check permissions for things that an
anonymous user can access.


I think the best solution is to add anonymous user permissions as
proposed by me a bit up, but only actually check them if a settings
flag is set to True (with a default on False). If it's not set it will
simply return False for anonymous users, otherwise it will check the
permissions.

That way pluggable apps decide for themselves if they want to check
permissions for all users and if they do throw an error if the flag is
not set. Or if they simply do it the old way by doing a login_required
for the views that need logged in users.



On Jan 26, 1:12 pm, Jari Pennanen  wrote:
> I read from "1.2 beta" thread that this might make it to the 1.2 beta
> of Django, any status on that? Is someone trying to commit the patches?

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I just thought of another way this might be possible: signals.

Just add them to the anonymous user functions.
The signal would get passed a variable holding the currently returned
result, and then returns it.
That way you can hook into it and modify the result without breaking
the current behaviour.


On Jan 20, 8:49 am, Harro <hvdkl...@gmail.com> wrote:
> class User(models.Model):
>     permissions = models.ManyToMany('Permission',
> through='UserPermission')
>
> class UserPermission(models.Model):
>      user = models.ForeignKey('User', blank=True, null=True)
>      permission = models.ForeignKey('Permission')
>
> class AnonymousUser(models.Model)
>
>     @property
>     def permissions(self):
>        return UserPermission.objects.filter(user__isnull=True)
>
> On Jan 19, 10:12 pm, Luke Plant <l.plant...@cantab.net> wrote:
>
> > On Tuesday 19 January 2010 16:23:32 Harro wrote:
>
> > > And I guess making it truely awesome would require permissions for
> > > anonymoususers in the default backend too. :(
>
> > > If I have timeI'll see what I can come up with.
>
> > Ticket #9444 [1] is about that, and it had a lot of opposition.
>
> > It is hard or very hacky for the provided auth backend to support
> > object-level permissions for anonymous users, because there is no
> > obvious place to store permissions.  But making it *possible* for
> > custom auth backends to do this is a different matter, and is all we
> > should be aiming for I think.
>
> > Now for some out-loud thinking about the consequences of this patch:
>
> > Once you make it possible, it is likely that the authors of re-usable
> > apps will want to depend on this capability.  That means that writing
> > custom auth backends would now be much more common. The auth backend
> > already covers both authorization and authentication, but if the
> > authors of re-usable apps are encouraged to depend on it to handle
> > authorization even for anonymous users, then it will be much more
> > commonly required.
>
> > I don't see this as necessarily a problem, it's just a shift in
> > direction.  The more I think about it, the more it seems that
> > authorization questions really need to be decided on a per-site basis,
> > and this mechanism is a good place to do it. (Some people object to
> > mixing authorization and authentication, but it's a bit too late to
> > fix that, and in practice full decoupling is tricky and overly-
> > complex).
>
> > I've thought through some other scenarios, such as having multiple
> > types of login (on one site I use 'User' in the normal way for people
> > with access to the admin, and a completely separate 'Member' model for
> > completely different type of access), and I can see ways for all of
> > these to work, although you might have to supply a custom
> > AuthenticationMiddleware, and your own User objects which have the
> > same interface as the supplied one.
>
> > The other consequence of app authors depending on this is that apps
> > might become more restrictive by default, and harder to "open up".  
> > Whereas before you would allow an anonymous user to, say, write a
> > comment, or had a single setting to control it, now you will just
> > delegate to the auth backend, which by default has no permissions for
> > anonymous users.  Again, I don't see this as particularly bad - the
> > amount of spam these days means it's probably helpful to have things
> > locked down by default.
>
> > Regards,
>
> > Luke
>
> > [1]http://code.djangoproject.com/ticket/9444
>
> > --
> > "Pretension: The downside of being better than everyone else is
> > that people tend to assume you're pretentious." (despair.com)
>
> > Luke Plant ||http://lukeplant.me.uk/

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

oh also: It's kinda like the messages framework rewrite now supporting
messages for anonymous users.

And I guess making it truely awesome would require permissions for
anonymoususers in the default backend too. :(

If I have timeI'll see what I can come up with.

On Jan 19, 4:34 pm, Jannis Leidel  wrote:
> Am 19.01.2010 um 16:10 schrieb Luke Plant:
>
>
>
>
>
> > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote:
>
> >>> I think the best argument in favor of it is using permissions
> >>> with reusable applications.  Say I have a wiki application I
> >>> write, I don't know whether anonymous users should be able to
> >>> edit pages, I could make it a setting, but that's ugly.  Instead
> >>> the natural thing to do is ask the auth backend and let the
> >>> developer implement it however.
>
> >> So you would implement an authentication backend specifically for
> >> your wiki app to be able to check if anonymous users have the
> >> permission to edit a page? How is that less ugly than a setting?
>
> > In that simple case, a setting might be easier, but it is ugly in the
> > sense of poor separation of concerns.  And it is much less flexible -
> > what if the setting might depend on which page they are editing?  Very
> > quickly you will end up with the wiki app needing it's own permission
> > system.  The writer of the wiki app can avoid the whole question by
> > always delegating authorisation questions to the standard mechanism.
>
> > I understand your concern about the auth backend assuming 'User', not
> > 'AnonymousUser', but we have specifically documented AnonymousUser as
> > implementing the same interface as User, and I cannot see what harm it
> > would cause to allow this.
>
> That's a good point, and I have to admit I begin to realize that the real 
> culprit for me is not the backend implementation but rather the special 
> status of the AnonymousUser. We have to jump through quite a few hoops to 
> make that possible.
>
> Jannis
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

@Janis: I see your point,in my proposal the default model
authentication backend always returns False for the AnonymousUser.
That would indeed mean guest users have no access at all.
But I guess you could write a wrapper that used a function specified
in the settings (with a default pointing to a function in your app)
that takes some arguments and based on that sees if the user is
anonymous or not and then does or doesn't check the has_perm function.

On Jan 19, 4:34 pm, Jannis Leidel  wrote:
> Am 19.01.2010 um 16:10 schrieb Luke Plant:
>
>
>
>
>
> > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote:
>
> >>> I think the best argument in favor of it is using permissions
> >>> with reusable applications.  Say I have a wiki application I
> >>> write, I don't know whether anonymous users should be able to
> >>> edit pages, I could make it a setting, but that's ugly.  Instead
> >>> the natural thing to do is ask the auth backend and let the
> >>> developer implement it however.
>
> >> So you would implement an authentication backend specifically for
> >> your wiki app to be able to check if anonymous users have the
> >> permission to edit a page? How is that less ugly than a setting?
>
> > In that simple case, a setting might be easier, but it is ugly in the
> > sense of poor separation of concerns.  And it is much less flexible -
> > what if the setting might depend on which page they are editing?  Very
> > quickly you will end up with the wiki app needing it's own permission
> > system.  The writer of the wiki app can avoid the whole question by
> > always delegating authorisation questions to the standard mechanism.
>
> > I understand your concern about the auth backend assuming 'User', not
> > 'AnonymousUser', but we have specifically documented AnonymousUser as
> > implementing the same interface as User, and I cannot see what harm it
> > would cause to allow this.
>
> That's a good point, and I have to admit I begin to realize that the real 
> culprit for me is not the backend implementation but rather the special 
> status of the AnonymousUser. We have to jump through quite a few hoops to 
> make that possible.
>
> Jannis
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

@Luke: A simple is_active check with return False will also do so for
the AnonymousUser.

@Łukasz:That's up to the developer of the backend I think. But with
that you could disallow logged in users from going to the registration
page for instance. (I know not a great example, but just to show the
point)

@Alex: Thanks for providing the example of reusable applications,
that's is the best example of why we need this.


On Jan 19, 8:23 am, Gert Van Gool <gertvang...@gmail.com> wrote:
> @Noah, You could also look at it as what a AnonymousUser can't do on
> some objects (while it's possible on others).
>
> -- Gert
>
> Mobile: +32 498725202
> Web:http://gert.selentic.net
>
> 2010/1/19 Noah Silas <n...@mahalo.com>:
>
>
>
> > I'm not certain I understand - if anyone can perform some action, what's the
> > point of protecting it with a permissions check?
> > ~Noah Silas
>
> > 2010/1/18 Łukasz Rekucki <lreku...@gmail.com>
>
> >> 2010/1/18 Alex Gaynor <alex.gay...@gmail.com>:
> >> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel <jan...@leidel.info>
> >> > wrote:
>
> >> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>
> >> >>> Hi Harro,
>
> >> >>>> Hmm I guess I'll just have to keep on hacking django then..
> >> >>>> because that 1% case is something I keep running into for every
> >> >>>> project in one way or another.
> >> >>>> And if it was designed for most apps, why was the row level
> >> >>>> permission bits added? It's useless without simply always being
> >> >>>> able to call request.user.has_perm('permission', obj)
>
> >> >>> Despite a slight overstatement in that last paragraph, your argument
> >> >>> seems pretty good to me.  The whole point of these methods is to allow
> >> >>> custom backends to implement their own logic, so obviously it is
> >> >>> pointless to arbitrarily limit it.
>
> >> >>> The only downside is that custom backends need to be able to cope with
> >> >>> anonymous users being passed to the has_perm methods, but that is
> >> >>> already well catered for with the is_anonymous() method.  It is also
> >> >>> better to make this change before 1.2 lands, otherwise we have a
> >> >>> slight backwards incompatibility if we wanted to do it in the future
> >> >>> (backends could break if they unexpectedly got an AnonymousUser
> >> >>> instead of a User).
>
> >> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
> >> >>> committing.
>
> >> >> Hm, I don't see a good argument to allow anonymous users to have a
> >> >> permissions, to be honest. Anonymous users are by definition not
> >> >> authenticated. Giving them more meaning by being able to grant them
> >> >> permissions doesn't make them anonymous anymore, right?
>
> >> >> Also, before adding those hooks to the ModelBackend, AnonymousUser
> >> >> never returned True when asked if it has a permission or not. Why 
> >> >> should it
> >> >> now?
>
> >> >> Jannis
>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> Groups "Django developers" group.
> >> >> To post to this group, send email to
> >> >> django-develop...@googlegroups.com.
> >> >> To unsubscribe from this group, send email to
> >> >> django-developers+unsubscr...@googlegroups.com.
> >> >> For more options, visit this group at
> >> >>http://groups.google.com/group/django-developers?hl=en.
>
> >> > I think the best argument in favor of it is using permissions with
> >> > reusable applications.  Say I have a wiki application I write, I don't
> >> > know whether anonymous users should be able to edit pages, I could
> >> > make it a setting, but that's ugly.  Instead the natural thing to do
> >> > is ask the auth backend and let the developer implement it however.
>
> >> This argument convinced me to like this idea :) My only concern is
> >> that, a newly created user could have fewer permissions then an
> >> anonymous one. I can't think of a situation where this would be
> >> useful. So maybe all other users could actually inherit those
> >> "anonymous permissions" ?
>
> >

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

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 and rate a photo. Which are two
separate things. For some photo's you might want to disable rating and/
or commenting.
Now you could go an add can_comment, can_rate booleans on the photo,
but thats not needed with row level permissions.

I really don't care how or where to store the permissions for
AnonymousUsers, that's up to the person implementing a backend for it,
I do care however about that fact that the current implementation is
limiting the system.



On Jan 15, 5:27 pm, Anton Bessonov  wrote:
> No. You need row based permissions if You will limit User(!) rights. For
> example user can edit entries with FK 2. 
> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions
>
> But AnonymousUser (Guest) don't have any permissions. It's a special and
> that the guest can - it's not a permission - it's a setting.
>
> Gert Van Gool schrieb:
>
>
>
> > Isn't the idea of row based permission that you don't need a special
> > model for that?
>
> > -- Gert
>
> > Mobile: +32 498725202
> > Web:http://gert.selentic.net
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

Because the authentication backend now allows for role based
permissions you might have a blog post which anonymous users are
allowed to comment on (create_comment) and another they can't.

Now you would have to have a guest_can_comment flag or something on
the blog post and check that before displaying the form.
Instead I want to use the permission system to see if the anonymous
user has create_comment permission on that specific blog item.

so that's why I think this would be a good addition.

It would also allow for temporary shutting down of certain publicly
accessible items by simply removing/disabling the permissions for
guest users.



On Jan 14, 3:17 pm, Juan Pablo Scaletti <juanpablo.scale...@gmail.com>
wrote:
> If an AnonymousUser can do something then everybody can do that as well.
> So why a regular unprotected view can't do the job?
>
>
>
>
>
> On Thu, Jan 14, 2010 at 8:13 AM, Harro <hvdkl...@gmail.com> wrote:
> > I was having a look at the new 1.2 row level permission support that
> > got added and ran into the problem that the AnonymousUser does not
> > call the authentication backend functions.
>
> > The default backend doesn't need this, but with a custom backend I
> > might want to implement Guest permissions.
>
> > I think it will make the permission system even more powerful !
>
> > What do you guys think?
>
> > Ticket:http://code.djangoproject.com/ticket/12557
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2Bunsubscr 
> > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
>
> Juan Pablo Scaletti
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: M2M Column Names Changed in 1.2 - Breaks Backwards Compatibility

[Harro]

Hmm where did the foreign key go on the 1.2 example?

And I must say that the name for the modelc column is a bit weird.


On Jan 14, 8:13 am, simonb  wrote:
> I think this tickethttp://code.djangoproject.com/ticket/12386
> identifies a change in the m2m code which breaks backwards
> compatibility.
>
> Consider the following three apps and models:
>
> AppA/models.py:
>
> class ModelA(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>
> AppB/models.py:
>
> class ModelB(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>     ma = models.ManyToManyField('AppA.ModelA', blank=True, null=True,
> related_name='mb')
>     mc = models.ManyToManyField('AppC.ModelC', blank=True, null=True,
> related_name='mc')
>
> AppC/models.py:
>
> class ModelC(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>
> The SQL generated for the m2m fields in AppB is different for Django
> 1.1 and 1.2/trunk. This breaks backwards compatibility.
>
> It seems that in some cases 1.2 names the m2m column 'app.model_id'
> whereas 1.1 uses 'model_id' only - i.e. no 'app.'
>
> This only seems to happen when there are more that one m2m fields in a
> model. Tested with postgresql. The SQL output for the M2M table is
> show below for the different Django versions.
>
> Django 1.1
>
> CREATE TABLE "AppB_modelb_mc" (
>     "id" serial NOT NULL PRIMARY KEY,
>     "modelb_id" integer NOT NULL REFERENCES "AppB_modelb" ("id")
> DEFERRABLE INITIALLY DEFERRED,
>     "modelc_id" integer NOT NULL REFERENCES "AppC_modelc" ("id")
> DEFERRABLE INITIALLY DEFERRED,
>     UNIQUE ("modelb_id", "modelc_id")
> );
>
> Django 1.2
>
> CREATE TABLE "AppB_modelb_mc" (
>     "id" serial NOT NULL PRIMARY KEY,
>     "modelb_id" integer NOT NULL,
>     "appc.modelc_id" integer NOT NULL,
>     UNIQUE ("modelb_id", "appc.modelc_id")
> );
>
> 1.1 = "modelc_id"
> 1.2 = "appc.modelc_id"
>
> I've uploaded a little test project to the ticket which demonstrates.
>
> Simon
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I was having a look at the new 1.2 row level permission support that
got added and ran into the problem that the AnonymousUser does not
call the authentication backend functions.

The default backend doesn't need this, but with a custom backend I
might want to implement Guest permissions.

I think it will make the permission system even more powerful !

What do you guys think?


Ticket: http://code.djangoproject.com/ticket/12557
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: phone2numeric doesn't convert "Q" or "Z"

[Harro]

hmm that's indeed weird. The regex excludes those as well
specifically.
The Q and Z should be added or a comment should be added to the code
explaining the reason for leaving them out.

On Jan 14, 11:23 am, Gabriel Hurley  wrote:
> 1. Is there a reason Django's phone2numeric method doesn't work for
> the letters Q or Z? I realize that those two letters are the ones that
> share four letters to a number instead of the standard three, but
> that's no reason to leave them out. Most modern phones include the
> full alphabet on their keys and it's silly not to let people convert
> those two letters.
>
> If there's no reason, I'd be happy to submit a patch since it's such
> an easy fix.
>
> 2. I was also wondering if there's a reason that the dictionary of
> numbers/letters used in that function is in such a seemingly random
> order... is there some brilliant logic behind it?
>
> The source for the function I'm referring to is here:
>
> http://code.djangoproject.com/browser/django/trunk/django/utils/text
>
> Thanks!
>
>     - Gabriel
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Adding an option to re-test only failed tests

[Harro]

Sounds like a bad plan, what if by fixing the failed test you break
another one?


On Sep 29, 6:03 pm, Rob Madole  wrote:
> I've been using nose for our tests, and one of the features that I
> really like is the ability to run the tests again but filter only the
> ones that caused a problem.
>
> I'm thinking it would look something like this
>
> ./manage.py test --failed
>
> Does this sound worthwhile to anybody?
>
> Rob

--~--~-~--~~~---~--~~
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---