Refactor initializer arguments for Issues::CloseService
What does this MR do and why?
All issuable services end up inheriting from IssuableBaseService
that inherits from BaseProjectService
.
Considering that want to have work items at group level, we would need all the Issue
related services to be able to reference both a project
and a group
.
Given that we have a BaseContainerService
I think it would make sense to have IssuableBaseService
inherit from BaseContainerService
and have a couple project
and group
methods within BaseContainerService
for backward compatibility.
At the same time in all these services we do pass in project:
argument in the initialize
method and it will be confusing, akward and just weird to pass a group
instance into project:
named argument at the same time changing the initializer
to take 2 arguments project:
and group:
and sort out which one is actually passed in(e.g. check which one is not null and not allow both arguments to be not null) is confusing and adds tech debt as well.
So I would like to rename the project:
argument on IssuableBaseService
to container
to fit the more generic purpose of having work items(issues and potentially other issuables) available at group level.
So I thought I'd do just that, and opened an MR with that change: !111663 (closed)
The MR passes all the specs, but it is huge, so I do not think there will be many willing to review and approve this
So I am now just splitting that huge MR into multiple more manageable MRs to review. Hopefully the big MR still serves as a source of context.
The list of MRs broken out of the original one, I'll be tracking in an epic that can be found here: Rename project argument to container for all Is... (&9878 - closed)
closes #391478 (closed)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.