Fix/project show also ldap users
In 336b7b8 a feature was (silently) added which broke our use case of using LDAP synced groups as a common base for user <-> project mapping 😒
Although
>v 7.4.0
> - [...]
> - Do not show ldap users in dropdowns for groups with enabled ldap-sync
> - [...]
indicates that the drop down boxes for groups have changed, it does not for projects in such a group. To be clear: It totally makes sense to not manually manage users for LDAP synced groups, on a project basis however it is very useful and an essential feature to allow self-service in organizations.
Please consider making the `skip_ldap` flag optional for the dropdown boxes.
[Also, make sure that the provider you're excluding actually is called `ldap`, which might not be the case for installations with multiple LDAP backends.](https://gitlab.com/subscribers/gitlab-ee/blob/master/lib/api/users.rb#L16)
This MR is a quick fix to disable this feature for projects.
See merge request !25
Improve issuable form links UX
> The create new label / milestone links should open in a new window / popup to avoid losing information already filled in for a new issue.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/855
See merge request !1291
* Show namespace thumbnail differently if project was already forked
* Show loading spinner when click on fork
* Fork link navigates to personal namespace only if no manageable groups exists
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Now you can fork project into group or personal namespace.
Also I moved fork logic from ProjectsController to own fork resource
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Better merge request manual instructions
I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:
1. Alice creates a repository and commits / pushes a single commit with SHA1 `A` to `master`.
2. Bob forks this repository and creates a new branch `myfeature` on `master` (`A`)
3. Alice commits `B` to `master` (which has the parent `A`)
4. Bob creates two commits on `myfeature` `P` and `Q`.
5. Bob submits the merge request to merge his `myfeature` into Alice's `master` branch.
6. Alice follows the manual merge request instructions:
1. `git checkout -b bob/repo-myfeature master`
2. `git pull http://... myfeature`
The branch `bob/repo-myfeature` was created from Alice's current `master`, which was `B`. When the `pull` is executed, git will fetch Bob's branch and then merged the fetched branch `Q` into the current branch's location `B`. This creates an unnecessary merge commit from `master` into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.
This is even worse if Alice has set `git pull` to rebase by default. In this case, the commit `B` is rebased on top of `Q`. When Alice checks out `master` and merges in the branch, there will actually be a duplicate `B` commit.
These new instructions instead tell the user to fetch Bob's `myfeature` branch. This will fetch the necessary commits `P` and `Q` and create a temporary ref `FETCH_HEAD` pointing to `Q`. Alice will then create her local `bob/repo-myfeature` branch starting at `FETCH_HEAD`. No unnecessary merge commits, and no accidental rebasing.
See merge request !16
Dmitriy Zaporozhets
Marin Jankovski
Dmitriy Zaporozhets
Vinnie Okada
Marin Jankovski
Marvin Frick
Drew Blessing
Valery Sizov
Nikita Verkhovin
skv
Valery Sizov
Valery Sizov
