Roundup Tracker - Issues


Author rouilj
Recipients Heiko, rouilj, schlatterbeck
Date 2023-02-22.17:20:45
Message-id <>
In-reply-to <>
Hello Heiko:

I'm sorry you are getting misplaced issues that you have to
sort out.  Let's see if some of Roundup's current features
will help. Some of the changes you request could be a new

What version of Roundup are you using? I think my
suggestions have been there since the 1.x series but..

I see you included Ralf, Ralf couple of questions for you

Sorry for the length of the email, but you have opened a
more complex part of Roundup.

In message <>,
Heiko Stegmann writes:

> [...] frequently happens that users do not follow this
> syntax [...] In these cases Roundup will
> not find the matching issue and create a new one instead

Roundup has two additional mechanisms to try to assign
emails to issues if prefix parsing fails.

 1. It looks for an in-reply-to header in the email and
    tries to match that up against an existing message with
    the same message id. Then it puts the new message on
    issue with the matching message.
 2. If message id matching fails, it tries to match on the subject.
    If the new message's subject is changed sufficiently from the
    title of an existing issue, this will fail as well.

I would expect #1 to catch most of what you describe.

Heiko, can you find one of your misrouted messages and dump
it using:

   roundup-admin -i <tracker home> get inreplyto msg<num>

Does it have a value (not None) for inreplyto? If so, does
that value match an existing message? If you have a newer
Roundup, and it has the filter command you can use:

  roundup-admin -i <tracker home> filter msg messageid="<1675055043.0895576.IZTXE7H4VMTIDGQA.issue226@localhost>"

to find the existing message.

Ralf, let's assume Heiko's experiment indicates that
inreplyto matching should work. Does this sound like a false
positive match in prefix parsing?  IIUC that would prevent
inreplyto and subject matching. It could also be a bug in
inreplyto parsing, bu I don't know of any do you?

Parsing the subject line is tricky. We don't want false
positives where a match happens, but shouldn't be. To guard
against this we use:

  1. known location for the prefix
  2. delimiters around the prefix
  3. strict format inside the delimiters

We also don't want false negatives missing a valid match.

Relaxing #3 could be useful in preventing false negatives.

>Roundup's mail gateway allows to set add email content to
>an issue by specifying the issue designator in square
>brackets at the beginning of the email subject
>line. However, the syntax must exactly follow the scheme

It is more complex that that, you can have:

  Subject: [user3] [realname=Fred]

to modify the realname of user3.

Also you can create a new item in the device class by

  Subject: [device] new device [location=32; category+=computing]

which creates a device and sets some of its properties.

You are correct it must be:

 [classname<number can be optional>]

>It must be placed at the beginning of the subject line,

You can strip prefixes from the subject line using refwd_re
in config.ini. It is meant to remove the prefixes added by
mailers when replying or forwarding message. If your users
have a mail client wih a different prefix, you can add it

>no blank spaces are allowed, only square brackets will work,

The brackets can be replaced with another pair of characters
using 'subject_suffix_delimiters' config.ini which works for
both the class/item prefix and the suffix modifiers. *But*
only one pair of delimiters/characters is allowed. So you
can allow




but not both.

>and I think it is also case sensitive.

That's correct since class names are case sensitive.

>However, it frequently happens that users do not follow
>this syntax

Some user education can go a long way there. However given
the variety of mail clients in use, education can be an
impossible task.

What is the setting for 'subject_prefix_parsing' in your
tracker's config.ini?

There are three settings:

  strict - which returns emails with unparsible prefixes to
           the user describing the problem and how to fix it.

  loose - which if it can't parse a prefix will pass the
          message through to create a new object in the
          default_class as specified in config.ini.

  none - which will not try to find a prefix and fall back
         to inreplyto or subject matching. If those fail, it
         will create a new object.

If you aren't using strict, it might help.

>My request is to make the mail gateway based issue matching
>more fault tolerant. It should not matter where in the
>subject line the issue designator is placed.

Are you actually seeing subject lines where the user takes
the time to edit the subject line on a reply to move the
prefix into or after the subject like:

  computer failure [issue24]

  computer [issue24] failure

or change the delimiters:

  computer failure <issue24>

  {issue24} computer failure

rather than leaving it alone and generating something like

  Re: [issue24] computer failure

>Blank spaces inside the brackets

This could be a useful option. Are people keeping the
designator together? So you see:

  [ issue24   ] 

or do they split the designator like:

  [  issue 24 ]

These look simpler to implement. Hopefully you aren't seeing

 [ iss ue 24 ]


>and brackets other than square should be allowed.

I assume here you want to support both '[]' and '<>' (for
example) as demlimiters?  If you just want to change the
delimiters, you can do that already.

>It should also be case insensitive.

You can name classes 'issue' or 'Issue' or even 'ISSUE'. So
it must be case sensitive by default. If it wasn't you
couldn't tell the difference between the three issue types.

Are you actually seeing a prefix of [issue24] being replied
to with a subject like:




If you are seeing that, is the rest of the subject line
modified as well?  e.g.

  [issue24] computer broken

is replied to as:


If so you would also probably want to set
'subject_updates_title = no' in config.ini so that people
using mail readers that sort/thread by subject don't get

However adding a config.ini option to make class name
matching for the prefix case insensitive could be possible.
Date User Action Args
2023-02-22 17:20:45rouiljsetrecipients: + rouilj, schlatterbeck, Heiko
2023-02-22 17:20:45rouiljlinkissue2551262 messages
2023-02-22 17:20:45rouiljcreate