Modify

Opened 16 years ago

Last modified 6 years ago

#3816 new enhancement

[Patch] Offer all keywords used up to now for selection

Reported by: rupert thurner Owned by:
Priority: normal Component: KeywordSuggestPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

it would be nice to offer all keywords used up to now for selection, not only the ones specified in the config file.

Attachments (4)

KeywordSuggestPluginPatch.tar.gz (1.7 KB) - added by carstenklein@… 15 years ago.
The "patch" to the KeywordSuggestPlugin (keywordsuggest.py)
keywordsuggest.py.tar.gz (1.7 KB) - added by carstenklein@… 15 years ago.
corrected version of the patch, the former did fail when fromdb was set to false
patch_against_trunk.diff (1.8 KB) - added by Carsten Klein 11 years ago.
Optionally look up keywords from existing tickets
patch_against_trunk.2.diff (1.8 KB) - added by Carsten Klein 11 years ago.
I accidentally uploaded the wrong version. This one is better in that it removes extra whitespace from the keywords.

Download all attachments as: .zip

Change History (29)

comment:1 Changed 16 years ago by anonymous

Do you mean with the tags out of the TagsPlugin ?

comment:2 Changed 16 years ago by anonymous

if the tags plugin is there it would be nice. otherwise just the entries already there in other ticket's keywords fields.

comment:3 Changed 16 years ago by scratcher

Status: newassigned

As an improvement for this plugin I've planned to add TagsPlugin support, this will be done soon. I find not a big sence to duplicate functionality provided by TagsPlugin - basically it does exactly what was requested above and even more. It's not hard to add keywords fetching procedure to KeywordSuggestPlugin in one of following ways:

  • Make DB query + delimeter parsing every time when it's necessary to show keywords input field
  • Collect unique keywords after each modification of keyword ticket's field (require extra table in database)

Both of them adds complexity to this plugin which was designed to be as simple as possible. So philosophy is: you should use either lightweight solution with list of tags in trac.ini or TagsPlugin if you need something more powerfull.

comment:4 Changed 16 years ago by rupert thurner

100% agree!

comment:5 Changed 16 years ago by anonymous

There could be a performance hit in using the TagsPlugin, look at trac-hacks tag link above, it takes a couple seconds to load all the tags. multiply this by how many uses you have on your system and it makes having a separate table for available keywords more enticing. Also, the TagsPlugin can take tags from all sorts of fields or wiki pages, not just keywords field.

Of course, when a new keyword was entered into a ticket it would need to be added to the keyword table via an event listener. The only problem i can see is how to remove old keywords that are no longer used in tickets.... two options come to mind

  • allowing removal of keywords through an administration window (a little excessive)
  • or simply repopulate the table with available keywords on a regular basis (eg. daily) so that it is self maintained but with better performance than the TagsPlugin option.

Either way though, i think this feature is an essential addition to the KeywordSuggestPlugin

comment:6 Changed 16 years ago by Alec Thomas

The primary reason the tags link on TracHacks takes a while to load is that it loads every wiki page corresponding to a tag name, to fetch the title. This is not a cheap operation, but would be unnecessary for completion.

comment:7 Changed 16 years ago by J Evan S

TagsPlugin is great but unless I'm missing something it doesn't provide the automatic, in-screen assistance in picking consistent tags?

Certainly would be nice to have an option to use all entered tags/keywords instead of having to administer the list.

Not fond of any big slowdown but perhaps not too much of a hit (I hope) if you just have to query when a keyword is removed?

comment:8 in reply to:  7 ; Changed 16 years ago by anonymous

Replying to jevans:

TagsPlugin is great but unless I'm missing something it doesn't provide the automatic, in-screen assistance in picking consistent tags?

Certainly would be nice to have an option to use all entered tags/keywords instead of having to administer the list.

Not fond of any big slowdown but perhaps not too much of a hit (I hope) if you just have to query when a keyword is removed?

Obviously there must be ways around this... but...

"I find not a big sence to duplicate functionality provided by TagsPlugin "

...except that wanting a tags page is not a universal taste: look at the tags page on Trac-Hacks, it is just a stupid ugly useless mess. No use to anyone.

comment:9 in reply to:  8 Changed 16 years ago by J Evan S

Replying to anonymous:

Replying to jevans:

TagsPlugin is great but unless I'm missing something it doesn't provide the automatic, in-screen assistance in picking consistent tags?

Certainly would be nice to have an option to use all entered tags/keywords instead of having to administer the list.

Not fond of any big slowdown but perhaps not too much of a hit (I hope) if you just have to query when a keyword is removed?

Obviously there must be ways around this... but...

"I find not a big sence to duplicate functionality provided by TagsPlugin "

...except that wanting a tags page is not a universal taste: look at the tags page on Trac-Hacks, it is just a stupid ugly useless mess. No use to anyone.

I'm all for leaving the tags page to the TagsPlugin. My interest is to avoid needing the admin to add tags manually to the config. That's probably fine for some. We're just looking for the auto-complete feature to avoid common typo's.

I don't know enough about Trac programming yet. My thought is if the ini setting is blank, you can maintain the list by checking for new or deleted tags when a ticket is saved. But of course I don't know what the overhead for that is.

