19 Mar, 2014

1 commit


14 Mar, 2014

1 commit


06 Mar, 2014

2 commits


05 Mar, 2014

1 commit


25 Feb, 2014

3 commits

  • Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
    Dmitriy Zaporozhets
     
  • Cleaner headers in Notification Emails
    
    Make the informations available in the notification email headers (sender, recipient, subject, etc.) more readable and meaningful.
    
    * Remove the email subject prefix
    * Don't write the project namespace in email subjects
    * Write the issue/merge request title in the notification email subject
    * Make the email appear as sent from the action author (the actual email address is still `gitlab@gitlab.com`)
    
    For instance, this is the notification email for a new issue comment before:
    
    > From: gitlab@gitlab.com
    > To: myemailaddress@gmail.com
    > Subject: GitLab | GitLab HQ / GitLab-Shell | New note for issue #1234
    
    And after :
    
    > From: Nick Brown <gitlab@gitlab.com>
    > To: myemailaddress@gmail.com
    > Subject: GitLab-Shell |  Add local update hook  (#1234)
    
    The recipient of the notification can easily get the gist of the message without even opening it — just by looking at how it appears in her inbox. None of the actual email addresses (From, To, Reply-to) changes, just the display name.
    
    Having a consistent subject for all notification emails sent about some resource also allow good email clients to group the discussion by thread (although grouping in Mail.app still needs some work).
    Dmitriy Zaporozhets
     
  • Main purpose is move big amount of methods from user, group, project
    models and place filtering logic in one place.
    It also fixes 500 error on group page for PostgreSQL
    
    Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
    Dmitriy Zaporozhets
     

19 Feb, 2014

1 commit

  • This changes the email "From" field from "gitlab@example.com" to either:
    
    * "John Doe <gitlab@example.com>" if the author of the action is known,
    * "GitLab <gitlab@example.com>" otherwise.
    
    Rationale: this allow mails to appear as if they were sent by the
    author. It appears in the mailbox more like a real discussion between
    the sender and the receiver ("John sent: we should refactor this") and
    less like a robot notifying about something.
    Pierre de La Morinerie
     

13 Feb, 2014

1 commit

  • Emails are used to associate commits with users. The emails
    are not verified and don't have to be valid email addresses. They
    are assigned on a first come, first serve basis.
    
    Notifications are sent when an email is added.
    Jason Hollingsworth
     

10 Feb, 2014

1 commit


22 Jan, 2014

1 commit


16 Jan, 2014

2 commits


15 Jan, 2014

5 commits


04 Dec, 2013

1 commit


14 Oct, 2013

1 commit


08 Oct, 2013

2 commits


17 Sep, 2013

1 commit


14 Sep, 2013

1 commit


13 Sep, 2013

2 commits


28 Aug, 2013

1 commit


25 Aug, 2013

1 commit

  • Any mention of Issues, MergeRequests, or Commits via GitLab-flavored markdown
    references in descriptions, titles, or attached Notes creates a back-reference
    Note that links to the original referencer. Furthermore, pushing commits with
    commit messages that match a (configurable) regexp to a project's default
    branch will close any issues mentioned by GFM in the matched closing phrase.
    If accepting a merge request would close any Issues in this way, a banner is
    appended to the merge request's main panel to indicate this.
    ash wilson
     

08 Aug, 2013

2 commits


30 Jul, 2013

1 commit


24 Jul, 2013

1 commit


17 Jul, 2013

3 commits

  • Trying to retrigger travis
    Change-Id: Ifd86fb4c6b2791ad176230254fbf69a9ade979fb
    Izaak Alpert
     
  • Change-Id: Ic23cb46901f8adc77943bf3cc79566587364e22a
    Izaak Alpert
     
  • The good:
    
     - You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
     - Push events take into account merge requests on forked projects
     - Tests around merge_actions now present, spinach, and other rspec tests
     - Satellites now clean themselves up rather then recreate
    
    The questionable:
    
     - Events only know about target projects
     - Project's merge requests only hold on to MR's where they are the target
     - All operations performed in the satellite
    
    The bad:
    
      -  Duplication between project's repositories and satellites (e.g. commits_between)
    
    (for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
    
    Fixes:
    
    Make test repos/satellites only create when needed
    -Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
    -project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
    -fixed remote removal
    -How to merge renders properly
    -Update emails to show project/branches
    -Edit MR doesn't set target branch
    -Fix some failures on editing/creating merge requests, added a test
    -Added back a test around merge request observer
    -Clean up project_transfer_spec, Remove duplicate enable/disable observers
    -Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
    -Signifant speed ups for tests
    -Update formatting ordering in notes_on_merge_requests
    -Remove wiki schema update
    Fixes for search/search results
    -Search results was using by_project for a list of projects, updated this to use in_projects
    -updated search results to reference the correct (target) project
    -udpated search results to print both sides of the merge request
    
    Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8
    Izaak Alpert
     

24 Jun, 2013

1 commit


10 Apr, 2013

1 commit


01 Apr, 2013

1 commit


28 Mar, 2013

1 commit