| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| |\ \ |
|
| | |/ |
|
| | | |
|
| |/
|
|
| |
Fixes #12518
|
| |\
| |
| |
| |
| |
| |
| | |
Labels should be visible in milestone view
Closes #3276
See merge request !2599
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
workaround for forks with an invalid repo
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/13465
The error occurs when a project returns a `nil` commit for a variety of reasons, I assume the repository is corrupt - perhaps as a result of a failed fork.
With this MR, we do not show forks with corrupted repos in the list of forks, as this does not seem to work anyway. A better solution is to fix the cause of the issue and/or any data integrity problem...
Also fixing Sentry issue: 1180
`undefined method 'already_forked?' for nil:NilClass `
See merge request !2836
|
| | | | |
|
| | |\ \
| | | |
| | | |
| | | | |
fix/project-forks-page
|
| | | | | |
|
| | |/ /
|/| | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
1. We now display the index of the current issuable among all its project's
issuables, of the same type and with the same state.
2. Also, refactored a bit the Issuable helpers into a new IssuablesHelper
module.
3. Added acceptance specs for the sidebar counter.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
Closes https://github.com/gitlabhq/gitlabhq/issues/9265
|
