- 25 Oct, 2016 3 commits
-
-
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 1 commit
-
-
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
-
- 03 Oct, 2016 2 commits
-
-
Robert Speicher authored
-
Rémy Coutable authored
Fortunately, only specs needed to be fixed, so that's good! Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 28 Sep, 2016 2 commits
-
-
Rémy Coutable authored
Changes include: - Ensure Member.add_user is not called directly when not necessary - New GroupMember.add_users_to_group to have the same abstraction level as for Project - Refactor Member.add_user to take a source instead of an array of members - Fix Rubocop offenses - Always use Project#add_user instead of project.team.add_user - Factorize users addition as members in Member.add_users_to_source - Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects - Destroy any requester before adding them as a member - Improve the way we handle access requesters in Member.add_user Instead of removing the requester and creating a new member, we now simply accepts their access request. This way, they will receive a "access request granted" email. - Fix error that was previously silently ignored - Stop raising when access level is invalid in Member, let Rails validation do their work 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
-
- 09 Sep, 2016 1 commit
-
-
Stan Hu authored
Fixes failed builds such as https://gitlab.com/gitlab-org/gitlab-ce/builds/3919501
-
- 07 Sep, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 31 Aug, 2016 1 commit
-
-
tiagonbotelho 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
Follow-up 1003454c
-
Ahmad Sherif authored
Follow-up on 1003454c
-
- 09 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 02 Aug, 2016 1 commit
-
-
winniehell authored
-
- 01 Aug, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 28 Jul, 2016 1 commit
-
-
Herminio Torres authored
Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value. E.g. When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title. Change the implementation of the `link_to` `filter_branches_path` - Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`. - Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.
-
- 26 Jul, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 19 Jul, 2016 2 commits
-
-
tiagonbotelho authored
same time and writes tests accordingly changes schema.db removes duplicate field inside CHANGELOG fix db/schema
-
tiagonbotelho authored
-
- 12 Jul, 2016 1 commit
-
-
Robert Speicher authored
-
- 01 Jul, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 15 Jun, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 14 Jun, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 16 May, 2016 2 commits
-
-
Sean McGivern authored
Before: we took the next milestone due across all projects in the search and found issues whose milestone title matched that one. Problems: 1. The milestone could be closed. 2. Different projects have milestones with different schedules. 3. Different projects have milestones with different titles. 4. Different projects can have milestones with different schedules, but the _same_ title. That means we could show issues from a past milestone, or one that's far in the future. After: gather the ID of the next milestone on each project we're looking at, and find issues with those milestone IDs. Problems: 1. For a lot of projects, this can return a lot of IDs. 2. The SQL query has to be different between Postgres and MySQL, because MySQL is much more lenient with HAVING: as well as the columns appearing in GROUP BY or in aggregate clauses, MySQL allows them to appear in the SELECT list (un-aggregated).
-
Sean McGivern authored
- Don't do setup in spec bodies. - Don't `describe` a symbol. - Don't use 'should'.
-
- 13 Apr, 2016 1 commit
-
-
Yorick Peterse authored
This ensures that IssuableFinder returns a collection of unique issues, even when filtering issues using multiple labels.
-
- 21 Mar, 2016 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Felipe Artur authored
-