[PATCH] search for Transactions by Tag

[wolfer]

this patch adds the option to search the transactions by tag.
patch is applied to the branch lp:~kolmis/wxbanker/transaction-tagging

[simpsus (bastian-kennel)]

I think with this patch we have fulfilled the "transaction-tagging" blueprint.

It would be nice if we then could advance to the "advanced-tagging" blueprint.

Karol weaved my patches in a very nice and clean way. thank you for that.

Also thank you for this cool project!!

[Michael Rooney (mrooney)]

Cool, I'll subscribe the author of this branch, thanks for the contribution! Karel, I assume you aren't getting notified of bugs like this, but let me know if you are. Wolfer, in the future you may find it easier to branch instead of patching. IE, branch ~kolmis/wxbanker/transaction-tagging, make your changes, push them, and propose a merge. This way it is easier to integrate and the right people get notified, and code review is easy that way as well. I'll see about doing this as I'd like to make a change or two to the patch.

[Michael Rooney (mrooney)]

Okay, I put your patch in a branch and made some small changes. Check out http://bazaar.launchpad.net/~mrooney/wxbanker/transaction-tagging-wolfer/revision/241 to see my changes. Basically I created properties for Tags and TagString so they can used instead of methods, to fit in with the rest of the code. I also simplified the GetTagString method and fixed a bug in it. I think in its initial implementation, it would return invalid matches because there was no separator. So if I tagged something with "cats" and "cars", and then search for the tag "scars", I think it would have come up because it would have been searching in "catscars". By adding a separator this won't happen anymore because it will search "cats, cars".

There may be a more ideal way that allows you to search for multiple tags, by separating with commas, and not having the order matter (probably a special case in the searching). But we can see if that is deemed important.

[Karel Kolman (kolmis)]

the patch looks exactly like what i created as a first try in getting tag searching support but in the end i didn't like it (concatenating the tag.Name strings). i took a different approach, searching the tag list separately.

and yes, i guess posting bugs against development branches is not such a good idea :) too bad launchpad doesn't have discussion linked to branches (or does it ?). publishing a branch seems more appropriate (and actually easier)

[wolfer (wolfer7)]

@kolmis: nicely done!

i think to make the search easier for the user, we could allow gmail-like searches like "tag: gas" or "amount: 23.54". but i guess this would be another blueprint.

and now that i have my own branch, i am going to push my changes there... what is left of the "transaction-tagging" blueprint? i would like to start working on the category thing after this one is finished.

[Michael Rooney (mrooney)]

On Thu, May 14, 2009 at 1:27 AM, Karel Kolman <email address hidden> wrote:
> too bad launchpad doesn't have discussion linked to branches (or does it ?)

Sort of! You can't have discussion on a branch but you CAN have
discussion on a merge proposal, so it would work just as well as long
as you propose a merge.

