Modify

Opened 7 years ago

Closed 9 months ago

#2429 closed enhancement (fixed)

[Patch] TagsPlugin should handle versioning of wiki tags

Reported by: dkg Owned by: hasienda
Priority: normal Component: TagsPlugin
Severity: normal Keywords: wiki version
Cc: lbruno@…, rjollos, jun66j5 Trac Release: 0.11

Description

Currently, tags on wiki pages as implemented by TagsPlugin are either present or not, with no record of who added the tag, when it was added, or if it was removed. Since the tagging table only contains a (tagspace,name,tag) tuple, there doesn't seem to be room in the current implementation for even storing the "author" of a tag on a certain wiki page, its history, or its destruction.

This seems contrary to the wikinature of the rest of trac, and certainly leaves the tickets (with their automatically revision-tracked keywords) looking much healthier. I'm not sure how one would make the transition for existing systems, but could the TagsPlugin be moved to a more wiki-ish model?

Attachments (4)

patch_for_wiki_tag_versions.txt (2.5 KB) - added by watho 6 years ago.
20131028_wiki_tags_version-history_pre-view.png (39.9 KB) - added by hasienda 14 months ago.
preview at Trac 1.0 wiki change history view with tag revisions enabled
revision-support.patch (26.6 KB) - added by hasienda 14 months ago.
patch for an implementation of tag revisions (not only) for wiki pages
20131102-2318-meta-chars-in-tag.png (8.5 KB) - added by jun66j5 14 months ago.

Download all attachments as: .zip

Change History (36)

Changed 6 years ago by watho

comment:1 Changed 6 years ago by watho

  • Type changed from defect to enhancement

I want this feature too. As a first step i can provide a patch which creates a new version of the wiki page if only the tags have changed. So you can see who added or removed tags and when it was done.

Perhaps this helps.

MfG WaTho

comment:2 follow-up: Changed 6 years ago by lbruno@…

  • Cc lbruno@… added; anonymous removed

Thanks MfG, I'll be using that patch. I'll also have to make some kind of timeline provider.

comment:3 Changed 5 years ago by AdrianFritz

  • Owner changed from athomas to otaku42
  • Summary changed from TagsPlugin should handle versioning of wiki tags to [Patch] TagsPlugin should handle versioning of wiki tags

comment:4 Changed 2 years ago by hasienda

  • Cc hasienda added
  • Keywords wiki version added

comment:5 Changed 18 months ago by hasienda

  • Cc rjollos added; hasienda removed
  • Owner changed from otaku42 to hasienda

I wonder, if we really need a new wiki page version.

  1. Seems a bit overkill and too much overhead for a decent page and just some tags changing.
  2. Deleting wiki versions will have no easy way to restore previous tags, and I'm not sure, if this would even be desired under all circumstances.

An alternative model would be to introduce versions directly to the default tag store and weave tag revisions into wiki page history like done for attachment changes in ticket change history for a long time. Attachments are not versioned yet, but I feel that the concept could work with versions too. Thought?

comment:6 follow-up: Changed 18 months ago by dkgdkg

i like the idea of introducing versioning information (or just timestamps?) into the default tag store.

what if the tag store was expanded from:

  • tagspace
  • name
  • tag

to:

  • tagspace
  • name
  • tag
  • added_by
  • added_when
  • removed_by
  • removed_when

The "by"s refer to users, the "whens" are timestamps, and the "removed"s would initially be null.

you could make a view that matches the current default tag store just by selecting all rows where removed_when is null.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 14 months ago by hasienda

Replying to dkgdkg:

i like the idea of introducing versioning information (or just timestamps?) into the default tag store.

what if the tag store was expanded ...

