Handling registraion errors/raise soft errors in detectors

"John P. Rouillard" <[email protected]>
Newsgroups gmane.comp.bug-tracking.roundup.devel
Message-ID <[email protected]>
Hi all:

I had an interesting use case come up with the bugs.python.org
tracker.

The user class has a homepage property that was validated by an
auditor to start with http or https.

Normally editing userN with the user.item.html template would provide
feedback to the user when they entered an invalid URL.

In the BPO tracker the user registration (user.register.html page)
asked for the homepage url during registration. There is no validation
of the registration request at the time of registration. Also BPO
sends a verification email to the user before acting on the
registration.

If the user put in a bad homepage url, the registration process failed
with a Reject error and the new user was not created.

Granted this is a bit of a niche operation because the registration
process is less interactive than editing the user item.

There are two ways to deal with this:

  1) validate the registration request
  2) allow auditors to return soft errors so the user is notified that
     something failed the audit. But the user is still created.

Validating the registration request, can be done today by replacing
the handler function using an extension like:

class NewRegisterAction(RegisterAction):

   def handle(self):

      props, links = self.client.parsePropsFromForm(create=1)

      if not props['homepage'] matches "^https?://": #ok, pseudocode
         raise Reject("Url does not start with http/https")

      RegisterAction.handle(self)

def init(instance):
    instance.registerAction('register', NewRegisterAction)

However this seems a bit clunky and RegisterAction.handle has to
rerun the parsePropsFromForm.

Another thought would be to add a validate() method to the
RegisterAction class in cgi/actions.py. By default it would be

   def validate(props, links): # use pre-parsed form values
       pass

Then the admin can override the function interfaces.py to do arbitrary
validation. This would be called after RegisterAction.handle parses
the form props, so there is only one parse. validate can raise Reject
on error. Then the user is returned to the registration page and can
fix any issues.

Another possibility is to make the auditor able to return a "soft
error" or "fatal error". This allows two things:

   1) the auditor can try to fix the error and notify the user to take
      a look at the fix.
   2) an auditor can report a fatal error (aborting the database
      change) but permit all of the auditors to run. So all errors are
      detected and the user can fix everything with one submission
      rather than fixing one after each submission.

In the BPO case, the auditor (on creation) could change the homepage
value to "INVALID:" followed by the original text. Then the auditor
would let the user creation process succeed and tell the user they
need to check the homepage field. If the user ignores the notice the
homepage URL would be broken but that is not the end of the world.

My thought was to allow an auditor to raise SoftError (name subject to
change). The auditor calling logic would add the error in the raised
exception to the _error_message property of Client just like raising
Reject. However unlike other exceptions, it would not terminate
application of the auditor loop and return. Instead all the rest of
the auditors and reactors (assuming no auditor raised another type of
exception) would be run. The user would be presented with the error
message when viewing the new user screen.

If an auditor raises FatalError, all auditors are run but after the
last one completes, Reject is raised to trigger feedback to the user
and terminate the change.

Has anybody dealt with these scenarios and come up with a different
solution? Anybody have a preference for these solutions?

Are these use cases sufficiently unlikely that it's not worth
addressing them since there is a current (although inefficient) method
for dealing with the original BPO issue.

Other thoughts?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.