I'll look into merging the tagging branch soon. Your SQL skills are
more advanced than mine so I'll have to try to figure out what your
tables and indexes are doing :) If you wouldn't mind proposing a merge
and briefly summarizing it, that could be useful. Also, making the
store's GetModel return the cached version breaks the assumptions of a
few unit tests (search for calls to that, you'll see. They still pass
but now won't fail on a regression) so I'll add a test for this
assumption and we can figure out the best way to fix it, probably a
simple change.

[Karel Kolman (kolmis)]

i reverted the bankmodel caching. i'll try to add a few reasonable unittests and will propose a merge.

[Michael Rooney (mrooney)]

I'll mark this as Triaged since it is a patch and will apply it when I merge in the tagging branch, thanks! The importance is Low only because the tagging bug is already Medium importance which will include this.

[Michael Rooney (mrooney)]

So with the approach being taken for 0.8, with tags being represented in the description via hash tags, I think this is implicitly taken care of as you can search for tags as you normally would search for anything, such as "#unpaid" and such. I don't think this will need any specific extra work, but what are others' thoughts, am I missing anything?

[simpsus (bastian-kennel)]

First, am I right that we talk only about the searching for tags, not tags in general?
Assuming I am right, my thoughts:
When the tags are included in the description, searching for a tag name would include all transactions that have that tag. Unfortunately the search can return more transactions, exactly when the tag appears somewhere in the description, but does not have the tag.
Is that a big problem? I don't know. At least it would break the assumption that you can see your total amount for one tag. For categories, this is not a problem as they are presented in a hierarchy anyway. For tags, the web2.0 way to do this is a tag cloud, which we do neither have nor currently plan to have.

So, summary: I don't see any problems except that you cannot state that you can view your transactions by tag (which is to me the reason to have tags in the first place).

[Michael Rooney (mrooney)]

Yeah, this bug is just for searching, but I don't think your understanding is quite in line with how it works. The tags show up in the description as hash tags like #groceries and #unpaid, so searching for "#unpaid" will only turn up tags and not things with the word "unpaid" in them.

You can do this out of the box currently in wxBanker, but I'm using kolmis's branch to have tags as indexed, first-class objects so that a tag cloud, tag auto-complete, and graphs by tags will be easy to implement in the future (does not require parsing every transaction description).

[simpsus (bastian-kennel)]

Bottom line, my point is perfectly valid but there is the '#' as a security net for tags which comes at the price that the user has to type '#anytag' when all the wants is 'anytag'.

As for the first-class objects .... I am pretty well aware of that. Wolfer reported this bug but we used to code the patches in here together. Of course I don't remember every detail given that is was ALMOST A YEAR AGO...

So, you want to close this bug? Go ahead. The purpose of this bug was never to point out a flaw, but to get the code and new feature into the main branch. As you are the owner of the main branch, feel free to do whatever you like.

[Michael Rooney (mrooney)]

Hmm, I am don't want to just "close the bug", I want to implement searching by tag in the simplest, most intuitive manner. I thought using twitter-style annotation and searching was that, but maybe your disagreement is telling me I am wrong about that. If there was a drop-down of type that was "Tag", you could select that, and search for just "anytag" certainly, but navigating to the drop-down, selecting "Tag", and then navigating to the search seems much more tedious than just typing a "#".

Maybe the ideal way would just be to add a drop-down that is the list of tags itself, sorted by most frequently tagged at the top. This way you are looking at transactions by tag in two clicks and no typing. It seems like a nice approach to me but what do you think?

Let's keep the hostility low and friendliness/constructiveness high; criticizing my free time available to work on this open source project only takes up more of it :)

[simpsus (bastian-kennel)]

Thank you for taking the time to respond so quickly.
I actually hadn't thought of the twitter style search, which is definitely an option worth considering.

If I recall correctly we were at the point of discussing something like a dropbox or different search area before. At the time the outcome was that you didn't want to clutter the interface with too much options.

What I can think of: Tags are basically another way of categorizing transactions, as categories and accounts are. So you could put said dropdown into the list of accounts. Perhaps this would confuse the user to mistakenly mix the search dimensions, perhaps this would even the path to future features like searching only for one tag inside one or a combination of accounts. I don't know.

My general approach would be to release early and often to get user feedback.

My least interest is to offend you. If you feel offended by my posts in any way please tell me and I will stop writing stuff in your domain.

[Michael Rooney (mrooney)]

Thanks for the feedback! I agree with the release early and often principal, which is why I've slated tags for 0.8 and categories for later. That was sort of the rationale for just having tags searchable via hash tags like twitter; it doesn't require extra UI work and already works, but allows a first iteration to get some feedback on and see what people actually want to do with tags (and how to visualize them) once they are being used.

I think I'm currently a fan of adding a drop-down of Tags in the search area, moving the search bar up above the Transactions / Summary tab, and having it apply application-wide. This way you can select tags easily and look at the transactions, or switch over to the Summary tab and view a graph of balance by tags. This would also allow arbitrary searches in the summary graph which I think would be useful.

Any yays or nays on an implementation in that direction (from anyone)?

[Michael Rooney (mrooney)]

Okay, with the current implementation I think tags are reasonable searchable for the initial version, but if it seems useful to be able to do more complex operations (like OR and NOT operations), that seems like a reasonable bug to file. I imagine it could be done in a similar way as Google, with minus signs and such.

[Michael Rooney (mrooney)]

I should follow up that I was a little surprised by the implementation; we have nice database tables and indexes for persisting tags, but after benchmarking it turns out that it only costs a few milliseconds of time per thousand transactions to parse the descriptions at start-up anyway, as if they had just been entered, so they aren't currently used. It still has some object-level utility via Tag classes and lists that are maintained, so it should lay the ground work hopefully for more reporting and such. I'm thinking maybe a "Tags" tab could be added that allows you to see most-used tags and totals by tag, and such.

[Michael Rooney (mrooney)]

Okay, so now you can search by tag by typing "#tagname" in the search bar, as well as right clicking on a transaction, selecting the tag, and clicking the search option!