There is no way to set an iteration on a work item. We can view a list of possible iterations now, but there is no way to save the selected iteration.
Proposal
When viewing a list of possible iterations, I can select one of the iterations from the list to associate an iteration with a work item.
If the work item already has a synced iteration, the manually selected iteration takes precedence and the "sync" is disabled ("Sync" is explained in this issue #367454.)
Acceptance
Associate a work item to an iteration.
Properly handle disabling the sync and allowing the manually set iteration to take precedence. Follow the same procedure as confidentiality initially. If parent has an iteration, default to that iteration for the task.
Redis counter
Redis Counter
name:users_updating_work_item_iteration
category:work_items
redis_slot:users
include in the following aggregation counters:
xmau_plan
xmau_project_management
xmau_product_planning
xmau_certify
users_work_items
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@deepika.guliani As discussed, going to assign this to you. We don't have finished designs yet, and there are still discussions happening around whether or not we will have editing of an iteration in a work item as part of the initial MVC. I do think we can start with assigning an iteration to a Task on creation, if the parent issue has an iteration. Then the iteration would be displayed as read-only on the task, like in #367462[Entered.png].
I don't believe we have the ability to add an iteration in the create work item mutation, but I think that's okay. We can probably just call the update work item mutation after it is created, with the iteration set then.
@nickleonard Hey Do we have more clarity on how the UX will look/work for the iterations on work items ? Here is a snapshot of just showing the name of the iteration.
@deepika.guliani I've updated this issue with some designs — these are still WIP and need validation, but there are some basic elements I wouldn't really expect to change much. This is more "vision" than MVC1, I can scope this down based on what we want to target initially.
This simplifies the display of iterations a bit versus the current state, and some recent explorations within the sidebar, keeping dates/cadence in the dropdown in an effort to avoid having too many competing details and in particular too many competing "date" values if milestone/due dates are used.
@euko hey Thanks for the working in this issue. So I started working for the frontend part for this and have a couple of questions
This comment mentions that we do not have the ability to add iteration to the task on creation which I do see here as well. But I am not sure why should we call updateWorkItem(another mutation again) when we can provide the ability to do so at one go.
I am not sure why I had to add this change as well to get the iteration widget as well for ee version of tasks. I was not able to retrieve the widget till this change was not made. Maybe this is intentional ? and I am missing something else ?
So I just wanted to make sure that we are on the same page for the scope of the work for this issue
Here is the MR link for what I have done till now.
What I understand :
When creating any task from an issue, in case the issue has an associated iteration to it , the iteration should also be added to the task. So , when we create the task from the issue , we call another mutation to set the iteration in case the iteration exists. Then , when we view the task standalone , we should be able to see the iteration associated with and also update/or read only.
I am just not sure why that ability was not added to createWorkItem mutation
I am not sure why I had to add this change as well to get the iteration widget as well for ee version of tasks.
If a task should be assignable to an iteration then that change should be made. We should explicitly state the supported work item types going forward.
mentions that we do not have the ability to add iteration to the task on creation
Simply because we haven't added the API yet. I rushed to add the update API before I left. @deepika.guliani Is chaining GraphQL requests (create+update) more onerous than initially thought as a stopgap?
So as far as I know task is the only work item on gitlab.com right now(with the frontend changes) , isn't it ? With widgets and stuff. So iteration is like weights for tasks ( work items here ), only applicable for the ee version.
About the create/update mutation for the work item , since we should be assigning the iteration be default when creating the task from issue ( in this case ) , It makes sense to add the capability while creating the task as well other than the case when we obviously change the iteration manually in work item details view. What do you think ?
It makes sense to add the capability while creating the task as well other than the case when we obviously change the iteration manually in work item details view. What do you think ?
@deepika.guliani I agree and think the plan was to add the capability. It was just that @donaldcook and I thought we could use a combination of createWorkItem + updateWorkItemtemporarily. I can prioritize this work now I am back if necessary. In fact, let me review the new designs.
mutationmyMutation{workItemCreate(input:{projectPath:"gitlab-org/plan-stage/test-project"workItemTypeId:"gid://gitlab/WorkItems::Type/1"title:"some work item with iteration"iterationWidget:{iterationId:"gid://gitlab/Iteration/87536"}}){errorsworkItem{idtitlewidgets{type...onWorkItemWidgetIteration{iteration{id}}}}}}
@euko hey again I was wondering if we would need a subscription for iteration update ? Like for real time updates ? Not sure just checking what you think about the same ?
I think we should add that here as well , maybe @donaldcook and @gweaver can also chime in since we are adding the subscription(and real-time update) to other widgets as well. What do you think ?
Displaying the iteration history of a WI (issue) requires some work in the backend as you can't easily retrieve this piece of information through the current version of our API. To keep the scope of this issue manageable, we should create a new issue for this work (both frontend+backend.)
If the work item already has a synced iteration, the manually selected iteration takes precedence and the "sync" is disabled ("Sync" is explained in this issue #367454.)
@gweaver, since we haven't yet implemented this sync feature, should this proposal be moved to the linked issue #367454?