Added system hooks messages for renaming and transferring a project
This is work in progress but I wanted to get some feedback on it in case there is something I've missed or a better way to do it.
As the title says when a project is renamed or transferred to another group a system hook message is generated.
Currently adds a couple of extra properties to the standard project system hooks messages.
old_path_with_namespace - The old path of the project so we can see what has been renamed / transferred
changed_at - The time that change took place
My main concern is if there is a better way of doing this than passing the extra_data variable into the system hook. Would it be better to extend the project model with these 2 items as transient properties as I doubt they would need to be saved to the database? The other
I've also seen, but can't find, someone talking about the emails sent when a project is renamed or transferred doesn't reference the original project path so if you have similarly named projects then you might not know what has been moved. I think the extra_data (or however it is best to implement this) would allow the extra information to be sent in emails.
Closes [System hooks for project transfer and repository rename](http://feedback.gitlab.com/forums/176466-general/suggestions/6006233-system-hooks-for-project-transfer-and-repository-r)
See merge request !611
The introduction of ActiveJob and `deliver_now` in 7f214cee7 caused a race
condition where the mailer would be invoked before the project was committed
to the database, causing the transfer e-mail notification to show the old
path instead of the new one.
Closes#4670
This is a temporary hotfix that allows to access build artifacts created
before 8.3. See #5257.
This needs to be changed after migrating CI build files.
Note that `ArtifactUploader` uses `artifacts_path` to create a storage
directory before and after parsisting `Ci::Build` instance, before and
after moving a file to store (save and fetch a file).
Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll
`git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.
Here are the gory details. Let's say you ran:
```
git log -n=5 --skip=2 README
```
This is the working case since it omits `--follow`. This is what happens:
1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
2. Once this is found, this commit is returned via `get_revision_1()`.
3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
4. `show_log()` gets called with that commit.
5. Repeat step 1 until we have all five entries.
That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:
* When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](https://github.com/git/git/blob/master/revision.c#L2351).
* If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
* In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
* As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
* Making matters worse, the `--skip` in the example above would actually skip a every other entry after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!
Since git uses a matching algorithm to determine whether a file was renamed, I
believe `git` needs to generate a diff of each commit to do this and traverse
each commit one-by-one to do this. I think that's the rationale for disabling
the `prune` functionality since you can't just do a simple string comparison.
Closes#4181, #4229, #3574, #2410
See merge request !2210
Revert vote buttons back to issue and MR pages
https://gitlab.com/gitlab-org/gitlab-ce/issues/3672
/cc @dzaporozhets @JobV
See merge request !2206
`git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.
Here are the gory details. Let's say you ran:
```
git log -n=5 --skip=2 README
```
This is the working case since it omits `--follow`. This is what happens:
1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
2. Once this is found, this commit is returned via `get_revision_1()`.
3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
4. `show_log()` gets called with that commit.
5. Repeat step 1 until we have all five entries.
That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:
* When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](https://github.com/git/git/blob/master/revision.c#L2351).
* If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
* In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
* As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
* Making matters worse, the `--skip` in the example above would actually skip every other after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!
Since git uses a matching algorithm to determine whether a file was renamed, I
believe `git` needs to generate a diff of each commit to do this and traverse
each commit one-by-one to do this. I think that's the rationale for disabling
the `prune` functionality since you can't just do a simple string comparison.
Closes#4181, #4229, #3574, #2410
Fix identity and user retrieval when special characters are used
Fixes#4023
I also added tests to make sure the user with special characters in his name is returned correctly.
@rspeicher this probably should be added to 8.3 as a patch.
See merge request !2176
Automatically fork a project when not allowed to edit a file.
Fixes#3215.
To do:
- [ ] Add tests
-----
## "Edit" button on file in a project the user does NOT have write access to
## Clicking will automatically create a fork
## When the fork has been created, the user is returned to the edit page on the original project with a notice
## The user cannot change the target branch and is informed that editing will start an MR
## Hitting "Commit changes" will commit and start an MR from my fork to the origin project
-----
## "Create file, "Upload file" and "New directory" buttons in a project the user does NOT have write access to
## Clicking any of these options will automatically create a fork
## When the fork has been created, the user is returned to the tree page on the original project with a notice
## Clicking "New directory" again will show the modal. The user cannot change the target branch and is informed that editing will start an MR
## Hitting "Create directory" will commit and start an MR from my fork to the origin project
cc @dzaporozhets @skyruler
See merge request !2145
Allow account unlock via email
We see a lot of users get confused about what it means when your account gets
locked. Many try to reset their password and are still faced with a lockout.
With this change, users receive an email that allows them to unlock their
account immediately. The previous behavior where the account is auto-unlocked
after a time also still works.
See merge request !2049
* master: (723 commits)
Bump Rack Attack to v4.3.1 for security fix
Remove duplicate entry in the changelog
Remove extra spaces after branchname
Fix merge-request-reopen button title
Add branch and tag operation to tree dropdown
Use gitlab-shell 2.6.9
Clarify Windows shell executor artifact upload support
Fix feature specs: we always show the build status if ci_commit is present
Do not display project group/name when issue and MR are in same project
Don't create CI status for refs that doesn't have .gitlab-ci.yml, even if the builds are enabled
Use gitlab-workhorse 0.5.1
Fix ci_projects migration by using the value only from latest row [ci skip]
Revert sidebar position for issue and merge request
Add info on using private Docker registries in CI [ci skip]
Upgrade Poltergeist to 1.8.1. #4131
Fix ux issue with "This issue will be closed automatically" message
Move MR Builds tab next to Commits
Api support for requesting starred projects for user
Fix Rubocop complain.
Fix merge widget JS for buttons
...
Conflicts:
app/models/project.rb
Dmitriy Zaporozhets
Stan Hu
Valery Sizov
Steve Norman
Robert Speicher
Grzegorz Bizon
Valery Sizov
Grzegorz Bizon
Gabriel Mazetto
Robert Speicher
Douwe Maan
Patricio Cano
Kamil Trzcinski
Tomasz Maczukin
Jared Szechy
Drew Blessing
Jared Szechy
Rubén Dávila