On Friday, July 8, 2016 at 11:22:00 AM UTC-7, Miguel Almeida wrote: > > I revisit this thread to see if you can help me setting up a solution for > this. > > I'm going the MultiProjectCommitTicketUpdaterPlugin > <https://trac-hacks.org/wiki/MultiProjectCommitTicketUpdaterPlugin> > route. I've set it up like [1]. > > *Works:*- a commit "foo (see xxx:#99) ", adds reference to ticket 99 in > project xxx > > *Doesn't work:1. * a commit "foo (closes xxx:#99) ", does not reference > nor close ticket 99 in project xxx > > I've also tried: > - removing the configuration commit_ticket_update in [trac] (see [2]) > - removing the configuration commit_ticket_update and adding just: > *commit_ticket_update_check_perms > = false* > > > Do you have any idea why tickets are not being closed? >
The user must have TICKET_MODIFY in order to close a ticket, assuming a typical workflow. Do you share an authentication store between Trac and Subversion? There can sometimes also be issues with case-sensitive usernames: https://trac.edgewall.org/wiki/TracIni#/ignore_auth_case > *[1] Configuration in global_trac.ini* > > [components] > multicommitupdater.* = enabled > > [multicommitupdater] > envelope = () > commands.refs = re see rel > > commands.close = fix fixes fixed-forever close closes > > > *[2] Original settings in [ticket] section* > commit_ticket_update_check_perms = false > commit_ticket_update_commands.close = close closed closes fix fixed fixes > commit_ticket_update_commands.refs = <ALL> > commit_ticket_update_envelope = () > commit_ticket_update_notify = true > > > On Wednesday, May 11, 2016 at 8:41:15 AM UTC+1, RjOllos wrote: >> >> >> >> On Tuesday, May 10, 2016 at 11:55:25 PM UTC-7, Cooke, Mark wrote: >>> >>> > -----Original Message----- >>> > From: RjOllos [mailto:[email protected]] >>> > Sent: 10 May 2016 20:52 >>> > >>> > On Tuesday, May 10, 2016 at 6:59:35 AM UTC-7, Cooke, Mark wrote: >>> > >>> > > Folks, >>> > > >>> > > I have one svn repository that is used by two Trac environments (the >>> > > second created after a major re-write). Unfortunately there is some >>> > > duplication of ticket numbers and I want to make sure that the >>> > > commit message gets to the correct ticket. >>> > > >>> > > I found this thread:- >>> > > >>> > > https://groups.google.com/forum/#!topic/trac-users/JmePlTBHklM >>> > > >>> > > ...but it is not clear to me how to solve my problem. >>> > > >>> > > A solution that occurs to me is to use different 'envelope' >>> > > characters for each Trac (e.g. "[]" or "<>") so that only one of the >>> > > two tracs picks up the message, then set my post-commit hook to call >>> > > both: >>> > > >>> > > @start trac-admin.exe D:\trac\env1 changeset added "%1" "%2" >>> > > @start trac-admin.exe D:\trac\env2 changeset added "%1" "%2" >>> > > >>> > > (note I am on windoze here!) >>> > > >>> > > Can anyone suggest a better solution? >>> > > >>> > > Many thanks, >>> > > >>> > > ~ Mark C >>> > > >>> > >>> > Using an envelope is an interesting idea. Thinking similarly, you >>> could >>> > define commit_ticket_update_commands.close and >>> > commit_ticket_update_commands.refs uniquely for each environment. For >>> > example, instead of the token "refs", you could define the token >>> "refs:proj1" >>> > or "proj1:refs". >>> >>> Hmm, interesting idea but we do not (yet) use the commands, only the >>> references (default set to `<ALL>`). >>> >>> > There is also: >>> > https://trac-hacks.org/wiki/MultiProjectCommitTicketUpdaterPlugin >>> >>> Thanks! That looks ideal (if a bit wordy!), I will have a look at the >>> code. Using existing inter-Trac prefixes is consistent with "normal" usage >>> >>> >> >>> > Another possibility is to set the starting ticket number for one of >>> the >>> > environments to a large-enough value that the sequences will never >>> overlap. >>> >>> I did not know you could do that (learn a new thing every day) >>> >>> > I'll be interested to hear what solution you end up going with. I >>> could see >>> > Trac doing something as an incremental step towards a multiproject >>> > environment. >>> >>> At the moment we are just sending all commits to the new project but >>> that is not ideal. >>> >>> I had another thought to replace the initial svn hook with a python >>> script that can then examine the message to identify the project (e.g. by >>> keyword) which would negate the need to call trac-admin twice. However >>> that is more flaky as svn hooks are not backed up by default `hotcopy` and >>> hides the solution outside of Trac... >>> >> >> SVN 1.8 adds the ability to store the authz file in the/a repository. I'm >> hoping it's also eventually possible to store the hook scripts in the/a >> repository, but I haven't looked to see if that's on the radar of the >> Subversion development team. >> >> https://subversion.apache.org/docs/release-notes/1.8.html#in-repo-authz >> >> Off-topic, but another really nice SVN 1.8 feature is the ability to >> configure the hook scripts environment through a config file, which can be >> shared among repositories. >> https://subversion.apache.org/docs/release-notes/1.8.html#hooks-env >> >> - Ryan >> > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
