Roundup Tracker - Issues

Issue 2550926

classification
Title: Original author adding a second message shouldn't set status to 'chatting'
Type: behavior Severity: minor
Components: Versions:
process
Status: new Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ber, justus.winter, rouilj
Priority: Keywords: patch

Created on 2016-09-27 09:00 by justus.winter, last changed 2016-10-05 20:09 by ber.

Files
File name Uploaded Description Edit Remove
chat_only_on_new_user.patch rouilj, 2016-10-01 20:09
Messages
msg5902 Author: [hidden] (justus.winter) Date: 2016-09-27 09:00
This is an issue that I find annoying at our Roundup installation.  Bug
reporters often add another message because they forgot some
information, and then the status is set to 'chatting'.

This matches neither my expectations nor the user guide, which describes
"chatting" as "under review or seeking clarification".
msg5903 Author: [hidden] (rouilj) Date: 2016-09-28 02:28
Hi Justus:

Would the following logic work for you:

  when receiving a new message on an issue, 
     check to see if the status of the issue is new (1)
     check to see if the submitter of the first message is the same as
         the new message
     if so keep the status as new
     if not change the status to chatting

This assumes that the "new" status is never reassigned. If it is
reassigned, then I guess scanning the history would be required.
So (1) would then read:

   check if the status of the issue is new and if
      the status has always been new (i.e. never changed)

so once the status of the ticket is changed, any email from anybody
would change it to chatting from new, done-cbb etc.

-- rouilj
msg5904 Author: [hidden] (justus.winter) Date: 2016-09-29 08:53
The simpler logic you described sounds just fine.  Thanks :)
msg5905 Author: [hidden] (ber) Date: 2016-09-30 13:56
Hi Justus, hi John,

the code for these state changes is part of the configuration,
thus it is part of the standard template bugs.gnupg.org is using.
roundup/share/roundup/templates/classic/detectors/statusauditor.py

You could change the logic in there for your tracker.
Some trackers switch it off alltogether. 

I think "chatting" often means that some activity has started on the
issue and action is needed. This is why "resolved" and "done-cc" switch
to it. When searching for new or chatting issues you should find all
that require user input.

For the use in bugs.gnupg.org where most users can only modify the
issues they have created themselfs, I agree that it may make sense to
not switch
to chatting if the status is new and the new message comes from the creator
of the issue. If you peek at statusauditor.py you probably figure out how
to add that logic.

So I'm unsure if we should change the default for roundups distributions.
Regards,
Bernhard
msg5906 Author: [hidden] (rouilj) Date: 2016-10-01 20:09
Hi Justus:

I have added a patch to statusauditor.py that implements the first
option discussed above.

I am assuming you are using an unmodified version of the classic tracker
statusauditor.py file.

To test it, cd to your tracker's detectors directory and run:

 patch < chat_only_on_new_user.patch

There is a variable:

 allow_multiple_initial_emails

at the beginning of the chatty function that is set to False.
To test the new functionality, you must set that variable to True
and restart your tracker.

Then you should be able to create a new issue (by email or browser).
As long as:

 the state of the issue is 'unread'

and

 the person who added the first message to the issue is the person
 updating the issue

the status should remain 'unread'. If somebody else adds a message,
the state will change to 'chatting'. If the starting state is done-cbb
or resolved, the state will be changed to chatting regardless of the
user updating the issue.

If this looks good, I will consider adding it to the roundup release,
but the 'allow_multiple_initial_emails' will be set to False so it's
disabled.

This allows people to upgrade but not have any change to their system
unless they take a specific step to enable it.

Also I am looking for a new name for 'allow_multiple_initial_emails'.
That's not exactly a great description of what it does. So suggestions
welcome.

Bern I think this is a useful patch to add, but I agree with you that it
should be disabled by default. One thing I am considering is if we
should ship a config.ini in the detectors directory and have optional
features such as this be enabled via the ini file. There are no
examples of this AFAIK, but

 
http://roundup.sourceforge.net/docs/customizing.html#extending-the-configuration-file

and

   https://sourceforge.net/p/roundup/mailman/message/11511368/

indicate this should work.

I think having a detectors/config.ini file is a good mechanism for addon
authors to use to customize the code and we could provide a web
interface to the ini files so that administrators can manage features
through the web interface.

Also Bern one other feature I have been asked about is preventing
reopening after some number of days. So if he issue is in the
resolved state and an update comes in say 30 days later,
the issue is not reopened.

I'll open a new issue for this as there are a number of questions about
how this should function.

-- rouilj
msg5908 Author: [hidden] (justus.winter) Date: 2016-10-04 09:12
Hi Bernhard, hey John :)

I didn't realize that this logic is part of the configuration/state. 
I'm new to roundup.

John, thanks for whipping up the patch.  I have applied it to our tracker.

Thanks for your time,
Justus
msg5909 Author: [hidden] (ber) Date: 2016-10-05 20:09
Am Samstag, 1. Oktober 2016 22:09:51 schrieb John Rouillard:
> Bern I think this is a useful patch to add, but I agree with you that it
> should be disabled by default. 

Fine with me.

> One thing I am considering is if we 
> should ship a config.ini in the detectors directory and have optional
> features such as this be enabled via the ini file.

This is a question probably best brought up on the devel mailinglist as well.
History
Date User Action Args
2016-10-05 20:09:29bersetmessages: + msg5909
2016-10-04 09:12:38justus.wintersetmessages: + msg5908
2016-10-01 20:09:50rouiljsetfiles: + chat_only_on_new_user.patch
keywords: + patch
messages: + msg5906
2016-09-30 13:56:58bersetnosy: + ber
messages: + msg5905
2016-09-29 08:53:14justus.wintersetmessages: + msg5904
2016-09-28 02:28:50rouiljsetnosy: + rouilj
messages: + msg5903
2016-09-27 09:00:31justus.wintercreate