| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/
| |
| |
| | |
See: http://www.elabs.se/blog/53-why-wait_until-was-removed-from-capybara
|
|/
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allow admin to create public deploy keys that are accessible to any project.
Addresses private issue https://dev.gitlab.org/gitlab/gitlabhq/issues/1774.
Project settings:

The "Public deploy keys" section is only shown when there are any. If there are public deploy keys but no project deploy keys, only public deploy keys are shown. If there are no public deploy keys and no project deploy keys, the current "Deploy keys from projects you have access to will be displayed here" placeholder is shown.
The list of projects below the public key has been changed to only show projects the user has access to.
"Public deploy key" seems to be repeated on the left, but the first is just the title. The label is always visible for public deploy keys.
Admin index:

Admin detail page:

Projects using the deploy key are listed on the left and can be disabled easily.
See merge request !469
|
| | |
|
| | |
|
| |
| |
| |
| | |
Closes #1321
|
| |
| |
| |
| | |
Closes #1363
|
|\ \
| |/
|/| |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support configurable attachment size in Application Settings page
### What does this MR do?
This MR provides the ability to configure the maximum size of an attachment inside a note. A parameter has been added to the Application Settings page.
### Are there points in the code the reviewer needs to double check?
What should be done with the legacy note attachment validation? I added code to make the validation work with the configurable setting. I could see an issue where an admin lowers the limit from 10 megabytes to 5 megabytes, which could cause an existing model to be invalid.
### Why was this MR needed?
We often have attachments that exceed 10 MB, and it would be nice to be able to override the defaults.
### What are the relevant issue numbers / [Feature requests](http://feedback.gitlab.com/)?
See Issue #1258
### Screenshots
Before:

After:

See merge request !407
|
| |
| |
| |
| |
| |
| | |
Fix bug where error messages from Dropzone would not be displayed on the issues page
Closes #1258
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
Don't allow username to end in period.
The current behavior doesn't do username referencing and mentioning in sentences like "I discussed with with @douwe." since `douwe.` is matched as a username.
Addresses private issue https://dev.gitlab.org/gitlab/gitlabhq/issues/2174.
See merge request !438
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
Closes #1294
|
|
|
|
| |
Closes #1274
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replace commits calendar with contributions calendar
* count opening of issues and merge requests
* dont trigger git repository - use events from database
* count pushes instead of commits for faster and easier counting
* much-much faster since does not affected by repository size
See merge request !420
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
settings form
Closes #1275
|
|/
|
|
| |
Closes #1267
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Subscription to issue/mr
Fixes #1911 and #1909


See merge request !1702
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
It is same search like we have at issues page. It allows to quickly
filter merge requests based on title or desription. I copy-pasted some
js code from Issues.js. In future search (filtering) logic should be
refactoed into one class for merge requests and issues
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix server error when editing a note to "+1" or "-1"
### Summary
If a user edits a comment with "+1" or "-1" in the beginning, the POST returns an Internal Server error. (issue #1151). This merge request resolves that error.
### Steps to reproduce
1. Comment on an issue with "Test comment".
2. Edit the issue.
3. Write "+1" and click "Save Comment".
### Expected behavior
The edited note should be saved and refreshed. Any previous upvotes/downvotes from the user should contain a strikethrough.
### Observed behavior
Internal Error
### Relevant logs
```
Started PUT "/avocode/avocode-manager/notes/4996" for 185.33.136.107 at 2015-02-28 17:11:53 +0100
Processing by Projects::NotesController#update as JS
Parameters: {"utf8"=>"✓", "authenticity_token"=>"*removed*", "note"=>{"note"=>"+1\r\n\r\nYes"}, "commit"=>"Save Comment", "project_id"=>"avocode/avocode-manager", "id"=>"4996"}
Completed 500 Internal Server Error in 86ms
ActionView::Template::Error (undefined method `each' for nil:NilClass):
28: %span.note-last-update
29: = note_timestamp(note)
30:
31: - if note.superceded?(@notes)
32: - if note.upvote?
33: %span.vote.upvote.label.label-gray.strikethrough
34: %i.fa.fa-thumbs-up
app/models/note.rb:495:in `superceded?'
app/views/projects/notes/_note.html.haml:31:in `_app_views_projects_notes__note_html_haml___812277000516355462_69988235638820'
app/controllers/projects/notes_controller.rb:71:in `note_to_html'
app/controllers/projects/notes_controller.rb:103:in `render_note_json'
app/controllers/projects/notes_controller.rb:39:in `block (2 levels) in update'
app/controllers/projects/notes_controller.rb:38:in `update'
```
### Fix
It turns out no tests were present for the "Edit Issue" functionality. I added spinach tests to exercise this and reproduced the error.
Most of the routes in `notes_controller.rb` appear to render all notes for the given discussion. `_form.html.haml` needs the full list of notes commented by the user to add strikethroughs for older upvotes/downvotes. However, only the `index` route appeared to obtain this information. The fix is to add a `before_filter` to obtain all the user's notes beforehand, except in the delete case where this information is not needed.
Things to watch: `NotesFinder` needs `target_type` and `target_id` to determine what to do. I'm not sure if there is a conscious effort to phase these keywords out in favor of `noteable_type` and `noteable_id`.
See merge request !360
|
| |
| |
| |
| | |
Closes #1151
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
into cirosantilli-link-to-button
Conflicts:
app/views/shared/_issuable_filter.html.haml
|
| | | |
|