Carry over tags from PageTemplates/ (was: TagIt macro)

[JaeWook Choi]

Is it possible to carry over tags from PageTemplates/ to the wiki page which is being created from the specific template page? This will unburden a trivia of repeatedly typing set of tags to newly created wiki page every time as new wiki page can highly likely to share the same set of tags from the template page used.

[JaeWook Choi]

I found [[TagIt()]] macro being used here and there in trac-hacks, however the macro had been deprecated from TagsPlugin. I believe using [[TagIt()]] macro in PageTemplates/ will allow tags to be carried over to new wiki page from page template selected by user. Is it possible to reincarnate [[TagIt()]] macro?

[Adrian Fritz]

+1 looking for this to be reimplemented. Someone knows the background why this functionality was deprecated?

[Adrian Fritz]

Reassign to new maintainer. :-) This macro still works at TH, does it?

[vchoi@…]

On my trac it doesn't work:

Error: Failed to load processor TagIt

No macro or processor named 'TagIt' found

+1 looking for this to be reimplemented

[Steffen Hoffmann]

(In [10623]) TagsPlugin: Copy tags from template to new wiki page, refs #3753.

This is a rather old feature request, but a pretty basic and intuitive one that I always expected to get resolved. So now I try as straight as possible.

[Steffen Hoffmann]

Test results and comment to me please.

[Steffen Hoffmann]

Replying to AdrianFritz:

+1 looking for this to be reimplemented. Someone knows the background why this functionality was deprecated?

Sorry, dunno, but anyway, test the new solution, if you still care, please.

[anonymous]

Replying to hasienda:

Replying to AdrianFritz:

+1 looking for this to be reimplemented. Someone knows the background why this functionality was deprecated?

Sorry, dunno, but anyway, test the new solution, if you still care, please.

Did not work jet.

Tested on Trac 0.12.0 (on Ubuntu, PG as datadase), tested strings below:

• wiki field: TagIt(OneTag SecondTag LastTag)?
• wiki: TagIt()?
  • plus this in tag field: OneTag SecondTag LastTag

Steps:

1. populated wiki PageTemplates/Sample with below sentences
2. created a new wiki page using template

[Adrian Fritz]

previuos reply was me. Adrian

[Adrian Fritz]

on previous comment should have shown for the texts

• wiki field: [[TagIt(OneTag SecondTag LastTag)]]
• wiki: [[TagIt()]]

[Steffen Hoffmann]

Replying to anonymous:

Replying to hasienda:

Replying to AdrianFritz:

+1 looking for this to be reimplemented. Someone knows the background why this functionality was deprecated?

Sorry, dunno, but anyway, test the new solution, if you still care, please.

Did not work jet.

Not this way, yes I know. Change your view please.

Tested on Trac 0.12.0 (on Ubuntu, PG as datadase), tested strings below:

• wiki field: [[TagIt(OneTag SecondTag LastTag)]]
• wiki: [[TagIt()]]
  • plus this in tag field: OneTag SecondTag LastTag

Steps:

1. populated wiki PageTemplates/Sample with below sentences
2. created a new wiki page using template

Sorry, if I wasn't clear enough right from the start: Why not just tag your templates as you do now with any wiki page - without using TagIt? This has been implemented and tested to work by me.

Thanks anyway for taking care. I'm looking forward to hear from you about further tests.

[Steffen Hoffmann]

As a side-note: Why would you really need TagIt back? What is the unique functionality? I didn't get that by now, never used it. At least tagging templates (preparing tags for new pages) is done without it.

[Adrian Fritz]

Replying to hasienda:

As a side-note: Why would you really need TagIt back? What is the unique functionality? I didn't get that by now, never used it. At least tagging templates (preparing tags for new pages) is done without it.

Besides standard "tags" usage, the idea is to automatize newly created wiki page with tags (even having wrote in instructions to full fill tags field accordingly to a template with a specific set of tags, we forget doing that).

[Steffen Hoffmann]

Replying to AdrianFritz:

Replying to hasienda:

![...] What is the unique functionality? ![...]

Besides standard "tags" usage, the idea is to automatize newly created wiki page with tags (even having wrote in instructions to full fill tags field accordingly to a template with a specific set of tags, we forget doing that).

Ok, you should be able to do this by tagging the template (instead of adding a macro to it) now. I even feel like the [TagIt] macro was more a hack to the hack in absence of a direct tag copy, that is available with r10623. So does that revision work for you this way?

[Steffen Hoffmann]

Make the way to go even clearer from the title as well.

