In the group's issues list, if an issue is linked to a group milestone. Clicking on this link do not redirect to all group issues in this milestone but rather to the issues at project level.
@bancarel.valentin Thanks for raising an issue. I'm unsure whether this is the intended behaviour to point to the project level milestone related to the project where the issue resides
To me as I'm on the group's issues I should be redirected to the group milestone.
Let's say I've two issue: I1 and I2; respectively belonging to projects P1 and P2, and to the same milestone M0. If I see that two issues have the same milestone but when I click this milestone I see only one and the other one just disappeared I'm confused. It's exactly what happened to me and it takes me a moment to realize I was at the project level.
@markglenfletcher@bancarel.valentin : This is not intended right now. But it's not a bug as it's existing functionality. But definitely something we want to fix.
@smcgivern : This is related to &22 (closed) in that it's all related to subgrouping and assigning/filtering labels/milestones from various ancestors and descendants.
I don't think I logged this particular use case yet of what happens when you click a milestone or a label from within a list view (or from within a board card). I think we have discussed it at some point, or I remember at least talking with @pedroms about it.
@smcgivern : I think we should first fix assignments and filtering first (so https://gitlab.com/gitlab-org/gitlab-ce/issues/36862), and then work on this particular case of clicking on a milestone/label from a list item or board card item right? That way, we won't have any undefined cases where we try to filter by something that's unfilterable? Is that correct?
Thank you @bancarel.valentin for bringing up this issue and starting the discussion.
@smcgivern: We have this issue open that I think we can leverage what we've done in the past: Have it be a UX deliverable to figure out the design more broadly. And then subsequently we can pick apart and have consistent implementations throughout GitLab. gitlab-design#83 (closed)
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?