| Age | Commit message (Collapse) | Author |
|---|
|
Adding support for personal snippet endpoint on the API
Closes #22042
See merge request !6373
|
|
Fix Archived project merge requests add to group's Merge Requests
Closes #24733
See merge request !7790
|
|
Ensure state param has a valid value when filtering issuables.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/25064
This fix makes sure we only call safe methods on issuable when filtering by state.
See merge request !2038
|
|
counter
This is done by:
- Extending the IssuableFinder adding the non_archived option to the params
- Overriding the #filter_params in the MergeRequestsAction
- Passing the non_archived param in the nav/_group.html.haml navbar
partial from the groups/merge_requests.html.haml
|
|
Adding the necessary API for the new /snippets Restful resource
added with this commit. Added a new Grape class `Snippets`, as
well as a `PersonalSnippet` entity.
Issue: #20042
Merge-Request: !6373
Signed-off-by: Guyzmo <guyzmo+gitlab+pub@m0g.net>
|
|
|
|
Closes #23150
|
|
Disable the "request access" functionality by default for new groups and projects
Currently this feature is enabled by default, and additional action is required to disable it.
Closes #21992
Closes !7011
See merge request !7425
|
|
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.
|
|
required
|
|
When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing
to the sha of the tag to the sha of the commit the tag points to. The
problem is that only annotated tags have `object_sha`s, lightweight tags
don't (it's nil), so (only) in their case we still need to use
`tag.target`.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
== 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
88fa5916ffa0aea491cd339272ed7437c3f52dc7) 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
|
|
|
|
Fortunately, only specs needed to be fixed, so that's good!
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
'21983-member-add_user-doesn-t-detect-existing-members-that-have-requested-access' into 'master'
Resolve "`Member.add_user`doesn't detect existing members that have requested access"
## What does this MR do?
This merge request handle the case when an access requester is added to a group or project (via the members page or the API).
In `Member.add_user`, if an access requester already exists, we simply accept their request (and set the `created_by`, `access_level` and `expires_at` attributes if given).
## Are there points in the code the reviewer needs to double check?
I've taken the opportunity to cleanup the whole `{Group,Project}Member.add_user*` methods since it was quite a mess.
## What are the relevant issue numbers?
Closes #21983
See merge request !6393
|
|
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>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
database IDs
Fixes failed builds such as https://gitlab.com/gitlab-org/gitlab-ce/builds/3919501
|
|
|
|
|
|
Todos sorting dropdown
Implements #18135
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5691
|
|
|
|
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
|
|
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
|
|
Follow-up 1003454c
|
|
Follow-up on 1003454c
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
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'`.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
same time and writes tests accordingly
changes schema.db
removes duplicate field inside CHANGELOG
fix db/schema
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
- Don't do setup in spec bodies.
- Don't `describe` a symbol.
- Don't use 'should'.
|
|
This ensures that IssuableFinder returns a collection of unique issues,
even when filtering issues using multiple labels.
|
|
|
|
|
|
|
|
|
