Opened 9 years ago

Closed 6 years ago

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

Reported by: Owned by: JaeWook Choi Steffen Hoffmann high TagsPlugin normal tags page templates JaeWook Choi, Ryan J Ollos, Michael Renzmann 0.11

### Description

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.

### comment:1 Changed 9 years ago by JaeWook Choi

Cc: JaeWook Choi added; anonymous removed

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?

### comment:2 Changed 8 years ago by Ryan J Ollos

Summary: Carry over tags from PageTemplstes/ → Carry over tags from PageTemplates/

### comment:3 follow-up:  9 Changed 7 years ago by Adrian Fritz

Priority: normal → high

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

### comment:4 Changed 7 years ago by anonymous

Summary: Carry over tags from PageTemplates/ → TagIt macro - Carry over tags from PageTemplates/

### comment:5 Changed 7 years ago by Adrian Fritz

Owner: changed from Alec Thomas to Michael Renzmann

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

### comment:6 Changed 7 years ago by 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

### comment:7 Changed 6 years ago by 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.

### comment:8 Changed 6 years ago by Steffen Hoffmann

Owner: changed from Michael Renzmann to Steffen Hoffmann new → assigned

Test results and comment to me please.

### comment:9 in reply to:  3 ; follow-up:  10 Changed 6 years ago by Steffen Hoffmann

Cc: Ryan J Ollos Michael Renzmann added

+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.

### comment:10 in reply to:  9 ; follow-up:  13 Changed 6 years ago by anonymous

+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:

Steps:

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

### comment:12 Changed 6 years ago by Adrian Fritz

on previous comment should have shown for the texts

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

### comment:13 in reply to:  10 Changed 6 years ago by Steffen Hoffmann

+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

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.

### comment:14 follow-up:  15 Changed 6 years ago by 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.

### comment:15 in reply to:  14 ; follow-up:  16 Changed 6 years ago by Adrian Fritz

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).

### comment:16 in reply to:  15 ; follow-up:  18 Changed 6 years ago by Steffen Hoffmann

![...] 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?

### comment:17 Changed 6 years ago by Steffen Hoffmann

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

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

### comment:18 in reply to:  16 Changed 6 years ago by Luiz Fernando

![...] 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.

### comment:19 Changed 6 years ago by Steffen Hoffmann

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

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

### comment:20 Changed 6 years ago by 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.

### comment:21 Changed 6 years ago by Luiz Fernando

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

### comment:22 follow-ups:  23  26 Changed 6 years ago by 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.

### comment:23 in reply to:  22 ; follow-up:  24 Changed 6 years ago by Ryan J Ollos

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.

### comment:24 in reply to:  23 ; follow-up:  27 Changed 6 years ago by Michael Renzmann

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.

### comment:25 Changed 6 years ago by Adrian Fritz

Thank you for the resolution hasienda. Nice work!!

### comment:26 in reply to:  22 ; follow-up:  28 Changed 6 years ago by Adrian Fritz

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 :-)

### comment:27 in reply to:  24 ; follow-up:  29 Changed 6 years ago by Ryan J Ollos

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.

### comment:28 in reply to:  26 Changed 6 years ago by Steffen Hoffmann

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.

### comment:29 in reply to:  27 Changed 6 years ago by Steffen Hoffmann

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?

### comment:30 Changed 5 years ago by 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.

### Modify Ticket

Change Properties