John:

I am going to plan on closing this in a couple of weeks if there is no
update. Currently it doesn't seem to be something we
will be writing or including in the roundup codebase.

If you have a working auditor example though feel free to re-open
attach your solution to the ticket and add the patch keyword.

However, I wonder if for your use case, this could be handled
differently in the web frontend.

You still need the auditor since a user can submit any request to the
tracker. Without the auditor they would be able to delete any user as
a result.

However for your use case does it make sense to always display the
nosy list as a read only field (unless the person is an admin or
manager). Users add themselves to the list using a checkbox (called
'in_nosy_list' for example) that the user can toggle to add/remove
themselves from the nosy list?

I am not quite sure how to set that up at the tracker level except by
hijacking the EditItemAction somehow to allow a new EditItemAction
to run something like (warning py pseudo code ahead):

  if 'in_nosy_list' in self.form:
     self.db.issue.get(issue, 'nosy')
     check the value of self.form['in_nosy_list']
     if unchecked remove user from nosylist
     else add user to nosylist
     self.form.list.append(cgi.MiniFieldStorage(
                               "nosy", new_nosy_value)
                          )

  # call the original EditItemAction handler somehow
  EditItemAction.handle(self)

It's possible somebody else on the mailing list or this issue can figure
out how to do this and supply a recipe.

Also it seems like this could be something we could add to
EditItemAction triggered by a special name for the checkbox. E.G.
a checkbox named:

   @modify@nosy:add_remove

will add (if checked) or remove (if unchecked) the current user from
the nosy list.

I am not sure if Thomas or Bern have other ideas on this but...

It would be nice to be able to pass these form fields into the
detectors somehow without requiring a database field to back the field.

-- rouilj