glmap: Workitems

New architecture in development which is partly available in the current release. For more information :

• GitLab Documentation
• GitLab Handbook with upcoming feature and status

Workitem is a new architecture used to regroup all entities to manage work in GitLab (e.g. Issues, requirements, incidents, tasks, ...). In the future the idea is to have a single basis for all these entities and to be able to extend it easily.

At the moment, (API version 17.10.0-pre) the only workitem available and available in the activity feed is the task. For the task, an important point is that, if we delete it, all events related to it are also deleted. It is not yet possible to see if the behavior is linked to the task or to the workitem architecture.

In therm of events, it works like issues. However, only specific events are available for the creation and closing of a workitem. The creation of a comment generates a CreateIssueComment event.

The following table shows the mapping of the events generated by GitLab for workitems. A fully detailed mapping can be found below.

Action	target_type	action
CreateWorkItem	WorkItem	opened
CloseWorkItem	WorkItem	closed

Activity	Actions	time window
CreateWorkItem	- CreateWorkItem - CreateIssueComment - Opt	3s
CloseWorkItem	- CloseWorkItem - CreateIssueComment - Opt	3s

1 - Actions

• Detection are the values used to detect what action has been performed.
• Details are information found in the payload of the event that can be used to group actions to activities. (name_in_action = name_in_payload)

1.1 - CreateWorkItem

Event triggered when we create a new workitem. (e.g. task)

Detection:

• action_name = opened
• target_type = WorkItem

Details:

• workitem.id = target_id
• workitem.iid = target_iid
• workitem.title = target_title

1.2 - CloseWorkItem

Event triggered when we close a workitem. (e.g. task)

Detection:

• action_name = closed
• target_type = WorkItem

Details:

• workitem.id = target_id
• workitem.iid = target_iid
• workitem.title = target_title

2 - Activities

Each activity is composed of one or more actions. Each action can be repeatable and can be optional. A maximum time window is also defined for each activity and it is used to group actions that are close to each other in time.

For each action, we can define a verification function (validate_with) to make sure that the action is part of the activity. (e.g comments are made on the same issue)

2.1 - CreateWorkItem

time window: 3s

Based on CreateIssue activity, we are not grouping consecutive creations.

As with Issue, reopening is the same as creating a new workitem. Thus, it would be possible to have have an opening of a workitem with a comment (Only basic comment,thread are not available). In this case, we have to verify that the comment is made on the workitem.

Actions:

• CreateWorkItem - mandatory and non-repeatable
• CommentIssue - optional and non-repeatable
  • CreateWorkItem: workitem.id = issue.id

2.2 - CloseWorkItem

time window: 3s

Based on CloseIssue activity, we are not grouping consecutive closures. Moreover, we could also close a workitem with a comment but, in this case, it can't be a thread.

Actions:

• CloseWorkItem - mandatory and non-repeatable
• CommentIssue - optional and non-repeatable
  • CloseWorkItem: workitem.id = issue.id