summaryrefslogtreecommitdiffstats
path: root/app/models/merge_request.rb
Commit message (Collapse)AuthorAgeFilesLines
* Use sequence number as MergeRequest#title, for better display in breadcrumbsMarius Mathiesen2010-02-111-1/+1
| | | | Thanks to Saur on #gitorious
* Add repository user as a watcher when creating a new repositoryJohan Sørensen2009-12-101-3/+3
|
* Move creation of favorites into controller. Also adding merge request to ↵Marius Mathiesen2009-12-101-1/+6
| | | | owner's favorites upon creation
* Change the way reviewers are notified about new merge requestsMarius Mathiesen2009-12-101-13/+19
| | | | | | | | | | When a merge request is created, each reviewer has this added as a favorite. In the same process, a FeedItem is created for the event associated (now created in the model and accessible as #creation_event). Messages are no longer sent to the reviewers, as this gave a lot of email to the reviewers. Instead, they will now be able to track the creation (and updates) of merge requests through their newsfeed. Since notifications are no longer sent to reviewers, the checkbox on Repositories#edit is no longer displayed (it has no effect). It is still in the database, though.
* When a merge request is created (confirmed_by_user), each reviewer will have ↵Marius Mathiesen2009-12-091-2/+11
| | | | | | a favorite created. - Support creation of favorites without creating an event.
* Make merge requests watchableMarius Mathiesen2009-12-071-0/+1
| | | | | - Moved linking logic into FavoritesHelper - Favorites know of their project
* Pedantic line-length and whitespace cleanupJohan Sørensen2009-11-301-13/+18
|
* MergeRequest's to_param now uses the sequence number instead of idMarius Mathiesen2009-11-301-3/+7
| | | | | | | | | | A summary of what's changed: - Routing - Links, where necessary - Git branch names use seq instead of id Also made some refactorings in PushEventProcessor to make it testable without a full stack test. And set some revealing sequence numbers in the fixtures.
* Adding sequence number to merge requests, will replace id in URLs etc.Marius Mathiesen2009-11-301-3/+14
|
* Only notify reviewers about new merge requestsJohan Sørensen2009-11-191-80/+80
|
* MergeRequest#resolvable_by? should use the committerships with a review bitJohan Sørensen2009-11-191-1/+1
|
* Use a proper SQL query for MergeRequest.cascaded_comments so we can order ↵Johan Sørensen2009-11-051-4/+6
| | | | | | | | | them properly Some MergeRequestController test cases had to be reworked as an effect of this, since they stub out too much internal logic of ActiveRecord, by stubbing out the association proxies, which is not a good thing to do anyway.
* Show the render_if_ready box if a merge request isn't readyJohan Sørensen2009-11-041-1/+1
| | | | | | With this we don't need to Refresh header, which causes confusion among users. Be able to supply an options hash to render_if_ready() that swaps out the spinner image with a refresh page
* Less cryptic MergeRequest#version_number(n)Johan Sørensen2009-11-041-1/+1
|
* Even less N+1 queries when fetching comments for a merge requestJohan Sørensen2009-11-041-1/+1
|
* Less N+1 queries when fetching comments for a merge requestJohan Sørensen2009-11-041-1/+3
|
* Display comments on both merge request and versions in the comment listingMarius Mathiesen2009-11-041-0/+5
|
* Don't create an extra version event when creating a new merge requestJohan Sørensen2009-10-221-14/+24
| | | | | | | | | The "New version 1" event created when a new merge request is created just leads to clutter and provide only what the MERGE_REQUEST_CREATED event already does Also clean up a few of the silly long lines (lets keep within 82 chars or so shall we)
* Grant merge request creators the ability to change the statusJohan Sørensen2009-09-231-1/+1
|
* Include summary in MergeRequest#to_xml and use the status_tag as wellJohan Sørensen2009-09-011-2/+2
|
* MergeRequest.from_filter shouldn't make special exceptions for 'open'/'closed'Johan Sørensen2009-08-271-7/+2
|
* Add a MergeRequest::public scope, and make sure to use it consequentlyJohan Sørensen2009-08-271-0/+1
| | | | We have no interest in showing merge requests in a pending state
* Validate presence of summary field for new merge requests and migrate ↵Johan Sørensen2009-08-271-1/+1
| | | | | | existing ones also made the tests pass with the new required summary field
* Merge commit 'qt/restructure-merge-request-view'Johan Sørensen2009-08-251-1/+1
|\ | | | | | | | | | | | | | | | | | | * commit 'qt/restructure-merge-request-view': Move merge-request help box to the bottom of the page Remove sidebar from merge-requests and move links to the bottom Use merge-request number for breadcrumb title instead of source branch Conflicts: app/views/merge_requests/show.html.erb
| * Use merge-request number for breadcrumb title instead of source branchTor Arne Vestbø2009-08-241-1/+1
| |
* | Be able to set a default MergeRequestStatusJohan Sørensen2009-08-251-3/+11
| | | | | | | | And use that as the default status for all new merge requests
* | dependent => :destroy for merge request versionsMarius Mathiesen2009-08-251-1/+1
| |
* | Make sure MergeRequest#status_string is a string (for the "legacy" template)Johan Sørensen2009-08-241-1/+1
|/
* Losen the custom merge request states even further and allow for both ↵Johan Sørensen2009-08-241-53/+45
| | | | | | | | | | | open&closed custom states - Introduce a StatusTag class for abstracting the loosely bounded MergeRequest#status_tag - Move to the "legacy" merge_requests closer to the normal ones - Simplify the internal MergeRequest statemachine to only have STATUS_OPEN and STATUS_CLOSED - Introduce a MergeRequestStatus model that users add to a project with one of the states above - Remove the legacy merge_requests_controller actions
* Be able to turn new merge-request notifications on or off, per repositoryJohan Sørensen2009-07-241-3/+9
|
* The "Open" status tag should be capitalized, not downcased when ↵Johan Sørensen2009-07-221-1/+1
| | | | confirmed_by_user
* Make sure pending merge requests are never included in the scopes or ↵Johan Sørensen2009-07-221-5/+5
| | | | #from_filter
* Refactor the merge-request tracking branches deletion to be in an ↵Johan Sørensen2009-07-221-9/+16
| | | | | | | | after_destroy hook Pass along all the data needed for the processor in the message body when the after_destroy hook is called. That way users don't get confused and delete it multiple times (since there's a small delay in the msg processing
* Adding a processor for handling deletion of merge requests.Marius Mathiesen2009-07-171-0/+6
| | | | | | | | Replacing MergeRequests#destroy with a call to #soft_delete, which posts a message to the MQ. This processor will both delete the ref in the target repository and delete the merge request itself. The ref in the tracking repository is not deleted yet, nor are updates in the backend handled for merge requests that are closed or reopened.
* Deletion of merge requests in Git should be allowed for local connections.Marius Mathiesen2009-07-161-0/+4
| | | | | Also added support for deleting the merge request ref in the target repository. This will be done before the merge request is deleted.
* The default status_tag of new merge requests should be openMarius Mathiesen2009-07-151-0/+2
| | | | | - This is set when MergeRequest#confirmed_by_user is called, meaning merge requests needing acceptance of contribution agreements will be set to open as soon as the agreement is accepted
* Calculate the merge base for a merge-request without timeoutsJohan Sørensen2009-07-151-1/+2
|
* Prettified the rendering of merge request status changes in comments and eventsJohan Sørensen2009-07-151-4/+5
|
* Add the comment in the event generated when updating a merge request with a ↵Marius Mathiesen2009-07-141-4/+8
| | | | new state.
* Supplying a list of status tags per repository when listing merge requests:Marius Mathiesen2009-07-131-1/+6
| | | | | | | | - add a list of unique status_tags - MergeRequest.from_filter uses a named scope by filter when given a non-defined string MergeRequest.from_filter now uses either a predefined name scope, the by_status named scope or open (when given nil)
* index the MergeRequest#status_tag as statusJohan Sørensen2009-07-131-1/+2
|
* Reformatted line-length, added a comment about future optimization andJohan Sørensen2009-07-131-4/+5
| | | | removed debug logger statement
* Change the filtering on merge requests to use the status_tag.Marius Mathiesen2009-07-021-5/+20
| | | | | | | - added a migration method for getting existing merge request up to the current version - use the status_tag instead of status_string in the views - commenting on a merge request and assigning a new status should notify the owner of the new status as well
* Let each project define its status tags for merge requestsMarius Mathiesen2009-07-021-37/+14
| | | | - when changing the state from a comment, create an event - display status field in merge request form
* Cache the commit status for 60 minutesMarius Mathiesen2009-07-011-1/+1
|
* Make sure the new mergerequest created Message has the correct sender in the ↵Johan Sørensen2009-06-301-1/+3
| | | | title
* Moving the calculation of commits in a merge request version where it belongsMarius Mathiesen2009-06-301-5/+1
|
* Commit status for commits in a merge request:Marius Mathiesen2009-06-301-4/+7
| | | | | | - Cache the merge status of each commit for merge requests - Load commit status with AJAX for each commit in merge request (- add some graphics)
* Push to the MergeRequest tracking repository without a timeoutJohan Sørensen2009-06-291-4/+7
|
* For legacy merge requests (that is, no versions yet) we need to use the ↵Marius Mathiesen2009-06-241-1/+6
| | | | ending_commit as limit
* Support for merge requests without versions (legacy):Marius Mathiesen2009-06-241-1/+5
| | | | | | | | | - Another show page is displayed - When a merge request is created, the page will reload after 5 seconds until a version is created in the background. - The commits_to_be_merged either returns the delta (legacy objects) or data loaded from the tracking branch (new objects) - Hide the selector for new versions
* Enabling edit/update in MergeRequestsController:Marius Mathiesen2009-06-241-3/+10
| | | | | - Edit will let the user choose a proposal and ending comit - Update will update and send a notification
* Handle legacy merge requests (=no versions) with a different templateMarius Mathiesen2009-06-241-1/+1
| | | | - Use dropdown for selecting versions instead of list
* Merge request updates:Marius Mathiesen2009-06-241-3/+6
| | | | | - show if a commit is merged in target_repo - rendering of merge request update events
* Adding versions to merge request, track the last common base between source ↵Marius Mathiesen2009-06-241-46/+107
| | | | | | and target repo - Also do not require subdomains for Repositories#real_path
* When migrating merge requests: handle situations where the ending commitMarius Mathiesen2009-06-241-2/+6
| | | | doesn't exist in the source repository by issuing a warning.
* Let users view commits from earlier versions of a merge requestMarius Mathiesen2009-06-241-2/+6
| | | | | | - Adding MergeRequests#version - Adding MergeRequest#versions - Moving commits into a partial
* Render a waiting message when viewing a merge request without a backend branch.Marius Mathiesen2009-06-241-1/+6
| | | | | | - Giving MergeRequest a ready? method for determining whether the backend branch has been created or not - Setting refresh header&use render_if_ready
* Make some status tags "sticky", that is change the state machinestate.Marius Mathiesen2009-06-241-11/+24
| | | | | | | - Add a list of status tags - Also remove the update_status method in MergeRequest, as this wasn't being used - Add tests for changing the status through comments
* Adding a loose state (status_tag) to merge requests, adding state change to ↵Marius Mathiesen2009-06-241-0/+11
| | | | | | | | | | | comments. - Adding a comment to a merge request now potentially sets or changes the loose state of the merge request (target) This way, target repository owners can mark that a merge request should change state when adding comments. This will eventually replace the more final reason from merge requests, replacing it with comments with an added context
* Add a migration facility for existing merge requestsMarius Mathiesen2009-06-241-1/+22
|
* Moved the authentication logic from SSH Client to pre-receive:Marius Mathiesen2009-06-241-0/+1
| | | | | | | | | | - script/gitorious only checks whether the repo exists, and sets an environment var for the URL for auth checking - hooks/pre-receive performs the access control, as before Currently, users should be allowed to push normally, like before. In addition to that, owners of merge requests are allowed to push to the special ref for the merge request in the target repository
* Renamed the merge request branches to refs/merge-requests/<id>Marius Mathiesen2009-06-241-3/+3
|
* Let merge requests live their own life in a branchMarius Mathiesen2009-06-241-2/+26
| | | | | | Requests are now living inside a ref/reviews branch in the tracking repository, and can be updated though normal pushes to the real repository. No authorization yet on pushing updates to a review - merge request owners will not yet be able to push to the target repository, but users with commit access will.
* Put the merge requests in refs/reviews/<id>/sequence Marius Mathiesen2009-06-241-1/+1
| | | | instead of refs/reviews/<id> - in order to keep history
* Push to an invisible branch in the target repository Marius Mathiesen2009-06-241-1/+2
| | | | when creating a merge request
* The name tracking_repository states its intention Marius Mathiesen2009-06-241-2/+2
| | | | clearer; this renames it accordingly
* Instead of pushing the entire branch to the trackingMarius Mathiesen2009-06-241-1/+1
| | | | repository, we'll only push the ending commit.
* When creating a merge request, a separate Git repositoryMarius Mathiesen2009-06-241-0/+7
| | | | | | | | | | | | | | is used for tracking the merge requests in the target repository. - If the tracking repository doesn't exist, it will be created through a separate message to the repository creation queue - The repository creation processor will resend another message in this case - Given an existing tracking repository, the source branch will be pushed to the tracking repository as merge_requests/<id> - These events are fired by MergeRequest#confirmed_by_user
* make sure the notifiable is always included in the notification_copyJohan Sørensen2009-06-221-1/+7
|
* Make a MergeRequest know if its ending commit (still) existsMarius Mathiesen2009-06-171-0/+4
|
* Index all merge requests, unless state is STATUS_PENDING_ACCEPTANCE_OF_TERMSJohan Sørensen2009-06-151-1/+1
| | | | Not the other way around.
* In stead of destroying messages when their notifiablesMarius Mathiesen2009-06-021-1/+8
| | | | | | | | | are destroyed (which could lead to messages becoming invisible), we nullify the notifiable references. Since AR's dependent => nullify only nullifies the id, not the type, a before_destroy filter is introduced.
* Added patch and xml format support for merge requests:Marius Mathiesen2009-05-281-0/+23
| | | | | | | | | - Added #to_xml to merge requests - Added support for merge_requests.xml - Added support for merge_request/id.xml - Added support for merge_requests/id.patch This way one can fetch a patch from Gitorious
* Make MergeRequest#resolvable_by? work together with the annoying ways in whichJohan Sørensen2009-05-271-0/+1
| | | | | | | the AuthenticationedSystem module works. I mean christ, who thinks this kinda bullshit up? Returning a :false symbol instead of nil, making us jump through hoops in the rest of the app.
* Adding support for re-opening merge requests.Marius Mathiesen2009-05-191-0/+14
| | | | | | | This is an explicit action, wrapped inside a separate method in MergeRequest which passes along the user who wants to re-open. - Also added a new Action and rendering of the events
* Be able to filter merge-requests on open/verifying, merged and rejectedJohan Sørensen2009-05-181-0/+15
|
* Adding an updated_by to merge requests. Marius Mathiesen2009-05-141-12/+12
| | | | | | | | | By default, this is the user who created the merge request, but is updated when the merge request enters another state. The updated_by information is displayed along with the rest of the information about the request.
* Adding a new state to merge requests: verifying. This is intended for ↵Marius Mathiesen2009-05-131-3/+33
| | | | | | | | telling users that we are working on the request, but need to verify some issues. - Adding a new transition - Adding a method for displaying the key/values for new states in the GUI - Still send the user an email when changing the state
* For compatibility with merge requests created before the Gitorious upgrade: ↵Marius Mathiesen2009-05-111-1/+2
| | | | skip validation of ending commit for existing merge requests.
* Adding support for deleting your own merge requests:Marius Mathiesen2009-05-111-1/+1
| | | | | | - Add link in the view - Don't create an event when destroying mr (would cause an invalid target) - Delete comments along with merge requests
* Changing the way signoff of merge requests work, due to a requirement that ↵Marius Mathiesen2009-04-301-1/+21
| | | | | | | | | | users who have already accepted the contribution agreement should be reminded of their confirmation when sending new contributions. - Instead of extracting the agreement version checksum from the response body, it is extracted from a response header (X-Contribution-Agreement-Version). - The response code (from the oauth provider) tells us whether this is the first or subsequent time a user accepts the license: 202 (Accepted) means it has been accepted before while other codes (preferably 201 Created) means it has been accepted for the first time - The response body is now used for providing the message to be displayed to the user The contribution notice is put into flash[:notice] and thus displayed to the user.
* Be able to comment on merge requests as wellJohan Sørensen2009-04-291-0/+1
| | | | | This requires the comments_controller to be able to deal with the polymorphic targets on the comment
* Make oauth related attributes on Project attr_protectedJohan Sørensen2009-04-231-1/+2
|
* Sending along the user's login when requesting a request token via OAuth. ↵Marius Mathiesen2009-04-221-0/+1
| | | | Also posting it when calling back after successful merge request creation.
* Made a first successful pass at OAuth integration with external siteMarius Mathiesen2009-04-221-3/+12
| | | | | | - URL-encoding the OAuth parameters sent off after creating a merge request. - Fixing a typo in the parameters for the OAuth parameters (extra _path appended) - Some more encoding:utf-8 statements
* Updated copyrights-blurb in all application filesJohan Sørensen2009-04-221-1/+5
|
* Letting the user accept the EULA on signup by presenting him with the ↵Marius Mathiesen2009-04-221-1/+6
| | | | | | | | current version and a checkbox including the checksum for this version. For now, if the user chooses not to accept he will still be created, but required to accept the EULA afterwards. Also, added the passing of more parameters when handing off a merge request to an OAuth server.
* Adding configurable merge request signoff information:Marius Mathiesen2009-04-221-11/+21
| | | | | | | | | - Project has got settings for OAuth settings (ie. consumer) - MergeRequest has got settings for access token information. Instead of storing it in the user's session we store it in the db, giving us the possibility to call back when the state changes - The Project now builds an OAuth consumer from the settings in the db - The MergeRequests use this consumer (which is stubbed out when testing) - Removed the passed arguments when performing OAuth validations, as these are now stored - Removed the now obsolete CONSUMER constant (OAuth settings can now safely be removed from gitorious.yml)
* Posting a request offsite after acceptance of termsMarius Mathiesen2009-04-221-2/+5
|
* Fixed merge request breadcrumb iconsJohan Sørensen2009-04-221-0/+4
|
* Reverse the commits_to_be_merge when there's an ending commitJohan Sørensen2009-04-221-2/+2
|
* Deliver merge request notifications to each committer in the target repositoryMarius Mathiesen2009-04-221-7/+9
|
* Moved the state machine logic in MergeRequest where it belongs, in a state ↵Marius Mathiesen2009-04-221-17/+40
| | | | machine.
* Deliver a status update when a merge request is resolved.Marius Mathiesen2009-04-221-5/+18
| | | | - Also refactoring the can_transition_to? so it can return a list of allowed transitions
* Adding a reason to Merge Request. Set the reason when the status is updated ↵Marius Mathiesen2009-04-221-2/+2
| | | | (MergeRequestsController#resolve). Also let MergeRequest#can_transition_to? accept String values, as this is what they're passed as from the controllers
* Can a merge request transition to a given state? Added a method which ↵Marius Mathiesen2009-04-221-1/+21
| | | | | | returns whether this is allowed and another method that lets you wrap a block to be executed if allowed. Added another merge request fixture that allows the state change.
* Adding notifiable support to messages:Marius Mathiesen2009-04-221-1/+1
| | | | | - Link a merge request with a message - Display link in message (web)
* Removing action, test and view for Mailer's merge request notification. This ↵Marius Mathiesen2009-04-221-4/+5
| | | | | | has been pulled into the Message class. Also added description to Message, so that it displays its type based on whether there is a notifiable or not
* [UNTESTED]: Creating a message to the repo owner when a new merge request is ↵Marius Mathiesen2009-04-221-1/+7
| | | | submitted
generated by cgit v1.1 at 2025-05-11 16:30:46 +0000