Adds a version requirement which it didn't have before, at 2.0.0. This
version has breaking API changes in that the namespace is now `FFaker`
instead of `Faker`.
This groups milestones by title for issue views like it has been done for
the milestone dashboard/project overview. Before milestones with the
same title would show up multiple times in the filter dropdown and one could
only filter per project and milestone. Now the milestone filter is based
on the title of the milestone, i.e. all issues marked with the same
milestone title are shown.
Link cross-project cross-reference notes to correct project.
- Fixes#1431: Don't crash when an MR from a fork has a cross-reference comment from the target project on of its commits.
- Include commit comments in MR from a forked project.
To accomplish this, the Commit model needs to know about its project. Adding this attribute also simplifies a bunch of other methods that deal with a note's target, that previously had to have special logic for when it belonged to a commit.
See merge request !554
Fix invalid Atom feeds when using emoji, horizontal rules, or images
This is a fix for issues #880, #723, #1113.
Markdown must be rendered to XHTML, not HTML, when generating summary content for Atom feeds. Otherwise, content-less tags like *img* and *hr* are not terminated and make the Atom XML invalid. Such tags are generated when issue descriptions, merge request descriptions, comments, or commit messages use emoji, horizontal rules, or images.
To pass this option through from the relevant Haml templates to the proper place in the `gfm()` method, a new method `gfm_with_options()` is introduced. It reuses the options dictionary passed to `markdown()` and interprets options `xhtml` and `parse_tasks` from it (the latter was a convenient replacement for `gfm_with_tasks()`). `xhtml` is already interpreted by Redcarpet::Render::HTML, but that alone was not sufficient, because the post-processing in `gfm()` would convert its XHTML tags back to HTML.
I found no way of passing additional optional options to the existing `gfm()` method without requiring updates to existing callers and without getting in the way of the existing optional arguments, but maybe someone who knows more about Ruby than I can think of one.
Thorough review appreciated since this is the first time I have used Ruby.
See merge request !344
Fixes issues #880, #723, #1113: Markdown must be rendered to XHTML, not HTML, when generating summary content for Atom feeds. Otherwise, content-less tags like <img> and <hr>, generated when issue descriptions, merge request descriptions, comments, or commit messages use emoji, horizontal rules, or images, are not terminated and make the Atom XML invalid.
We were having the following issues:
- the indicator would sometimes stay red even if the password that was
entered was long enough;
- the indicator had a middle yellow signal: what does that mean?
- the red/green backgrounds were not color-blind-friendly.
Add a password strength indicator to SIGN UP and PROFILE pages
Fixes#1647
Added a password strength indicator to the sign up page. You can see how it looks in the following screenshot. In the sign up page, it checks if the password contains the username and alerts the user about it. If the user still wants to proceed with creating his account, nothing will stop him. This is merely a message. The indicator changes the input background color based on the strength like this:

The password strength indicator can also be found in the profile edit page. It functions in almost the exact same way, with the exception that it doesn't check if the password contains the username.

There are tests included.
/cc @job
See merge request !1227
Create a new shared module for common issue/merge request behavior,
use `expect` syntax instead of `should`, and avoid `visible: false` in
the `have_css` matcher.
Update the project API controller to use `Projects::DestroyService`
instead of calling `Project#destroy` directly.
Also add an optional parameter, `:keep_repo`, that allows a project to
be deleted without deleting the repository, wiki, and satellite from
disk.
This spec featured the slowest tests in the entire suite. After some
debugging, the cause was found to be the large commit diff generated by
comparing the stable and master branches.
To fix this, the seed repository was modified to create a simple branch
off of master that consists of three simple commits and minor changes.
The spec was then updated to compare master to this branch instead of
stable. The result is a spec group that runs in under 30 seconds, down
from about 90.
Public Groups
This is the initial work (meaning no tests) for making groups public if they have a public project (or internal for logged in users). This allows issues and merge requests to be viewed, but _not_ group membership. As part of this I have also added back the link in the public project title section (it was removed as it didn't make sense before).
This addesses the following suggestions/issues:
http://feedback.gitlab.com/forums/176466-general/suggestions/5314461-groups-containing-one-or-more-public-projects-shou
Issue #32https://github.com/gitlabhq/gitlabhq/issues/5203
as well as a few closed issues.
This also changes the public user page to only show groups that are accessible to the user in some manner.