Reusable commenting module

[Peter Suter]

Trac so far only supports comments on tickets, but not on other resources like:

• Wiki pages (#4279)
• Changesets (#2035)
• Source files
• Attachments
• Milestones
• Resources provided by external plugins

I would like to implement a reusable comment module, that (similar to the existing attachment module) allows us (and plugin writers) to easily add a commenting feature to all kinds of resources.

Existing plugins

​th:AddCommentMacro, ​th:WikiCommentsPlugin, ​th:CodeCommentsPlugin, various CodeReview plugins

Related previous ideas

AdvancedWikiOperations, DataModel, TracObjectModelProposal, ContextRefactoring, GenericTrac, GenericTrac/Brainstorm, CodeReview/Annotations

[Peter Suter]

A first prototype for discussion in log:psuter.git:t11676 starts with a rather basic implementation, and then uses that in the wikipage and milestones modules as two first example use cases.

(When we agree on the general idea, more work is needed to add missing features like preview, editing, sorting modes, etc.)

Please let me know what you think.

[Ryan J Ollos]

It looks pretty nice and useful. I'll continue looking at the code, but the immediate question I have is how permissions should be handled. It seems like the permissions should be realm-based. Would something that parallels LegacyAttachmentPolicy make sense?

One really small thing, after #11512 you can use DatabaseManager.create_tables in the upgrade step: trunk/trac/db/api.py@12926:312#L306​

[Peter Suter]

Replying to rjollos:

It seems like the permissions should be realm-based. Would something that parallels LegacyAttachmentPolicy make sense?

Yes, it should be easy to follow the same design (including an equivalent of ILegacyAttachmentPolicyDelegate) if desired. I'm not against this, and initally planned to do so, but was unsure because of the term Legacy. ​The initial rationale behind this mechanism suggested maybe fine grained AuthzPolicy rules can now be used instead.

you can use DatabaseManager.create_tables in the upgrade step

Thanks for the pointer!

[Ryan J Ollos]

Replying to psuter:

Yes, it should be easy to follow the same design (including an equivalent of ILegacyAttachmentPolicyDelegate) if desired. I'm not against this, and initally planned to do so, but was unsure because of the term Legacy.

I had the same concern about Legacy, and need to take some time to understand the history and potential future plans better.

​The initial rationale behind this mechanism suggested maybe fine grained AuthzPolicy rules can now be used instead.

I recently noticed this comment about future plans for permission policies: trunk/trac/perm.py@12930:152-154#L117​.

[lkraav <leho@…>]

Are ticket comments going to be replaced by this module?

[Peter Suter]

Replying to lkraav <leho@…>:

Are ticket comments going to be replaced by this module?

I think it should not be an initial goal.

Not all resources have to use this reusable commenting module. It's just an option. Hopefully that option will often be "good enough". But if there are special requirements (as there may be with ticket comments) a special solution is appropriate.

It would be nice if at some point this is flexible and extensible enough to replace ticket comments, but it's not a big problem if it never does.

[lkraav <leho@…>]

There's probably no argument that it makes sense to have a singular uber CommentSystem over long term, right? And that the only problem we're facing here is the workload and available people? Prototyping the idea in a branch can definitely use whatever model to show the idea, but merges to the core should be forward-looking. Currently, we're looking at separate comment systems for tickets, @osimons fullblog and now this.

All of them are bound to have different user experiences and functionalities and a lot of duplication. Having no consistent UX across functionalities will always keep Trac from advancing in the world. But a consistent UX can only be built on a simple foundation, esp. with the low headcount we have.

Perhaps the tickets' comment system can be somehow re-used instead? Every wikipage's comment thread could very well have a ticket associated with it, although it may seem weird at first and can possibly introduce some other logic issues. But it would give us the full fine-tuned functionality and way to go forward for other modules, too.

This sort of goes into GenericTrac territory, but why couldn't a wikipage also be a ticket, just rendered differently? We'd then have to have a routing / permalink system that associates the wikipage name to the base object (artist formerly known as Ticket) ID. This is exactly how world's most popular CMS named WordPress works. Everything is a single "post" model which can be "subclassed", default installation has two post types pre-defined: "posts" (for blog) and "pages" (static info). Sounds like tickets and wikipages to me. This approach has taken 20+% of the world. How wrong can it be?

[Peter Suter]

Replying to lkraav <leho@…>:

There's probably no argument that it makes sense to have a singular uber CommentSystem over long term, right? And that the only problem we're facing here is the workload and available people?

I'm sure everyone prefers a unified system, but I think using specialized comment-like systems in certain subsystems is still "allowed" and can sometimes be preferable.

For example wikipages will still support one "comment" per version, not integrated with this commenting module.

The existing ticket comments are a similar in a way (one comment per ticket change). But they are also similar to the "pure" comments of this commenting module.

merges to the core should be forward-looking.

But a consistent UX can only be built on a simple foundation

And that's why I think we need to start "from scratch" with a simple forward-looking foundation.

Once we have that we can maybe see if the ticket comments can be replaced or "simulated" by the this commenting module plus some extensions that implement any ticket specific features. (But there's no urgency to do that in the same release. It's "just" code cleanup.)

[Ryan J Ollos]

Replying to psuter:

But a consistent UX can only be built on a simple foundation

And that's why I think we need to start "from scratch" with a simple forward-looking foundation.

I think your approach is a good one. Also, with regard to ​th:FullBlogPlugin, it could be a use-case to see if an existing plugin can be refactored to utilize the new module.

[lkraav <leho@…>]

Replying to psuter:

And that's why I think we need to start "from scratch" with a simple forward-looking foundation.

Once we have that we can maybe see if the ticket comments can be replaced or "simulated" by the this commenting module plus some extensions that implement any ticket specific features. (But there's no urgency to do that in the same release. It's "just" code cleanup.)

OK I like the general "starting a comment system" rethink idea here for sure. That may indeed be a faster path to The One And Only, compared to starting from TicketSystem's current comments component (no quality evaluation performed).

Yes, if osimons's stuff could be the first outside customer, that would indeed validate the idea well.

Extensible, opt-in way of implementing functionalities, such as comment edits and whatnot (stuff I was missing in ​th:FullBlogPlugin comments) - sounds awesome.