• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

• Policy Name: UFD Process (Unexpected Form Data)

• Policy Owner: Kiko

Policy Statement

1. Form handlers need to accept data that can be entered into forms
2. Should the form handler encounter unexpected data and it is not seamlessly handled then we must raise a UFD.
3. A UFD must have an informative OOPS page

SteveA:

1. Form handlers need only to accept data that can be entered into forms.
2. Should the form handler encounter unexpected data and it is not seamlessly handled then we must raise a UFD rather than some other kind of exception.
3. A UFD shall have an informative OOPS page.

The exception to point 1 is where we decide that a particular form handler is a public interface that will be accessed from a Launchpad form and also by other means.

Rationale

The reason for this is that there can be a lot of spaghetti code to handle various different "schemas" of form data. The benefit of supporting many "schemas" is usually outweighed by the costs of creating, maintaining and testing the code. However, this is not true in all cases, so we use a specific exception (UnexpectedFormData) to monitor when a form is used outside of its design parameters.

A consistent UFD process will allow us to see when we get UFD errors so we can deal with them as part of our production QA activities, so we can:

• Understand the situations where users are attempting to use form handlers in ways that we do not expect.
• Understand the situations where the UFD is a transient condition that will go away without our doing anything.
• Make good decisions about when we need to make form handlers handle old patterns form data, or when we can keep form handler code simple.

Process Description

Triggers

1. A Launchpad form handler encounters unexpected data
   • users manually editing URL lines for GETs
   • users caught between server upgrades -- form page rendered on version N, but submitted to version N+1
   • form posts from non-launchpad site
   • other user-agents accesing Launchpad making assumptions about how the forms work
2. A Launchpad form handler that does not accept data legitimately entered from its form
3. A bug in Launchpad, for example where an interaction between the redirection machinery and the form machinery led to UFD.

Inputs

1. Offending Data entered into the form by by a user, a user's browser, or a robot.

Outputs

1. A UFD produces an informative OOPS page. Customer is both Launchpad user and Launchpad Developers. A good UFD example should be https://beta.launchpad.net/products?text=foo&text=foo however currently it is producing an OOPS instead of a UFD (XXX: Bug#57474)

Participants

• Launchpad user/robot - creates the data causing the form handler failure
• Developer - Codes the appropriate form error handling code to produce a UFD exception.

Subprocesses

• None.

Standard Path Events/Activities

• We may choose for a particular UFD to:
  • ignore it
  • contact the person (if known) who is running the robot/script
  • change our form to support the particular request.
  • considering the "false triggers", to fix our form handler code or application code.

• 
  
  XXX: Need handling instructions (or perhaps code snippet)

Alternative Path Events/Activities

None.

Supporting Documentation

• UFDs are collated specially in OOPS summaries. See the OOPS QA Process for details.

Comments

• SteveA:
  1. Also, we have the "false trigger" of a launchpad form handler that does not accept data legitimately entered from its form. We have another "false trigger" of some other bug in Launchpad, for example where an interaction between the redirection machinery and the form machinery led to UFD.

     • JoeyStanford: Updated. Thanks!

  2. Actually, data submitted to a form-handler by a user, a user's browser, or a robot.

     • JoeyStanford: Updated. Thanks.

  3. To produce a UFD exception. Not an OOPS.

     • JoeyStanford: Updated. Thanks.

  4. also, considering the "false triggers", to fix our form handler code or application code.

     • JoeyStanford: Updated. Thanks.

  5. I'd suggest that this process is part of the OOPS QA process.

     • JoeyStanford: Updated. Thanks

  6. This page should be a UFD. It is not at present, but it should be converted to be one: https://beta.launchpad.net/products?text=foo&text=foo

     • JoeyStanford: Updated. Thanks