GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2022-11-07T20:08:47Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/2483Deploy boards needs to use actual_namespace2022-11-07T20:08:47ZMark PundsackDeploy boards needs to use actual_namespaceIf you leave the k8s service namespace blank, deploy boards can show extra, non-existent pods. It seems to need to be related to `actual_namespace` like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11653.If you leave the k8s service namespace blank, deploy boards can show extra, non-existent pods. It seems to need to be related to `actual_namespace` like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11653.9.2https://gitlab.com/gitlab-org/gitlab/-/issues/1904Multiple assignees for issues2022-05-19T17:05:13ZLiam BrownMultiple assignees for issues### Resources
UX @dimitrieh FE @ClemMakesApps BE @vsizov
### Docs blurb
<details>
GitLab is a tool that encourages everyone to contribute, and often multiple people likely work on the same issue together. This can especially be difficul...### Resources
UX @dimitrieh FE @ClemMakesApps BE @vsizov
### Docs blurb
<details>
GitLab is a tool that encourages everyone to contribute, and often multiple people likely work on the same issue together. This can especially be difficult to track in large teams where there is shared ownership of an issue, and those multiple folks may not work together day to day. With this release, GitLab enables you to assign as many users as you want to a given issue. Every one of those assignees are first class citizens, and receive the same notifications as before. With this change, you can now also search for issues for two or more assignees. Each search result will have at least the set of assignees you have specified.
</details>
### Description
* EE Starter Edition
* Multiple assignees for an issue
* Within an issue, view and edit the multiple assignees. Same existing permissions for these actions as now, for one assignee.
* No maximum number of assignees.
* The designs should be scalable to 7 assignees. But they don't have to look "good" beyond that. We expect users to use the feature responsibly and not just keep assigning too many people. And so we give the responsibility to them, rather than putting a restriction on the upper limit, since putting an upper limit requires additional work that is not worth it. We don't have upper limits for other fields (labels, participants). So from that perspective, we do not need to enforce an upper limit.
* If _there is_ a good reason to enforce an upper limit, that will be a future feature, not in scope here.
* When there is an update for an issue, GitLab triggers notification emails and todos for the assignee. For the scope of this issue, the only change is that those triggers happen multiple times for each assignee. That is, each assignee receives the same notification email and todo. Even if the email text copy is worded that implies one assignee, that does not change. That is out of scope for this issue.
* Searches in the search bar for issues list is a separate issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/28947
* Update issue export to dump multiple assignees, i.e. updating this https://gitlab.com/gitlab-org/gitlab-ee/issues/1480
### Out of scope
Merge requests are out of scope for this issue.
### Design
#### Issue and Issue board sidebar
__1 Assignee in the sidebar stay the same__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/ff43dde7c94f89eb70b6629f93900183/image.png)
__2 Assignees an onwards should be 5 Assignees per row in the sidebar__
![Group_3](https://gitlab.com/gitlab-org/gitlab/uploads/4ac6055b44ffd699527e60c0e9de12d2/Group_3.png)
__6 Assignees and more__
![Group_2](https://gitlab.com/gitlab-org/gitlab/uploads/1b3a00f92150a3b2166703fcee1c2301/Group_2.png)
__6 Assignees and more expanded__
![Group](https://gitlab.com/gitlab-org/gitlab/uploads/9bf4b39f77d7343bcb8caaccb9791eea/Group.png)
##### Closed sidebar
__1 assignee__
![Group_3_Copy](https://gitlab.com/gitlab-org/gitlab/uploads/5efecd0b77fb30f618941c72f8a6bf14/Group_3_Copy.png)
__2 Assignees__
![Group_3](https://gitlab.com/gitlab-org/gitlab/uploads/7c600ee0a1c664cdb43b0ececd290d96/Group_3.png)
__more than 2 assignees__
![Group_3_Copy_2](https://gitlab.com/gitlab-org/gitlab/uploads/d23fe9648065618e51a5672bd8c4b943/Group_3_Copy_2.png)
__more than 99 assignees__
![Group_3_Copy_3](https://gitlab.com/gitlab-org/gitlab/uploads/f2fb00f6a757e0f56f2109c94014b20d/Group_3_Copy_3.png)
##### Assigning an assignee from the sidebar
![image](https://gitlab.com/gitlab-org/gitlab/uploads/a61bfba9a8b5543aa60a490e4c948a8e/image.png)
#### Issue board cards
Following your "stacked" approach, we can show up to three pictures in the corner
| 1 assignee | 2 assignees | 3 assignees |
|------------|-------------|-------------|
| ![card--1-assignee](https://gitlab.com/gitlab-org/gitlab-ce/uploads/d70e4d38afc7d47025966004bdeb8ffa/card--1-assignee.png) | ![card--2-assignees](https://gitlab.com/gitlab-org/gitlab-ce/uploads/d109fb9cd9c3093abd452db931740fc3/card--2-assignees.png) | ![card--3-assignees](https://gitlab.com/gitlab-org/gitlab-ce/uploads/e755953874f0e8295e2b5e1242d4f38e/card--3-assignees.png) |
Through hovering or clicking on the pictures, we can expand them to show a little more detail. We can cover over the issue title with a transparency gradient and slide them out to the left. If there are 4 assignees, we can show them all, and if there are more than 4, we can use the fourth circle to indicate the number of remaining assignees
| 3 assignees | More than 4 assignees |
|-------------|-----------------------|
| ![card--3-assignees-expanded](https://gitlab.com/gitlab-org/gitlab-ce/uploads/dd12f491a7992909b00e9ce0211e006b/card--3-assignees-expanded.png) | ![card--3-plus-assignees-expanded](https://gitlab.com/gitlab-org/gitlab-ce/uploads/217aef3657b756e8a97fcd5cb421c6bf/card--3-plus-assignees-expanded.png) |
#### Issue list rows
__1 to 4 assignees__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/f021081a2de147d07c9f54564bd4e430/image.png)
__More than 4 assignees__
![img](https://gitlab.com/gitlab-org/gitlab-ce/uploads/6a9a8e44e8eee3a2b7147945c09922c9/image.png)
#### Slash commands
__Assigning__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/8b68d40242a7708b763342e9d5249fe1/image.png)
__Unassigning__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/2a9a19561c5e6f58e11cae8f9acb649a/image.png)
#### System note
Will follow this pattern, next to what is already there:
__assigned to multiple assignees at the same time__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/18f877fd84c31a47c0521500a6386785/image.png)
__Assigned to someone if there already is one or multiple assignees__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/2fb5fa35f56d5927432118bfaa991ecb/image.png)
__removed all assignees__
Show which assignees you unassigned, when you unassigned all assignees. (as this is valuable information).
Let's to this up to a max of 5 people.. and let the rest be shown as X others
![image](https://gitlab.com/gitlab-org/gitlab/uploads/4a9b3014606117fcf38f8d2aff18562f/image.png)
__removing assignee and assigning assignee__ (same logic as with labels)
![image](https://gitlab.com/gitlab-org/gitlab/uploads/80e06400e5c8ff8024ad3a94b54e77f7/image.png)
__removing assignee and assigning assignee while there still is/are another assignee(s)__
![image](https://gitlab.com/gitlab-org/gitlab/uploads/0e59ce5b8d605658fe5c15eb64dad5d6/image.png)
__extra note:__ Unassigned __from__ would be nice as in:
![img](https://gitlab.com/gitlab-org/gitlab-ce/uploads/ed58c56a6785e84d0b661e87036cdf3f/image.png)
#### Search
See: https://gitlab.com/gitlab-org/gitlab-ce/issues/28947
<!-- 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 -->9.2Valery SizovClement HoVictor Wuvictor@gitlab.comValery Sizovhttps://gitlab.com/gitlab-org/gitlab/-/issues/1565Global search for all project wikis2022-05-19T16:57:29ZFloGlobal search for all project wikis### Description
Problem: global search of all project wikis not possible
Use case: We maintain many different projects for different customers and every projects documentation is based on its gitlab EE wiki. Searching a wiki is only pos...### Description
Problem: global search of all project wikis not possible
Use case: We maintain many different projects for different customers and every projects documentation is based on its gitlab EE wiki. Searching a wiki is only possible if you know/remember the project name.
Benefit: No need of another documentation tool if you are able to search all wikis
~"feature proposal"
### Proposal
Enable global search for wikis
### Links / references
none9.2Nick ThomasNick Thomashttps://gitlab.com/gitlab-org/gitlab/-/issues/1526Suggest approvers in merge request - UX improvements2022-05-19T16:57:29ZVictor Wuvictor@gitlab.comSuggest approvers in merge request - UX improvements### Resources
PM @victorwu | FE @lbennett
### Problem
* In the existing implementation, the suggested approvers is below the entire section. It is not that helpful when you are actually choosing approvers.
<img src="/uploads/b550415ce3...### Resources
PM @victorwu | FE @lbennett
### Problem
* In the existing implementation, the suggested approvers is below the entire section. It is not that helpful when you are actually choosing approvers.
<img src="/uploads/b550415ce3323b089384da23854e3d89/Screen_Shot_2017-01-16_at_09.39.07.png" height="300px" />
* The new design of approvers selection (per project, and per merge request), is here: https://gitlab.com/gitlab-org/gitlab-ee/issues/1738
* This issue will also help with the selection of approvers themselves: https://gitlab.com/gitlab-org/gitlab-ee/issues/1593.
### Scope
* Re-design the UX of the suggested approvers to be inline with the above new design.
* The suggestion BE algorithm itself does not change. The scope of this issue is just integrating that suggestion on the FE in a coherent manner.
* The BE algorithm to change suggestions will be worked on in separate issues.
- This applies to the project settings area. The same area in the merge request web form should also be updated, but is a stretch goal for this issue. (I.e. if it's minor extra effort and can be done together easily without delay, let's include it as well.)
### Design
<img src="/uploads/71fd57a3bc57d6d6b0f95d8e4dfcffe4/Screen_Shot_2017-03-19_at_6.28.26_PM.png" width=70% />
`Add an approver / a group as an approver suggestion for each merge request` was replaced by `Suggested approvers: Username`.
![suggested-approvers](/uploads/3b44b650b52f5ab377cf8f17f795fb86/suggested-approvers.png)9.2Luke BennettLuke Bennetthttps://gitlab.com/gitlab-org/gitlab/-/issues/1442Add API URL or API Port to JIRA Integration2022-05-19T16:57:28ZRob CampbellAdd API URL or API Port to JIRA Integration### Description
We recently upgraded to 8.14.5-ee from 8.13.x-ee and in doing so lost some of the JIRA integration functionality that we previously utilized.
*JIRA Options pre-upgrade*:
- Description
- Project URL: https://jira.host/is...### Description
We recently upgraded to 8.14.5-ee from 8.13.x-ee and in doing so lost some of the JIRA integration functionality that we previously utilized.
*JIRA Options pre-upgrade*:
- Description
- Project URL: https://jira.host/issues/?jql=project=<YOUR-JIRA-PROJECT-HERE>
- Issues URL: https://jira.host/browse/:id
- New Issue URL: https://jira.host/secure/CreateIssue.jspa
- API URL: https://jira.host:8446/rest/api/2
- Username
- Password
- JIRA Issue Transition
*JIRA Options post-upgrade*:
- URL: https://jira.host:8446
- Project key: PROJECT
- Username
- Change Password
- Jira issue transition
The use case is that our API calls utilize a non-standard port due to our JIRA instance living in a VM environment that where :non-standard-port is PAT'd to 443. We were able to obtain the intended functionality by setting the API URL to `jira.host:port` while the other URLs were set to `jira.host` and were able to resolve properly due to host-headers being in place.
You'll see in the Screenshot below that the URL shows `jira.host:8446`. This does not resolve in-browser and is generated due to the URL in the integration being set to jira.host:8446. Currently we're choosing to maintain API functionality (so commits and MRs are added in JIRA), instead of having URLs rendering properly in Gitlab.
### Screenshot
![Screen_Shot_2016-12-21_at_2.27.27_PM](/uploads/4e88b85af10072607f7fa3db9d0bf634/Screen_Shot_2016-12-21_at_2.27.27_PM.png)
### Proposal
Add API URL or an API Port field to the JIRA integration for non-standard port usage.9.2https://gitlab.com/gitlab-org/gitlab/-/issues/1798Rename Jenkins services2022-05-19T16:55:20ZRobert SchillingRename Jenkins servicesWe have a deprecated Jenkins project service.
We should rename the two services to 'Jenkins GitLab Plugin' and 'Jenkins GitLab Hook Plugin'.We have a deprecated Jenkins project service.
We should rename the two services to 'Jenkins GitLab Plugin' and 'Jenkins GitLab Hook Plugin'.9.2https://gitlab.com/gitlab-org/gitlab/-/issues/2037Search exact phrase2022-05-19T16:54:20ZVictor Wuvictor@gitlab.comSearch exact phrase* Elasticsearch-only
* ~"EE Starter"
* Search for an exact phrase in an exact order.
* Capitalization and punctuation is ignored.
* Applies to all search fields in GitLab, including issue search bar, merge request search bar, and top ri...* Elasticsearch-only
* ~"EE Starter"
* Search for an exact phrase in an exact order.
* Capitalization and punctuation is ignored.
* Applies to all search fields in GitLab, including issue search bar, merge request search bar, and top right search bar on all pages.
* Use double quotes as the syntax, i.e. `"Hello terrible world"`
* Same as what is described here: https://www.google.com/intl/en_u/insidesearch/tipstricks/all.html.9.2Nick ThomasNick Thomashttps://gitlab.com/gitlab-org/gitlab/-/issues/1976Re-word Board to Boards in navigation2022-05-19T16:54:16ZVictor Wuvictor@gitlab.comRe-word Board to Boards in navigation### Resources
FE @lbennett
### Description
In EE we have multiple boards. Our nav should reflect that.
I thought we had an issue for it, or maybe it was in some nav issue and got lost.### Resources
FE @lbennett
### Description
In EE we have multiple boards. Our nav should reflect that.
I thought we had an issue for it, or maybe it was in some nav issue and got lost.9.2Luke BennettLuke Bennetthttps://gitlab.com/gitlab-org/gitlab/-/issues/2379Elastic indexing task does not handle errors properly2022-05-19T16:51:54ZValery SizovElastic indexing task does not handle errors properlyReproduced on EE master. I don't have any index in ES server. I run `rake gitlab:elastic:index`.
I see this
```
$ be rake gitlab:elastic:index
Index created
Index status has been reset
Indexing project repositories...I, [2017-05-10T19:1...Reproduced on EE master. I don't have any index in ES server. I run `rake gitlab:elastic:index`.
I see this
```
$ be rake gitlab:elastic:index
Index created
Index status has been reset
Indexing project repositories...I, [2017-05-10T19:19:24.461874 #95161] INFO -- : Indexing Gitlab Org / Gitlab Test (ID=1)...
I, [2017-05-10T19:19:28.184211 #95161] INFO -- : Indexing Gitlab Org / Gitlab Test (ID=1) is done!
I, [2017-05-10T19:19:28.185730 #95161] INFO -- : Indexing Gitlab Org / Gitlab Ce (ID=2)...
I, [2017-05-10T19:20:01.113759 #95161] INFO -- : Indexing Gitlab Org / Gitlab Ce (ID=2) is done!
I, [2017-05-10T19:20:01.115423 #95161] INFO -- : Indexing Gitlab Org / Gitlab Ci (ID=3)...
I, [2017-05-10T19:20:06.334836 #95161] INFO -- : Indexing Gitlab Org / Gitlab Ci (ID=3) is done!
I, [2017-05-10T19:20:06.335931 #95161] INFO -- : Indexing Gitlab Org / Gitlab Shell (ID=4)...
I, [2017-05-10T19:20:10.322744 #95161] INFO -- : Indexing Gitlab Org / Gitlab Shell (ID=4) is done!
I, [2017-05-10T19:20:10.323933 #95161] INFO -- : Indexing Documentcloud / Underscore (ID=5)...
I, [2017-05-10T19:20:14.978830 #95161] INFO -- : Indexing Documentcloud / Underscore (ID=5) is done!
I, [2017-05-10T19:20:14.980447 #95161] INFO -- : Indexing Twitter / Flight (ID=6)...
I, [2017-05-10T19:20:18.709942 #95161] INFO -- : Indexing Twitter / Flight (ID=6) is done!
I, [2017-05-10T19:20:18.710907 #95161] INFO -- : Indexing Twitter / Typeahead.Js (ID=7)...
I, [2017-05-10T19:20:22.657519 #95161] INFO -- : Indexing Twitter / Typeahead.Js (ID=7) is done!
I, [2017-05-10T19:20:22.658468 #95161] INFO -- : Indexing H5bp / Html5 Boilerplate (ID=8)...
I, [2017-05-10T19:20:26.971866 #95161] INFO -- : Indexing H5bp / Html5 Boilerplate (ID=8) is done!
I, [2017-05-10T19:20:27.058812 #95161] INFO -- : Indexing Projects...
I, [2017-05-10T19:20:27.059252 #95161] INFO -- : Indexing Issues...
I, [2017-05-10T19:20:27.060184 #95161] INFO -- : Indexing MergeRequests...
I, [2017-05-10T19:20:27.060557 #95161] INFO -- : Indexing Snippets...
I, [2017-05-10T19:20:27.060960 #95161] INFO -- : Indexing Notes...
I, [2017-05-10T19:20:27.061711 #95161] INFO -- : Indexing Milestones...
I, [2017-05-10T19:20:27.508879 #95161] INFO -- : Indexing Projects... done
I, [2017-05-10T19:20:27.556806 #95161] INFO -- : Indexing MergeRequests... done
I, [2017-05-10T19:20:27.692020 #95161] INFO -- : Indexing Snippets... done
I, [2017-05-10T19:20:28.277658 #95161] INFO -- : Indexing Issues... done
I, [2017-05-10T19:20:30.533979 #95161] INFO -- : Indexing Notes... done
rake aborted!
ArgumentError: gitlab-development does not exist to be imported into. Use create_index! or the :force option to create it.
/Users/valery/.rvm/gems/ruby-2.3.3/gems/elasticsearch-model-0.1.9/lib/elasticsearch/model/importing.rb:118:in `import'
/Users/valery/.rvm/gems/ruby-2.3.3/gems/elasticsearch-model-0.1.9/lib/elasticsearch/model.rb:116:in `import'
/Users/valery/gdk-ee/gitlab/app/models/concerns/elastic/application_search.rb:111:in `import_with_parent'
/Users/valery/gdk-ee/gitlab/lib/tasks/gitlab/elastic.rake:83:in `block (4 levels) in <top (required)>'
Tasks: TOP => gitlab:elastic:index_database => gitlab:elastic:index_milestones
(See full trace by running task with --trace)
~/gdk-ee/gitlab
```
cc @nick.thomas
@smcgivern I think we should fix that before relase9.2Valery SizovValery Sizovhttps://gitlab.com/gitlab-org/gitlab/-/issues/2365[API] Mention in the release blog post that we have deprecated assignee_id fo...2022-05-19T16:51:53ZValery Sizov[API] Mention in the release blog post that we have deprecated assignee_id for issues/cc @smcgivern/cc @smcgivern9.2Victor Wuvictor@gitlab.comVictor Wuvictor@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/2272Approvals sentence is wrong when everyone needs to approve it2022-05-19T16:51:41ZSean McGivernApprovals sentence is wrong when everyone needs to approve it![image](/uploads/4c07fead988ccc6c3b95d96bc673055c/image.png)
This is only wrong for the case where the number of approvals is equal to the number of approvers in the list.
If there are more approvers in the list than approvals require...![image](/uploads/4c07fead988ccc6c3b95d96bc673055c/image.png)
This is only wrong for the case where the number of approvals is equal to the number of approvers in the list.
If there are more approvers in the list than approvals required:
> Requires 2 more approvals (from Sean McGivern, Robert Speicher, or Jacob Schatz)
If there are fewer approvers in the list than approvals required:
> Requires 1 more approval (from Sean McGivern or Jacob Schatz)
So it's only in the case where they are equal, where it should say _and_, not _or_ :slight_smile:
This is actually implemented correctly in the backend, but apparently we don't use that helper any more: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/helpers/merge_requests_helper.rb#L1019.2Sean McGivernSean McGivernhttps://gitlab.com/gitlab-org/gitlab/-/issues/2235Using up arrow to edit last comment in a discussion focus the last comment of...2022-05-19T16:51:40ZFilipa LacerdaUsing up arrow to edit last comment in a discussion focus the last comment of the merge request insteadTried to edit the last comment of a discussion by using the up arrow and instead the page scroll down to last comment of the Merge Request and made that one editable:
![up_arrow](/uploads/72cbc037ceeafa5b7f773db88a1c7cbb/up_arrow.gif)Tried to edit the last comment of a discussion by using the up arrow and instead the page scroll down to last comment of the Merge Request and made that one editable:
![up_arrow](/uploads/72cbc037ceeafa5b7f773db88a1c7cbb/up_arrow.gif)9.2https://gitlab.com/gitlab-org/gitlab/-/issues/2556Approvers don't appear when MR is created from a fork2022-05-19T16:50:30ZCindy Pallares 🦉cindy@gitlab.comApprovers don't appear when MR is created from a fork### Summary
When creating a merge request from a fork, attempting to add any approver that is a member of the group in the merge request box for approvals will result in "No matches found".
### Steps to reproduce
1. Fork a project tha...### Summary
When creating a merge request from a fork, attempting to add any approver that is a member of the group in the merge request box for approvals will result in "No matches found".
### Steps to reproduce
1. Fork a project that has approvals enabled.
2. Create a merge request
3. Type a member of that group as an approver
### What is the current *bug* behavior?
Drop down displays "No matches found"
### What is the expected *correct* behavior?
The approver should appear in the dropdown.
### Relevant logs and/or screenshots
![Pasted_Image_6_2_17__5_26_PM](/uploads/87839e9f00dcda3d975edc9f62355516/Pasted_Image_6_2_17__5_26_PM.png)
#### Results of GitLab environment info
9.2.0
https://gitlab.zendesk.com/agent/tickets/783669.2Sean McGivernSean McGivernhttps://gitlab.com/gitlab-org/gitlab/-/issues/2473Issue board focus mode is broken2022-05-19T16:50:28ZVictor Wuvictor@gitlab.comIssue board focus mode is brokenCan't toggle out
https://docs.gitlab.com/ee/user/project/issue_board.html#focus-mode
![2017-05-23_16.23.43](/uploads/716b686a898d185432dfd5c49da523bd/2017-05-23_16.23.43.gif)Can't toggle out
https://docs.gitlab.com/ee/user/project/issue_board.html#focus-mode
![2017-05-23_16.23.43](/uploads/716b686a898d185432dfd5c49da523bd/2017-05-23_16.23.43.gif)9.2Phil HughesPhil Hugheshttps://gitlab.com/gitlab-org/gitlab/-/issues/2470/unassign command does not work as expected with multiple assignees2022-05-19T16:50:28ZAndrew Newdigateandrew@gitlab.com/unassign command does not work as expected with multiple assignees### Assigning
CE: `/assign @user Assign user`
EES: `/assign @user1 @user2 Assign user(s)`
### Unassigning
CE: `/unassign @user Remove assignee`
CE `/unassign` (Unassigns yourself)
EES: `/unassign @user1 @user2 or @all-assignees Remov...### Assigning
CE: `/assign @user Assign user`
EES: `/assign @user1 @user2 Assign user(s)`
### Unassigning
CE: `/unassign @user Remove assignee`
CE `/unassign` (Unassigns yourself)
EES: `/unassign @user1 @user2 or @all-assignees Remove assignee(s)`
EES `/unassign` (Unassigns yourself)
### System notes
Specified in description of https://gitlab.com/gitlab-org/gitlab-ee/issues/1904.
<details>
<summary>Original description</summary>
<pre>
I have an issue assigned to multiple assignees, `@user-a` and `@user-b`
I used `/unassign @user-b` to remove `@user-b` from the issue.
I expected the assignment list to still have `@user-a` as an assignee, but the slash command had the effect of removing all assignees.
</pre>
</details>
### Design
| Command | Action |
|---------|--------|
| `/assign @user1 @user2` | Assign user(s) |
| `/unassign @user1 @user2` | Remove all or specific assignee(s) |
| `/reassign @user1 @user2` | Reassign to user(s) |
We don't need a special command to assign to the current user; we don't currently have this for non-multiple-assignee `/assign` either. When you type `/ass[TAB]`, it will automatically autocomplete to `/assign @`, which will show the dropdown with the current user's username high up in the list.
This is consistent with the current slash commands for labels:
| Command | Action |
|---------|--------|
| `/label ~foo ~"bar baz"` | Add label(s) |
| `/unlabel ~foo ~"bar baz"` | Remove all or specific label(s) |
| `/relabel ~foo ~"bar baz"` | Replace all label(s) |
And mostly consistent with non-multiple-assignee slash commands in CE, which is important for people upgrading, with the only difference being that `/assign` adds to the current assignee(s) instead of overwriting them, but I think that makes sense:
| Command | Action |
|---------|--------|
| `/assign @username` | Assign |
| `/unassign` | Remove assignee |9.2Valery SizovValery Sizovhttps://gitlab.com/gitlab-org/gitlab/-/issues/2385Rebase button disabled when merge request hasn't been approved2022-05-19T16:50:25ZAdam MulvanyRebase button disabled when merge request hasn't been approved------
### Description
As requested by customer:
> we noticed that gitlab now enforces us to really approve not just by adding :thumbsup but by really clicking approve button.
> However, as you can see in the screenshot below this se...------
### Description
As requested by customer:
> we noticed that gitlab now enforces us to really approve not just by adding :thumbsup but by really clicking approve button.
> However, as you can see in the screenshot below this seems not to be really working well with rebase strategy at the moment.
Look, the branch is 19 commits behind and one cannot rebase it until it has been approved. Since during a normal working day we move rather fast, we need a simple way to rebase a branch. The “rebase branch” button from gitlab was very helpful in this sense.
> Is it possible to allow rebasing, even if no approves has been made? Otherwise it slows us down a lot and we might prefer to go back to our old strategy.
Note the message displayed to the user:
> Rebasing is disabled until merge request has been approved
Found in file:
app/views/projects/merge_requests/widget/open/_rebase.html.haml
Above file appears to be removed in !MR1711 so I'm no longer sure where this is handled.
### Proposal
Enable rebase before merge request has been approved.
### Links / references
ZD: https://gitlab.zendesk.com/agent/tickets/76177
Possibly affected by:
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1711
### Documentation blurb
1. Why should someone use it; what's the underlying problem.
- Customer requires rebase often and disabling this feature until an MR has been approved causes significant delays to their workflow.
2. What is the solution.
- Reverse the behavior "Rebasing is disabled until merge request has been approved"
3. How does someone use this
- Rebase button should be enabled, instead of disabled.9.2https://gitlab.com/gitlab-org/gitlab/-/issues/2433Locked milestone should not be remove-able for milestone-associated board2021-11-08T16:24:42ZVictor Wuvictor@gitlab.comLocked milestone should not be remove-able for milestone-associated board- For boards that are associated with a board, the milestone filter is locked into the search bar.
- The milestone filter should not be able to removed.
- With the 9.2 release that includes the `x`, you can now remove it by clicking `x`....- For boards that are associated with a board, the milestone filter is locked into the search bar.
- The milestone filter should not be able to removed.
- With the 9.2 release that includes the `x`, you can now remove it by clicking `x`. (https://gitlab.com/gitlab-org/gitlab-ce/issues/30466#note_28308230).
- This should not be the case. The `x` should not be there in this case.
![Screen_Shot_2017-05-18_at_14.12.12](/uploads/1f24e9ecf7b8da1bb5a66f0210942065/Screen_Shot_2017-05-18_at_14.12.12.png)9.2Eric Eastwoodcontact@ericeastwood.comEric Eastwoodcontact@ericeastwood.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/2222Deploy boards polling should use new polling mechanism2021-06-01T05:02:23ZFilipa LacerdaDeploy boards polling should use new polling mechanismDeploy boards currently have 2 ways of polling:
- Uses backoff polling to do the 1st request.
- Uses a fixed interval to update the data
It should be using the new polling mechanism with etag support and visibility API.Deploy boards currently have 2 ways of polling:
- Uses backoff polling to do the 1st request.
- Uses a fixed interval to update the data
It should be using the new polling mechanism with etag support and visibility API.9.2https://gitlab.com/gitlab-org/gitlab/-/issues/1493Geo: Improve Repository Sync2020-05-14T14:35:23ZGabriel MazettoGeo: Improve Repository SyncThis is a follow up on https://gitlab.com/gitlab-org/gitlab-ee/issues/1463 issue. We've implemented a partial fix for Geo (#76), that will prevent or reduce the chance of concurrent updates filling up the repository in the secondary node...This is a follow up on https://gitlab.com/gitlab-org/gitlab-ee/issues/1463 issue. We've implemented a partial fix for Geo (#76), that will prevent or reduce the chance of concurrent updates filling up the repository in the secondary node with useless data.
When a git push starts the client sends a bunch of packed objects to the other side and at the end it "commit" the changes to the repository. When multiple clients are trying to update the same information at the same time, at the end only one will finish, but you will end-up with multiple waste from the other tries.
This is a situation where you have to execute `git gc` to cleanup the repository.
We currently experienced this type of issue, because we were using `push` and `tag_push` events from `SystemHook`. There is a proposal to add a different event: https://gitlab.com/gitlab-org/gitlab-ce/issues/26325 that will notify in a single request all the relevant data.
This is part of the solution. By not sending one notification for each changed branch in a push, we reduce the chance of concurrent updates, but if multiple different pushes happen very close to each other, there is still a chance that a few will execute concurrently with the same data (the current state of the repository).
# Proposal
There are two things we can do here, after start using the new SystemHook:
1. We need to start increasing the repository GC counter, in the secondary node, so eventually a GC will run and will cleanup the repository
1. We can also introduce an execution lock (so only one repository update for the same repository will happen at the same time).
For the execution lock, my initial idea was to use https://github.com/mhenrixon/sidekiq-unique-jobs, but as @yorickpeterse said, we can't use any gem that hijacks Sidekiq's fetching API as we already use https://github.com/brainopia/sidekiq-limit_fetch. (See discussion: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1015#note_20888051)
As we can't use that Gem, and we will already reduce the impact on the notification generation side, we can use a simpler alternative: `Gitlab::ExclusiveLease`. This is already being used by the GC Job.
The new SystemHook will either require the current information per-branch that we use to decide upon the cache invalidation strategy, or we will have to figure out a different cache invalidation heuristic. (For the patch in https://gitlab.com/gitlab-org/gitlab-ce/issues/26325 we are always invalidating everything, which is not ideal).
cc @smcgivern @dbalexandre @rspeicher @stanhu @DouweM @yorickpeterse @dblessing
# Checklist
- [x] New SystemHook (!1789)
- [x] Backport SystemHook changes to CE (gitlab-org/gitlab-ce!11140)
- [x] Documentation for the new SystemHook (gitlab-org/gitlab-ce!11140)
9.2Gabriel MazettoGabriel Mazettohttps://gitlab.com/gitlab-org/gitlab/-/issues/2241Service ping times out due to Service count2020-02-24T21:58:12ZStan HuService ping times out due to Service countI noticed GitLab.com usage pings weren't going through, and then I found this Sentry error:
https://sentry.gitlap.com/gitlab/gitlabcom/issues/26258/
Unfortunately, it looks like the database statement timeout is occurring here:
```rub...I noticed GitLab.com usage pings weren't going through, and then I found this Sentry error:
https://sentry.gitlap.com/gitlab/gitlabcom/issues/26258/
Unfortunately, it looks like the database statement timeout is occurring here:
```ruby
services: Service.where(active: true).count
```
/cc: @ernstvn, @regisF, @rdavila
It's probably due to a sequence scan since filtering by all active Services isn't really a common activity.9.2