GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-25T15:04:01Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/448843Add "Manage Deploy Tokens" as a customizable permission2024-03-25T15:04:01ZJoe RandazzoAdd "Manage Deploy Tokens" as a customizable permission### Release notes
Group owners and project maintainers have the ability to manage deploy tokens. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With the release...### Release notes
Group owners and project maintainers have the ability to manage deploy tokens. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With the release of this permission, you can create a custom role to allow a Developer (or any base role) plus this permission to manage push rules without being overprivileged.
### Background
Group owners and project maintainers have the ability to deploy tokens. This leads organizations elevating a subset of users who need to manage these settings that as a consequence can edit other Group/Project settings. This permission will allow a custom role such as Developer + this permission offering organizations to reduce Owners and Maintainers in their environment
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Deploy Tokens" that can be selected.
2. The permission actions for `admin_deploy_tokens` includes CRUD and all the properties associated:
<table>
<tr>
<th>Group Actions</th>
<th>Project Actions</th>
</tr>
<tr>
<td>
Group Repository Settings
* Deploy Tokens
</td>
<td>
Project Repository Settings
* Deploy Tokens
</td>
</tr>
</table>
APIs
* https://docs.gitlab.com/ee/api/deploy_tokens.html
Views+Workflows include:
- [ ] Base + permission: Can see Group-\> Settings -\> Repository Settings -\> Deploy Tokens
- [ ] Base + permission: Can see Project-\> Settings -\> Repository Settings -\> Deploy Tokens
### Documentation
* [ ] Permissions attribute: `admin_deploy_tokens`
* [ ] Permission Title: `Manage Deploy Tokens`
* [ ] Permission Description: `Configure deploy tokens at the group or project level.`
* [ ] Update prerequisites for...
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1563798208Next 1-3 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/448823Add "Manage Protected Branches" as a customizable permission2024-03-25T15:04:02ZJoe RandazzoAdd "Manage Protected Branches" as a customizable permission### Release notes
Project maintainers have the ability to manage protected branches. This often leads to a user becoming overprivileged where they may not need other project destructive permissions. With the release of this permission, ...### Release notes
Project maintainers have the ability to manage protected branches. This often leads to a user becoming overprivileged where they may not need other project destructive permissions. With the release of this permission, you can create a custom role to allow a Developer (or any base role) plus this permission to manage protected branches without being overprivileged.
### Background
Project maintainers have the ability to protected branches. This leads organizations elevating a subset of users who need to manage these settings that as a consequence can edit other Project settings. This permission will allow a custom role such as Developer + this permission offering organizations to reduce Owners and Maintainers in their environment
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Protected Branches" that can be selected.
2. The permission actions for `admin_protected_branches` includes creating, reading, updating, and deleting protected branches along with properties associated:
<table>
<tr>
<th>Group Actions</th>
<th>Project Actions</th>
</tr>
<tr>
<td>No group actions available</td>
<td>
Project Repository Settings
* CRUD on Protected Branches
* Including properties
* Allowed to Merge
* Allowed to push and merge
* Allowed to force push
* Code Owner Approval
</td>
</tr>
</table>
APIs
* https://docs.gitlab.com/ee/api/protected_branches.html
Views+Workflows include:
- [ ] Base + permission: Can see Project-\> Settings -\> Repository Settings -\> Protected Branches
### Documentation
* [ ] Permissions attribute: `admin_protected_branches`
* [ ] Permission Title: `Manage Protected Branches`
* [ ] Permission Description: `Create, read, update, and delete protected branches for a project.`
* [ ] Update prerequisites for...
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1497709588
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1504880260
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1570435642Next 1-3 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/443235Add "Merge Request Settings" as a customizable permission2024-03-25T15:03:59ZJoe RandazzoAdd "Merge Request Settings" as a customizable permission### Release notes
Group owners and project maintainers have the ability to manage merge request settings. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With th...### Release notes
Group owners and project maintainers have the ability to manage merge request settings. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With the release of this permission, you can create a custom role to allow a Developer (or any base role) plus this permission to manage merge request settings.
### Background
Group owners and project maintainers have the ability to MR settings. This leads organizations elevating a subset of users who need to manage these settings with a consequence of editing other Group/Project settings. This permission will allow a custom role such as Developer + this permission offering organizations to reduce Owners and Maintainers in their environment
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Merge Request Settings" that can be selected.
2. The permission actions for `admin_merge_request_settings` includes:
<table>
<tr>
<th>Group Actions</th>
<th>Project Actions</th>
</tr>
<tr>
<td>
Merge request settings:
* Merge request checks
* Merge request approvals
</td>
<td>
Merge request settings:
* MR configurations including methods, options, squash, and merge checks.
* Status checks
* Approval rules and approval settings
* Suggested Reviewers
* MR branch workflow and branch target
Exclude
* Security Approvals - this will fall under `admin_security_policies`
</td>
</tr>
</table>
* API for reference
* https://docs.gitlab.com/ee/api/merge_request_approvals.html
* https://docs.gitlab.com/ee/api/projects.html
* https://docs.gitlab.com/ee/api/status_checks.html
Views+Workflows include:
- [ ] Base + permission: Can see Group-\> General -\> Merge requests
- [ ] Base + permission: Can see Group-\> General -\> Merge request approvals
- [ ] Base + permission: Can see Project-\> Settings -\> Merge request settings
### Documentation
* [ ] Permission Title: `Manage Merge Request Settings`
* [ ] Permission Description: `Configure merge request settings at the group or project level. Group actions include managing merge request checks and approval settings. Project actions include managing MR configurations, approval rules and settings, suggested reviews, and branch targets.`
* [ ] Update prerequisites for...
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1550198109
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1400795515
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1570435642
* https://gitlab.com/groups/gitlab-org/-/epics/4035#note_1600469949
* https://gitlab.com/groups/gitlab-org/-/epics/4035#note_1389988477
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_178837371716.11Alex Buijsabuijs@gitlab.comAlex Buijsabuijs@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/442851Add "Manage Runners" as a customizable permission2024-03-25T15:04:02ZJoe RandazzoAdd "Manage Runners" as a customizable permission### Release notes
Group owners and project maintainers have the ability to manage runners. This often leads to a user who is overprivileged where they may not need other group or project destructive permissions. With the release of this...### Release notes
Group owners and project maintainers have the ability to manage runners. This often leads to a user who is overprivileged where they may not need other group or project destructive permissions. With the release of this permission, you can create a custom role and set the permission to enable least privileged access.
### Background
Group owners and project maintainers have the ability to manage runners. This leads organizations elevating a subset of users who need to manage runners that as a consequence can edit other Group/Project settings.. This permission will allow a custom role such as Developer + this permission offering organizations to reduce Owners and Maintainers in their environment
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Runners" that can be selected.
2. If the user role is targeted at the group level, they will be able to perform Group Actions indicated below to the group and sub groups. This continues to follow the waterfall permission model.
3. If the user role is targeted at the project level, they can only perform Project Actions indicated below for the project.
4. The permission actions for `admin_runners` allows create / write (create/update) / delete on Runners and settings including:
<table>
<tr>
<th>Group Actions</th>
<th>Project Actions</th>
</tr>
<tr>
<td>
Runner Object
* Create a group runner
* Edit a runner
* Delete a runner
* View details
* Continue to only show objects that the user has access to (jobs/projects)
Runner List
* View list of runners (all, group or project) and status including filtering
* Edit, Resume, Delete Runner on List item
* Registration Token Dropdown Option (Deprecated)
Runner Settings
* Enable runner instances
* Enable stale cleanup
</td>
<td>
Runner Settings
* View Project Runners
* View Instance Runners
* Project Runner
* Create runner
* Remove runner
* Pause runner
* Configuration
* Enable instance runners
* Disable group runners
Pipelines View
* Clear Cache
</td>
</tr>
<tr>
<td>
</td>
<td>
</td>
</tr>
</table>
* API for reference
1. https://docs.gitlab.com/ee/api/runners.html
2. https://docs.gitlab.com/ee/api/graphql/reference/#queryrunner and more
Views+Workflows include:
- [ ] Base + permission: Can see Group-\> Build -\> Runners
- [ ] Base + permission: Can see Group -\> Build -\> Create Runner
- [ ] Base + permission: Can see Group -\> Build -\> View Runner Details
- [ ] Base + permission: Can see Group-\> Settings \> CI/CD \> Runners
- [ ] Base + permission: Can see Projects -\> Settings \> CI/CD \> Runners
- [ ] Base + permission: Can see Projects -\> Pipelines \> Clear Runner Cache
### Documentation
* [ ] Permission Title: `Manage Runners`
* [ ] Permission Description: `Create, view, edit, and delete group or project Runners. Includes configuring Runner settings.`
* [ ] Update prerequisites for [Manage Runner Documentation](https://docs.gitlab.com/ee/ci/runners/runners_scope.html), [Configure Runners](https://docs.gitlab.com/ee/ci/runners/configure_runners.html), [Tutorials](https://docs.gitlab.com/ee/tutorials/automate_runner_creation/) with:
* [ ] Update group prerequisites: `You must have the Owner role for the group or custom role with the permission "admin_runners"`
* [ ] Update project prerequisites: `You must have the Maintainer role for the project or custom role with the permission "admin_runners"`
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1563798208
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1713157342
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1579653185
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1345654387
* https://gitlab.com/groups/gitlab-org/-/epics/4035#note_133925654416.11https://gitlab.com/gitlab-org/gitlab/-/issues/440226Add "Manage Security Policy Links" as customizable permission2024-03-25T15:03:59ZJoe RandazzoAdd "Manage Security Policy Links" as customizable permission### Release notes
The default role Owner is required to manage and assign security policies which can lead to an over privileged user. With the release of this permission, you can create a custom role and set the permission to enable le...### Release notes
The default role Owner is required to manage and assign security policies which can lead to an over privileged user. With the release of this permission, you can create a custom role and set the permission to enable least privileged access.
### Background
Today, a user must be a project or group owner to assign and link a security policy
This results in teams escalating a security engineer to owner on the group or project level.
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Security Policy Links" that can be selected.
2. This permission `admin_security_policy_links` gives them the ability to:
1. Assign and unassign security policy links at the group or project level.
API for reference
* https://docs.gitlab.com/ee/api/graphql/reference/#mutationsecuritypolicyprojectassign
* https://docs.gitlab.com/ee/api/graphql/reference/#mutationsecuritypolicyprojectunassign
Views+Workflows include:
- [ ] Base + permission: Can see Group or Project -\> Secure -\> Policies -\> Edit Policy Project Button
- [ ] Base + permission: Can see Group or Project -\> Policies -\> Edit Policy Project Modal to assign or unassign
### Documentation
* [ ] Permission Title: "Manage Security Policy Links"
* [ ] Permission Description: Assign and unassign Security Policy Links for a group or project.
* [ ] Update prerequisites for [Linking a security policy project](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project)
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1563798208
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_171315734216.11Jarka Košanovájarka@gitlab.comJarka Košanovájarka@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/437590[FE] Ability to edit a role's permissions2024-03-25T15:04:00ZJoe Randazzo[FE] Ability to edit a role's permissions### Release notes
### Problem to solve
A customer can create a new role and recently now has the ability to edit the role in the API. There is no view to edit the Role through the UI. This may be cumbersome for the user to go through t...### Release notes
### Problem to solve
A customer can create a new role and recently now has the ability to edit the role in the API. There is no view to edit the Role through the UI. This may be cumbersome for the user to go through the API versus quickly selecting in the UI.
### Proposal
Dependent on https://gitlab.com/gitlab-org/gitlab/-/issues/393238+
The API now allows custom permissions to be [edited in the API](https://gitlab.com/gitlab-org/gitlab/-/issues/429889 "Support changing permission values in update MemberRole mutation"). Allow for users to edit their role permissions in the UI. This will only editing name, description, custom permissions, and not the base role.
### UX
1. Select "More actions" and "Edit role" from the custom role table UI
2. Routes to the new "Edit role" Screen.
3. Pre-populates with current data
4. Breadcrumb shows "Edit role"
5. Title shows "Edit role"
6. The user is able to edit the "Name", "Description", and " Custom Permissions".
7. The "Base Role" is not editable, but shown as a<span dir=""> </span>`read-only` value.
8. Validation should be the same as the "Create Role" view.
9. Confirmation button highlights "Save Changes" instead of "Create Role"
### Documentation
* [ ] Include documentation on how to edit permissions.
* [ ]
### Designs
* [Figma File](https://www.figma.com/file/G6Dn9X0739dIpNteen6ueg/Edit-Custom-Role?type=design&node-id=1616%3A9144&mode=design&t=BSJs4zT9nbzFYpbe-1)
### ![Edit custom role - with button enabled (1).png](/uploads/77c4c6452ca87cf9e2fe8800b6997b69/Edit_custom_role_-_with_button_enabled__1_.png)16.11Daniel TianDaniel Tianhttps://gitlab.com/gitlab-org/gitlab/-/issues/421786Add "Manage Push Rules" as a customizable permission2024-03-27T02:43:00ZHannah SutorAdd "Manage Push Rules" as a customizable permission### Release notes
Group owners and project maintainers have the ability to manage push rules. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With the release of...### Release notes
Group owners and project maintainers have the ability to manage push rules. This often leads to a user becoming overprivileged where they may not need other group or project destructive permissions. With the release of this permission, you can create a custom role to allow a Developer (or any base role) plus this permission to manage push rules without being overprivileged.
### Background
Group owners and project maintainers have the ability to push rules. This leads organizations elevating a subset of users who need to manage these settings that as a consequence can edit other Group/Project settings. This permission will allow a custom role such as Developer + this permission offering organizations to reduce Owners and Maintainers in their environment
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Push Rules" that can be selected.
2. The permission actions for `admin_push_rules` includes editing push rules and all the properties associated:
<table>
<tr>
<th>Group Actions</th>
<th>Project Actions</th>
</tr>
<tr>
<td>
Group Repository Settings
* Pre-defined Push Rules
</td>
<td>
Project Repository Settings
* Push Rules
</td>
</tr>
</table>
APIs
* https://docs.gitlab.com/ee/api/projects.html#get-project-push-rules
* https://docs.gitlab.com/ee/api/groups.html#push-rules
Views+Workflows include:
- [ ] Base + permission: Can see Group-\> Settings -\> Repository Settings -\> Pre-defined push rules
- [ ] Base + permission: Can see Project-\> Settings -\> Repository Settings -\> Push Rules
### Documentation
* [ ] Permissions attribute: `admin_push_rules`
* [ ] Permission Title: `Manage Push Rules`
* [ ] Permission Description: `Configure push rules at the group or project level.`
* [ ] Update prerequisites for...
### Evidence
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1747246360
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1752775569
* https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_155019810916.11Hinam MehraHinam Mehrahttps://gitlab.com/gitlab-org/gitlab/-/issues/411502Add "Manage Compliance Framework" as a customizable permission2024-03-27T17:40:35ZHannah SutorAdd "Manage Compliance Framework" as a customizable permission### Release notes
The default role Owner is required to manage compliance framework settings which can lead to an overprivileged user. With the release of this permission, you can create a custom role and set the permission specifically...### Release notes
The default role Owner is required to manage compliance framework settings which can lead to an overprivileged user. With the release of this permission, you can create a custom role and set the permission specifically on the user.
### Background
Today, a user must be a project owner to assign a compliance framework labels and group owners are only able to create and manage compliance frameworks.
This results in teams escalating a security or compliance manager to owner role, therefore the user is over-privileged.
### Proposal and User Experience
1. When creating a role, any base can be selected. A new permission is available and labeled "Manage Compliance Frameworks" that can be selected.
2. This permission `admin_compliance_framework` gives them the ability to:
1. Create, Read, Update, and Delete the compliance framework at the group level
2. Set the default framework label at the group level.
3. Assign the compliance framework at the project level.
4. Assign the compliance framework on a project on the Compliance Center.
API for reference
* https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationcreatecomplianceframework
* https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationdestroycomplianceframework
* https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationdestroycomplianceframework
* https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationprojectsetcomplianceframework
Views include:
* Base + permission: Can see Group Settings -\> General -\> "Compliance frameworks" section -\> Manage Framework
* Base + permission: Can see Project Settings -\> General -\> "Compliance framework" section -\> Assign Project
* Base + permission: Can see Compliance Center -\> Projects -\> Edit Compliance Framework Label on Project
### Evidence
- https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1364396925
- https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1563798208
- https://gitlab.com/gitlab-org/gitlab/-/issues/411502#note_1448497237
- https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1307836412
- https://gitlab.com/groups/gitlab-org/-/epics/11156
### Documentation
* [ ] Permission Title: `Manage Compliance Frameworks`
* [ ] Permission Description: `Create, view, edit, and delete compliance frameworks. Also ability to assign a compliance framework label on a project and set default framework on a group.`
### Implementation Plan
1. The following abilities are in question for implementing this feature: `manage_compliance_framework`, `admin_compliance_framework`, `read_compliance_framework`, `admin_compliance_pipeline_configuration`, `manage_group_level_compliance_pipeline_config`.
2. We should probably merge `manage_compliance_framework` policy into `admin_compliance_framework` as technically both of these are same and require a user to be the group owner.
3. Need to follow the [steps in this doc](https://docs.gitlab.com/ee/development/permissions/custom_roles.html#implement-a-new-ability) for adding a new ability and should also take help from the MRs shared for reference in the doc.16.11Jarka Košanovájarka@gitlab.comJarka Košanovájarka@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/3610Anomaly alerts MVC2023-09-05T21:58:24ZJoshua LambertAnomaly alerts MVC## Proposal
As an MVC towards the broader anomaly detection and alerting issue (https://gitlab.com/groups/gitlab-org/-/epics/119) we should provide alerting based on deviation from the weekly mean. This issue covers the backend piece of...## Proposal
As an MVC towards the broader anomaly detection and alerting issue (https://gitlab.com/groups/gitlab-org/-/epics/119) we should provide alerting based on deviation from the weekly mean. This issue covers the backend piece of this work. The frontend pieces are covered separately as part of https://gitlab.com/gitlab-org/gitlab-ee/issues/5366.
- [ ] Define a recording rule for a weekly moving average of desired metrics. See [this doc for more details on potential implementations](https://medium.com/qubit-engineering/using-seasonality-in-prometheus-alerting-d90e68337a4c).
- [ ] Define a recording rule for a 5 minute moving average of all nodes/pods for each metric.
- [ ] Create alert for each metric when the 5 minute moving average is X standard deviations beyond the weekly moving average
- [ ] Create alert for each metric when a node's 5 minute moving average is X standard deviations beyond the populations average.
In this case our definitions would be:
* Anomaly: two standard deviations away from the weekly moving average. 2sigma would then only fire, in theory, in the event we are 95% sure of an error. (Assuming normal distribution.)
* Outlier: a single node's metrics are two standard deviations away from the rest of the fleet.
We could provide documentation and examples for how to do this with an external Prometheus server, then support support adding these to the managed Prometheus.
## Interaction
How do users disable the pre-configured alert?
1. Turn off alerts entirely
1. Adjust the alertmanager config to remove that specific alert
## Out of scope
In this issue we are not considering the ability for users to configure their own anomaly alerts on custom or pre-provided metrics. We will only be adding out-of-box anomaly alerts to out-of-box metrics.
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*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.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/412353Support replaced Go modules in Gemnasium2023-09-21T12:11:00ZPhilippe LafoucrièreSupport replaced Go modules in Gemnasium<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
[Go modules can be replaced](https://go.dev/ref/mod#go-mod-file-replace) in `go.mod` files. This feature is used for diffe...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
[Go modules can be replaced](https://go.dev/ref/mod#go-mod-file-replace) in `go.mod` files. This feature is used for different purposes, one being to use a fork of an upstream project where we patch some code. This is the case for example in [gitlab-shell](https://gitlab.com/gitlab-org/gitlab-shell) where `golang.org/x/crypto` is replaced by [`gitlab-org/golang-crypto`](https://gitlab.com/gitlab-org/golang-crypto): https://gitlab.com/gitlab-org/gitlab-shell/-/blob/68d860f64eb02b46d9d8f861770b4edee77e1aa5/go.mod#L98
Yet, this replacement isn't reflected in the dependency list, which can alter the SBOM generated for this project.
### Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
Short term solution: Include the replacement as a new dependency.
Long term solution: Support replacements in the dependency scanning report schema.
### Implementation
- Update the [`module`](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/be57da1f5ed495307013264e2bce1f57df5739b6/builder/golang/golang.go#L27) struct so that it includes the module replacement field.
- Add a test to verify that it generates the correct command and parses the output correctly.
- Update the Go [builder](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/be57da1f5ed495307013264e2bce1f57df5739b6/builder/golang/golang.go#L140) so that it checks if the replacement module field is set.
- Update specs to verify that the module replacement detection is working as intended.
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/434473Modernize sorting and filtering in Explore > Projects2024-03-25T03:26:03ZChristina Lohrclohr@gitlab.comModernize sorting and filtering in Explore > Projects## Problem
Our filtering options are misaligned across the product. In Explore > Projects, the sorting dropdown currently lists several items that could be condensed if we would also add the sorting element. See also: https://design.git...## Problem
Our filtering options are misaligned across the product. In Explore > Projects, the sorting dropdown currently lists several items that could be condensed if we would also add the sorting element. See also: https://design.gitlab.com/components/sorting. This will help with the visual alignment across the product.
![Screenshot_2023-12-08_at_10.51.53](/uploads/944b57b36ce4df450c898665ad095727/Screenshot_2023-12-08_at_10.51.53.png)
This is similar to work done in https://gitlab.com/gitlab-org/gitlab/-/issues/25368.
## Proposal
Following the proposal in https://gitlab.com/gitlab-org/gitlab/-/issues/25368, let's update the existing search and sort components so they are more consistent with the rest of the platform. This change will improve the ability to search and filter the list page, create an opportunity to introduce additional filter options in future, and better align the experience on this list page with the other list pages in the product, for example, the issue and MR lists. Here's how it will look, visually:
![Explore___projects___First_iteration__2_](/uploads/a0a155cb668998c6e15ca87739870b95/Explore___projects___First_iteration__2_.png)
This update includes the following changes:
- Updating the order of the tabs.
- Introducing an `Active` and an `Inactive` tab. The active tab will include all projects that aren't archived. Following the proposal in https://gitlab.com/gitlab-org/gitlab/-/issues/25368+, the Inactive tab will display the projects that are archived.
- Introduce [filtered search](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-filtered-search--default). The first-pass filters for the Trending, Most starred, and All tabs will include `Language` (sub-filters the same as existing options) and `Role` (sub-filters to include just `Owner` for a first pass; additional filters added in https://gitlab.com/gitlab-org/gitlab/-/issues/437921). The filters for the [Inactive tab](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4380%3A72673&mode=design&t=XAlWieuYbsbLxhqO-1) will include just `Role`(with `Owner` as the sub-filter) for the first iteration, with a status filter being added later in https://gitlab.com/gitlab-org/gitlab/-/issues/437920.
- Replace the existing sort dropdown with the [sorting component](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-sorting--default). Sort options for all tabs will include `Name`, `Created date`, `Updated date` and `Stars`.
- Add instrumentation to the "Inactive" tab to see if, in fact, anyone looks at archived content in the "Explore" context. If not, we will consider deprecating the display of archived content on this page, in future.
The default sorting mechanism applied per tab should be as follows:
- **Most stars** - sort by `Stars`
- **Trending** - sort by `Updated at`
- **All** - sort by `Updated at`
- **Inactive** - sort by `Updated at`
[Figma](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4430%3A31469&mode=design&t=PdCFSPIRG5HygjGU-1)
## Implementation plan
1. Use filter search component added in https://gitlab.com/gitlab-org/gitlab/-/issues/434469
1. Move `Show archived` projects filter (`?archived=true`) into a new tab called `Inactive`
1. Move language filter into the filter bar
1. Move `Owned by me` into filter bar as `Role` -> `Owner`
1. Above component should reload the page with correct query parameters when submitted
2. Mount component in [app/views/shared/projects/_search_form.html.haml#L24](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/shared/projects/_search_form.html.haml#L24)
3. Update [documentation](https://gitlab.com/gitlab-org/gitlab/-/issues/434473)16.11https://gitlab.com/gitlab-org/gitlab/-/issues/434469Modernize sorting and filtering in Explore > Groups2024-03-25T03:26:03ZChristina Lohrclohr@gitlab.comModernize sorting and filtering in Explore > Groups## Problem
Our filtering options are misaligned across the product. In Explore > Groups, the sorting dropdown currently lists six items that could be condensed to three if we would also add the sorting element. See also: https://design....## Problem
Our filtering options are misaligned across the product. In Explore > Groups, the sorting dropdown currently lists six items that could be condensed to three if we would also add the sorting element. See also: https://design.gitlab.com/components/sorting. This will help with the visual alignment across the product.
![Screenshot_2023-12-08_at_10.19.09](/uploads/434300a313d4ea0ecfd5b7ec43642d7e/Screenshot_2023-12-08_at_10.19.09.png)
## Proposal
Following what we're doing with [Explore > Projects](https://gitlab.com/gitlab-org/gitlab/-/issues/434473), and the other list pages, we propose to update the search and sort functionality on the Explore > Groups page. For a first pass, we'll just opt for updating the existing functionality. Currently, there is just basic search and sort so, in this issue, we'll focus just on updating those elements as follows:
![Explore___Groups___First_iteration](/uploads/03390ea3c7942459e04bd0a4fcb0155b/Explore___Groups___First_iteration.png)
This update includes the following changes:
- Introduce [filtered search](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-filtered-search--default) component. For the first pass, this will be used for search only. Filters will be added in a follow-up iteration. Filters are still TBD, but may include role and visibility, as shown [here](https://gitlab.com/gitlab-org/gitlab/uploads/5abcf10e0ffc99cae1a623481be4dfe5/Explore___Groups___Future.png).
- Replace the existing sort dropdown with the [sorting component](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-sorting--default). Sort options will include `Name`, `Created date`, and `Updated date` to match the other list pages.
- Remove alert and replace with text under the page header. Example alert:
![image](/uploads/322ccc9d939f93f4cf2f67f59fc318db/image.png)
For placement of the description text, follow the design in [this example](https://gitlab.com/gitlab-org/gitlab/uploads/ede2d2d177d28490e3a205bdb1a2bfa2/Screenshot_2024-01-17_at_6.40.37_PM.png). Use the following text:
- gitlab.com: `Below you will find all the groups that are public. Contribute by requesting to join a group. \[Learn more\](https://docs.gitlab.com/ee/user/group/#view-groups).`
- Self managed: `Below you will find all the groups that are public or internal. Contribute by requesting to join a group. \[Learn more\](https://docs.gitlab.com/ee/user/group/#view-groups).`
[Figma](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4490%3A30433&mode=design&t=B2n1jQutNYgIqrHf-1)
## Implementation plan
- Create a new component in `app/assets/javascripts/groups_projects/components` called `filtered_search_and_sort`
- Move logic in [app/assets/javascripts/organizations/groups_and_projects/components/app.vue#L135](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/organizations/groups_and_projects/components/app.vue#L135)
- Mount the filtered search bar in [app/assets/javascripts/groups/components/app.vue#L238](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/groups/components/app.vue#L238) and conditionally render based on a new prop
- Fire `fetchFilteredAndSortedGroups` when filtered search or sort is changed
- Remove [app/views/explore/groups/_nav.html.haml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/explore/groups/_nav.html.haml)
- Remove https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/views/explore/groups/index.html.haml#L16 and corresponding JavaScript in [app/assets/javascripts/pages/explore/groups/index.js#L7](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/pages/explore/groups/index.js#L7)
- Add message under the title using `gon.dot_com` value
- On gitlab.com the message should be `Below you will find all the groups that are public. Contribute by requesting to join a group. \[Learn more\](https://docs.gitlab.com/ee/user/group/#view-groups).`
- On self-managed the message should be `Below you will find all the groups that are public or internal. Contribute by requesting to join a group. \[Learn more\](https://docs.gitlab.com/ee/user/group/#view-groups).`16.11Peter HegmanPeter Hegmanhttps://gitlab.com/gitlab-org/gitlab/-/issues/411239Deprecate running a single database and require main and ci database instead2024-03-28T09:13:36ZChristina Lohrclohr@gitlab.comDeprecate running a single database and require main and ci database insteadFor guidance on the overall deprecations, removals and breaking changes workflow, please visit [Breaking changes, deprecations, and removing features](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-an...For guidance on the overall deprecations, removals and breaking changes workflow, please visit [Breaking changes, deprecations, and removing features](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes)
<!-- Use this template as a starting point for deprecations. -->
### Deprecation Summary
<!--
This should contain a brief description of the feature or functionality that is deprecated. The description should clearly state the potential impact of the deprecation to end users.
It is recommended that you link to the documentation.
The description of the deprecation should state what actions the user should take to rectify the behavior. If the deprecation is scheduled for an upcoming release, the content should remain in the deprecations documentation page until it has been completed. For example, if a deprecation is announced in 14.9 and scheduled to be completed in 15.0, the same content would be included in the documentation for 14.9, 14.10, and 15.0.
**If this issue proposes a breaking change outside a major release XX.0, you need to get approval from your manager and request collaboration from Product Operations on communication. Be sure to follow the guidance [here](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes.)**
-->
We want to deprecate running a single database. We plan to require two databases (`main:`, and `ci:`) in %"18.0"
### Breaking Change
<!-- Does this MR contain a breaking change? If yes:
- Add the ~"breaking change" label to this issue.
- Add instructions for how users can update their workflow. -->
~"breaking change"
### Affected Topology
<!--
Who is affected by this deprecation, Self-managed users, SaaS users, or both? This is especially important when nearing the annual major release where breaking changes and removals are typically introduced. These changes might be seen on GitLab.com before the official release date.
-->
self-managed users
### Affected Tier
~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
### Checklists
**Labels**
- [x] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels.
- [x] This issue is labeled ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes).
**Timeline**
Please add links to the relevant merge requests.
- As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release):
- [ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations).
- [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).
- [ ] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement-1) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post.
- On the major milestone:
- [ ] The deprecated item has been removed.
- [ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change".
**Mentions**
- [ ] Your stage's stable counterparts have been `@mentioned` on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
- To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/)
- If there is no stable counterpart listed for Sales/CS please mention `@timtams`
- If there is no stable counterpart listed for Support please mention `@gitlab-com/support/managers`
- If there is no stable counterpart listed for Marketing please mention `@cfoster3`
- [ ] Your GPM has been `@mentioned` so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
### Deprecation Milestone
%"16.1"
### Planned Removal Milestone
%"18.0"
### Links
<!--
Add links to any relevant documentation or code that will provide additional details or clarity regarding the planned change.
This issue is the main SSOT for the deprecations and removals process. Be sure to link all
issues and MRs related to this deprecation/removal to this issue. This can include removal
issues that were created ahead of time, and the MRs doing the actual deprecation/removal work.
-->
<!-- Label reminders - you should have one of each of the following labels.
Use the following resources to find the appropriate labels:
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
<!-- Populate the Section, Group, and Category -->
<!-- Choose the Pricing Tier(s) -->
<!-- Identifies that this Issue is related to deprecating a feature -->
<!-- Add the ~"breaking change" label to this issue if necessary -->18.0https://gitlab.com/gitlab-org/gitlab/-/issues/387005Set `allow_blank: false` for the `private_profile` param in User API2024-01-22T11:54:48ZManoj M JSet `allow_blank: false` for the `private_profile` param in User APISee the discussion in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107362#note_1226433852 for details.
This is a breaking change for the API, and hence can only be done in 16.0
TODO:
- Remove the TODO items mentioned in `lib/...See the discussion in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107362#note_1226433852 for details.
This is a breaking change for the API, and hence can only be done in 16.0
TODO:
- Remove the TODO items mentioned in `lib/api/users.rb` related to this issue
- Add `allow_blank: false` for the API param `private_profile`Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/219230Members from shared projects or shared groups are not listed2024-03-27T08:19:27ZImre FarkasMembers from shared projects or shared groups are not listed## Summary
When using the group members API resource, we cannot get invited groups that are then also members as per the recent share groups with other groups feature released in 13.1 (GitLab.com SaaS environment).
Members from shared...## Summary
When using the group members API resource, we cannot get invited groups that are then also members as per the recent share groups with other groups feature released in 13.1 (GitLab.com SaaS environment).
Members from shared projects are also not listed on:
- group members page
Members from shared groups are not listed on:
- group members page
- project members page
## Steps to reproduce
- Create a group with `group_invited` as a title and add direct members on it
- Create another group with `group_with_project` as a title
- From the `group_with_project` invite the group `group_invited` with a developer role
- Request the API using the following request
```
# :id is the id of the group group_with_projects
GET /groups/:id/members
```
### What is the current behavior?
Only direct members or inherited ones (if `/all` is used in the query) from the `group_with_projects` will be retrieved in the response. we don't get the members from the invited group.
### What is the expected *correct* behavior?
It would be great to get the members from the invited group(s) also (unless we can retrieve the shared groups in another way??). This change should be reflected in the UI.16.11Abdul WadoodAbdul Wadoodhttps://gitlab.com/gitlab-org/gitlab/-/issues/437013Modernize sorting and filtering in Group overview2024-03-25T03:26:03ZChristina Lohrclohr@gitlab.comModernize sorting and filtering in Group overview## Problem
Our filtering options are misaligned across the product. In Groups, the sorting and filtering already follows a more modern pattern. However, the search bar is very small and the whole search and filter element could be exten...## Problem
Our filtering options are misaligned across the product. In Groups, the sorting and filtering already follows a more modern pattern. However, the search bar is very small and the whole search and filter element could be extended to follow the page spanning design used on other pages. This will help with the visual alignment across the product.
![Screenshot_2024-01-03_at_13.43.05](/uploads/65e3f182b529cb4d2d3d072fd0fd7bcf/Screenshot_2024-01-03_at_13.43.05.png)
## Proposal
- [ ] Change Archived projects tab to Inactive: https://gitlab.com/gitlab-org/gitlab/-/issues/436392
- [ ] Update the wording of the sort options to align with how we present them on other pages (see mockup)
- [ ] Change `Created` to `Created date`
- [ ] Change `Updated` to `Updated date`
- [ ] Move search element underneath tabs and span the same width of the page as used for the group list (see mockup)
- [ ] Have the timestamps match the sorting, so that the last updated date is shown when sorting by `updated_at` and the created date is shown when sorting by `created_at`.
![image](/uploads/626eef4b665fc599719348c5d8cc90a2/image.png)
## Implementation guide
1. Switch [app/assets/javascripts/groups/components/overview_tabs.vue#L228](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/groups/components/overview_tabs.vue#L228) to `~/vue_shared/components/filtered_search_bar/filtered_search_bar_root.vue`
1. Use CSS to move the filter and sort below the tabs
1. Update sort options names in [app/assets/javascripts/groups/constants.js#L34](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/groups/constants.js#L34)17.1https://gitlab.com/gitlab-org/gitlab/-/issues/421310Disable users from changing user profile to private2024-03-25T14:27:49ZHarkanwar Singh JohalDisable users from changing user profile to private## Problem
Users can set their own profiles to private (https://docs.gitlab.com/ee/user/profile/#make-your-user-profile-page-private). As instance admins we want to restrict users from making their profile private.
### Proposal
Solut...## Problem
Users can set their own profiles to private (https://docs.gitlab.com/ee/user/profile/#make-your-user-profile-page-private). As instance admins we want to restrict users from making their profile private.
### Proposal
Solution could look very similar to https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#disable-user-profile-name-changes
## Implementation Guide
### Design
![Frame_560](/uploads/f6395643df9f4a5543bc1cd994e3771c/Frame_560.png)
The setting should be checked by default meaning that, by default, people _can_ make their profiles private.
Additional details:
1. If the admin setting is unchecked, and people can't make their profiles private, the checkbox on the user profile > user settings page would appear, but it would be disabled and have a lock after it. Hovering over the lock icon would trigger a popover explaining why the setting is disabled.
2. If the admin setting is unchecked and all profiles are thus required to being public, the setting above it ("Make new users' profiles private by default") would be disabled and have a lock icon after it. Hovering over the lock icon would trigger a popover explaining why the setting is disabled.
Here's how that would look:
| 1: User setting page | 2: Admin setting page |
| ------ | ------ |
| ![Frame_559](/uploads/17482ad7adc0e2e1cb8d1ec0c874f417/Frame_559.png) | ![Frame_558](/uploads/9b49a6a074b14ed2b2e5a268cbaa61ed/Frame_558.png) |
The text for the popover on the lock icon on the user profile page should read:
> **Setting locked**
> Profiles are required to be public in this instance.
The text for the popover on the lock icon on the admin setting page should read:
> **Setting locked**
> The option to make profiles private has been disabled. Profiles are required to be public in this instance, and cannot be set to private by default. [Learn more]().
Learn more should link to: https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-profiles-of-new-users-to-private-by-default
### Docs updates
As part of this change, we should update the following docs pages: https://docs.gitlab.com/ee/user/profile/#make-your-user-profile-page-private and https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-profiles-of-new-users-to-private-by-default. More details [here](https://gitlab.com/gitlab-org/gitlab/-/issues/421310#note_1522416359).16.11https://gitlab.com/gitlab-org/gitlab/-/issues/344491Empty subgroups are accessible, but not listed w/o replicating group sharing ...2024-03-15T17:28:09ZDmitry Radzevich (MST)Empty subgroups are accessible, but not listed w/o replicating group sharing of the parent (sub)group<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "type::bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://g...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "type::bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
A user U is a member of some group X. The group X is added as a member of another group Y. The group Y has empty subgroups.
When the user U logs in and navigates to the group Y's page, only those subgroups of Y are shown in the **Subgroups and projects** section that have the user U or its group X as an explicit member **OR** are non-empty (i.e. have projects or subgroups).
But even those empty subgroups of Y that are not shown on the group Y's page are still accessible to the user U when navigated to directly.
### Steps to reproduce
Consider an org model:
- `org_root/`
- `users/`
- `group1/`
- `public/`
- `subgroup1/`
- `subgroup2/`
- `subgroup3/`
- `project3.1`
- `restricted/`
1. create the org model as shown above
2. add user U to `org_root/` with **Minimal Access**
3. add user U to `/users/group1/` with **Maintainer** access
4. add `/users/group1/` as a member to `public/`
5. add `/users/group1/` as a member to `public/subgroup2`
### Example Project
N/A
### What is the current *bug* behavior?
When GitLab's page for `/org_root/public/` is opened, only `subgroup2/` and `subgroup3/` entries are listed for the user U.
But despite `subgroup1/` not being listed, it can still be opened directly by navigating to `/org_root/public/subgroup1/`.
### What is the expected *correct* behavior?
All subgroups (including `subgroup1`) should be listed for the user U on the `/org_root/public/`'s page.
### Relevant logs and/or screenshots
N/A
### Output of checks
This bug happens on GitLab.com
#### Results of GitLab environment info
N/A
#### Results of GitLab application Check
### Possible fixes
N/ABackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25368Modernize sorting and filtering in Your Work > Projects2024-03-24T13:05:59ZJeremy Watson (ex-GitLab)Modernize sorting and filtering in Your Work > Projects## Problem
The project dashboard at `/dashboard/projects` is intended to help with project search and discoverability. Currently, it uses a two-level tab design pattern to accomplish this. This is limited; the search options we offer on...## Problem
The project dashboard at `/dashboard/projects` is intended to help with project search and discoverability. Currently, it uses a two-level tab design pattern to accomplish this. This is limited; the search options we offer only allow filtering by name, and this leaves room for improvement on large instances (esp. at the scale of GitLab.com).
Also, the sort element on the projects page is a dropdown, but it should be a sort component.
While working on this issue, please keep in mind that there is additional functionality in development that might impact the design. A [project language filter](https://gitlab.com/gitlab-org/gitlab/-/issues/15490) is in development at the moment, and additional [build status filter](https://gitlab.com/gitlab-org/gitlab/-/issues/387526) is planned for the future.
## Proposal
Introduce [filtered search](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-filtered-search--default) on the project list page. Replace the existing sort dropdown with the [sorting component](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-sorting--default). A prototype of how this will work and look is available [here](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-sorting--default).
This change will improve the ability to search and filter the list page, create an opportunity to introduce additional filter options in future, and will better align the experience on the project list with the other list pages in the product, for example, the issue and MR lists.
![Screenshot_2024-02-29_at_10.34.14_AM](/uploads/5c6d96b22446b9cc33372dd0ce2a3d4e/Screenshot_2024-02-29_at_10.34.14_AM.png)
The changes included:
- Removing the double tabs under `Yours` and moving `Personal` to the main tab selection. There should be one line of tabs: `Yours`, `Starred`, `Personal` and `Pending Deletion`. Note that there is a [follow-up issue](https://gitlab.com/gitlab-org/gitlab/-/issues/18354) to update the tab names.
- Replacing current name search with the filtered search component. The first-pass [filters](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4314%3A53097&mode=design&t=XAlWieuYbsbLxhqO-1) for Contributed, Starred, Personal, and All tabs will include `Language` (using the existing language filter options) and `Role`. For the first pass, the role filter will narrow options by owner only; we'll add filters for additional roles as part of a follow-up. The filters for the [Inactive tab](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4380%3A72673&mode=design&t=XAlWieuYbsbLxhqO-1) will include `Status` (archived and pending deletion) and `Role` (owner). Future iteration could include a visibility filter.
- Updating to the sort component. [Sort options](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=4313%3A51922&mode=design&t=XAlWieuYbsbLxhqO-1) for all tabs will include `Name`, `Created date`, `Updated date` and `Stars`.
- Update documentation: https://docs.gitlab.com/ee/user/project/working_with_projects.html#search-in-projects
Note that tabs on this list page are being updated as part of https://gitlab.com/gitlab-org/gitlab/-/issues/18354+, so that work isn't included as part of the work on this issue.
[Figma](https://www.figma.com/file/lIKtBi5ENSNnz4ukZUzrN6/Modernize-sorting-and-filtering-on-Your-work-%3E-Projects?type=design&node-id=2806%3A40100&mode=design&t=VVePlbLO3Ww0d7IP-1) -- [Final designs in `Design` tab]
<details><summary>Old Proposals</summary>
### Filtering
The [segmented control](https://design.gitlab.com/components/segmented-control) (all / personal) that has been suggested further below is a deprecated component. We could get around this by removing that all together and in the filter have a token that represents personal projects. Perhaps it could be combined with `owner` and slightly renamed, like:
* `project type` `=` `owned by me` (I am the owner of a project, but the project can be under any namespace)
* `project type` `=` `personal` (I am the owner of the project and it is in my personal namespace)
:point_up_2_tone1: : the wording here might need to be improved. That means we have a only a filter bar and a sort component.
* Move options to show/hide archived projects and options about ownership that are currently listed in the dropdown to [filter component](https://design.gitlab.com/components/filter):
* `project type` `=` `archived`
* `owner` `=` `me`
### Sorting
* Update sorting to [sort component](https://design.gitlab.com/components/sorting)
![Screen_Shot_2022-09-23_at_12.04.40](/uploads/21b8599765894c1d6eecd46af527f8b0/Screen_Shot_2022-09-23_at_12.04.40.png)
* `Name` and `Name, descending` get merged to `Name`. Ascending and descending will be handled by the sorting component.
* `Updated date` and `Oldest updated` get merged to `Updated`. Ascending and descending will be handled by the sorting component.
* `Most stars` gets converted to `Stars`. Ascending and descending will be handled by the sorting component.
* `Last created` and `Oldest created` get merged to `Created`. Ascending and descending will be handled by the sorting component.
* The result should be in line with the sorting behaviour for groups:
![Screenshot_2022-12-06_at_19.10.45](/uploads/5e54ecbfff12ebb873b6cc5ebf0b8f6d/Screenshot_2022-12-06_at_19.10.45.png)
Add a full-width search bar with smart filter capabilities below the first-level tab bar.
| Tab | Current | Design |
| --- | ------- | ------ |
| Your projects | ![your-projects--current](https://gitlab.com/gitlab-org/gitlab/uploads/36e64625764fd506b1e57d193714e8ea/your-projects--current.png) |![your-projects](https://gitlab.com/gitlab-org/gitlab/uploads/f97e4e10f7e8728b3ba7dcfc691247fa/your-projects.png) |
| Starred projects | ![starred-projects--current](https://gitlab.com/gitlab-org/gitlab/uploads/3d4e3b9ecc35acfa773a1809512d5add/starred-projects--current.png) | ![starred-projects](https://gitlab.com/gitlab-org/gitlab/uploads/cefa095319c602ebf75ec0f067aeb17f/starred-projects.png) |
| Explore projects | ![explore-projects--current](https://gitlab.com/gitlab-org/gitlab/uploads/d69e46ab8543d037c4d3f374fe4964ec/explore-projects--current.png) | ![explore-projects](https://gitlab.com/gitlab-org/gitlab/uploads/db9e50c48f17c6679e8eec80c262224c/explore-projects.png) |
The changes to be made are:
- Second level of tabs: This secondary tab bar currently displayed under `Your projects` and `Explore projects` will be replaced with a segmented control to the left of the search bar. Clicking on the segmented control should automatically alter the list below.
- 'Most stars' view: Under 'Explore projects' there is currently a 'Most stars' view. This simply orders the list of public projects by star number. We will remove this option from the segmented control and rely on the sorting dropdown to achieve this ordering.
- Visibility dropdown: This dropdown will be removed, as it will be replaced with tokens in the search bar.
- Search bar: The current search bar performs the search as the user types. Since we will now have tokens, we should wait for the user to hit `Enter` or press the magnifying glass button to perform the search.
- The placeholder will be changed to `Search or filter projects…`
- Background color: Change the background color of the whole section to `#fafafa` to match the search in othe places, like Issues and MRs.
- Sorting dropdown: Add a `Sort by` label to its left and append an ascending/descending order button to its right. This will require a change to the options inside the dropdown:
| Current | New |
| ------- | --- |
| Last updated <br> Oldest updated | Last updated + `↑`/`↓` |
| Last created <br> Oldest created | Created date + `↑`/`↓` |
| Name | Name + `↑`/`↓` |
| Most stars | Stars + `↑`/`↓` |
#### Filtering
When the user starts typing, a dropdown with suggestions for the different filter types will pop up.
<img src="/uploads/604c57e06901a1c7efab75247af3442a/filtering__main-menu.png" width=400px>
Filtering will be done through tokens. The three types of filtering available will be:
- Visibility: Public, Internal or Private.
- Format: `visibility:level`
- Token format: Icon + visibilty level.
- Note: Visibilty filtering is currently only available under `Explore projects`. We need to make sure this can be applied to all tabs.
- Group: The group the project belongs to.
- Format: `group:@group`
- Token format: Avatar + full group name.
- Note: Should this be changed to Namespace? Projects can belong to users, not only groups.
- Topic: Project topics.
- Format: `topic:topic`
- Token format: Plain text.
- Note: These are not currently displayed in the list. Perhaps we should wait until gitlab-ce#54373 to add this type of filtering.
Since projects can only have one visibility level and parent group, once one these filters is applied, the corresponding option should be removed from the main menu. Only topic filtering accepts multiple values.
| Filter | Menu | Token |
| ------ | ---- | ----- |
| Visibility |<img src="/uploads/6d5bf509ea464db81177075dab648f3b/filtering__visibility.png" width=480px> | <img src="/uploads/dfbbc9c5161baab560c7274f2832f5f6/filtering__visibility--finished.png" width=400px> |
| Group | <img src="/uploads/eeec93105ea25fa9a2fbc4c7307e7a8f/filtering__group.png" width=560px> | <img src="/uploads/1a68999c15d5b2690828d94fec26922a/filtering__group--finished.png" width=400px> |
| Topic | <img src="/uploads/3855e7b396397c384547d45fe75f8323/filtering__topic.png" width=480px> | <img src="/uploads/583895b966f813b21287214e73dfe889/filtering__topic--finished.png" width=400px> |
#### Mobile
On mobile, the segmented control, search bar and sorting dropdown will all become full-width and appear stacked.
<img src="/uploads/8a58c06bdecd6c2d449fd1db18ce3c0f/mobile.png" width=400px>
#### Original proposal
* Introduce a filter bar below the three `Your projects`, `Starred projects`, and `Explore projects` options.
* The filter bar should use the same pattern we use in issues and boards.
* Users should be able to filter the project list by:
* Group
* Project topic
* Visibility level
</details>
Please see the related issues below for specific issues for UX and FE. Once all issues have been closed, this issue may also be closed.
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*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.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->17.0https://gitlab.com/gitlab-org/gitlab/-/issues/440851[MVC 1] DevOps Artifacts -- Create MR quick action and display of widget2024-03-27T22:42:18ZGabe Weavergweaver@gitlab.com[MVC 1] DevOps Artifacts -- Create MR quick action and display of widget## Problem
There is no way to associate a merge request to a work item from within the work item.
## Proposal
Create a ["hard linked" MR](https://gitlab.com/gitlab-org/gitlab/-/issues/353614) from `/create_merge_request <branch name>...## Problem
There is no way to associate a merge request to a work item from within the work item.
## Proposal
Create a ["hard linked" MR](https://gitlab.com/gitlab-org/gitlab/-/issues/353614) from `/create_merge_request <branch name>` quick action. Provide a way to define a target project in quick action. Ideally, project selection supports autocomplete. A project would be required when creating an MR from a group work item. It would be optional if the work item is owned by a project. The development widget updates in real time.
If a work item is referenced in an MR description, branch name, or commit message using the appropriate syntax, create a "hard" relationship to the referenced work item. The development widget updates in real time.
## UX
https://gitlab.com/gitlab-org/gitlab/-/issues/427975+16.11Alexandru CroitorMario CeliAlexandru Croitor