Roundup Tracker - Issues


Author rouilj
Recipients ber, justus.winter, rouilj
Date 2016-10-01.20:09:48
Message-id <>
Hi Justus:

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

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

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

 patch < chat_only_on_new_user.patch

There is a variable:


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'


 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

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

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


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
Date User Action Args
2016-10-01 20:09:51rouiljsetmessageid: <>
2016-10-01 20:09:51rouiljsetrecipients: + rouilj, ber, justus.winter
2016-10-01 20:09:50rouiljlinkissue2550926 messages
2016-10-01 20:09:50rouiljcreate