| Age | Commit message (Collapse) | Author |
|---|
|
== 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
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
Refactor ability.rb into Policies
## What does this MR do?
Factors out `ability.rb` into a new abstraction - the "policy" (stored in `app/policies`). A policy is a class named `#{class_name}Policy` (looked up automatically as needed) that implements `rules` as follows:
``` ruby
class ThingPolicy < BasePolicy
def rules
@user # this is a user to determine abilities for, optionally nil in the anonymous case
@subject # this is the subject of the ability, guaranteed to be an instance of `Thing`
can! :some_ability # grant the :some_ability permission
cannot! :some_ability # ensure that :some_ability is not allowed. this overrides any `can!` that is called before or after
delegate! @subject.other_thing # merge the abilities (can!) and prohibitions (cannot!) from `@subject.other_thing`
can? :some_ability # test whether, so far, :some_ability is allowed
end
def anonymous_rules
# optional. if not implemented `rules` is called where `@user` is nil. otherwise this method is called when `@user` is nil.
end
end
```
See merge request !5796
|
|
|
|
|
|
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
|
|
|
|
Move to project dropdown with infinite scroll for better performance
## What does this MR do?
On the Move dropdown on the edit issue page we introduced infinite scrolling to just return a limited number of projects, 50 items. So if the user can move the issue to 50 or more items when scroll down on the list a new set of projects will be requested to the server.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
See #17932
## What are the relevant issue numbers?
Closes #17932
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- ~~[ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- ~~[ ] API support 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 !5686
|
|
Support slash commands in issues / MR description & comments
See merge request !5021
|
|
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
|
|
# Conflicts:
# app/services/issues/create_service.rb
|
|
|
|
Closes #20828
|
|
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>
|
|
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 |
|
|
|
|
Add approval required todos
Ports the 'approval required' todo type from EE - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/547
See merge request !5217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Manually create todo for issuable
## What does this MR do?
Adds a button to the sidebar in issues & merge requests to allow users to manually create a todo item themselves.
## What are the relevant issue numbers?
Closes #15045
## Screenshots (if relevant)
See merge request !4502
|
|
|
|
Added a button into the sidebar for issues & merge requests to allow users to manually create todo items
Closes #15045
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
them differently
|
|
within projects you have access to.
|
|
todo model
|
|
the join
|
|
By joining the Todos on the project table.
|
|
|
|
|
|
Fix groups API to list only user's accessible projects
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/17496
See merge request !1966
|
|
|
|
Closes #17496
|
|
|
|
|
|
Create a todo on failing MR build
Implements #14067. I worked on this with @DouweM (any mistakes are mine).
When a build fails for a commit, create a todo for the author of the merge request that commit is the HEAD of. If the commit isn't the HEAD commit of any MR, don't do anything. If there already is a todo for that user and MR, don't do anything.
Current limitations:
- This isn't configurable by project.
- The author of a merge request might not be the person who pushed the breaking commit.
- I haven't tested this with a working CI setup, just with the unit tests below and by modifying my DB directly.
See merge request !3177
|
|
# Conflicts:
# app/controllers/projects/merge_requests_controller.rb
# app/models/note.rb
# db/schema.rb
# spec/models/note_spec.rb
|
