Re: Allow changing form field properties after form creation

On 6 April 2012 07:26, Beres Botond wrote: > Hi Chris, > > Isn't it this what you are trying to do? > > class DocumentForm(ModelForm): >        def __init__(self, *args, **kwargs): >                super(MyForm, self).__init__(*args, **kwargs) >                

ModelForm.Meta.overrides

A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm violently -1 on the whole topic "meta programming form fields after they've been instantiated", it's a mess. Yes it would be more DRY, but also much harder to know how the hell the form fields are composed as. Just override

Django Sprint at PyCon Australia 2012 -- Monday 20th August

Monday 20th August 0900-2359 AEST at PyCon Australia 2012 (Hobart) [1] The Interaction Consortium [2] have kindly offered to provide pizza and beer (presumably only for those physically present ;) Join us via the #django-sprint IRC channel on Freenode; see [3] for more information. [1]

Re: Python 3 - style question

> On 10 August 2012 18:56, Vinay Sajip wrote: >> I think Option 2 is better, for the reasons you state. +1. And it's not too entangled to be easily stripped out if/when Python 2 support is removed. On 11 August 2012 06:10, Łukasz Rekucki wrote: >

Re: Python 3: should we apply unicode_literals everywhere?

It's a shame we couldn't skip straight to Python 3.3 and take advantage of PEP414... On 22 August 2012 07:32, Adrian Holovaty wrote: > On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin > wrote: >> In my opinion, option (2) is a logical

Re: RedirectView supporting View-Names

See https://code.djangoproject.com/ticket/15273 On 23 November 2012 23:30, Ludwig Kraatz wrote: > Hi, > > is there a specific reason why the RedirectView does not have a > "view_name" attribute and out-of-the-box supporting to reverse it? > > if self.url: > url =

Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

