Modify

Opened 6 years ago

Closed 3 years ago

Last modified 21 months ago

#3753 closed enhancement (fixed)

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

Reported by: butterflow Owned by: 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 (0)

Change History (30)

comment:1 Changed 6 years ago by butterflow

  • Cc butterflow added

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 5 years ago by rjollos

  • Summary changed from Carry over tags from PageTemplstes/ to Carry over tags from PageTemplates/

comment:3 follow-up: Changed 5 years ago by AdrianFritz

  • Priority changed from normal to high

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

comment:4 Changed 5 years ago by anonymous

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

comment:5 Changed 4 years ago by AdrianFritz

  • Owner changed from athomas to otaku42

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

comment:6 Changed 4 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 3 years ago 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.

comment:8 Changed 3 years ago by hasienda

  • Owner changed from otaku42 to hasienda
  • Status changed from new to assigned

Test results and comment to me please.

comment:9 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by hasienda

  • Cc rjollos otaku42 added

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.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 3 years ago 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

comment:11 Changed 3 years ago by AdrianFritz

previuos reply was me. Adrian

comment:12 Changed 3 years ago by AdrianFritz

on previous comment should have shown for the texts

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

comment:13 in reply to: ↑ 10 Changed 3 years ago 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.

comment:14 follow-up: Changed 3 years ago 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.

comment:15 in reply to: ↑ 14 ; follow-up: Changed 3 years ago 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).

comment:16 in reply to: ↑ 15 ; follow-up: Changed 3 years ago 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?

comment:17 Changed 3 years ago 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.

comment:18 in reply to: ↑ 16 Changed 3 years ago 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.

comment:19 Changed 3 years ago by hasienda

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

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

comment:20 Changed 3 years ago 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.

comment:21 Changed 3 years ago by luizfernando

  • Resolution set to fixed
  • Status changed from assigned to 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: Changed 3 years ago 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.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 3 years ago 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.

comment:24 in reply to: ↑ 23 ; follow-up: Changed 3 years ago 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.

comment:25 Changed 3 years ago by AdrianFritz

Thank you for the resolution hasienda. Nice work!!

Adrian

comment:26 in reply to: ↑ 22 ; follow-up: Changed 3 years ago 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

comment:27 in reply to: ↑ 24 ; follow-up: Changed 3 years ago 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.

comment:28 in reply to: ↑ 26 Changed 3 years ago 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.

comment:29 in reply to: ↑ 27 Changed 3 years ago 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?

comment:30 Changed 21 months ago 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 Comment

Modify Ticket

Action
as closed .
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.