Modify

Opened 5 years ago

Last modified 5 years ago

#6956 new enhancement

Allow filtering changesets in ticket changer

Reported by: olemis Owned by: olemis
Priority: high Component: RepositoryHookSystemPlugin
Severity: normal Keywords: filter hook changesets vcs ticket
Cc: marc.swingler@…, k0s Trac Release: 0.11

Description

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) .

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by anonymous

  • Cc marc.swingler@… added

comment:3 Changed 5 years ago by olemis

  • Cc k0s added

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

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.