[Luiz Fernando]

Replying to hasienda:

Replying to AdrianFritz:

Replying to hasienda:

![...] What is the unique functionality? ![...]

Besides standard "tags" usage, the idea is to automatize newly created wiki page with tags (even having wrote in instructions to full fill tags field accordingly to a template with a specific set of tags, we forget doing that).

Ok, you should be able to do this by tagging the template (instead of adding a macro to it) now. I even feel like the [TagIt] macro was more a hack to the hack in absence of a direct tag copy, that is available with r10623. So

does that revision work for you this way?

Hi.. I work with AdrianFritz. Just installed the trunk latest revision - r10754. The tags are being copied from the template, however in a wrong way.

Ex.: tag1 tag2 in the template tag field becomes [u'tag1', u'tag2'] in the newly created page. Any clues of what is happening? Thank you.

[Steffen Hoffmann]

Ok, obviously not tried with multiple tags by now, sorry.

Thanks for mentioning this. I'll try to fix it soon.

[Steffen Hoffmann]

(In [10764]) TagsPlugin: Fix tags copy from template to new wiki page, refs #3753.

Now this should be safe for wiki templates tagged with any number of tags.

While testing I recognized, that the wiki_page_renamed method of WikiTagInterface called a non-existing TagSystem method. Fixed that and a debug message for reporting retrieved tags as well.

[Luiz Fernando]

• It's working! Tested with two tags.
• Thank you very much hasienda for your time and availability! Closing this issue..

[Steffen Hoffmann]

Thank you too for verification. Obviously you've been the first to test this feature.

Btw, I've accustomed the habit of closing tickets only on availability in an official release. Keep it like that here - just note for future actions. I've already referenced this ticket under resolved issues for tractags-0.7 release (see changelog​). All tickets there will get closed on release time.

[Ryan J Ollos]

Replying to hasienda:

Btw, I've accustomed the habit of closing tickets only on availability in an official release. Keep it like that here - just note for future actions.

That seems like a good idea. It would be nice to see at a glance though which tickets were resolved on the trunk when viewing the existing bugs and feature requests. Since we aren't able to add custom fields to the ticket form, the best idea I have for that is to do something like change the summary by adding a [0.7] once the issue is believed to be resolved on the trunk.

[Michael Renzmann]

Replying to rjollos:

Since we aren't able to add custom fields to the ticket form,

Please specify what you have in mind for such a custom field. If it's possible to "generalize" it (so that it could be of use for all other hacks hosted here), we could talk about adding it.

[Adrian Fritz]

Thank you for the resolution hasienda. Nice work!!

Adrian

[Adrian Fritz]

Replying to hasienda:

Btw, I've accustomed the habit of closing tickets only on availability in an official release. Keep it like that here - just note for future actions....

Sorry my fault. I asked Luiz to close it since it was tested. We now know what to do next time :-)

Adrián

[Ryan J Ollos]

Replying to otaku42:

Please specify what you have in mind for such a custom field. If it's possible to "generalize" it (so that it could be of use for all other hacks hosted here), we could talk about adding it.

My thought was, that if the only purpose of this Trac site was for development of the TagsPlugin, we could probably add a drop-down list "Fixed In" or use the milestone field to indicate what revision it was fixed in.

To generalize it within the constraints of the existing Trac-hack's site, I guess we could add a step to the workflow, but I worry that a change like this would confuse others. If I was following the policy of closing tickets only on next release for one of the projects I maintain, I'd probably just add something to the summary to indicate that it's fixed for the upcoming release.

[Steffen Hoffmann]

Replying to AdrianFritz:

Sorry my fault. I asked Luiz to close it since it was tested. We now know what to do next time :-)

Caused no problem, really. And thanks for the encouraging comments to both of you. You're welcome.

[Steffen Hoffmann]

Replying to rjollos:

My thought was, that if the only purpose of this Trac site was for development of the TagsPlugin, we could probably add a drop-down list "Fixed In" or use the milestone field to indicate what revision it was fixed in.

Not a dropdown please, but I was thinking about the milestone to indicate work on a ticket too. OTOH we go along without additional fuzz of milestone administration happily today.

Would it be possible to have a simple worked_on_in_changeset custom text field with .format=wiki to get a click-able link to that changeset in the ticked view?

[Steffen Hoffmann]

(In [12390]) TagsPlugin: Don't use tags on wiki templates for anything else than copying tags, refs #3753 and #9636.

Once again this has been reported by Itamar Ostricher. Thank you very much for nudging me to fix it.