hassanakbar4 / ttest

0 stars 0 forks source link

datatracker 500 error when adding a draft #351

Closed hassanakbar4 closed 14 years ago

hassanakbar4 commented 14 years ago

resolution_fixed type_defect | by rjsparks@nostrum.com


When I selected [Add] on the page at https://datatracker.ietf.org/doc/draft-ietf-sipping-nat-scenarios/ and then fill out the form at https://datatracker.ietf.org/doc/draft-ietf-sipping-nat-scenarios/edit/info/ setting the intended status to BCP and the responsible AD to me (either by selecting myself in the dropdown or by checking the assign to me button)

I get a 500 after clicking save.

I did not fill in the status date field, change the suggested email recipients, or select a telechat date. (And I just retried, providing a status date, resulting in the same error)

(reporting against Version 3.02, 2010-07-21)


Issue migrated from trac:351 at 2021-12-13 14:45:37 +0500

hassanakbar4 commented 14 years ago

@henrik@levkowetz.com changed component from datatracker.ietf.org to doc/

hassanakbar4 commented 14 years ago

@henrik@levkowetz.com changed milestone from ` to3.02`

hassanakbar4 commented 14 years ago

@henrik@levkowetz.com commented


I believe this bug is caused by wrong use of Django's initial form data.

I spotted this already shortly after the initial 3.00 release, and sent the following mail off to IOLA:

Subject: Fwd: [Django] Error (EXTERNAL IP): /doc/draft-ietf-alto-reqs/edit/info/
Date: Mon, 19 Jul 2010 13:20:02 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
To: Ole Laursen <olau@iola.dk>

Hi Ole,

I've now merged and released the IESG tracker.  During the first couple of day's
use, a few errors has popped up.  I've looked at them, and done some easy fixes
at once, but here is one which I see needs some attention not only for this
particular case, but in a number of other cases.

The issue is that in the code leading up to the point where the exception is
triggered, you create (for internal use only, not for display) a form with
some initial data, intending (I believe) that the initial data should be used
as default form content if nothing else is provided by the user.

Unfortunately, the way I understand the use of initial data (see Django doc page
http://docs.djangoproject.com/en/dev/ref/forms/fields/#initial) the initial
data will only be displayed, and not returned as part of the populated form.

It seems to me that the result is that at the point where the exception is
triggered below, there is no 'area_acronym' to fall back on if new_document
is true...

Could you have a look at this please, and also other places where you may have
used an initial= parameter for the purpose of providing default data?  If I'm
right, these will have to be rewritten.

Best,

    Henrik
hassanakbar4 commented 14 years ago

@henrik@levkowetz.com changed status from new to closed

hassanakbar4 commented 14 years ago

@henrik@levkowetz.com set resolution to fixed

hassanakbar4 commented 14 years ago

@henrik@levkowetz.com commented


Fixed in e6c429ce4ff8b668a4d9085d626866dcef20f9b2:

Fix for issue 351, from olau@iola.dk. Now permits editing of document state without getting a 500 error.