Feat/optional project scoping

[leiflm]

Disclaimer

This contribution was created AI assisted. Feel free to reject it right away if it violates your policies.

Problem

PyleroConfig.__init__ requires default_project to be set — either via the POLARION_PROJECT environment variable or as a key in ~/.pylero. If neither is present, config.get() on line 78 raises an unhandled configparser.NoOptionError and the module fails to initialize entirely.

The only valid workaround was to set default_project= (empty string) in ~/.pylero. But the old search methods treated an empty default_project as falsy and fell back to it unconditionally via or, producing a broken Lucene fragment (AND project.id:) that would be rejected by Polarion.

Fix

TestRun.search() and _SpecificWorkItem.query() now distinguish None from "" using an explicit identity check:

resolved_project = project_id if project_id is not None else cls.default_project
if resolved_project:
    query += " AND project.id:%s" % resolved_project

None → falls back to default_project (unchanged for users with a project configured). "" → project filter is omitted, enabling cross-project queries. This makes default_project= in ~/.pylero a valid, well-behaved configuration.

Backwards compatibility

Fully backwards-compatible. Any caller passing a non-empty project_id or relying on a non-empty default_project sees identical behaviour.

[leelavg]

sry, I'm a bit confused about the issue? if we were accepting empty string for default_project then that's a bug to be fixed disallowing empty string but not workaround it and anything that's touching the cfg at basepolarion needs a good testing.

AI code is fine but it should be reviewed by the author before posting, on a quick glance it's a bit troublesome to review rest of the code when I see a new if is introduced just to return where the above line also does the same condition.

[leiflm]

sry, I'm a bit confused about the issue? if we were accepting empty string for default_project then that's a bug to be fixed disallowing empty string but not workaround it

the objective is to be able to execute query statements against the global scope. Without these changes queries would fall back to be executed against „default_project“ if no other project was explicitly specified. Working around this limitation by specifiying an empty string as default _project would lead to a crash either in pylero or the Server side.

and anything that's touching the cfg at basepolarion needs a good testing.

Makes sense.

AI code is fine but it should be reviewed by the author before posting, on a quick glance it's a bit troublesome to review rest of the code when I see a new if is introduced just to return where the above line also does the same condition.

Fair enough, my apologies. I’ll manually review and ping again.