Created on 2016-09-27 09:00 by justus.winter, last changed 2016-10-05 20:09 by ber.
|chat_only_on_new_user.patch||rouilj, 2016-10-01 20:09|
|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.
|2016-10-05 20:09:29||ber||set||messages: + msg5909|
|2016-10-04 09:12:38||justus.winter||set||messages: + msg5908|
keywords: + patch
messages: + msg5906
messages: + msg5905
|2016-09-29 08:53:14||justus.winter||set||messages: + msg5904|
messages: + msg5903