| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
and syntax fixes.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Submit to Akismet Part 1 (Issues)
Related to #5932 #5573 gitlab-com/infrastructure#14
See merge request !5538
|
| | |
| |
| |
| | |
- Refactored SpamCheckService into SpamService
|
| | |
| |
| |
| |
| | |
- Added `submitted_as_ham` to `SpamLog` to mark which logs have been submitted to Akismet.
- Added routes and controller action.
|
| | |
| |
| |
| |
| |
| |
| | |
- Removed unnecessary column from `SpamLog`
- Moved creation of SpamLogs out of its own service and into SpamCheckService
- Simplified code in SpamCheckService.
- Moved move spam related code into Spammable concern
|
| | |
| |
| |
| |
| |
| |
| | |
- Merged `AkismetSubmittable` into `Spammable`
- Clean up `SpamCheckService`
- Added tests for `Spammable`
- Added submit (ham or spam) options to `AkismetHelper`
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
Try to get back todo's cache or at least avoid hitting the database
See merge request !5789
|
| | |
| |
| |
| |
| |
| |
| | |
We’re being kept up to date the counter data but we’re not using it.
The only thing which is not real if is the number of projects that the
user read changes the number of todos can be stale for some time.
The counters will be sync just after the user receives a new todo or mark any as done
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Change the order of the access rules to check simpler first, and add specs
See merge request !5799
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
In Banzai::Filter::SanitizationFilter#customize_whitelist, we append
three lambdas that has reference to the SanitizationFilter instance,
which in turn (potentially) has a reference to the following chain:
context hash -> Project instance -> Repository instance -> lookup hash
-> various Rugged instances -> various mmap-ed git pack files.
All of the above is not garbage collected because the array we append
the lambdas to is the constant
HTML::Pipeline::SanitizationFilter::WHITELIST.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DRY code + fix rubocop
Add more test cases
Append to changelog
DRY changes list
find_url service for merge_requests
use GET for getting merge request links
remove files
rename to get_url_service
reduce loop
add test case for cross project
refactor tiny thing
update changelog
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
Remove Grack::Auth: part 2 (LFS)
Deprecate Grack::Auth and handle LFS in Rails controllers under the Project namespace.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14501
See merge request !5369
|
| | |\
| | |
| | |
| | | |
remove-grack-lfs
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Refactor pipeline creation service
## What does this MR do?
This refactors GitLab CI build processing: all builds for pipeline are pre-created when a pipeline object is created.
The builds are created with a new introduced status `created`.
The builds are then automatically promoted to `pending` when a previous stage do succeed.
This significantly simplifies pipeline processing code solving a lot of problems of lazily initialisation of previous approach (builds were created on-demand).
## Why was this MR needed?
The previous mechanism had a lot of flows (shown in related issues) in how it work, but also in code design. Removing cross model-service-library dependencies.
The current approach moves a build creation to single place `CreatePipelineService` and removes a dynamic dependency on `config_processor` significantly simplifying a build creation and pipeline processing. Pipeline processing is implemented in `ProcessPipelineService`.
This also allows to easily extend GitLab with Manual Actions which is part of 8.10 direction issue.
## Migration problem
~~This MR removes the a on-demand creation of builds in pipelines.
Pipelines that are running and are in mid-stage (some stages started, but not all) will not be fully evaluated after application restart.
This happens, because the code responsible for on-demand creation is removed.
There's no easy way to migrate existing pipelines, other than doing offline migration and putting pipeline processing in migration code (which seems to be a really bad idea).~~
To support old pipelines I added a lazy initialization of builds if none is found.
## What are the relevant issue numbers?
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/12839
Solves: https://gitlab.com/gitlab-org/gitlab-ce/issues/18644 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/289
Allows to easily implement: https://gitlab.com/gitlab-org/gitlab-ce/issues/17010
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [ ] 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)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5295
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This change simplifies a Pipeline processing by introducing a special new status: created.
This status is used for all builds that are created for a pipeline.
We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
This also allows us to visualise a full pipeline (with created builds).
This also removes an after_touch used for updating a pipeline state parameters.
Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix front-end for branches that happen to contain urlencoding escape characters (e.g. %)
_Originally opened at !3574 by @ewiltshi._
- - -
Adding a branch with a name like "foo%20bar" (via command-line) and setting it to the project's default branch causes the project "show" page to 404 for that project. "assign_ref_vars" unescapes the branch name ("foo%20bar" ==> "foo bar"), making GitLab look for a non-existent branch.
This MR adds logic to skip the URL unescaping step in "assign_ref_vars".
Fixes #10772, #14992, #15304.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [ ] 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 !5770
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
characters (e.g. %)
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use `File::exist?` instead of `File::exists?`
Each `File::exists?` replaced to `File::exist?`.
Since version ruby-2.2.0, method `File::exists?` is deprecated.
See merge request !5747
|
| | |/ / /
| | | |
| | | |
| | | | |
Since version ruby-2.2.0, method `File::exists?` is deprecated.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
'master'
Add group members API endpoints to request access and approve requests
## What does this MR do?
Add group members API endpoints to request access and approve requests.
## Are there points in the code the reviewer needs to double check?
I chose to factorize the group/project members API as well as the new group/project access requests API.
I initially also created new services to centralize the permission checks related to actions on members, but this was out of scope and this MR is already quite big so I opened a temp MR at !5566 based on this one.
## Why was this MR needed?
To finish the "request access" feature.
## What are the relevant issue numbers?
Closes #18583.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] 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 !4833
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
API endpoints
The performance was greatly improved by removing two N+1 queries issues
for each endpoint.
For comparison:
1. `GET /projects/:id/members`
With two N+1 queries issues (one was already fxed in the following
snippet):
```
ProjectMember Load (0.2ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL ORDER BY "members"."id" DESC [["source_type", "Project"],
["source_id", 1], ["source_type", "Project"]]
User Load (0.5ms) SELECT "users".* FROM "users" WHERE "users"."id" IN
(5, 22, 16, 13) ORDER BY "users"."id" DESC
ActiveRecord::SchemaMigration Load (0.2ms) SELECT
"schema_migrations".* FROM "schema_migrations"
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL AND "members"."user_id" = $4 ORDER BY "members"."id" DESC LIMIT 1
[["source_type", "Project"], ["source_id", 1], ["source_type",
"Project"], ["user_id", 5]]
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL AND "members"."user_id" = $4 ORDER BY "members"."id" DESC LIMIT 1
[["source_type", "Project"], ["source_id", 1], ["source_type",
"Project"], ["user_id", 22]]
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL AND "members"."user_id" = $4 ORDER BY "members"."id" DESC LIMIT 1
[["source_type", "Project"], ["source_id", 1], ["source_type",
"Project"], ["user_id", 16]]
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL AND "members"."user_id" = $4 ORDER BY "members"."id" DESC LIMIT 1
[["source_type", "Project"], ["source_id", 1], ["source_type",
"Project"], ["user_id", 13]]
```
Without the N+1 queries issues:
```
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
NULL ORDER BY "members"."id" DESC LIMIT 20 OFFSET 0 [["source_type",
"Project"], ["source_id", 1], ["source_type", "Project"]]
User Load (0.5ms) SELECT "users".* FROM "users" WHERE "users"."id" IN
(5, 22, 16, 13) ORDER BY "users"."id" DESC
```
2. `GET /projects/:id/access_requests`
With two N+1 queries issues:
```
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
NOT NULL) ORDER BY "members"."id" DESC [["source_type", "Project"],
["source_id", 8], ["source_type", "Project"]]
User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" =
$1 ORDER BY "users"."id" DESC LIMIT 1 [["id", 24]]
User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" =
$1 ORDER BY "users"."id" DESC LIMIT 1 [["id", 23]]
ActiveRecord::SchemaMigration Load (0.2ms) SELECT
"schema_migrations".* FROM "schema_migrations"
ProjectMember Load (0.1ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
NOT NULL) AND "members"."user_id" = $4 ORDER BY "members"."id" DESC
LIMIT 1 [["source_type", "Project"], ["source_id", 8], ["source_type",
"Project"], ["user_id", 24]]
ProjectMember Load (0.2ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
NOT NULL) AND "members"."user_id" = $4 ORDER BY "members"."id" DESC
LIMIT 1 [["source_type", "Project"], ["source_id", 8], ["source_type",
"Project"], ["user_id", 23]]
```
Without the N+1 queries issues:
```
ProjectMember Load (0.3ms) SELECT "members".* FROM "members" WHERE
"members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
"members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
NOT NULL) ORDER BY "members"."id" DESC LIMIT 20 OFFSET 0
[["source_type", "Project"], ["source_id", 8], ["source_type",
"Project"]]
User Load (0.5ms) SELECT "users".* FROM "users" WHERE "users"."id" IN
(24, 23) ORDER BY "users"."id" DESC
```
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also, mutualize AccessRequests and Members endpoints for Group &
Project.
New API documentation for the AccessRequests endpoints.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixing scope issue in GitAccess.
This MR fixes a scoping issue around the GitAccessStatus.new call - it needs to be scoped to the Gitlab otherwise it can end up being confused with the GitAccessStatus class in gitlab-shell, which has a 3-element constructor.
Although not strictly necessary for community GitLab, it is more correct, and fixes an issue we (Perforce) found due to our engine overrides.
This change should have any affect on community GitLab.
See merge request !5483
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Clean up project destruction
Instead of redirecting from the project service to the service and back to the model, put all destruction code in the service. Also removes a possible source of failure where run_after_commit may not destroy the project.
See merge request !5695
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Instead of redirecting from the project service to the service and back to the model,
put all destruction code in the service. Also removes a possible source of failure
where run_after_commit may not destroy the project.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use badge image template instead of using separate images
## What does this MR do?
Makes it possible to use template for badge instead of having multiple files.
## Are there points in the code the reviewer needs to double check?
We also have a deprecated badge in `controllers/ci/projects_controller.rb`. We decided to leave it until 9.0, so we still have images in `public/ci/` until 9.0.
## Why was this MR needed?
We are going to implement build coverage badge, and we do not want to store 101 SVG images for each percentage value.
## What are the relevant issue numbers?
#3714
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] ~~[CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added~~ (refactoring)
- [ ] ~~[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)
- [ ] ~~[Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)~~ (refactoring)
See merge request !5520
|
| | |\ \ \ \
| | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* master: (52 commits)
remove offending empty line
Namespace EnableDeployKeyService under Projects
Update version_sorter and use new interface for faster tag sorting
Avoid to show the original password field when password is automatically seted
Support pending invitation project members importing projects
Added concern for a faster "cache_key" method
Update templates
"This file is managed by gitlab-ctl. Manual changes will be erased!"
Remove legacy Ci::StaticModel we do not use anymore
Revert "Defend against 'Host' header injection"
Simplify feature introduction note
Add migration-related tips to the "Merge Request Guidelines" doc
Enable Style/SpaceAroundEqualsInParameterDefault cop
Enable Style/EmptyLinesAroundClassBody cop
Enable Style/EmptyLinesAroundModuleBody cop
Ensure we are looking for the right dropdown inside the form wrapper
Set for for labels and ID for dropdowns on create form
Fix .panel-title style
Refine selector for form submit button
Fix spelling. `braches` to `branches`
...
|
| | | | | | |
|
| | | | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* master: (363 commits)
Added changelog item for issuable form dropdowns
Add 'run tests' docs from GDK
Bump gitlab_git to lazy load compare commits
Add examples to repository files API (!5465)
Ignore URLs starting with // (!5677)
Add failing test for #7032
Update timeago to shorter representation
Add missing DOWNTIME constant to the AddTimestampsToMembersAgain migration
Added guide about migrations and downtime
Update CHANGELOG for 8.10.4
Add a data migration to fix some missing timestamps in the members table (again)
Move abilities by subject class to a dedicated method
Remove unnecessary empty line after css var
Set consistency in list text height css
Add description to text/plain emails
Fix Rename `add_users_into_project` and `projects_ids`
fix spec
Underscore variable to camelCase
using shared path for project import uploads and refactored gitlab remove export worker
Structure the development documentation
...
|
| | | | | | | |
|
| | | | | | | |
|
