connor-prodege/gitlabhq — pull request #3 by AlexanderOlkhovskiy (2013-10-22 20:44:36+00:00)
Title: Allow for accept without merge

See https://prodegellc.atlassian.net/browse/SWAG-471 ("Modify gitlab to allow for accept without merge")

What is implemented in my changes, it isn't exactly how Raphael initially described the task, because I tried to reuse the existing GitLab functionality as much as possible and we agreed that we will start from this version and change more things if it would be needed:
* Merge requests now have the `accepted` state.
* There is a new event type (as far as I understand, 'event' is a message which is displayed in feeds on user's and on project's home pages, maybe it is used also in some other purposes): `ACCEPTED`; there are hardcoded IDs for these types, so we will face issues when we (you) will merge upstream changes, which use the same ID (we will need to handle them using a data migration or something); currently upstream version has IDs from 1 to 9, I used 101, but we can pick a more unreachable number given that it is stored in `INT` DB column.
* There are two new 'abilities': `accept_merge_request` for developers and `merge_merge_request` for 'project masters'; `merge_merge_request` is an additional restriction to see the regular merge controls (automerge button or manual merge instructions) on the merge request page; if user doesn't have the `merge_merge_request` ability, but does have the `accept_merge_request` one, he will see 'Accept without merge' button instead of the merge controls;
* `can_push_code` check in `MergeRequestsController.allowed_to_merge?` doesn't have much sense with current abilities setup, since 'project masters' can either push to any branch and merge all MRs and 'developers' can push to non-protected branches, but can't merge any MRs anyway. But I left this logic (and created separate abilities instead of reusing e.g. `push_code`/`push_code_to_protected_branches`) for better compatibility with upstream version and for case if abilities will be rearranged.
* When a merge request (MR) is accepted without merge the regular GitLab notification is sent (just like when e.g. MR is closed/merged), so it would be sent to MR author, assignee and 'Participating' members (see the comment in `app/services/notification_service.rb`); everyone will see an 'event' in feeds on user's and on project's home pages.
* Accepted MRs are listed besides opened ones on 'Merge requests' pages. Status is displayed in parentheses.
* There are two data migrations, both do nothing in forward ('up') direction (since my changes add only new values for a couple of columns, but do not change the DB schema), but clean up DB in backward ('down') direction: change `accepted` MRs back to `opened` state and remove the `ACCEPTED` events

After deploying these changes you will need to grant people from US Team (at least those, who supposed to merge MRs) the project master rights and people from Russian Team the developer rights (I suppose it is already so) and test things a bit, since if I broke something it can prevent people from merging MRs via GitLab.