On 13 June 2013 07:41, Simon Meers <drme...@gmail.com> wrote: > On 13 June 2013 03:33, <rich...@richard.ward.name> wrote: > >> I think that the usability of ForeignKeyRawIdWidget could be vastly >> improved if the representation part of the widget (the object name,

Re: Suggestion: DictionaryField

I had considered designing something like this last week. It does seem to be a common requirement -- any situation where a simple field would be almost suitable but for the fact you'd like to avoid duplicates and allow fast selection of existing values. A Field shortcut could be commonly used to

Bug in Form metaclass?

Disclaimer: Just in case this was a naive mistake on my part, I posted this on django-users first [1] and posed the question several times on #django, but have received no answers. # # forms.py:

Re: Bug in Form metaclass?

Thanks for looking into this Russ > Firstly, django-dev isn't "second tier tech support" - if you don't > get an answer on django-users for a user-space question, that's a > pity, but it doesn't mean you can or should "escalate" to django-dev. I realise this; I thought this was the place to

Display link to change-form on inlines where model is registered in admin site

I've just submitted #13163 [1] with a patch to display a link to the full change-form for inlines of models which are registered in the same admin site, similar to the existing "view on site" link for inlines. I have had numerous projects where this would have been immensely useful (for which I

Trac Full!

I was trying to figure out why I was getting Internal Server Errors when attempting to upload a patch on code.djangoproject.com -- I have discovered that there is "no space left on the device"! Now you can't even add a comment to the database: Traceback (most recent call last): File

Re: Trac Full!

> I was trying to figure out why I was getting Internal Server Errors > when attempting to upload a patch on code.djangoproject.com -- I have > discovered that there is "no space left on the device"! This seems to be fixed now (thank you webmaster). However it may be worth noting that the email

Django Related-Object Links in Admin

I've uploaded some screenshots [1] of the new patch for #13163 [2] and #13165 [3] in action, to allow people to see the affect without necessarily applying the changes. These enhancements have *vastly* improved the navigability of the admin interface between related objects. Please have a look

#11882 Ready for checkin?

I was today momentarily caught out by the missing documentation for formfield_for_manytomany, and found #11882 [1] which has a patch for this very issue and was marked "Ready for checkin" last year. It's a shame it missed 1.2 Anyone care to give it a push? [1]

Re: www.djangoproject.com down?

http://downforeveryoneorjustme.com/djangoproject.com On 1 June 2010 17:23, Vinay Sajip wrote: > I've been having trouble accessing www.djangoproject.com recently, > from here in the UK. Is this a known problem? Is the server down? > > Regards, > > Vinay Sajip > > -- >

Re: Django Related-Object Links in Admin

On 25 May 2010 07:50, Simon Meers <drme...@gmail.com> wrote: > > I've uploaded some screenshots [1] of the new patch for #13163 [2] and > #13165 [3] in action, to allow people to see the affect without > necessarily applying the changes. > > These enhancement

Re: Django Related-Object Links in Admin

> The demo screenshots you provide certainly look good to me; I haven't > done a full teardown on the patch, but a from a quick glance it > certainly looks promising. Thanks for your response Russ. >  * Why allow edit links on a readonly field? This seems a little > redundant to me? Because

Re: Admin patches

Hi Sebastian, > Btw, running the test suite with mysql takes forever. > If you know the reason please tell me. However i was able to run the > test suite on a plain django 1.2.1 installation with sqlite, but got 11 > failures and 37 errors ... Have you read [1]? Do you still get errors if you

Re: Django Related-Object Links in Admin

>>  * Permissions - from my initial inspection, it isn't obvious to me >> that you are honoring (and/or testing that you are honoring) >> permissions. If I don't have permission to edit an object, I shouldn't >> get an edit link. Given the addition in 1.2 of object-level >> permissions, this means

Re: Feature Request

> EmailField, UrlField, Foreign Key, OneToOneField and ManyToManyField > clickable in the admin changelist interface of Django 1.3: > if you click you are redirected to: >  - Foreign Key, OneToOneField and ManyToManyField: the change page of > the linked object This is already implemented in the

Re: Feature Request

On 21 June 2010 17:49, Massimiliano della Rovere wrote: > If I understood correctly, these patches are related to the change view of > the instance, not to che change list view (the page where instances are > listed). Correct; I interpreted your request for

Re: Feature Request

On 22 June 2010 19:59, Massimiliano della Rovere < massimiliano.dellarov...@gmail.com> wrote: > Anyway using this method I can't sort columns any more. > This is why I was suggesting having links created by the framework: > callable aren't sortable. > They can be -- set admin_order_field on the

Re: natural keys and dumpdata

> I'll put it on my todo list; if anyone else wants to give it a sanity > check, I'd appreciate the extra eyeballs. Looks pretty sane to me, though I wonder if the deserialisation should raise an exception if the pk is missing and an incomplete set of natural key fields is provided? Nice work,

Re: postgresql last_insert_id issue

The patch here [1] fixes this if anyone feels like reviewing. This bug is preventing me from using trunk on several projects at present, so it would be great to get the patch checked in. It also fixes a number of other problems people have been reporting, I believe. Simon [1]

Re: Why this feature is still not accepted ?

Apart from permissions issues etc as Mikhail mentioned, there is also an important design decision required about whether it is a good idea to provide a dynamic link to the selected item rather than the last saved item. If you allow the user to change their selection and then click the link to

#3400 -- ModelAdmin.list_filter improvements

A gentle reminder to anyone who would like to review the recent patch uploaded for #3400 [1]. I have come across quite a number of people who consider list_filter's current inability to span relationships (e.g. as search_fields can) to be one of the more obvious/annoying of Django's limitations

Actions in popups

Users regularly get confused when you present them with a raw_id popup window which shows action checkboxes beside the list of items they are selecting from -- they try to click the checkboxes, and wonder why the window isn't closing. IMHO it really doesn't make much sense to be performing actions

Re: Something.is_live instead of implementation specific is_live settings

If everything is under version control, you'll need to detect the server status somehow. Some options: - check the absolute path of the settings file on the filesystem if you can ensure this path is different on the production server - import socket; and check socket.gethostname() - check for

Re: #3400 -- ModelAdmin.list_filter improvements

Anyone? I know it is a relatively complex patch to review, but it would be a shame to see such a frequently requested feature/fix miss the 1.3 boat. On 29 August 2010 08:06, Simon Meers <drme...@gmail.com> wrote: > A gentle reminder to anyone who would like to review the recent patch &

Re: Permission support for admin inlines

On 27 October 2010 08:15, Simon Litchfield wrote: > The ModelAdmin's permission hooks are great- has_add_permission, > has_change_permission, and has_delete_permission. > > It would be nice if they were supported by inlines in the same way; ie > InlineModelAdmin,

prepopulated_fields javascript error since r14123

Has anyone else found that using prepopulated_fields in admin.ModelAdmin since r14123 produces a javascript error: "d.join is not a function"? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: prepopulated_fields javascript error since r14123

On 27 October 2010 19:40, Andrew Godwin <and...@aeracode.org> wrote: > On 27/10/10 07:01, Simon Meers wrote: > >> Has anyone else found that using prepopulated_fields in admin.ModelAdmin >> since r14123 produces a javascript error: "d.join is not a function"? >

Re: prepopulated_fields javascript error since r14123

On 30 October 2010 07:50, Andrew Godwin wrote: > > It's working fine for me on my freshly-updated 1.2.X branch - did you make > sure the caches were clear, etc, etc? > Yes, and I'd experienced it on several different servers/projects/client-machines. Yet I've just tested

Re: Need advice on ticket #14928 (manage runserver does not allow host name as address)

> I don't know how many people actually used that feature (I never did), > but it seems like it was a bit accidental. As we are speaking about a > development server, I don't find this feature very useful as (most of > the time) you want to run it on a host-only address, which won't have > many

Re: Feature request: Abstract ManyToManyField

2011/2/5 Carl Meyer > > Hi Mike, > > On Feb 3, 4:36 pm, Mike Lindsey wrote: > > I'm doing something with bidirectional ManyToManyFields, in a project > > I'm working on, that is resulting in duplicate attempts to create the > > intermediate

Re: type-field model inheritance

On 4 March 2011 17:03, Craig de Stigter wrote: > Hi guys > > Thanks for pointing those out. I knew I couldn't have been the first to want > this. I guess I just didn't know the right words to search for here. > It looks like django_polymorphic does what I want. I'm not yet

Re: type-field model inheritance

Hi Carl, > FWIW, django-model-utils [1] includes an InheritanceManager that > implements polymorphic queries in a single query via select_related. Ah, there goes my theory that I thought of it first :) And of course introspection of subclasses via the reverse OneToOne descriptors is perfect. --

Re: ModelBackend should have a get_anonymous_user method

Hi Ric, On 18 November 2011 19:53, Ric wrote: > ... > i've created a ticket > https://code.djangoproject.com/ticket/17254 Thank you for your contributions of late. Please note that you don't need to email django-developers when you create a new ticket; we receive