Feature Request: Add support for Work Items
### Problem Statement The GitLab Go package currently lacks high-level API support for work items, which are GitLab's collective term for epics, issues, and tasks. While issues have comprehensive support through the `IssuesService`, and epics were previously supported via REST API (now deprecated), there's no convenient way to interact with the work items GraphQL API. Currently, developers must use `GraphQL.Do()` to issue arbitrary GraphQL queries, which creates significant friction: 1. **Query complexity**: Developers must learn GraphQL syntax and construct queries manually, which is a barrier to entry for those just trying to solve immediate business needs 2. **Data structure definition**: GraphQL responses require developers to define matching Go structs based on their specific queries 3. **Type conversions**: Response fields often need transformation (e.g., IID returned as string needs parsing to int64) This offloads substantial complexity onto users that the library should reasonably handle. ### Proposed Solution Create a new `WorkItemsService` with: - **Pre-defined data structures** matching common work item fields and operations - **High-level functions** (e.g., `GetWorkItem()`, `ListWorkItems()`, `CreateWorkItem()`, `UpdateWorkItem()`) that abstract away GraphQL query construction - **Automatic type conversion** from GraphQL response types to idiomatic Go types - **Consistent API patterns** following the conventions established by `IssuesService` and other existing services The service would internally use GraphQL queries but expose a clean, REST-like interface that Go developers expect from this package. ### Context - The REST API for epics is deprecated in favor of the work items GraphQL API - Tasks currently have no high-level API support - Work items represent GitLab's unified approach to work tracking across epics, issues, and tasks ### Next Steps I'm willing to implement this feature but would like alignment on the approach before investing time and effort. Happy to discuss API design, scope, and implementation details.
issue