Features for next version of plugin

[Ryan J Ollos]

Here are some thoughts I have on the next version of the plugin, from reviewing the codebase over the weekend:

1. Create a ticket-changeset relation table. The table would be populated by implementing IRepositoryChangeListener. It looks like the original author had similar ideas: tracticketchangelogplugin/0.12/ticketlog/model.py@13954​ is currently unused. This should make the plugin faster, and extraction of the referenced tickets from the changeset message can be made more precise since we won't have to use a LIKE clause in the query (see next item). => #12620.
2. The configuration settings of CommitTicketUpdater can be used to determine which tickets are referenced by a changelog message, rather than redefining redundant configuration settings. The CommitTicketUpdater configuration settings can be seen on the TracIni#ticket-section page: commit_ticket_update_commands.close, commit_ticket_update_commands.refs, commit_ticket_update_envelope, ... We might even want to subclass CommitTicketUpdater so that we can reuse the message parsing code, which should be more robust and will allow us to fix #7884 and maybe #8428. => #12621
3. Remove TICKETLOG_VIEW permission (as well as the unused TICKETLOG_EDIT and TICKETLOG_ADMIN). TICKETLOG_VIEW appears to be redundant with LOG_VIEW if the purpose is to control the ability to view a resource. TICKETLOG_VIEW would provide the ability to control whether the log is present for some users, but I'm not sure this is needed. We would probably be better off showing the log to all users with LOG_VIEW, but having it be initially collapsed so it is out of the way. If greater control is needed to tune this to user preferences, we can follow the lead of ​trac:#9807 by implementing a user preference on the Preferences panel.
4. Add an HTML template for the changelog section. Currently the HTML is constructed in JavaScript. We can probably use an ITemplateStreamFilter to insert the HTML and avoid the need for JavaScript entirely (provided there are no performance issues with Genshi).

[Steffen Hoffmann]

A few comments regarding no. 3 (1-2 are indisputable fine): I see a use case for keeping at least one of edit and admin permissions for corrective edits on-top of commit messages, where doing it in the repository would be practically unfeasible (big SVN repo) or impossible (HG). Third opinion is reasonable again and shouldn’t be too hard to implement.

[Ryan J Ollos]

Replying to hasienda:

A few comments regarding no. 3 (1-2 are indisputable fine): I see a use case for keeping at least one of edit and admin permissions for corrective edits on-top of commit messages, where doing it in the repository would be practically unfeasible (big SVN repo) or impossible (HG).

That is a really nice idea that I never considered. Should we consider just implementing a feature directly in Trac that allows repository messages to be edited through the changeset view and/or log view (I imagine there is a ticket open somewhere in Trac for that feature).

For Subversion this would require that the appropriate hooks be configured (pre-revprop-change and post-revprop-change). Are you saying that large Subversion repositories have performance issues when trying to edit commit messages, or rather that it is just difficult to edit many messages when working with a large Subversion repository and the existing tools? Commit messages can't be edited in Hg?

Allowing edits through Trac would, with changes to the database schema, allow versioning of the commit messages, a feature that has always been lacking from Subversion.

Thanks for the feedback!

[anonymous]

Replying to rjollos:

Should we consider just implementing a feature directly in Trac that allows repository messages to be edited through the changeset view and/or log view (I imagine there is a ticket open somewhere in Trac for that feature).

​t:ticket:781?

[Steffen Hoffmann]

Replying to anonymous:

Replying to rjollos:

Should we consider just implementing a feature directly in Trac that allows repository messages to be edited through the changeset view and/or log view (I imagine there is a ticket open somewhere in Trac for that feature).

​t:ticket:781?

I think so, especially note ​comment 24 of that ticket, that among other things answers the question regarding Hg, which has immutable messages indeed.

[anonymous]

Replying to rjollos:

Commit messages can't be edited in Hg?

Just like in Git, commit messages are part of the changeset hash, so commit messages of public changesets are not supposed to be edited. For private / draft changesets you can use commit --amend to edit history (again just like in Git). (HG changeset evolution will use obsolescence markers to show relations between such amended changesets and their precursors, and help with evolving affected child changesets.)

