Allow filtering changesets in ticket changer

[Olemis Lang]

The original source of inspiration for this is ​Mark Swingler's request at trac-users list . The approach I see so far is to plug different components that might add additional rules in a form of a chain of responsibility (first denial and changeset will be ignored ;o) .

[anonymous]

I was originally thinking about doing this on the commit hook side as stated below. But as Olemis suggests above implementing on the Trac Server side is another option. (And probably a better one.) I'd then suggest something more along the lines of what Hudson does with post-commit: call wget to the Trac server from the post-commit script passing the revision number. Trac could use svn commands to request data it needs:

changeset

svn diff [--username <...> --password <...>] --summarize -c <revision#> <svn url>

log

svn log [--username <...> --password <...>] -c <revision#> <svn url>

I'd parse the output of the log and diff commands to get the log, author and list of changed files. Next, as Olemis suggests, I'd consult a table of denial rules. Get a match and the comment is ignored. Denial rules could consist of a list of regular expressions:

<user/group-name> <path/project-name>

If a commit is not denied process the commit log.

Another thing to think about would be recording changeset/log/ticket associations to a dedicated set of tables in the Trac DB. Make it editable through the UI as well. This data could be useful in a number of scenarios. (If we go this route we should be sure to also use the repository UUID in addition to the revision number.)

E.G.: Continuous Build servers could send a message to Trac when a project gets rebuilt, noting changesets since the most recent build. Tickets could then be auto-magically associated with build numbers.

Definitely up to discuss. I was thinking of filter rules based on users and SVN paths of the changeset. A filter config file could let admins define a list of rules specifying user, path, tracServer. First match wins. It'd have to allow a regular expression syntax for user and path in the entry. The tracServer server could either be a URL or a predefined short-name already associated with a URL. A nice to have (but not necessary) would be a way to define groups (a set of users) and projects (a set of paths). Groups and projects could then act as keywords in the filter set.

[Olemis Lang]

After reading previous comments I think that initial requisites should be :

• Filter rules based on users and SVN paths of the changeset
• It'd have to allow a regular expression syntax for user and path in the entry
• The tracServer server could either be a URL or a predefined short-name already associated with a URL
• A nice to have (but not necessary) would be a way to define groups (a set of users) and projects (a set of paths).
• Denial rules could consist of a list of regular expressions: <user/group-name> <path/project-name>
• If a commit is not denied process the commit log.
• Another thing to think about would be recording changeset/log/ticket associations to a dedicated set of tables in the Trac DB. (If we go this route we should be sure to also use the repository UUID in addition to the revision number)
• Continuous Build servers could send a message to Trac when a project gets rebuilt, noting changesets since the most recent build. Tickets could then be auto-magically associated with build numbers

I'll start implementing this ASAIC, and will post comments for each candidate feature. For the moment here are my initial $0.02 with (potentially redundant) features to consider in order to implement filters in Trac RepositoryHookSystemPlugin

• Control what users can trigger a particular hook action.
• Different policies for different actions.
• Provide support to define (reuse) groups of users.
• Provide integration to reuse ​TracFineGrainedPermissions.
  • Introduce VCSHOOK_INVOKE ?
• Reliability
  • Do not halt if exceptions are raised and recover gracefully .
• Log events helpful for debugging purposes
  • Changeset ignored on behalf of an active filter
  • Log exceptions raised by custom filters
  • Include detailed information