Option NOT to update tickets comments (while Ticket-Changesets-List-Box unique functionality is active)

[dnedelchev]

It should be easy to implement it:

1. The unique plugin's functionality may or may not be an option.
   
2. But the duplicated functionality (which is present in tracopt too) must be an option for the plugin, I think.
   That would allow one choosing between the tracopt and plugin for the duplicated ticket-comment-update functionality.
   

It probably should be categorized as defect rather than as an enhancement.

I've tested that both tracopt's and the plugin's listeners can be enabled and both can work in the same time.

---

You've made a very useful tool and I really like that Ticket-Changeset list box!
However I still hesitate using it in our production environments (because of yet lacking un-reformat functionality) but if the proposed here option was implemented, I'd go installing it immediately.

BTW: Speaking honestly, I can't understand why you've cloned the existing tracopt functionality too instead of getting only what you really need from their code?
IMHO it would be better if the plugin was kept as simple as possible, doing only its unique things (and concentrate on making it do just these things as better as possible). For example if you implemented only the plugin's unique features then you wouldn't need any "diff" and "reformat" commands too.

[Mikael Relbe]

Sorry, but I do not fully understand the request. I can see that it could be a problem if both this plugin and the tracopt are activated at the same time. Is this what you are referring too? However, why would you want to activate both tracopt and this plugin? (Perhaps the documentation is not clear about this, or this plugin lacks some kind of check that the original tracopt is deactivated...)

I appreciate you comment about the cloning of the existing code. It's a valid question. The most honest answer I can give, by recalling my memory, is that the original code did not fully fit the needs (not even by inheritance). A more appropriate solution would be, of course, to update the original tracopt package and remove the one included here. But I would have to dig into to the code again to really defend myself :) and an appropriate action could very well be that inheritance is the correct way. I will have a look into this too.

The "diff" and "reformat" commands would nevertheless still be necessary since the format of changeset ticket comments differs between Trac 0.11 and 0.12.

[dnedelchev]

If both tracopt and the plugin are active nothing dangerous happens, just some "spam" is added since the ticket comments are updated twice - one comment is added by tracopt and another one - by the plugin. So you don't have to check if tracopt is active (I even think else it would be another restriction for the user).

I prefer using tracopt to update tickets and the plugin - only for the Repository Changesets list box because I always can reformat tracopt's ticket comment messages and migrate to the plugin (for ticket comments too). But (at least for now) I'm unable to do reformatting in the opposite direction (i.e. migrate back from plugin to tracopt). Also there probably is a chance that the plugin (since it's maybe a one-man-project) occasionally may not be updated for a long time, while tracopt (being a part of the Trac project) probably will be supported predictably steady. If it happens I eventually may be forced not to use any new related tracopt functionality (or at least to use it on the price of the so generated comment-duplication spam)

I had neglected the Trac 0.11/0.12 comment formatting difference. As you've improved the original tracopt code, it really looks highly preferable the Trac project to accept your contribution.
I think it even would be best if they accept and integrate not only ticke-comment-update improved functionality and trac-admin commands but also the changesets list box... i.e. the whole plugin!

Best Regards, Dimitar.

[dnedelchev]

Talking about minimizing of spam generated by Trac system, I'd go a bit further...
Yet another reason to take Ticket-Comment-Update code improvements integrated back in tracopt:

If one day TracBacksPlugin is also integrated in Trac, then it would be possible to avoid some extra generated spam.
If the commit message contains reference commands to more than one ticket, for example:

...
Fixed #33, see #37, #38, #21, #28
...

A commit-message-quotation comment is added to any of these tickets.
And then what TracBacksPlugin does now?
It guileless adds a number of extra comments (4 for the example) to each ticket in the form of:

This ticket has been referenced in ticket #XX:
> ''[YY]:{{{#CommitMessage revision="YY"...Fixed #33, see #37, #38, #21, #28...''

And if e-mail notification is used (most often) extra e-mail is sent for each extra message too...
If TracBacksPlugin knew that this information was already added to a ticket, this multiplication could be avoided. (I know, it's not always so simple and there are some things to be considered though)

[Mikael Relbe]

(In [10003]) TracTicketChangeSetsPlugin: Fixed #7529: Option NOT to update tickets comments (while Ticket-Changesets-List-Box unique functionality is active)

New option ticket_comments controls whether ticket comments are added or not, based on changeset info:

[ticket-changesets]
ticket_comments = true