feat: Add filterType property to work item and work item template APIs models - #228
Conversation
Signed-off-by: gokulprasanth-ni <gokulprasanth.ravi@emerson.com>
There was a problem hiding this comment.
🟢 Approval recommended
The change is additive, follows existing JsonModel camelCase serialization conventions, and includes integration test coverage plus updated examples for the new field.
Pull request overview
Adds a filterType/filter_type field to Work Item and Work Item Template resource models so callers can explicitly indicate whether resource filters are interpreted as LINQ or LUCENE, and updates integration tests/examples to exercise and document the new behavior.
Changes:
- Introduces
FilterTypeenum and addsfilter_typetoResourcesDefinitionandTemplateResourcesDefinition(serialized asfilterType). - Extends query projection enums with
RESOURCES_FILTER_TYPEfor both work items and templates. - Updates integration tests and examples to set and validate
filter_type(and adjusts sample filter strings accordingly).
File summaries
| File | Description |
|---|---|
| tests/integration/work_item/test_work_item_client.py | Adds integration coverage for create/update/query behaviors involving resources.filter_type and updates sample filters. |
| nisystemlink/clients/work_item/models/_resources_definition.py | Adds FilterType enum plus filter_type fields to resource definition models. |
| nisystemlink/clients/work_item/models/_query_work_items_request.py | Adds WorkItemField.RESOURCES_FILTER_TYPE projection field. |
| nisystemlink/clients/work_item/models/_query_work_item_templates_request.py | Adds WorkItemTemplateField.RESOURCES_FILTER_TYPE projection field. |
| nisystemlink/clients/work_item/models/init.py | Exports FilterType from the public models package. |
| examples/work_item/work_items.py | Demonstrates setting filter_type for work item create/update resource filters. |
| examples/work_item/work_item_templates.py | Demonstrates setting filter_type for template resource filters and updates. |
Review details
- Files reviewed: 7/7 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
|
|
||
| class FilterType(str, Enum): | ||
| """The type of filter used to select the resources for the work item.""" |
There was a problem hiding this comment.
| """The type of filter used to select the resources for the work item.""" | |
| """Query language used to interpret resource filters in the reservation.""" |
There was a problem hiding this comment.
Similarly update in other places.
| LINQ = "LINQ" | ||
| LUCENE = "LUCENE" |
There was a problem hiding this comment.
| LINQ = "LINQ" | |
| LUCENE = "LUCENE" | |
| LUCENE = "LUCENE" | |
| LINQ = "LINQ" |
Since Lucene is the default FilterType, we could place it first.
| ], | ||
| filter='modelName = "cRIO-9045" && serialNumber = "01E82ED0"', | ||
| ), | ||
| filter_type=FilterType.LINQ, |
There was a problem hiding this comment.
| filter_type=FilterType.LINQ, | |
| filter_type="LINQ", |
This is more readable and reflect the usage, can we update it in all 4 places in examples?
| name="Updated work item", | ||
| resources=ResourcesDefinition( | ||
| systems=SystemResourceDefinition( | ||
| filter='properties.data["Lab"] = "Battery Pack Lab"', |
There was a problem hiding this comment.
| filter='properties.data["Lab"] = "Battery Pack Lab"', | |
| filter='properties.data["Location"] = "Lab 1"', |
This filter is already set in the create request model. Are we using the update API to set it again here?
same applies for templates example as well.
| filter="os:linux AND arch:x64", | ||
| filter='os = "linux" && arch = "x64"', | ||
| ), | ||
| filter_type=FilterType.LINQ, |
There was a problem hiding this comment.
| filter_type=FilterType.LINQ, | |
| filter_type="LINQ", |
| ) | ||
| assert delete_work_item_template_response is None | ||
|
|
||
| def test__create_work_item__returns_resources_with_filter_type( |
There was a problem hiding this comment.
In my opinion, field-level validations (like asserting the response contains expected filter_type) are already covered by the service that the client calls. Our integration tests should only verify that the client correctly wires the request/response and deserializes the fields and don't throw error.
Other integration clients typically use focused assertions rather than validating every field in every response, so having a separate filter-type-specific test for each API feels inconsistent.
We could add the filter_type assertion to the existing update work items and templates tests alone, since the LINQ → LUCENE transition verifies the mutation behavior, and remove all the dedicated tests.
What does this Pull Request accomplish?
Add filterType property to resource models in work item and template APIs
Why should this Pull Request be merged?
This support makes it easier for the users to create work items with either
LinqorLuceneresource filtersWhat testing has been done?
Automated integration tests are included.