Improve performance of viewing individual issues
This MR does two things:
1. `Issue#related_branches` no longer performs Git operations that aren't needed
2. The output of `Repository#exists?` is now cached and flushed properly
Combined these two changes should further cut down the amount of Git operations performed when viewing individual issues (and possibly other pages).
See merge request !3296
These tests would check if the "This project is empty" banner would
contain SSH clone URLs. Oddly enough this should have never passed (as
far as I can tell) as SSH clone URLs in this banner are _only_ displayed
if the current user has at least 1 SSH key attached. Since the tests
never seem to create any they never should have passed, yet somehow they
did. To solve this the Spinach tests in question now ensure at least 1
SSH key is present.
Adds small AJAX optimistic functionality to todos.
Fixes#13656 <br/>
A good first step and boring solution. <br/>
Will make ajax call to remove each issue. <br/>
If issue is last in group of issues will refresh page. <br/>
If issues remain in group will remove row with JS. <br/>
Adds loading spinner to button and disables. <br/>
 <br/>
cc @dzaporozhets @JobV @dbalexandre
See merge request !2946
1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
1. Allow subscribing (the current user) to a label
- Refactor the `Subscription` coffeescript class
- The main change is that it accepts a container, and conducts all
DOM queries within its scope. We need this because the labels
page has multiple instances of `Subscription` on the same page.
2. Creating an issue or MR with labels notifies users subscribed to those labels
- Label `has_many` subscribers through subscriptions.
3. Adding a label to an issue or MR notifies users subscribed to those labels
- This only applies to subscribers of the label that has just been
added, not all labels for the issue.
Revert the avatar cropping feature
Reverts !2951 since the added 'mini_magick' dependency should be replaced by client-side croppping
See merge request !3223
Cleanup Ci::Commit, Ci::Build and CommitStatus views
This MR tries to do first sweep of cleanups to Ci::Commit and
Ci::Build objects removing all view-related functions and fixing the
API from other side.
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/6046
See merge request !2760
Bring from EE: Share Project with Group
- [x] Models and migrations
- [x] Logic, UI
- [x] Tests
- [x] Documentation
- [x] Share with group lock
- [x] Api feature
- [x] Api docs
- [x] Api tests
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
For #12831
cc @DouweM @rspeicher @vsizov
See merge request !3186
- Remove all view related methods from Ci::Build and CommitStatus
- Remove unused Ci::Commit and Ci::Build methods
- Use polymorphism to render different types of CommitStatus
Added discard button to comment form
Also changed the labels on the buttons to better match the action they are completing.
Closes#8057
See merge request !3085
Add error for ajax:error when submitting comments
Fixes#13814

cc @dblessing
See merge request !2976
These three tests were essentially checking that adding a note to
something updated its `noteable`'s `updated_at` attribute.
This is well-tested Rails behavior and we shouldn't feel the need to
write an integration test to verify it. At most we should be ensuring
that the association definition adds the `touch: true` option, which we
now do in Note's unit test.
Indicate when an MR diverged from the target branch
This adds an indicator to the "Merge MR" box, to tell if and how much an MR diverged from its target branch.
For instance, consider an MR to merge the branch `feature` into `master`. Some other commits were added to `master` since `feature` was created, and the two branches diverged.
```text
o master
|
o o feature
| |
o o
| /
o
```
In this case, there will be a label in the MR Merge box stating:
> This MR is by 3 commits behind the target branch `master`.
## Screenshots
### The branch diverged from the target (UI Proposal)

### The branch diverged from the target (alternative UI Proposal)

## How is this useful?
- In a _rebase-workflow_ (MR are preferably rebased before being merged), the reviewer wants to know if an MR is rebased on the target branch before merging it.
_With this indicator, the reviewer knows immediately if the branch is rebased, or if she needs to ask the committer to rebase its branch._
<br>
- To keep the git history readable, a team prefers to avoid merging branches that really lag a lot behind the target branch. Merging an MR that is 10 commits behind is fine, but 200 is too much.
_With this indicator, the reviewer can see on the MR page if the branch is really far behind the target – or only a few commits behind._
## Open questions
We've been using this at @captaintrain for a few months now, and found it quite useful.
I guess the open-questions are mostly: what UI would be the more adequate? Any thoughts on this, on the general usefulness and/or on the code?
See merge request !2217