Skip to content

Refactor initializer arguments for Issues::RelatedBranchesService

Alexandru Croitor requested to merge 391479_rename_project_param_to_container into master

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 #391479 (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.

Edited by Alexandru Croitor

Merge request reports