Ability to move issue to another project
Tasks:
- [x] Create scaffold of service that will move issue to another project.
- [x] Close old issue, add system note about moving issue to a new project.
- [x] Create a new issue, add system note about issue being moved from old project.
- [x] Check if issue can be moved to another project before executing service
- [x] Check permissions when moving an issue (`:admin_issue` ability)
- [x] Display select box for a new project when editing an issue
- [x] Show only projects that issue can be moved into in that select box
- [x] Add project select handler, helper and some permission filters to it
- [x] Preserve as much information as possible, including author
- [x] Prepare mechanisms that unfolds local references in issue description
- [x] Rewrite issue description with references unfolding and add some specs for it
- [x] Rewrite all system notes and comments attached to issue that is being moved
- [x] Update `Label` so that is was able to create cross reference labels (separate MR)
- [x] Add notifications about moving issue to another project
- [x] Display confirmation alert/message when issue move has been requested
- [x] Make it possible to undo selecting project where issue will be moved to
- [x] Add column to issue, that will indicate if it has been moved to another project
- [x] Do not allow to move issue that has been already moved
- [x] Write top-to-bottom feature spec in RSpec instead of Spinach
UI:
Closes#3024
See merge request !2831
* master:
Fix bug where wrong commit ID was being used in a merge request diff to show old image
Remove CHANGELOG item that was added during merge resolution
Improve the "easy WIP & un-WIP from link" feature
Fix specs
\#to_branch_name now uses the iid as postfix
Add label description in tooltip to labels in issue index and sidebar
Easily (un)mark merge request as WIP using link
Use specialized system notes when MR is (un)marked as WIP
another attempt to fix oauth issue
attempting to fix omniauth problem
Conflicts:
app/assets/javascripts/issuable_form.js.coffee
In the real world a project always has a repository. This fact allows
code such as Issue#related_branches to work without explicitly checking
if a repository exists.
This caches the output of Repository#exists? in Redis while making sure
it's flushed properly when creating new repositories, deleting them,
etc.
For the ProjectWiki tests to work I had to make ProjectWiki#create_repo!
public as testing private methods in RSpec is a bit of a pain.
Requesting the branch names of a repository works even when it's empty,
thus there's no need to explicitly check for an empty repository.
Removing this check cuts down the amount of Git operations which in turn
cuts down request timings a bit. The regular expression used to compare
branches was also moved out of the loop so it's created only once.
Easily (un)mark merge request as WIP using link
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/3768 and https://gitlab.com/gitlab-org/gitlab-ce/issues/3516
## Link to add `WIP` prefix (underline is visible because of hover)
## Link to remove `WIP` prefix
## System note after WIP is added
## Widget with link to remove WIP
## Flash after WIP is removed
## System note after WIP is removed
## Widget when current user cannot remove the WIP prefix
cc @creamzy
See merge request !3006
Add label description in tooltip to labels in issue index and sidebar
The tooltip can get quite big, but it’s so useful to inform people about what these labels mean
new
@JobV writes on Slack:
> yeah I think it’s better than not, but I’d have to try it 😃
>
> cautious yes, revert if it’s annoying 😉
See merge request !3124
#to_branch_name now uses the iid as postfix
Given the branch name 'mep-mep' with an iid being 1,
the current way, master's way, would yield a branch name of
1-mep-mep. The problem for larger projects however would be that
a developer might forget what iid the issue was.
When this developer would try to tab complete it would:
- Or result in 20+ branches possibly
- Or start with the wrong digit, try again with digit++
- Would see 20 branches, repeat
Thus the obvious way of solving this is letting the dev tab complete
on the issue title, which is easier to remember.
@DouweM Should this be labelled `pick-in-master`?
See merge request !3308
* master: (121 commits)
Dedupe labels in labels selector in Dashboard pages
Refactor colors and lists
Add a safeguard in MergeRequest#compute_diverged_commits_count
Fix an issue when the target branch of a MR had been deleted
Add avatar to issue and MR pages header
Cleanup somce css colors
Re-group scss variables
Refactor `Todo#target`
Fixes issue with filter label missing on labels & milestones
Rename `Todo#to_reference` to `Todo#target_reference`
Fixed failing tests
Updated controller with before_action Fixed other issues based on feedback
Fixes issue on dashboard issues
Full labels data in JSON
Fixed issue with labels dropdown getting wrong labels
Update CHANGELOG
Use `Note#for_project_snippet?` to skip notes on project snippet
Use `Commit#short_id` instead of `Commit.truncate_sha`
Reuse `for_commit?` on conditional validations
Update schema info comment on todo related files
...
Conflicts:
app/models/issue.rb
db/schema.rb
spec/models/issue_spec.rb
Given the branch name 'mep-mep' with an iid being 1,
the current way, master's way, would yield a branch name of
1-mep-mep. The problem for larger projects however would be that
a developer might forget what iid the issue was.
When this developer would try to tab complete it would:
- Or result in 20+ branches possibly
- Or start with the wrong digit, try again with digit++
- Would see 20 branches, repeat
Thus the obvious way of solving this is letting the dev tab complete
on the issue title, which is easier to remember.
Fix MergeRequest#source_sha when there is no diff
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14170
### Overview
This MR fixes an unhandled Exception when visiting the page of an open Merge Request without diff.
### Description
`MergeRequest#source_sha` is expected to return the sha of the source branch last commit. But when an open Merge Request has no diff (e.g. all commits have already been merged to the target branch), `merge_request.source_sha` incorrectly returns `nil`.
This was without consequences before – but since !2217 was merged (a few days ago), it makes `Gitlab::Git::Commit.between` raise an "Unexpected nil argument" exception. This can be reproduced when visiting the http://localhost:3000/gitlab-org/gitlab-test/merge_requests/2 page on a fresh local Gitlab setup.
This MR fixes the crash, by making sure that `source_sha` returns a
correct result even when there is no diff available. I also added tests.
@DouweM I believe you wrote most of this code in the first place ; does this looks correct to you, or is there a better way to resolve this issue maybe?
See merge request !3135
Changing filter dropdowns shows loading
Instead of doing a full refresh of the page - i've modified the filterResults method on the Issues object to work for this form as well
Closes#14359
See merge request !3237
Kamil Trzciński
Douwe Maan
Arinde Eniola
Grzegorz Bizon
Stan Hu
Yorick Peterse
Zeger-Jan van de Weg
Jacob Schatz
Douwe Maan
Felipe Artur
Rémy Coutable
Robert Speicher
Douglas Barbosa Alexandre
Jacob Vosmaer
Phil Hughes