comment:10 Changed 15 years ago by Ryan J Ollos

I had thought this plug-in pulled keywords from the list of Tags, but I see now that is not the case. From what I have seen, with the TagsPlugin installed and the trac.ini configuration parameter ticket_fields = keywords, then all keywords will get added into the list of tags.

It would therefore be nice to have a trac.ini configuration parameter that allows the autocomplete of keywords to be take from the list of tags, such as keywordsfromtags = true.

comment:11 Changed 15 years ago by Ryan J Ollos

It looks like someone may have implemented this in ticket #4201.

comment:12 Changed 15 years ago by carstenklein@…

attached you find a new version of the plugin that will also read existing keywords from the database, namely from the table ticket and ticket_change. this can be controlled by a new configuration setting

[keywordsuggest]
fromdb = True | False

in addition it will mix in keywords defined in the configuration.

Changed 15 years ago by carstenklein@…

The "patch" to the KeywordSuggestPlugin (keywordsuggest.py)

comment:13 Changed 15 years ago by carstenklein@…

Here is a corrected version, the former did fail when fromdb was set to False.

Changed 15 years ago by carstenklein@…

Attachment: keywordsuggest.py.tar.gz added

corrected version of the patch, the former did fail when fromdb was set to false

comment:14 Changed 15 years ago by anonymous

Summary: offer all keywords used up to now for selection[Patch] Offer all keywords used up to now for selection

comment:15 Changed 13 years ago by Ryan J Ollos

Owner: changed from scratcher to Ryan J Ollos
Status: assignednew

comment:16 Changed 13 years ago by Ryan J Ollos

Status: newassigned

If someone can redo this patch against the trunk, I'd be willing to incorporate it.

comment:17 Changed 11 years ago by Ryan J Ollos

Status: assignednew

comment:18 in reply to:  8 Changed 11 years ago by Steffen Hoffmann

Replying to anonymous:

"I find not a big sence to duplicate functionality provided by TagsPlugin "

+1

...except that wanting a tags page is not a universal taste: look at the tags page on Trac-Hacks, it is just a stupid ugly useless mess. No use to anyone.

Not true anymore with a sensible 'mincount' applied, and the whole page could even be deactiveted by disabling tractags.web_ui.TagRequestHandler, if you insist.

comment:19 in reply to:  13 Changed 11 years ago by Steffen Hoffmann

Replying to carstenklein@…:

Here is a corrected version, the former did fail when fromdb was set to False.

Well, but #4503 for TagsPlugin still reminds me to take performance serious. So the SQL query on 'ticket' Trac db table seems potentially harmful considering an application with a decent number of tickets, say 2.000+. The query on 'ticket_change' seem even worse, if you hope to be able to edit-away some depreciated keywords, that would become immutable that way. Parsing keyword list per ticket will finally kill your users patience.

The current, normalized tag storage in TagsPlugin is the best way to go in the long run, seriously. Profile it on your own, if you don't trust me, but publish numbers and testing conditions to prove your point, if you do, please.

comment:20 in reply to:  16 Changed 11 years ago by Steffen Hoffmann

Replying to rjollos:

If someone can redo this patch against the trunk, I'd be willing to incorporate it.

Fine, as long as the turn-off switch option is retained, preferably adding an explicit performance warning to its description.

comment:21 Changed 11 years ago by Carsten Klein

Its been a while since I came up with the patch, but here you go. I applied the change to current trunk, meaning that I implemented the get_from_db method and the usedb_opt(ion) and integrated everything into the web_ui module.

The feature is off by default due to the performance concerns brought up by hasienda and the description of the option reflects that.

Changed 11 years ago by Carsten Klein

Attachment: patch_against_trunk.diff added

Optionally look up keywords from existing tickets

comment:22 in reply to:  21 Changed 11 years ago by anonymous

I forgot to mention that the query was changed so that it will query the ticket table only to speed up things a bit.

Changed 11 years ago by Carsten Klein

Attachment: patch_against_trunk.2.diff added

I accidentally uploaded the wrong version. This one is better in that it removes extra whitespace from the keywords.

comment:23 Changed 11 years ago by Steffen Hoffmann

In 13860:

TagsPlugin: Merge code from KeywordSuggestPlugin's current trunk (0.5.0dev), refs #1344, #3816, #4201 and #4503.

Functional overlap of the aforementioned plugin with TagsPlugin is a fact.
TagsPlugin lacking auto-complete-style assistance for 'keyword' alias tag
input fields took a lot from its potential efficiency.

Consequently KeywordSuggestPlugin is getting integrated from now.
Maintaining said plugin separately as another low-profile plugin for users
that dislike TagsPlugin might still happen depending on developer priorities
and user feedback.

PEP8 clean-up and move to TagsPlugin >= 0.7 performance-enhanced API for
querying current tag list has been done on the way.

comment:24 Changed 11 years ago by Steffen Hoffmann

In 13867:

TagsPlugin: Refit of configuration options inherited from KeywordSuggestPlugin, refs #1344, #3816, #4201 and #11690.

Included are minor changes for component doc-strings as follow-up to [13865].

comment:25 Changed 6 years ago by Ryan J Ollos

Owner: Ryan J Ollos deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.

Add Comment


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

 
Note: See TracTickets for help on using tickets.