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
Branded appearance to CE
Closes#11489
The difference with the EE version is only that there is no distinction between light and dark logos, though this wasn't used anyway. If this is fine, I'll create a MR on EE too.
TODO:
- [x] Copy docs
- [x] Make new screenshots
- [ ] Remove Custom Welcome message feature?
@rymai: I was unsure what labels to add to ping you, so I just ping you like this 😉
/cc @DouweM
See merge request !2927
The only major difference with the EE version is the change from a light and dark logo to only a header logo
The dark logo wasn't used anyway, so it seemed to make sense to me to rename the field to the actual function of it
Move "I should see Crowd login form" feature to a view spec
We were doing all kinds of code gymnastics to "enable" Crowd in the
feature spec and this would sometimes cause a transient failure.
Really what it's testing is if the Crowd login form shows when Crowd's
enabled, so this is much better suited to a view spec.
See merge request !2963
Sidebar overlaps content when screen is below 1200px.
When screen is below 1200px, the sidebar overlaps.
When screen is above 1200px, the sidebar pushes content out.
z-index change to make sure hamburger stays on top.
Fixes#12717
Also sorry I couldn't get the collapse button in the screen cap. It's there.
See merge request !2620
We were doing all kinds of code gymnastics to "enable" Crowd in the
feature spec and this would sometimes cause a transient failure.
Really what it's testing is if the Crowd login form shows when Crowd's
enabled, so this is much better suited to a view spec.
Robert Speicher
Jacob Schatz
Dmitriy Zaporozhets
Phil Hughes
ashleys
Jacob Schatz
Kamil Trzcinski
Robert Speicher
Douwe Maan
Rubén Dávila
Grzegorz Bizon
Jacob Vosmaer
Pierre de La Morinerie
Alfredo Sumaran
Josh Frye
Zeger-Jan van de Weg
Rémy Coutable
