Re: Two types of submit, nosy and silent

Hi Tom:

In message <CO3PR08MB79576102FC15D901064BB1E5CA759@CO3PR08MB7957.namprd08.prod.
outlook.com>, Tom Ekberg writes:
>I have a tracker whose issue page has two types of submit buttons:
>Submit Change and Silent Change. The Submit Change button sends email
>to the nosy list; the Silent Change button does not. When looking at
>the green messages that appear near the top of the page after doing a
>submit, there doesn't seem to be a way to distinguish between these
>types of submit.

True. The standard messages just report creation/change to the db. The
reactors don't have access to the client object, so they can't add
errors or ok messages.

>One thought is to call client.add_ok_message when
>either Submit Change is pressed, or when an issue is changed
>silently. It looks like the text of the message passed to
>client.add_ok_message is subject to internationalization,

What makes it tricky? If the message doesn't appear in any translation
file, it will just be passed to the user as is.

>making it a
>bit tricky to add new messages. I'd like to know if there is another
>way (history?) to distinguish between the 2 types of submit.

What's your goal:

 1 to notify the user they did a silent/noisy submit
 2 to be able to answer the question "why didn't X" get a notification
 3 for audit purposes

Also are you concerned only with messages being silent, or would
changes that do not create a change note/message have to record
silent/noisy submission?

For 2 and 3 covering only the case where a message is created, the
best answer I have is to add a field to the message class called
submission_type and record the submission type in an auditor.

I don't have an answer for 2 and 3 for random fields.

For 1, I don't have a good answer, but you can modify your edit action
that looks for the submit_button so that it captures the Redirect
exception from EditItemAction.

Something like:

  from roundup.cgi.exceptions import Redirect
   ...
     def handle()
        ...
        try:
            EditItemAction.handle(self)
        except Redirect as r:
	    if self.db.web['submit'] is not None:   
	        rargs[0] **
	raise       

at ** parse r.args[0] which is the url with the @ok_message already
encoded in it. Parse r.args[0] and modify the @ok_message query
parameter adding your message to it. Then recompose the URL and raise
Redirect(url). This seems fragile and a bad idea, but it's the least
invasive I have at the moment.

Since EditItemAction::handler() raises the redirect, you could copy
the hander() into your class (under another name) and modify the lines
in handler that read::

        props, links = self.client.parsePropsFromForm()

        # handle the props
        try:
            message = self._editnodes(props, links)
        except (ValueError, KeyError, IndexError, Reject) as message:
            escape = not isinstance(message, RejectRaw)
            self.client.add_error_message(
                self._('Edit Error: %s') % str(message), escape=escape)
            return

        # commit now that all the tricky stuff is done
        self.db.commit()


to read:

        props, links = self.client.parsePropsFromForm()

        # handle the props
        try:
            message = self._editnodes(props, links)
        except (ValueError, KeyError, IndexError, Reject) as message:
            escape = not isinstance(message, RejectRaw)
            self.client.add_error_message(
                self._('Edit Error: %s') % str(message), escape=escape)
            return

	# add this    
	try:	
           if self.db.web['submit'] is not None:	
            	message += '\n' + 'Silent submission complete.'
        except KeyError:
	    pass # submit is missing; email submission for example

        # commit now that all the tricky stuff is done
        self.db.commit()

then call this method in place of EditItemAction.handle(self).  This
is safer, but means that you aren't using the core editing code.

Sorry I don't have a better idea. There was a discussion about having
an exception that could be raised by a reactor to supply info to the
user. This seems like it would be a good use case.

Also as an aside, one of my trackers has a silent submit button. I
found out it doesn't work. I use the bouncer js library for form
validation. Turns out it calls event.preventDefault() as soon as the
submit event handler is called. This prevents the submit button from
being included in the POST data. Result, silent submissions were
noisy.  The fix was easy, I'll ship it upstream to the author, but
figuring out what was happening was a pain.

Have a great week.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.