I envision a separate db table rather then extending the current table. Among other things it would allow to switch versioning on/off per realm (you likely don't need it for tickets). There should be only one author column, and repeated adding and removing of the same tag should not cause history overwrites. A db schema similar to `ticket_change` would allow for that with a minimal primary key extension and lower column count.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 14 months ago by anonymous

Replying to hasienda:

I envision a separate db table rather then extending the current table. Among other things it would allow to switch versioning on/off per realm (you likely don't need it for tickets).

the tags for the ticketing system are all contained in the ticket keywords anyway, right? the tags table is only used for wiki pages.

There should be only one author column, and repeated adding and removing of the same tag should not cause history overwrites.

Ah right, my proposal was definitely flawed in that regard.

A db schema similar to `ticket_change` would allow for that with a minimal primary key extension and lower column count.

yep, i think this makes sense. if this was implemented, could we drop the tags table after an upgrade?

comment:9 in reply to: ↑ 8 Changed 14 months ago by hasienda

Replying to anonymous:

Replying to hasienda:

I envision a separate db table rather then extending the current table. Among other things it would allow to switch versioning on/off per realm (you likely don't need it for tickets).

the tags for the ticketing system are all contained in the ticket keywords anyway, right? the tags table is only used for wiki pages.

No and no. Ticket keywords are configurable in [tags] section of trac.ini via the 'ticket_fields' option. 'keywords' is only its default value. Could be any combination of ticket fields (custom fields not supported yet, see #2804). But I don't feel that this is relevant here.

Wiki is not the only other tag-able realm today, there are blog and screenshots, not to speak about tomorrow.

There should be only one author column, and repeated adding and removing of the same tag should not cause history overwrites.

Ah right, my proposal was definitely flawed in that regard.

No problem. We discuss to find the best way.

A db schema similar to `ticket_change` would allow for that with a minimal primary key extension and lower column count.

yep, i think this makes sense. if this was implemented, could we drop the tags table after an upgrade?

No. As with ticket_change this will be only for the change records. It make a great deal of flexibility to keep these information separate and only join tables on demand.

Version 0, edited 14 months ago by hasienda (next)

comment:10 Changed 14 months ago by dkgdkg

OK, makes sense to me. thanks for the followup and clarification. and thank you for your work on this!

comment:11 Changed 14 months ago by hasienda

You're welcome. I guess, that #11205 changed priority of this ticket significantly.

Changed 14 months ago by hasienda

preview at Trac 1.0 wiki change history view with tag revisions enabled

comment:12 Changed 14 months ago by hasienda

  • Cc jun66j5 added

I'll publish a patch for testing soon.

preview at Trac 1.0 wiki change history view with tag revisions enabled

Here is a preview on current look-and-feel of tags version tracking for wiki pages backed by new tags_change db table. Tag change info in comments mimics keywords field history style in tickets. Links behind stars in version column lead to the wiki page version the tag change has been recorded for. Comments welcome.

Changed 14 months ago by hasienda

patch for an implementation of tag revisions (not only) for wiki pages

comment:13 Changed 14 months ago by hasienda

Early adopters beware: This feature requires an additional db table. After installing a TagsPlugin version with this patch you'll need to upgrade your environment. Keep a backup for rolling back later on. Test reports are required to get it into next release tractags-0.7.

comment:14 Changed 14 months ago by hasienda

In 13428:

TagsPlugin: Introduce tag version recording, requires db upgrade, refs #2429.

This will especially help recovering tags after SPAM tagging, refs #11205.
Therefore configurable behavior enables tracking of wiki page tag changes, but
excludes ticket keywords changes by default.

comment:15 Changed 14 months ago by hasienda

In 13430:

TagsPlugin: Optimize tag change transactions, refs #2429.

Calculate effective differences instead of dumb delete-and-insert.
Additionally tag change recordes are removed now on resource destruction.

Changed 14 months ago by jun66j5

comment:16 follow-up: Changed 14 months ago by jun66j5

I've tried it.

If wiki meta characters is uses in tag, those characters would explain as wiki in history view. I guess we should use ITemplateStreamFilter.filter_stream api.

  1. Add 1.0 [{{{}}}] bar foo foobar plugin as tag
  2. Replace the tags with abc**def bar baz foo

Also, the old version wiki view shows always the latest tags.

comment:17 in reply to: ↑ 16 ; follow-up: Changed 14 months ago by hasienda

Replying to jun66j5:

If wiki meta characters is uses in tag, those characters would explain as wiki in history view. I guess we should use ITemplateStreamFilter.filter_stream api.

I see. What you guess, is to escape these characters to keep them visible verbatim instead of interpreted as wiki syntax, right? I'll look into it.

Also, the old version wiki view shows always the latest tags.

I confess, that it even was intentional to not create real, revertible tag revisions at once. The change recording at least is complete, and more functionality could be added from there on as we see the need. But as the '*' suggests, re-tagging does not create a new wiki page revision. So when there is no such hard connection, is it really good to rollback younger tag changes for viewing older wiki page versions?

Of course there is always at least an order by change time. There are even more issues, like line truncating, so larger change sets are not displayed in full. Not that I would ignore it, I'm just unsure, if I can handle this all too soon.

comment:18 in reply to: ↑ 17 Changed 14 months ago by jun66j5

Replying to hasienda:

If wiki meta characters is uses in tag, those characters would explain as wiki in history view. I guess we should use ITemplateStreamFilter.filter_stream api.

I see. What you guess, is to escape these characters to keep them visible verbatim instead of interpreted as wiki syntax, right? I'll look into it.

Sorry, I've tried it and it's difficult to solve using filter_stream. But I found the workaround to replace wiki_to_oneline, 33babfb.

Also, the old version wiki view shows always the latest tags.

Proposed changes can be found in f41d59c. The changes add tags_version parameter to query string in history view. The old tags for wiki page are searched by tags_version or version parameter.

https://github.com/jun66j5/trac-tagsplugin/compare/ticket2429.

comment:19 follow-up: Changed 14 months ago by hasienda

The majority of the recent 7 proposed changes look just fine to me. I've commented them accordingly and invite you kindly to apply them - folded to 6 changes - to trunk here as well.

Obviously you don't see the need for my "tags change record composition" string. So it is not required for extra flexibility in some languages, isn't it? I thought giving a fixed positional order would be bad, but you do so by appending to the comment in your changeset 33babfb150e8aef86dedca63a27c2d3471d10513.

Thank you very much for these contributions to refine the new feature. I'll update message catalogs after application of these patches to adapt to the i18n-related changes in there.

comment:20 in reply to: ↑ 19 ; follow-up: Changed 14 months ago by jun66j5

Obviously you don't see the need for my "tags change record composition" string. So it is not required for extra flexibility in some languages, isn't it?

Indeed. You're right. I've updated ticket2429 branch based on your suggestions, and included some refactoring.

comment:21 Changed 12 months ago by hasienda

It did isolated test of most of your changes by now, and I left my comments at GitHub. Would be great to have your contributions in trunk for the next release to come. Thanks for taking all the precious time to hack it.

comment:22 in reply to: ↑ 20 ; follow-up: Changed 10 months ago by hasienda

Replying to jun66j5:

Obviously you don't see the need for my "tags change record composition" string. So it is not required for extra flexibility in some languages, isn't it?

Indeed. You're right. I've updated ticket2429 branch based on your suggestions, and included some refactoring.

Just for clarity: I have finished the review with comment on afbcd4d in December, and I would appreciated, if you find the time to commit these latest changes to plugin's trunk branch yourself. If not, I would do it myself in fewer, but still isolated changesets for

  • new RequestsProxy class,
  • new private methods in wiki tag provider,
  • method signature extension for setting time stamp explicitly and
  • other fixes.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 10 months ago by jun66j5

Just for clarity: I have finished the review with comment on afbcd4d in December, and I would appreciated, if you find the time to commit these latest changes to plugin's trunk branch yourself. If not, I would do it myself in fewer, but still isolated changesets for

  • new RequestsProxy class,
  • new private methods in wiki tag provider,
  • method signature extension for setting time stamp explicitly and
  • other fixes.

Sorry for delay. Thanks for reviewing. I'll push proposed changes to trunk as 0.7 within a few days.

comment:24 Changed 10 months ago by jun66j5

In 13719:

TagsPlugin: small tweaks (refs #2429)

  • iterate directly cursor rather than cursor.fetchall()
  • remove redefined to_datetime in tractags.model
  • prevent calling strip() twice in split_into_tags()

comment:25 Changed 10 months ago by jun66j5

In 13720:

TagsPlugin: prevent interpreting tagging comment as wiki in wiki history view (refs #2429)

comment:26 Changed 10 months ago by jun66j5

In 13721:

TagsPlugin: shows versioned tags for versioned wiki page (refs #2429)

comment:27 Changed 10 months ago by jun66j5

In 13723:

TagsPlugin: added tagn_ api which has tag_ and ngettext features, also tagn_ is one of extract keywords, now (refs #2429)

comment:28 Changed 10 months ago by jun66j5

In 13724:

TagsPlugin: store modified time of wiki page to tags_change.time when page is created and modified using request instance which is saved in threading.local (refs #2429)

comment:29 in reply to: ↑ 23 ; follow-up: Changed 10 months ago by jun66j5

Sorry for delay. Thanks for reviewing. I'll push proposed changes to trunk as 0.7 within a few days.

The changes have been committed. Thanks.

comment:30 in reply to: ↑ 29 Changed 10 months ago by hasienda

Replying to jun66j5:

Sorry for delay. Thanks for reviewing. I'll push proposed changes to trunk as 0.7 within a few days.

The changes have been committed. Thanks.

No, it's my pleasure to thank you for your dedication to make this feature complete. Now I feel confident to roll this new release. With this feature and substantial performance improvements this will become a remarkable milestone. I love to develop with such great co-contributors.

comment:31 in reply to: ↑ 2 Changed 9 months ago by rjollos

Replying to lbruno@…:

Thanks MfG, I'll be using that patch. I'll also have to make some kind of timeline provider.

I've created a new ticket for the timeline provider: #11661.

comment:32 Changed 9 months ago by hasienda

  • Resolution set to fixed
  • Status changed from new to closed

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.

Add Comment

Modify Ticket

Action
as closed The owner will remain hasienda.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.