- 16 Nov, 2016 1 commit
-
-
Robert Speicher authored
Prior, an administrator viewing a project's Labels page would see _all_ labels from every project they had access to, rather than only the labels of that specific project (if any). This was not an information disclosure, as admins have access to everything, but it was a performance issue.
-
- 09 Nov, 2016 1 commit
-
-
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
-
- 01 Nov, 2016 2 commits
-
-
Douglas Barbosa Alexandre 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.
-
- 25 Oct, 2016 5 commits
-
-
Stan Hu authored
Some users experienced 502 timeouts when viewing group labels. Labels#open_issues_count and Label#open_merge_requests_count were taking a long time to load because they were loading every ActiveRecord of the user-accessible projects into memory. This change modifies the system so that #presence and hence to_a isn't called. Closes #23684
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
If you attempt to move an issue from one project to another and leave labels blank, LabelsFinder would assign all labels in the new project to that issue. The issue is that :title is passed along to the Finder, but since it appears empty no filtering is done. As a result, all labels in the group are returned. This fix handles that case. Closes #23668
-
- 19 Oct, 2016 12 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 10 Oct, 2016 1 commit
-
-
Yorick Peterse authored
This commit introduces a Sidekiq worker that precalculates the list of trending projects on a daily basis. The resulting set is stored in a database table that is then queried by Project.trending. This setup means that Unicorn workers no longer _may_ have to calculate the list of trending projects. Furthermore it supports filtering without any complex caching mechanisms. The data in the "trending_projects" table is inserted in the same order as the project ranking. This means that getting the projects in the correct order is simply a matter of: SELECT projects.* FROM projects INNER JOIN trending_projects ON trending_projects.project_id = projects.id ORDER BY trending_projects.id ASC; Such a query will only take a few milliseconds at most (as measured on GitLab.com), opposed to a few seconds for the query used for calculating the project ranks. The migration in this commit does not require downtime and takes care of populating an initial list of trending projects.
-
- 05 Oct, 2016 1 commit
-
-
Yorick Peterse authored
== Public Projects This finder class now _only_ returns public projects. Previously this finder would also return private and internal projects. Including these projects makes caching data much harder and less efficient. Meanwhile including this data isn't very useful as very few users would be interested in seeing projects they have access to as trending. That is, the feature is more useful when you want to see what _other_ popular projects there are. == Caching The data returned by TrendingProjectsFinder is now cached for a day based on the number of months the data should be restricted to. The cache is not flushed explicitly, instead it's rebuilt whenever it expires. == Timings To measure the impact I changed the finder code to use the last 24 months instead of the last month. I then executed and measured 10 requests to the explore page. On the current "master" branch (commit 88fa5916) this would take an average of 2.43 seconds. Using the changes of this commit this was reduced to around 1.7 seconds. Fixes gitlab-org/gitlab-ce#22164
-
- 30 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 28 Sep, 2016 3 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Sep, 2016 1 commit
-
-
barthc authored
-
- 07 Sep, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 31 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 19 Aug, 2016 1 commit
-
-
Felipe Artur authored
-
- 18 Aug, 2016 1 commit
-
-
Paco Guzman authored
Use just SQL to check is a user can admin_issue on a project Using offset pagination instead pages to avoid a count query Tradeoff - we duplicate how we check admin_issue in a SQL relation in the Ability class
-
- 17 Aug, 2016 1 commit
-
-
Paco Guzman authored
Use just SQL to check is a user can admin_issue on a project Tradeoff - we duplicate how we check admin_issue in a SQL relation in the Ability class
-
- 15 Aug, 2016 2 commits
-
-
Ahmad Sherif authored
-
Ahmad Sherif authored
Closes #20828
-
- 12 Aug, 2016 1 commit
-
-
Rémy Coutable authored
Some important things to note: - commands are removed from noteable.description / note.note - commands are translated to params so that they are treated as normal params in noteable Creation services - the logic is not in the models but in the Creation services, which is the right place for advanced logic that has nothing to do with what models should be responsible of! - UI/JS needs to be updated to handle notes which consist of commands only - the `/merge` command is not handled yet Other improvements: - Don't process commands in commit notes and display a flash is note is only commands - Add autocomplete for slash commands - Add description and params to slash command DSL methods - Ensure replying by email with a commands-only note works - Use :subscription_event instead of calling noteable.subscribe - Support :todo_event in IssuableBaseService Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 01 Aug, 2016 1 commit
-
-
zs authored
Provide more sensible default sort order for issues and merge requests based on the following table: | type | state | default sort order | |----------------|--------|--------------------| | issues | open | last created | | issues | closed | last updated | | issues | all | last created | | merge requests | open | last created | | merge requests | merged | last updated | | merge requests | closed | last updated | | merge requests | all | last created |
-
- 19 Jul, 2016 1 commit
-
-
tiagonbotelho authored
-