| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
legibility in `SpamCheckService`
|
|
|
|
|
|
|
|
|
|
| |
user projects
Currently, even when searching for all authorized issues of *one* project, we run the
`Users#authorized_projects` query (which can be rather slow). This update checks if
we are handling issues of just one project and does the authorization check locally.
It does have the downside of basically repeating the logic of `Users#authorized_projects`
on `Project#authorized_for_user`.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
of max database values
When using #XYZ in Markdown text, if XYZ exceeds the maximum value of a signed 32-bit integer, we
get an exception when the Markdown render attempts to run `where(iids: XYZ)`. Introduce a method
that will throw out out-of-bounds values.
Closes #18777
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several changes to this module:
1. The use of an explicit stack in Participable#participants
2. Proc behaviour has been changed
3. Batch permissions checking
== Explicit Stack
Participable#participants no longer uses recursion to process "self" and
all child objects, instead it uses an Array and processes objects in
breadth-first order. This allows us to for example create a single
Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
a ReferenceExtractor removes the need for running potentially many SQL
queries every time a Proc is called on a new object.
== Proc Behaviour Changed
Previously a Proc in Participable was expected to return an Array of
User instances. This has been changed and instead it's now expected that
a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
value of the Proc is ignored.
== Permissions Checking
The method Participable#participants uses
Ability.users_that_can_read_project to check if the returned users have
access to the project of "self" _without_ running multiple SQL queries
for every user.
|
|
|
|
|
|
|
|
|
| |
In 8278b763d96ef10c6494409b18b7eb541463af29 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
|
| |
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
due tomorrow to issues.
Fix typos on sorting dropdown related to due date
Remove constant array and add Structs on Issue to keep due date data to fill options
|
|
|
|
|
|
|
|
|
|
|
| |
Add due_date text field to sidebar issue#show
Add ability sorting issues by due date ASC and DESC
Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options
Add handling issue due_date field for MergeRequest
Update CHANGELOG
Fix ambigous match for issues#show sidebar
Fix SCREAMING_SNAKE_CASE offenses for due date contants
Add specs for due date sorting and filtering on issues
|
|\
| |
| |
| |
| |
| |
| | |
Define constants only if not defined yet and freeze them
Fixes #15139.
See merge request !3810
|
| |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
| |
| |
| | |
`<id>-confidential-issue`.
|
|\ \
| |/
| |
| | |
14566-confidential-issue-branches
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Previously, the controller held the logic to calculate
related branches, which was:
`<branches ending with `issue.iid`> - <branches with a merge request referenced in the current issue>`
- This logic belongs in the `related_branches` method, not in the
controller. This commit makes this change.
- This means that `Issue#related_branches` now needs to take a `User`.
When we find the branches that have a merge request referenced in the
current issue, this is limited to merge requests that the current user
has access to.
- This is not directly related to #14566, but is a related refactoring.
|
|/
|
|
|
|
|
| |
- When creating new branches for confidential issues,
prefer a branch name like `issue-15` to
`some-sensitive-issue-title-15`.
- The behaviour for non-confidential issues stays the same.
|
|
|
|
|
| |
These methods are called quite often in loops so by memoizing their
output we can reduce timings a bit.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
# Conflicts:
# app/models/issue.rb
# app/views/projects/_home_panel.html.haml
# app/views/shared/projects/_project.html.haml
# db/schema.rb
# spec/models/project_spec.rb
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Improve performance of viewing individual issues
This MR does two things:
1. `Issue#related_branches` no longer performs Git operations that aren't needed
2. The output of `Repository#exists?` is now cached and flushed properly
Combined these two changes should further cut down the amount of Git operations performed when viewing individual issues (and possibly other pages).
See merge request !3296
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Requesting the branch names of a repository works even when it's empty,
thus there's no need to explicitly check for an empty repository.
Removing this check cuts down the amount of Git operations which in turn
cuts down request timings a bit. The regular expression used to compare
branches was also moved out of the loop so it's created only once.
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* master:
Fix bug where wrong commit ID was being used in a merge request diff to show old image
Remove CHANGELOG item that was added during merge resolution
Improve the "easy WIP & un-WIP from link" feature
Fix specs
\#to_branch_name now uses the iid as postfix
Add label description in tooltip to labels in issue index and sidebar
Easily (un)mark merge request as WIP using link
Use specialized system notes when MR is (un)marked as WIP
another attempt to fix oauth issue
attempting to fix omniauth problem
Conflicts:
app/assets/javascripts/issuable_form.js.coffee
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* master: (121 commits)
Dedupe labels in labels selector in Dashboard pages
Refactor colors and lists
Add a safeguard in MergeRequest#compute_diverged_commits_count
Fix an issue when the target branch of a MR had been deleted
Add avatar to issue and MR pages header
Cleanup somce css colors
Re-group scss variables
Refactor `Todo#target`
Fixes issue with filter label missing on labels & milestones
Rename `Todo#to_reference` to `Todo#target_reference`
Fixed failing tests
Updated controller with before_action Fixed other issues based on feedback
Fixes issue on dashboard issues
Full labels data in JSON
Fixed issue with labels dropdown getting wrong labels
Update CHANGELOG
Use `Note#for_project_snippet?` to skip notes on project snippet
Use `Commit#short_id` instead of `Commit.truncate_sha`
Reuse `for_commit?` on conditional validations
Update schema info comment on todo related files
...
Conflicts:
app/models/issue.rb
db/schema.rb
spec/models/issue_spec.rb
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given the branch name 'mep-mep' with an iid being 1,
the current way, master's way, would yield a branch name of
1-mep-mep. The problem for larger projects however would be that
a developer might forget what iid the issue was.
When this developer would try to tab complete it would:
- Or result in 20+ branches possibly
- Or start with the wrong digit, try again with digit++
- Would see 20 branches, repeat
Thus the obvious way of solving this is letting the dev tab complete
on the issue title, which is easier to remember.
|
| | |
|
| |
| |
| |
| | |
Spinach was right, I was a fool..
|
| |
| |
| |
| | |
The feature spec now also tests the absence of the new branch button
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
These scopes don't care about the order. Removing the explicit "ORDER
BY" can speed up the queries by a little bit.
|
|
|
|
|
|
|
| |
This replaces plucking of IDs with a sub-query, saving the overhead of
loading the data in Ruby and then mapping the rows to an Array of IDs.
This also scales much better when dealing with a large amount of IDs
that would be involved.
|
| |
|
| |
|
| |
|
| |
|
| |
|