If the project does not have refs/meta/config the revision is
null. Enable loading the access screen anyway with a null revision
field, and on save of any edits require the branch to be new.
This is already handled by MetaDataUpdate, provided that the base
revision we supply is null, so make it @Nullable inside of the
ChangeProjectAccess handler.
Change-Id: I4417bf802e329eb7193a7cb514f7ebcd7d68f26e
Gerrit was insisting on DIGEST authentication when doing git over http.
This change allows to configure gerrit to trust the container to do
the authentication. A new boolean configuration parameter
auth.trustContainerAuth was introduced.
Change-Id: Ie527ed2c9e73c4f7136b271c66ee8b621fc4c79a
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Jens Baumgart <jens.baumgart@sap.com>
Add columns for 'Owners', 'Group Type', 'Email Only Authors' and
'Visible To All' into the groups table used by Admin->Groups Screen
and MyGroups Screen. Adding more info to this table helps the
administrators to view the settings and additional info of a group
faster without clicking on each group. This can work as a dashboard
or report that contains the info for all the groups in one place.
As an example, this allows one to quickly find all the groups which
are having emails squelched.
Change-Id: Ia952e9dcecf415c4fce7001a0d28ad4731ff5b1c
When we do Gerrit development work we start by creating a "gerrit
test site". During test site initialization, normally we select
"DEVELOPMENT_BECOME_ANY_ACCOUNT" mode. However, to setup test user
accounts we need to register users. For every test-user we add
to the test site, Gerrit wants to send a confirmation email which
we need to receive and then click the link in it.
This change will enable Gerrit accept email address automatically
in "DEVELOPMENT_BECOME_ANY_ACCOUNT" mode.
Change-Id: Iec6f34e0ecd335b04ef5bf1a5d61c8a906cfd19f
This feature aims to test the mergeability of each change tagging it
according to the result (true or false).
When the change page is load, the test is triggered and the sha1 of
the dest branch (tested against) is stored within the change table.
The submit button will be enabled or disabled according to the result.
The test is triggered only if it’s outdated.
As the branch evolves the sha1 stored at the moment of the test
becomes different from the last one merged into the branch, meaning
the test is outdated.
Bug: issue 381
Change-Id: I8bdb26db6fc35067b8c14b987984cfd80745f3d3
The Eclipse Reviews plugin currently parses what types of reviews are possible
by parsing the javascript from a gerrit page load. This minor
improvement exposes the same information via json rpc that is provided
via the HTML.
Curl command to test:
curl --header 'Accept: application/json' --data-binary \
'{"jsonrpc":"2.0","method":"gerritConfig",id:2222}' -H 'Content-Type: \
application/json; charset=UTF-8' \
http://127.0.0.1:8080/gerrit/rpc/SystemInfoService
Bug: issue 848
Change-Id: Ie114d91073857304a234602187deee183eec4510
The refs/meta/config branch was not shown in the ProjectBranchesScreen
since all refs that were not starting with refs/heads/ were filtered
out. The refs/meta/config branch contains important configuration data
for the project and should therefore be displayed along with the other
branches. With this change the refs/meta/config branch is not ignored
anymore and displayed properly in the ProjectBranchesScreen.
Since refs/meta/config is not just any branch, but has a special
meaning to Gerrit it is always displayed at the top below HEAD.
Change-Id: I2b9d89004a15813ef301ce6ea803b5c4e10b7302
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
The first 5 (by accountId) user names are displayed as clickable
links. Clicking a user name logs in as this user.
This change speeds up switching between different users when using
the DEVELOPMENT_BECOME_ANY_ACCOUNT authentication type.
Change-Id: Ie9e5f2c4fe2809d03aa16bdf516e8fd04323c897
On the ChangeScreen it is now possible to add a group as reviewer for
a change. When a group is added as reviewer the group is resolved and
all its members are added as reviewers to the change.
To avoid that users accidentily add groups as reviewers that have a
large amount of members, Gerrit administrators can configure a
maximum number of reviewers that can be added at once by adding a
group as reviewer. In addition Gerrit administrators can configure
that users should confirm the adding of the reviewers if the number
of reviewers that should be added is over a certain limit.
It is also possible to add the system group 'Project Owners' as
reviewer. In this case all users which own the project are added as
reviewers.
If a user and a group have the same name, only the user is added as
reviewer.
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
Bug: issue 881
Change-Id: I78a359f89ce045a81306e0a447384c37cda07d00
The restore action has been erroneously using the Abandoned.vm
template. Create a template and sender for the restore
command. Refactor some code to make this additonal sender
share much in common with the AbandonedSender.
Change-Id: Id1c61ead7cf71c3476759f0a968f1bf013b77b47
Instead of using http://site/#change,1234 we now use a slightly more
common looking http://site/#/c/1234 URL to link to a change. It
is also quite a bit shorter than the old format, using up less space
in the address bar.
Files within a patch set are now denoted below the change, as in
http://site/#/c/1234/1/src/module/foo.c making it easier to jump
directly to a specific file, or to just see the structure of the
current view.
Whenever possible the old URLs continue to work by redirecting
to the equivalent new URL. We plan to keep the old URLs alive,
as many issue tracking systems have direct links based on the old
URL format and these links should not be invalidated.
This change also fixes the dynamic redirects of http://site/1234
and http://site/r/deadbeef to jump directly to the corresponding
change if there is exactly one possible URL. This avoids the ugly
interim redirect to http://site/#/q/1234,n,z when the server can
compute what the correct location should be on its own.
Entities that have multiple views suffix the URL with ",view-name"
to indicate which view the user wants to see. For files the default
view is the side-by-side view and does not have a suffix, while the
unified patch view has a suffix of ",unified", for example:
http://site/#/c/1234/1/src/module/foo.c,unified.
Project admin panels use a similar view suffix to denote which of
the tabs on the left menu is currently open, with the main info tab
being the default with no suffix.
Change-Id: I2bac7ef1b2638fb08df2659b8373960eadec205a
* changes:
Add permission_sort cache to remember sort orderings
Reuse cached RefControl data in FunctionState
Refactor how permissions are matched by ProjectControl, RefControl
Cache effective capabilities to improve lookup performance
If change dependency no longer the latest patchSet for that
change, mark it OUTDATED in the dependencies table and make
its row red, and add a warning message to the dependencies
header. Additionally make the link for dependencies link to
the exact patchSet of the dependent change. Lastly, keep the
dependencies disclosure panel open even when an outdated
dependent change is merged.
Bug issue: 855
Change-Id: I238431eeccba3c41555ef229e4003c3910746499
Currently the FunctionState code is run for every change in a
change listing in the web UI, or the user dashboard. Looking
up the relevant permissions for each reviewer is costly, but
can typically be cached and reused off the request's cache,
as most changes are not on username specific references.
Change-Id: Idff421e1eecf651db11549d6591484578cd9543c
Change-Id: I82447dd9ce47ffc44727d9f886a45a9fa1a2463e
Signed-Off-By: James Y Knight <jyknight@google.com>
(cherry picked from commit b8ddd05fbf98c63b70bfa3a714952b43bcad549a)
When a client asks the server for access to a Git repository, the
server has to compute a list of tags to advertise to the client.
It is an expensive computation to determine which tags are reachable
from the branches the client has READ permission on. For large
repositories with many tags the computation can take a considerable
amount of time, bordering on several seconds per connection. To make
the general case more efficient, introduce a cache called "git_tags".
On a trivial usage of the Linux kernel repository, the average
running time of the VisibleRefFilter when caches were hot was
7195.68 ms. With this commit, it is a mere 5.07 milliseconds
on a hot cache. A reduction of 99% of the running time.
The caches performs incremental updates under certain situations,
making common updates relatively painless for waiting clients:
* Branch fast-forward / change submission:
When a branch fast-forwards to a new commit, or a change is
submitted to a branch, all prior tags that are reachable from
that branch are still reachable. The cache updates itself
in-place to this new commit, after performing a fast-forward
check. Although a fast-forward check requires walking commit
history, most fast-forwards are only a few commits ahead of the
prior position, making the check fast enough to do on demand
for a client. Once the cache has been updated, other clients
will not need to perform the check.
* Short branch rewinds:
If a branch rewinds to a prior version (or cuts to a different
history), and in doing so does not eliminate any tags, the
cache is updated in-place in real-time. Since the change did
not impact any tags, the cache is still valid and can continue
to be reused.
* Branch deletion:
If a branch is deleted, the cache is not updated. The deleted
branch is simply ignored in the cache. If a great number of
branches are deleted and the cache is wasting memory, site
administrators should flush the "git_tags" cache and force a
rebuild. However, since a branch costs just 1 bit per tag, plus
the size of the branch name string, it would require deleting
75,000 branches before its even worth considering flushing the
cache manually... as 75,000 branches is about 5 MB of storage.
* Branch creation at another branch tip:
If a new branch is created and points to the same commit as
an existing branch, the cache is updated by cloning itself
and adding the new branch for all tags reachable from the
source branch. To keep things thread-safe in memory with
minimal locking, this type of update requires making a full
copy of the cache's data and is therefore more expensive than
the prior update techniques, but is significantly cheaper than
a full rebuild.
There are some nasty corner cases the cache does not try to
handle. For these we just suffer through a full rebuild:
* Branch creation not at another branch tip:
Since the newly created branch does not exactly match another
branch, the project history must be scanned and computed to
determine which tags are reachable from which branches. There
is no optimization available for creating a new branch at
an existing tag, so those cases also force a rebuild.
* New tag:
Since the tag position is not exactly known, which branches can
reach it is also not known. The project history is scanned to
rebuild the cache.
Unlike the prior version of VisibleRefFilter, a rebuild of the
cache only walks the history of the project once. This makes a
rebuild slightly faster (5s now vs. 7s before).
Cache updates occur automatically as a result of observed changes in
the Git repository references. Doing these updates live just before
sending the advertisement to a client ensure the cache's reachability
data accurately represents the advertisement the client will receive.
It also ensures any updates made directly to the repository (without
Gerrit being involved) is still properly reflected in the result.
We try to optimize updates for two common cases: change submission
and direct push fast-forwards. Both attempt to update the cache
immediately after the reference has been updated. This saves clients
from needing to perform the fast-forward check themselves, as the
change submission or receive code already performed the check and
has the results on hand.
There is still room for future improvement:
Adding a new tag to the cache could be computed more quickly by
copying the old cache, and doing a walk from all branch heads up
to the new tag, but stopping at the new tag. This does not always
work well when there are disconnected branches in the repository,
as those unrelated branches will scan to the roots before
terminating, making the update nearly the cost of full rebuild.
Adding a new branch not at the exact same position as another
branch could be computed more quickly by scanning all commits
in the new branch (to see if tags were added), and all commits
in existing branches (to see if tags should be excluded), and
stopping at the merge base of the two sets. Any tags that are not
excluded from the other branches but are reachable from the other
branches should also be reachable from the new branch. However
this is a tricky concept, as one must consider unrelated branches,
so this operation may need to be performed once per unique set
of branches that a tag can reach. Since this may require more
than one history traversal, and if the branches are unrelated,
a traversal all the way to the root, its nearly as expensive as
the full rebuild option. Since its a lot more complex than a full
rebuild, I am punting on this and may never implement it.
Change-Id: I519a39ade2742de02003d9dedd17a8edca5c4923
The UI now shows whatever the results of the submit_rule are, which
permits the submit_rule to make an ApprovalCategory optional, or to
make a new label required. Currently making a new label required is
also going to make the change unsubmittable, as we do not yet have
a way to store the new label.
Change-Id: I9c6600c181e9f22ff980539d535caa8458d9a654
This is a refactoring, it should not change functionality
at all. Move CLA check out of ReceiveCommits and into
ProjectControl. Create a common Capable class to facilitate
this.
Change-Id: I43ff798bcb727918eb39b1ec8dc7e14278c91b1f
This should be done only once, inside of the common
PerformCreateGroup object and not by both the HTTP
and SSH interface glue.
Change-Id: I6f774fe318412a7220206b99d7279d5b061355ad
Instead of using a magical group, use a special capability to
denote users that should get the batch priority behavior.
Change-Id: I3e1f8f3ee39f5dcb2cdad2f9c71c46db25fc30b6
This gets rid of the special entries in system_config and
gerrit.config related to who the Administrators group is,
or which groups are permitted to create new projects on
this server.
An interesting side effect of this change is admins can
now actually remove the blessed Administrators group and
run the server entirely without it. Fine grained rules
can be used for most permissions, and direct access to
the All-Projects.git repository can be used for cases
where the "Administrate Site" override power is needed.
Another benefit is the 'Create Project' capability is
now dynamic, and can be modified at runtime without a
server restart.
Bug: issue 742
Change-Id: I44702010a4a521fd67d986d5b20411002c9481dd
The Global Capabilities section in All-Projects can now be used to
grant subcommands that are available over SSH and were previously
restricted to only Administrators.
Bug: issue 48
Bug: issue 742
Change-Id: I7d8a931b174915191817ff845f1f9a846181d709
This makes it easier to ask what is the current user permitted to
perform, given the system's access controls. The limits are needed
not just for query size, but also other fine-grained permissions.
Change-Id: Ic767eb9184acce34e435629a00b037245e6ea607
A server should have the Global Capabilities block with a default
query limit, but some older installations might not have this set
yet in their All-Projects configuration.
Change-Id: I07292d49a5502648c36fffb2494831b64862cf7a
A project name should never end in "/", this is the filesystem
name separator and is typically optional at the end of a path.
In Gerrit Code Review we have standarized on never terminating
a project name with "/", as this is somewhat redundant.
After the move of the projects table out of the database and to
the local filesystem, clients over SSH were able to incorrectly
specify a project name with a trailing "/" during push, creating
new changes for review with the wrong value in the dest_project
column in the database.
Change-Id: I01c1c21daa9dd110cca53302ec52fd00b61efd30
Allow site administrators to configure the query limit for users
to be above the default hard-coded value of 500. Administrators
can add a global block to All-Projects project.config file with
group(s) that should have different limits:
[capability]
queryLimit = +0..1000 group Automated Tools
queryLimit = +0..100 group Registered Users
When applying a query limit to a user the largest value granted by any
of their groups is used.
This limit applies not only to the `gerrit query` command, but also
to the web UI results pagination size.
Bug: issue 934
Change-Id: I4e05448794de44bf51d3f0121358e456ab965c8b
Signed-off-by: Shawn O. Pearce <sop@google.com>
Re-implement the canSubmit() logic in Prolog, removing one of the
last uses of FunctionState. This is a simple re-implementation
that does not provide any new functionality.
PatchSetApproval objects are exposed into Prolog on demand by
loading them from the database if the submit predicate needs
them. These get indexed in a temporary HashMap by their label name
(aka ApprovalCategory), making access faster during evaluation of
the rule.
ApprovalTypes are loaded into Prolog on demand from the Guice
Injector. This will eventually go away when we get rid of the
global declaration of ApprovalCategories in the web UI.
CurrentUser instances are loaded and cached within the Prolog
environment as needed to consider PatchSetApproval objects and if
the user has the necessary permission to make that assertion.
Bug: 971
Change-Id: I7e261948db08b7c3180e590e81f492ff3e6f237e
Signed-off-by: Shawn O. Pearce <sop@google.com>
Users who are not the owner of an access section should only be
able to see group names and rules for groups they are a member of,
are visible to all users, or that they own.
Bug: issue 972
Change-Id: I97cd2c3915021048dfe9d91f471e42e48a7db45b
* stable:
Fix ChangeDetailFactory's invocation of PatchSetDetailFactory
Release notes for 2.1.7.1
Fix API breakage on ChangeDetailService
Do not reset Patch History selection on navigation to next file diff
Resolve Project Owners when checking access right on any ref
Conflicts:
gerrit-server/src/main/java/com/google/gerrit/server/project/ProjectControl.java
gerrit-server/src/test/java/com/google/gerrit/server/project/RefControlTest.java
Change-Id: I6e956625cb4648df35035b9be2d32e6e431fb8f3
I flipped the order of the arguments, but did not correctly
update all callers.
Change-Id: Iae14ec35374342f53bc353082db35cb8750a750a
Signed-off-by: Shawn O. Pearce <sop@google.com>
The Mylyn Reviews project pointed out Gerrit changed the API
signature of a JSON method they use remotely. Fix the API back to the
original signature, and define a new method with the extra arguments.
Change-Id: I51cbbdd64bdb72a666a6b5266db3b93494b75182
Signed-off-by: Shawn O. Pearce <sop@google.com>
If a project has no access controls listed in its project.config,
nobody was able to add new sections in the web UI. Ensure that
users are at least able to create new sections if they have owner
power on any reference, which may be inherited down from parent
projects or be implied because of their site administrator status.
Bug: issue 1000
Change-Id: I19bab2a75fe3248275fef9fd87ed86cfa580845a
Signed-off-by: Shawn O. Pearce <sop@google.com>
The abandon and restore routines can fail if the change
is in the wrong state (abandoned already, or open still).
These failure lead to internal NPEs. Instead, create a
new exception and give a reason for the failure to the user.
Change-Id: Id7861d75e535c439c12329f7e891797c5b1f6eca
