Add work item support
What does this MR do and why?
This MR provides initial support for work items.
Goal
For any issue check that the weight of any issue is at least as high as the sum of the weights of all **Tasks **attached to it.
Realisation
A couple of things needed to be touched. In general 99% of this MR only adds to the code base but not changed the existing flow.
Big picture
TASKs can only be fetched by the graphql API as a work item. Therefore this MR added support for work items in general, but specifically for TASKs and ISSUEs. Work Items have the methods
parent
children
which allows the user to traverse the hierarchy. Parents and children are dynamically loaded by a seperate API call on first use.
It also adds the methods
-
weight
- easy access to the weight property (which is otherwise hidden quite deep in the WorkItemWidget structure).
-
widgets
- aux function to have access to all existing WorkItemWidgets by name
Details
Filters
The graphql query for work items doesn't provide as many filters as the REST issue API. Therefore more filtering of resources happens after the query results get back
query{
project(fullPath: "xxx") {
workItems(#not so many filters)
Actions
The comment action needed to enhanced such that a comment can happen via graphql to enable adding comments to TASKs.
ProjectId (& GroupId) parsing
Graphql doesn't give back the projectId anywhere within the workItems sub-structure. The projectId was therefore queried from the project directly.
query{
project(fullPath: "xxx") {
id #<-- project_id
workItems {
}
The groupId is not part of this MR.
Example
resource_rules:
work_items:
rules:
- name: Task showcase
conditions:
types:
- ISSUE
limits:
most_recent: 1
actions:
comment: |
/weight #{children[0].weight}
Limitations
In theory this MR supports all kinds of work items. However, the focus of the MR is clearly on the workItemtyes ISSUE & TASK.
The WorkItemType: TASK is marked as an experiment as well as the project{workItems{}}
query itself.