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