[Ryan J Ollos]

Replying to rjollos:

1. Create a ticket-changeset relation table. The table would be populated by implementing IRepositoryChangeListener.

This might also allow us to support repositories that are not cached (comment:16:ticket:8428).

[Ryan J Ollos]

tracticketchangelogplugin/1.0​ branch created in [14180] for development of next major version of this plugin.

[Ryan J Ollos]

In 14182:

1.0dev: Style Commit History section like the other sections (Attachments, Change History, ...). Refs #11821.

[Ryan J Ollos]

Unintended change to 0.12 branch in [14182] reverted in [14183].

[Ryan J Ollos]

In 14186:

1.0dev: Append table of revisions in an ITemplateStreamFilter call rather than an AJAX callback.

The Change History is initially collapsed.

Refs #11821.

[Ryan J Ollos]

Replying to rjollos:

4. Add an HTML template for the changelog section. Currently the HTML is constructed in JavaScript. We can probably use an ITemplateStreamFilter to insert the HTML and avoid the need for JavaScript entirely (provided there are no performance issues with Genshi).

This change is implemented on the tracticketchangelogplugin/1.0​ branch. Next I'll work on adding the ticket-changeset relation table.

[Ryan J Ollos]

In 14187:

1.0dev/i18n: New extraction. Refs #11821.

[Ryan J Ollos]

In 14191:

1.0dev: Show number of entries next to Commit History heading. Refs #11821.

[Ryan J Ollos]

In 14194:

1.0dev: Hide table and show (No commits) message when there are no commits associated with the ticket..Refs #11821.

[Ryan J Ollos]

In 14195:

1.0dev: Added license headers to template files. Refs #11821.

[Ryan J Ollos]

In 14227:

1.0dev: Require LOG_VIEW permission to view the ticket log and remove definition of TICKETLOG_* permssions..Refs #11821.

[Ryan J Ollos]

In 14228:

1.0dev: Implement fine-grained permission checks..Refs #11821.

Granting LOG_VIEW for the ticket realm is equivalent to granting the TICKETLOG_VIEW permission that existed in previous versions of the plugin.

[Ryan J Ollos]

Refocusing.

[Cinc]

Replying to rjollos:

In 14186:

1.0dev: Append table of revisions in an ITemplateStreamFilter call rather than an AJAX callback.

The Change History is initially collapsed.

Refs #11821.

Adding the commit log in ITemplateStreamFilter may not be a great idea here. I just created ticket #12265 to address page/browser freeze because of slow commit log parsing. In my environment preparing the revisions for a ticket may need up to 20 seconds which is why an asynchronous AJAX call (note the 'asynchronous') is a life saver for us.

[Ryan J Ollos]

The changes in this ticket are work in progress. The performance constraint will be addressed by item (1) in comment:description.

Similar issue was reported in ​gmessage:trac-users:zL1Py9zpsj4/UxPOI5Tnk64J.

[Ryan J Ollos]

#12436 closed as a duplicate. Item (2) in comment:description will address the general issue.

[anonymous]

When will these changes be implemented?

[Ryan J Ollos]

(3) and (4) from comment:description have been implemented. Created #12620 and #12621 to address items (1) and (2).

[Ryan J Ollos]

Replying to anonymous:

When will these changes be implemented?

Implemented now on the 1.2 branch​. You'll need to be running at least Trac 1.2.x.

[Ryan J Ollos]

In 16847:

TracTicketChangelogPlugin 1.0.1: Require CHANGESET_VIEW

This revises r14227, as CHANGESET_VIEW is more appropriate
than LOG_VIEW.

Refs #11821.

[Ryan J Ollos]

In 16848:

TracTicketChangelog 1.2.0dev: Require CHANGESET_VIEW

This revises r14227, as CHANGESET_VIEW is more appropriate
than LOG_VIEW.

Refs #11821.