Ticket #3753 (closed enhancement: fixed)

Opened 5 years ago

Last modified 6 months ago

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

Reported by: butterflow Assigned to: hasienda
Priority: high Component: TagsPlugin
Severity: normal Keywords: tags page templates
Cc: butterflow, rjollos, otaku42 Trac Release: 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.

Attachments

Change History

09/25/08 16:50:07 changed by butterflow

  • cc set to butterflow.

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?

08/04/09 02:11:29 changed by rjollos

  • summary changed from Carry over tags from PageTemplstes/ to Carry over tags from PageTemplates/.

(follow-up: ↓ 9 ) 02/07/10 19:31:51 changed by AdrianFritz

  • priority changed from normal to high.

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

02/08/10 17:19:40 changed by anonymous

  • summary changed from Carry over tags from PageTemplates/ to TagIt macro - Carry over tags from PageTemplates/.

03/05/10 01:47:56 changed by AdrianFritz

  • owner changed from athomas to otaku42.

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

10/07/10 01:08:14 changed by vchoi@vchoi.org

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

08/28/11 17:24:28 changed by hasienda

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

08/28/11 17:25:19 changed by hasienda

  • status changed from new to assigned.
  • owner changed from otaku42 to hasienda.

Test results and comment to me please.

(in reply to: ↑ 3 ; follow-up: ↓ 10 ) 08/28/11 17:32:01 changed by hasienda

  • cc changed from butterflow to butterflow, rjollos, otaku42.

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.

(in reply to: ↑ 9 ; follow-up: ↓ 13 ) 08/31/11 04:53:02 changed by 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:

Steps:

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

08/31/11 04:54:01 changed by AdrianFritz

previuos reply was me. Adrian

08/31/11 04:57:06 changed by AdrianFritz

on previous comment should have shown for the texts

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

(in reply to: ↑ 10 ) 08/31/11 06:28:30 changed by hasienda

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.

(follow-up: ↓ 15 ) 08/31/11 06:31:33 changed by 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.

(in reply to: ↑ 14 ; follow-up: ↓ 16 ) 08/31/11 15:29:22 changed by AdrianFritz

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

(in reply to: ↑ 15 ; follow-up: ↓ 18 ) 08/31/11 21:46:17 changed by 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?

09/24/11 23:28:27 changed by hasienda

  • summary changed from TagIt macro - Carry over tags from PageTemplates/ to Carry over tags from PageTemplates/ (was: TagIt macro).

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

(in reply to: ↑ 16 ) 10/11/11 21:42:44 changed by luizfernando

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.

10/11/11 23:30:02 changed by hasienda

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

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

10/13/11 01:42:03 changed by hasienda

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

10/13/11 21:58:14 changed by luizfernando

  • status changed from assigned to closed.
  • resolution set to fixed.
  • It's working! Tested with two tags.
  • Thank you very much hasienda for your time and availability! Closing this issue..

(follow-ups: ↓ 23 ↓ 26 ) 10/13/11 23:24:46 changed by hasienda

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.

(in reply to: ↑ 22 ; follow-up: ↓ 24 ) 10/14/11 09:48:21 changed by rjollos

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.

(in reply to: ↑ 23 ; follow-up: ↓ 27 ) 10/14/11 11:17:32 changed by otaku42

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.

10/14/11 20:48:27 changed by AdrianFritz

Thank you for the resolution hasienda. Nice work!!

Adrian

(in reply to: ↑ 22 ; follow-up: ↓ 28 ) 10/14/11 20:50:56 changed by AdrianFritz

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

(in reply to: ↑ 24 ; follow-up: ↓ 29 ) 10/14/11 21:46:30 changed by rjollos

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.

(in reply to: ↑ 26 ) 10/15/11 00:24:48 changed by hasienda

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.

(in reply to: ↑ 27 ) 10/15/11 00:32:31 changed by hasienda

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?

11/27/12 00:57:07 changed by hasienda

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

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




Change Properties
Action