GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2023-12-07T04:54:45Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/412158Add the dependency proxy enabled/disabled setting to the instance level admin...2023-12-07T04:54:45ZTim Rizzitrizzi@gitlab.comAdd the dependency proxy enabled/disabled setting to the instance level admin panel### Context
You can use the GitLab UI or API to turn off the group-level dependency proxy. Self-managed customers can turn off the feature at the instance level following https://docs.gitlab.com/ee/administration/packages/dependency_pro...### Context
You can use the GitLab UI or API to turn off the group-level dependency proxy. Self-managed customers can turn off the feature at the instance level following https://docs.gitlab.com/ee/administration/packages/dependency_proxy.html#turn-off-the-dependency-proxy.
### Problem to solve
The problem is that when you turn off the feature at the group level, it is still enabled for the sub-group. This means that if you want to turn off the feature and don't have Admin privileges at the instance level, you need to turn off the feature for every group and sub-group, which is quite inefficient.
In addition, for Dedicated customers, because this setting is not exposed in the UI, they don't have the ability to turn the feature off for their Dedicated instance.
### Proposal
Add the instance-level setting for the dependency proxy to the instance-level admin panel, so that instance Owners can enable or disable the feature from the UI, including GitLab Dedicated customers.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/338181Create Label Web Component2024-03-06T14:44:22ZThomas RandolphCreate Label Web ComponentBased on a [recent Slack conversation](https://gitlab.slack.com/archives/C0GQHHPGW/p1627942839028900), it would be useful to create a re-usable label/scoped-label component that can be used in both `gitlab-kramdown` and in the other appl...Based on a [recent Slack conversation](https://gitlab.slack.com/archives/C0GQHHPGW/p1627942839028900), it would be useful to create a re-usable label/scoped-label component that can be used in both `gitlab-kramdown` and in the other applications (Vue, even HAML, ???-future framework).
Goals:
- Implement labels with native Web Components
- Colors
- Scoped labels
- Close (x) button
- Long description tooltipBacklogThomas RandolphThomas Randolphhttps://gitlab.com/gitlab-org/gitlab/-/issues/229949Move work in progress MR widget to be the last one displayed2023-10-26T16:34:49ZThomas RandolphMove work in progress MR widget to be the last one displayedDeferred from [an MR to show the Rebase button widget instead of the WIP widget](https://gitlab.com/gitlab-org/gitlab/-/issues/21318#note_380945897).
There may be primarily code maintenance solutions to make this UI move.
There are tw...Deferred from [an MR to show the Rebase button widget instead of the WIP widget](https://gitlab.com/gitlab-org/gitlab/-/issues/21318#note_380945897).
There may be primarily code maintenance solutions to make this UI move.
There are two problems with the code relating to the MR Widgets:
1. There's a single test that tests each widget and depends on their source code order
2. The way the widgets are shown depends implicitly on their source order in a long `if/else if` block
The former of these will be addressed by https://gitlab.com/gitlab-org/gitlab/-/issues/228611, but the source block is still very complex and brittle.
In the [first issue linked above](https://gitlab.com/gitlab-org/gitlab/-/issues/21318), this brittleness led to only a partial solution to the desired outcome. The desired outcome was that the work in progress widget appeared last.
Because the Unresolved Discussions check includes a check for WIP, it *has* to come after the Work in Progress check.
So, there's one more thing to investigate: Are the widgets correctly isolated and scoped? What's the business reason that the UI is instructed to show that there are Unresolved Discussions when the MR is a work in progress even if there are zero discussions?
If we:
- Isolate and scope each widget
- Ensure that a given set of variables can only result in one widget (a use-case for a finite state machine?)
- Eliminate the implicit importance of the [source order of the widgets](https://gitlab.com/gitlab-org/gitlab/-/blob/c4247c9c73d34d501ebf51725d45b64b6d9f8311/app/assets/javascripts/vue_merge_request_widget/stores/get_state_key.js#L4-33)
then moving the widgets around should be trivial! :wink:Backlog