fix(test_run): custom field type Enum: Work Item: Query register as _…

[jenshoffend]

Dear all,

i was hit with an over engineered test run template setup.

A TestRun.create( ...) greeted me with an "IndexError: list index out of range".

Pylero was able to create a Testrun in Polarion but failed right after that, which lead me into test_run.py:

_cache_custom_fields(...) -> _custom_field_types(...)

The generated list at test_run.py#L429 was empty.
The comment there says we ignore certain fields, those fields seem to be handled by the split globals lookup. But it did not catch this case.

The attached screenshots show the kind of field pylero and myself stumbled over:

The "field_type" is in the nature of:
@workitems[type:c_product AND status:approved AND project.id:polarion_id]
->
@workitems["work item query"]

Since such a work item query can be all kind of work items class objects i opted to use the _Workitem class.

With this TestRun.create( ...) succeeds and the TestRun object can be operated.

I am not entirely sure that this is what should be done or if with this the generated list lookup can be dropped.

Looking into the query and checking which work item classes are returned seems to be mood, since we need a singular type?

[leelavg]

looks correct to me based on some debugging, seems _WorkItem is the only odd one out and we can't directly translate to the type in globals, I don't see WorkItem as enum in test instance so tried with build[temp]

(Pdb) field_type # src/pylero/test_run.py:424 before the split
@build[temp]
(Pdb) [globals()[x] for x in globals() if x.lower() == field_type[1:].lower()][0]
*** IndexError: list index out of range
(Pdb) [globals()[x] for x in globals() if x.lower() == "build".lower()][0]
<class 'pylero.build.Build'>
[...]
(Pdb) [getattr(v, "enum_id", None) for v in results] # src/pylero/test_run.py:479
[None, @user, @plan, None, arch, variant, None, @build[temp]]
(Pdb) [getattr(v, "type", None) for v in results]
[ns8:Text, ns10:EnumOptionId, ns11:EnumOptionId, xsd:boolean, ns20:EnumOptionId, ns21:EnumOptionId, xsd:string, ns30:EnumOptionId]

[...]

[
 'ArrayOfCustom': <class 'pylero.custom.ArrayOfCustom'>,
 'ArrayOfEnumOptionId': <class 'pylero.enum_option_id.ArrayOfEnumOptionId'>,
 'ArrayOfTestRecord': <class 'pylero.test_record.ArrayOfTestRecord'>,
 'ArrayOfTestRunAttachment': <class 'pylero.test_run_attachment.ArrayOfTestRunAttachment'>,
 'BasePolarion': <class 'pylero.base_polarion.BasePolarion'>,
 'Build': <class 'pylero.build.Build'>,
 'Custom': <class 'pylero.custom.Custom'>,
 'CustomFieldType': <class 'pylero.custom_field_type.CustomFieldType'>,
 'Document': <class 'pylero.document.Document'>,
 'EnumCustomFieldType': <class 'pylero.enum_custom_field_type.EnumCustomFieldType'>,
 'EnumOptionId': <class 'pylero.enum_option_id.EnumOptionId'>,
 'Plan': <class 'pylero.plan.Plan'>,
 'Project': <class 'pylero.project.Project'>,
 'PyleroLibException': <class 'pylero.exceptions.PyleroLibException'>,
 'TestRecord': <class 'pylero.test_record.TestRecord'>,
 'TestRun': <class 'pylero.test_run.TestRun'>,
 'TestRunAttachment': <class 'pylero.test_run_attachment.TestRunAttachment'>,
 'Text': <class 'pylero.text.Text'>,
 'User': <class 'pylero.user.User'>,
 '_WorkItem': <class 'pylero.work_item._WorkItem'>,
]

# src/pylero/test_run.py:524
                if (
                    isinstance(cache[field]["type"], type)
                    and "project_id"
                    in cache[field]["type"].__init__.__code__.co_varnames[
                        : cache[field]["type"].__init__.__code__.co_argcount
                    ]
                ):
                    self._cls_suds_map[field]["additional_parms"] = {"project_id": project_id}

[leelavg]

even though the code & explanation looks correct, I can't verify how it'd behave in a polarion instance which has WorkItem as enum, if in your server it's working fine then we can merge.

[jenshoffend]

Thank you for reviewing it.

We have the change in full use (nightly and manual triggered jobs) with six Polarion projects on our production server [1].
The most recently to be automated added project has the "over engineered test run template" configuration that necessitated this change.

So the change works for those six different test run template configurations.

[1] Version 2506