search in given field has to be fixed and generalized

This patch against bughelper.main r161 fixes that issue.

TODO: find a way to handle attributes like attachments which are non-strings

Markus

Some example use cases:
    <contains>
      <op field="title">MASTER</op>
    </contains>

    <contains>
      <op field="importance">r'(High|Wishlist)'</op>
    </contains>

This patch against bughelper.main r163 adds a function to search fields which are list or tuples.
I added an example clue-file bughelper.info to data to demonstrate this new thing.

To search the tags you have to either patch "python-launchpad-bugs/main" with the attached patch or use "python-launchpad-bugs/xpath"

Example use-case:
        <and>
            <op field="proptags">r'(xpath|commandline)'</op>
            <op field="importance">Undecided</op>
        </and>

NOTE: If have choosen "proptags" as a field-name for tags as we use the tags attribute in other parts of the Bug-object. My plan is to only have one tags attribute.

Markus

please use this patch or "python-launchpad-bugs/xpath"

well done ... remember to update 0.3 xml schema as well in bughelper-data (if not already done so)

in the meantime the fix landed in bughelper.main branch.

setting to "in progress". As soon as schema is updated as well, this is probably fix committed.

This new version of the patch against bughelper.main r161 fixes that issue. bughelper also prints a warning if the bug/attachment-object does not have the attribute given by "field".

please use this patch instead of these ones attached to comment 1 and 3

markus

actually, I don't think falling back to search .text field in case the specified field does not exist is the right thing to do, because the clue author definitly wanted the search to be constraint on some specific field. widening match on the full text then will most likely not do what author wanted.

My suggestion: Print out warning and check for proper fields on "try-clue" ... but don't process in case wrong field is given.

Alexander,
this falling back to the text attribute is a real big problem caused by the design of the whole infofile classes and functions: for example we are using the condition_matches function to look in either a Bug-object or a BugAttachment-object. The problem is that BugAttachement for example does not have a "title" attribute. So when you have something like <op field="title">MASTER</op> and you tell bughelper to quit whenever field is not in attributes then it will never work.

So the easiest solution is to fallback to .text as it is an attribute of Bug and BugAttachment.

So we need another solution, my suggestion: an other attribute in op called "in".

Examples:
<op field="title" in="Bug">MASTER</op> - That would search the title of a bugreport
<op field="title" in="BugAttachment">MASTER</op> - That would always fail as there is no BugAttachment.title, but that is the mistake of the user
<op field="title">MASTER</op> - That would search in Bug and BugAttachement but fail for Attachment, again mistake by the user

I'm happy to hear any other and better solution!

Markus

An attachment has no attributes. It's just text (and maybe the content-type and size, but they should be irrelevant). If a 'field=<something>' argument is specified it will not match an attachment.

Maybe I miss something, but where is this problematic?

Ok, sorry for complicating this discussion, just ignoring non existing attributes would be the best solution.

This patch against r165 of bughelper.main introduces the field thing once again without any fallback to text attributes. If an attribute given by a field does not exist, this clue does not match.

Markus

------------------------------------------------------------
revno: 166
committer: Markus Korn <email address hidden>
branch nick: bughelper.main
timestamp: Wed 2007-04-25 15:02:41 +0200
message:
  support field attributes in clue conditions (bug 109533)
------------------------------------------------------------