Convert remaining bugtask*.pt templates to 3.0 layout rules

Bug #429933 reported by Gavin Panella on 2009-09-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Eleanor Berger

Bug Description

Gavin Panella (allenap) on 2009-09-28
Changed in malone:
milestone: 3.0 → 3.1.10
Changed in malone:
assignee: Gavin Panella (allenap) → Tom Berger (intellectronica)
Gavin Panella (allenap) wrote :

To avoid heading down the same dead-end road I did, please note my
comments on revisions 9444 and 9445 of the linked branch

 9444 Gavin Panella 2009-09-15
      Attempt to use the standard form machinery in the bugtask edit form.

 9445 Gavin Panella 2009-09-15
      Revert previous revision.

      The previous revision changed LaunchpadFormView.setFieldError() to
      remove errors from self.errors that were related to the specified
      field, on the basis that if you're *setting* the error, you probably
      want to override any existing errors, and you don't want messages like
      "there were 2 errors" when only one is highlighted in the page.

      However, zope.formlib.form.getWidgetsData() is broken, IMO, and
      prevents this from working. It populates a data dict, and returns a
      list of the errors discovered. If an error is a ValidationError, it
      wraps it in a WidgetInputError, which has a field_name. However, if
      the error is one of, the error is
      return as-is, and these errors don't record the field that failed
      validation. So, when these end up in my_form.errors, there's no way to
      know if they can be removed or not.

      In the specific case I was trying to fix, the error was that a product
      name was not found in the vocabulary, which causes a ConversionError
      to be raised.

Changed in malone:
status: In Progress → Fix Committed
Changed in malone:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers