| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The issue was fixed in 2ba5e62. The spec is going in separately just
so the fix could go in as soon as possible.
|
|
|
| |
This reverts merge request !4970
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Revert "Optimistic locking for Issue and Merge Requests"
The migration to add `lock_version` in !5146 to every issue and merge request takes too long on GitLab.com since it has to add a default value of 0 to every row. Unfortunately, Rails 4.2 doesn't work properly if the value is left as `nil`; anything using optimistic locking cannot be edited.
This bug was fixed in Rails 5.0 via this commit: https://github.com/rails/rails/commit/13772bfa49325a8dc26410d2dcb555665a320f92. I suggest we revert this change for now, and when we upgrade to Rails 5.0 we can reintroduce this feature.
See merge request !5245
|
| |
| |
| |
| | |
This reverts commit c39356998b1850f3dc26fe0b987cb419c1d1afb4.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GL dropdowns in issuable form
## What does this MR do?
Changed all the issuable dropdown menus over to user GL dropdowns. This brings the dropdowns to be inline with the issuable filter dropdowns and allows for labels to be created whilst creating/editing an issuable.
## What are the relevant issue numbers?
Closes #12574
## Screenshots (if relevant)
See merge request !4970
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
With the option to expand and collapse individual diffs, these aren't
needed any more.
|
| |/ |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Workhorse to serve raw diffs
Fixes (partially) #13999
Dependent on: gitlab-org/gitlab-workhorse!45
See merge request !4130
|
| | |
|
|/
|
|
| |
The buttons were rarely used and added at least 1 query each on every page load.
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
| |
Mostly replaces several Spinach tests with RSpec Feature tests.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Mutliple label filter
Fixes #989
See merge request !3438
|
| | |
|
|/
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Updated UI for new merge request
Closes #2540


See merge request !3228
|
| | |
|
|/
|
| |
This reverts merge request !3494
|
|
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
before the search field is focused
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Fixes "iid of max iid" in Issuable sidebar for merged MR
Fixes #13928.
See merge request !3046
|
| |
| |
| |
| | |
Fixes #13928
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |/
| |
| |
| | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
|/
|
|
| |
Closes #13982
|
|\
| |
| |
| |
| |
| |
| | |
Don't repeat labels listed on Labels tab.
Fixes #13622
See merge request !2924
|
| | |
|