An error occurred fetching the project authors.
- 29 Nov, 2016 1 commit
-
-
Douwe Maan authored
Replace issue access checks with use of IssuableFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867 ## Which fixes are in this MR?
- Potentially untested - No test coverage - Test coverage of some sort exists (a test failed when error raised) - Test coverage of return value (a test failed when nil used) - Permissions check tested ### Issue lookup with access check Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells). - [x] app/finders/notes_finder.rb:15 [`visible_to_user`] - [x] app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`] - [x] app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`] - [x] lib/api/issues.rb:112 [`visible_to_user`] - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone - [x] lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too? - [x] lib/gitlab/search_results.rb:53 [`visible_to_user`] ### Previous discussions - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126 - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87 See merge request !2031
-
- 23 Nov, 2016 5 commits
-
-
Yorick Peterse authored
Flushing the events cache worked by updating a recent number of rows in the "events" table. This has the result that on PostgreSQL a lot of dead tuples are produced on a regular basis. This in turn means that PostgreSQL will spend considerable amounts of time vacuuming this table. This in turn can lead to an increase of database load. For GitLab.com we measured the impact of not using events caching and found no measurable increase in response timings. Meanwhile not flushing the events cache lead to the "events" table having no more dead tuples as now rows are only inserted into this table. As a result of this we are hereby removing events caching as it does not appear to help and only increases database load. For more information see the following comment: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Ahmad Sherif authored
-
Ahmad Sherif authored
-
Ahmad Sherif authored
Closes #23938
-
- 21 Nov, 2016 1 commit
-
-
Yorick Peterse authored
This refactors repository caching so it's possible to selectively refresh certain caches, instead of just expiring and refreshing everything. To allow this the various methods that were cached (e.g. "tag_count" and "readme") use a similar pattern that makes expiring and refreshing their data much easier. In this new setup caches are refreshed as follows: 1. After a commit (but before running ProjectCacheWorker) we expire some basic caches such as the commit count and repository size. 2. ProjectCacheWorker will recalculate the commit count, repository size, then refresh a specific set of caches based on the list of files changed in a push payload. This requires a bunch of changes to the various methods that may be cached. For one, data should not be cached if a branch used or the entire repository does not exist. To prevent all these methods from handling this manually this is taken care of in Repository#cache_method_output. Some methods still manually check for the existence of a repository but this result is also cached. With selective flushing implemented ProjectCacheWorker no longer uses an exclusive lease for all of its work. Instead this worker only uses a lease to limit the number of times the repository size is updated as this is a fairly expensive operation.
-
- 18 Nov, 2016 5 commits
-
-
Ahmad Sherif authored
Closes #23150
-
Kamil Trzcinski authored
-
Robert Speicher authored
This also updates _some_ specs to use these new methods, just to serve as an example for others going forward, but by no means is this exhaustive. Original implementations at !5992 and !6012. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20944
-
Z.J. van de Weg authored
This prevents leakage of project names on an endpoint which is unauthenticated and thus open to the world.
-
Z.J. van de Weg authored
-
- 17 Nov, 2016 4 commits
-
-
Z.J. van de Weg authored
-
Kamil Trzcinski authored
-
Z.J. van de Weg authored
-
Z.J. van de Weg authored
This commit includes a couple of thing: - A chatops controller - Mattermost::CommandService - Mattermost::Commands::(IssueService|MergeRequestService) The controller is the point where mattermost, and later slack will have to fire their payload to. This in turn will execute the CommandService. Thats where the authentication and authorization should happen. So far this is not yet implemented. This should happen in later commits. Per subcommand, in case of `/gitlab issue show 123` issue whould be the subcommand, there is a service to parse the data, and fetch the resource. The resource is passed back to the CommandService which structures the data.
-
- 16 Nov, 2016 4 commits
-
-
Valery Sizov authored
-
Adam Niedzielski authored
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 15 Nov, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 14 Nov, 2016 1 commit
-
-
Alejandro Rodríguez authored
-
- 11 Nov, 2016 1 commit
-
-
- 09 Nov, 2016 3 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
Douwe Maan authored
Honour issue and merge request visibility in their respective finders This MR fixes a security issue with the IssuesFinder and MergeRequestFinder where they would return items the user did not have permission to see. This was most visible on the issue and merge requests page for a group containing projects that had set their issues or merge requests to "private". Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22481 See merge request !2000
-
- 07 Nov, 2016 2 commits
-
-
tiagonbotelho authored
reactivates all tests and writes more tests for it
-
Douwe Maan authored
email token be reset
-
- 04 Nov, 2016 1 commit
-
-
Nick Thomas authored
-
- 01 Nov, 2016 2 commits
-
-
Felipe Artur authored
-
Douglas Barbosa Alexandre authored
-
- 28 Oct, 2016 1 commit
-
-
Adam Niedzielski authored
Do not pass project.owner because it may return a group and Labels::FindOrCreateService throws an error in this case. Fixes #23694.
-
- 24 Oct, 2016 1 commit
-
-
David Wagner authored
They were Rails' default and are unnecessarily overridden. Signed-off-by: David Wagner <david@marvid.fr>
-
- 20 Oct, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
Callback associations are not common to see around. We want to make clear that the `before_add` callback uses the number before the addition, in this particular case 1.
-
Douwe Maan authored
-
- 19 Oct, 2016 5 commits
-
-
Felipe Artur authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
James Lopez authored
Fixed all related specs and also changed the logic to handle edge cases. This includes exporting and exporting of group labels, which will get associated with the new group (if any) or they will become normal project labels otherwise. Found other issues to do with not being able to import all labels at once in the beginning of the JSON - code was much simpler when we import all labels and milestones associated to a project first, then the associations will find the already created labels instead of creating them from the associations themselves.
-
Douglas Barbosa Alexandre authored
-