- Use '/' key to quickly access this field.
- Enter a name of repository, or repository group for quick search.
- Prefix query to allow special search:
user:admin, to search for usernames, always global
user_group:devops, to search for user groups, always global
pr:303, to search for pull request number, title, or description, always global
commit:efced4, to search for commits, scoped to repositories or groups
file:models.py, to search for file paths, scoped to repositories or groups
For advanced full text search visit: repository search
repo groups: make it possible to remove own explicit permissions, now when group owners always have admin permissions
Until recently, group owners very given explicit admin permissions on repo
group, and special care was taken to make sure they didn't remove themselves.
Now we always give admin permissions to owners, and don't care about the
explicit permissions. We no longer add them when creating groups or changing
owner. There is no migration step to remove redundant permissions, but we
should allow group admins to remove them. This change will thus remove the
mechanism for preventing removal of own/owner permissions.
repo group: stop giving explicit admin permission to owner on create
The repo owner will always get admin permissions when computing permissions, so
there is no need to assign these permissions explicitly.
Note: Permissions that has been added in the past are redundant but will be kept.
auth: always consider the repo group owner an admin when computing it's permissions
When computing repo group permissions in repository_group_permissions(), always
give admin permissions to the group owner.
That is similar to how repository_permissions() gives admin permissions to the
repo owner.
The extra computation shouldn't cause any extra database hits or make the
computation more complex or expensive, so that should be fine for stable.
Note: This will leave behind some (automaticly added) explicit permissions. I
consider this a very minor glitch, not worth addressing.
tests: skip reading Git system and global configuration in test_vcs_operations
The parent changeset reduced the dependency on global configuration and made it
possible to run tests without any global git configuration. But it is still
unfortunate to even look at the global configuration when running tests.
Global configuration is already disabled for Mercurial by setting HGRCPATH.
Now do something similar for Git. According to the git man page,
GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM set to /dev/null will make Git skip
reading the configuration files on all platforms.
Note that the GIT_CONFIG variables were introduced in Git 2.32.0, so this will
not work with all the Git versions supported by Kallithea.
tests: stabilize Git committer in test_vcs_operations
Git tries to find out name and email in this order:
1. The author can be set e.g. via the `--author` option of `git commit`.
2. If set, the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL are taken.
3. If set, various (global) config files are considered.
4. Unless disabled by the user.useconfigonly config, the names and emails are
inferred from various system sources such as various fields from /etc/passwd,
/etc/mailname and the environment variable EMAIL.
The author can be provided on the command line (1), but that is not possible
for the committer.
It is not an option to modify Git’s configuration files, so the result of (3)
depends on the system the tests run on, which should be avoided. A follow-up
patch will try to instruct Git to not read the system Git configuration files.
(4) is also system-dependent. On some systems, (4) is disabled in the Git
configuration. If enabled, Git will try to infer the committer name from the
gecko field in /etc/passwd, but will fail if it is empty. The previous code
passed the environment variable EMAIL to provide the corresponding email
address.
By passing the names and emails via (2), we can set the author and committer
name and email uniformly and prevent Git from using the system-dependent ways
(3) and (4). This will replace the use of of EMAIL. The environment variables
were introduced in 2005, so there should be no backwards compatibility
problems.
The tests will specify --author explicitly in the cases where the actual name
matters. We just need default values that can be used for committing when we
don't care.
We set it as static defaults to:
Author: test_regular <test_regular@example.com>
Commit: test_admin <test_admin@example.com>
Based on changes and research by Manuel Jacob <me@manueljacob.de>.
setup: avoid setuptools 67 - it can't handle celery's broken pytz dependency
With setuptools 67 or later, launching Kallithea fails as:
$ gearbox serve -c my.ini --reload
15:56:54,111 ERROR [gearbox] Expected closing RIGHT_PARENTHESIS
pytz (>dev)
~^
The `packaging` vendored in setuptools cannot handle the broken syntax
`Requires-Dist: pytz (>dev)` in
venv/lib/python3.11/site-packages/celery-5.0.5.dist-info/METADATA .
The old celery version currently used by Kallithea is wrong, and setuptools has
moved on after a reasonable grace period. We thus have to work around and avoid
latest setuptools.
See https://github.com/pypa/setuptools/issues/3889 .
i18n: make sure 'en' in Accept-Language is recognized as having 100% coverage
The workaround in 7c7d6b5c07c7 no longer works after upstream addressed the
main issue and released the changes in TurboGears 2.4.3 .
Setting `i18n.native = en` in the .ini works as a workaround.
The native language for translations is an implementation detail that users
shouldn't have to configure, so we define it as a default value without making
it explicit in the generated .ini template files.
Note that even though TG will figure out that languages like `en_US` should
fall back to using the `en` `kallithea.mo`, it doesn't consider `en_US` native
if `en` is in the native list but `en_US` isn't. We thus include the most
common aliases for `en` in the list.
api: fix get_changeset() when incomplete raw_id is passed with with_reviews
Previously, ChangesetStatusModel was queried with the raw_id passed as an
argument to the API function. When the raw_id was incomplete (i.e. shortened),
no reviews were found. Using the full raw_id from the changeset instance fixes
that.
Someone might argue that the caller is supposed to pass a full raw_id to the
API function. However, in any case, the return value should not be incomplete
without notice.
pullrequests: also limit to stop displaying merged changes
If the number of available changes are ok but merged changesets are not, then
just show the available changesets.