tests: fix vcs Hg helper functions get_user_name and get_user_email to actually use provided config_file
Running just test_get_user_name and test_get_user_email would fail when run as: py.test kallithea/tests/vcs/test_repository.py -k test_get_user
The config file was not used at all, and the tests would only pass when test_get_config_value had been run first and as an unfortunate side-effect had read the same file.
The icon of the comment bubble is slightly off-center vertically (too low). This problem can be solved by reducing the line height instead of using the default of 20px.
style: remove vertical scrollbar on hover of last line's comment bubble
When hovering the comment bubble of the last line of a diff, a vertical scrollbar appears. This behavior is not present on the stable branch.
Attempts to fix the problem by changing element sizes or padding did not solve the problem. As an alternative, this commit hides overflow - this makes no visual difference.
model/scm: fix incorrect reporting of pull from remote git repo
In issue #327 it was reported that the pull of a remote git repo causes the following inaccurate journal entry: "committed via Kallithea into repository"
The problem is caused by the following flow:
1. pull_changes calls _handle_push for git repos, passing action='push_remote'.
2. _handle_push calls _handle_rc_scm_extras, but does not pass 'action'
3. _handle_rc_scm_extras uses a default value of 'push_local' for action.
4. The action string 'push_local' will result in the mentioned journal entry, via action_map in action_parser() (kallithea/lib/helpers.py).
To get a more accurate log entry, _handle_push should pass the action that it got from pull_changes. In that case, the log entry will become "pulled from remote into repository"
Commit 39bdf0ab2862 has changed the Git hooks. When upgrading Kallithea to this commit, but not explicitly reinstalling the Git hooks, pushing to Git repos will fail.
Add a section to the documentation to explain that a reinstall of the hooks may be needed, and how to do it.
notification: don't repeat common actions for each email recipient
The emails sent upon PR creation or comments are identical for all recipients, except for the 'To:' header added by the send_email method. Calculation of subject, body, etc. can thus be moved outside of the loop.
Move the manipulation of the recipient list down to where it is used, for clarity.
it does not actually work. The '/repos' part is stripped off by the canonical_url method.
The 'host' entry in the arguments passed to routes.url does not strictly need to be a pure hostname. At least, the implementation does no validation of this fact, it is concatenated verbatim between the protocol and the rest of the URL.
As mapping Kallithea to a subpath of a base hostname is a valid implementation, the canonical_url feature should allow it.
setup: bump all upper pip dependency versions to minor updates of what currently is available and testable on pypi
Based on manual editing after: pip freeze | sed -n 's/==/ /gp' | while read p v; do sed -i -e "/\<$p[ \"]/s/\(\",\|$\)/, < $v\1/gi" setup.py dev_requirements.txt; done
These updates have been tested with automated tests and some amount of manual testing. Remaining problems will hopefully be caught by additional testing before the branch is declared stable.
The latest supported Celery version, 3.1.26.post2, is the latest in the whole 3 series. It works fine. But celery-4.0.0 doesn't work at all when testing. For now, just make it explicit that this is the limit.
`gearbox ishell` has an "optional" dependency on ipython as it fails with: Kallithea ishell requires the IPython Python package Before the previous change, after installing ipython < 4, it would however still fail the same way. With the previous change, it would fail in a slightly more helpful way with: ImportError: No module named traitlets.config.loader
With ipython < 4, after installing the missing traitlets (4.3.2) as hinted, ishell still failed with: TraitError: The 'config' trait of an InteractiveShellEmbed instance must be a Config or None, but a value of class 'traitlets.config.loader.Config' (i.e. {'InteractiveShellEmbed': {'confirm_exit': False}}) was specified.
With ipython >= 4, traitlets is installed as dependency, and ishell works. Tested with both ipython 4.0 and current latest version 5.8 .
Thus, just clarify that we only support ipython >= 4 .
auth: strip RFC4007 zone identifiers from IPv6 addresses before doing access control
If using IPv6, the request IP address might contain a '%' that the ipaddr module that is used for IP filtering can't handle.
https://tools.ietf.org/html/rfc4007#section-11 specifies how IPv6 addresses can have zone identifiers like trailing '%13' or '%eth0'. The zone identifier is used to help distinguish *if* the same address should be available on multiple interfaces. It *could* potentially have security implications in the odd case where the same address is different on different interfaces. The IP whitelist functionality does however not support zone filters, so there is no way users can expect the zone to be relevant for IP filtering. We can thus safely strip the zone index and only check for match on the other parts of the address.
Remove some unused imports, using 'autoflake' followed by manual redacting. find kallithea/lib/paster_commands/ -name "*.py" \ | xargs autoflake --remove-all-unused-imports -i
This same command could be applied gradually throughout the code base as areas are touched. Since autoflake may be too greedy in special cases, it is more difficult to do a big-bang action over all code.
remote: Traceback (most recent call last): remote: File "hooks/post-receive", line 36, in <module> remote: main() remote: File "hooks/post-receive", line 32, in main remote: sys.exit(kallithea.lib.hooks.handle_git_post_receive(repo_path, git_stdin_lines)) remote: File "kallithea/lib/hooks.py", line 453, in handle_git_post_receive remote: git_revs += scm_repo.run_git_command(cmd)[0].splitlines() remote: File "kallithea/lib/vcs/backends/git/repository.py", line 164, in run_git_command remote: return self._run_git_command(cmd, **opts) remote: File "kallithea/lib/vcs/backends/git/repository.py", line 151, in _run_git_command remote: raise RepositoryError(tb_err) remote: kallithea.lib.vcs.exceptions.RepositoryError: Couldn't run git command (['git', '-c', 'core.quotepath=false', 'log', 'b991c8d9ae7e66e165fc5eeb297c6843d21915e0', '--reverse', '--pretty=format:%H', '--not', '']). remote: Original error was:Subprocess exited due to an error: remote: fatal: ambiguous argument '': unknown revision or path not in the working tree. remote: To http://127.0.0.1:44433/new_git_DHAsQQ * [new branch] master -> master
hg: don't use custom diff arguments when generating diffstats for rss feed
With Mercurial 4.7, it is no longer possible to pass arguments like `git=True` to `ctx.diff()`.
This will change the reported data slightly, but the difference isn't important. Also, the code should be refactored to do something similar to what we do in other places.
522cfb2be9e1 introduced test_custom_hooks_preoutgoing, but thorough testing now reveals that the test failed with Mercurial 4.0 to 4.1.0 . Instead of investigating and fixing code or test, just accept this more than one year old version as minimum.
ishell: use traitlets.config and require ipython >= 4.0.0
Since version 4 was released in 2015, ishell has warned: IPython/config.py:13: ShimWarning: The `IPython.config` package has been deprecated. You should import from traitlets.config instead. "You should import from traitlets.config instead.", ShimWarning)
Goal is to reduce the gigantic 'setup' page in size, and make the information more understandable. Currently, the different topics do not really belong together. This is one small step towards that goal.
docs: split vcs_support into admin/vcs_setup and usage/vcs_notes
The existing page on VCS support was a mix of information needed to setup Kallithea with respect to version control systems, with information regarding using version control systems (or specific aspects of it) with Kallithea.
Move the first part to the Administrator Guide, and rebrand the second part as VCS Usage Notes.
In vcs_notes.rst, the general info is moved above the Mercurial-specific part, but otherwise left untouched.
db: drop constraint that started failing with MariaDB 10.2 / MySQL 5.7 (Issue #324)
The constraint was to prevent simple recursive parent references, but it only checked direct parents. We thus have to rely on the high level application maintaining the invariant anyway.
Reorganize the index page of the manual into three main sections: administrator guide, user guide, developer guide. In principle, administrators, users and developers are independent roles that can be fulfilled by different people.
'Administrators' install, configure and maintain Kallithea. They have 'admin' privilege in the web interface.
'Users' do not have access to the Kallithea installation files. They can only access the web interface, and generally do not have 'admin' privilege. They may be the owner of repositories, repository groups, or user groups, and as such modify the settings of these objects, even though they cannot modify the settings of Kallithea itself.
'Developers' modify the Kallithea source code. They may or may not contribute these changes back to the Kallithea community.
The 'Readme' section is a bit outside of this classification. As it serves as a basic introduction to Kallithea, it is kept first.
The 'Index' and 'Search' functionality are not really 'part of' the manual, so should not be under 'Other topics'. Instead they are put at the very top so they are readily visible.
This commit is only changing the index page. Subsequent commits can move and split some documentation files in the repository to mirror this structure. For example, the 'Version control systems support' page has information for administrators (ini settings and importing existing repositories) as well as for users (handling Mercurial subrepositories).
utils: move repo_name_slug to utils2 to prevent import cycle on setup_db
After commit 57a733313e4f, 'gearbox setup-db -c my.ini' fails with an import cycle as follows:
Traceback (most recent call last): File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/bin/gearbox", line 11, in <module> sys.exit(main()) File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/lib/python2.7/site-packages/gearbox/main.py", line 199, in main return gearbox.run(args) File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/lib/python2.7/site-packages/gearbox/main.py", line 145, in run return self._run_subcommand(remainder) File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/lib/python2.7/site-packages/gearbox/main.py", line 149, in _run_subcommand subcommand = self.command_manager.find_command(argv) File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/lib/python2.7/site-packages/gearbox/commandmanager.py", line 78, in find_command cmd_factory = cmd_ep.resolve() File "/home/tdescham/repo/contrib/kallithea/venv/kallithea-release/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2324, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) File "/home/tdescham/repo/contrib/kallithea/kallithea-release/kallithea/lib/paster_commands/setup_db.py", line 27, in <module> from kallithea.lib.db_manage import DbManage File "/home/tdescham/repo/contrib/kallithea/kallithea-release/kallithea/lib/db_manage.py", line 47, in <module> from kallithea.model.repo_group import RepoGroupModel File "/home/tdescham/repo/contrib/kallithea/kallithea-release/kallithea/model/repo_group.py", line 35, in <module> import kallithea.lib.utils File "/home/tdescham/repo/contrib/kallithea/kallithea-release/kallithea/lib/utils.py", line 48, in <module> from kallithea.model.repo_group import RepoGroupModel ImportError: cannot import name RepoGroupModel
i.e. kallithea.model.repo_group wants to import kallithea.lib.utils which in turn wants to import kallithea.model.repo_group.
In fact there exists kallithea.lib.utils and kallithea.lib.utils2. The current split is that 'utils2' contains 'simple' utilities, none of which depend on kallithea models, controllers, ... In contrast, 'utils' does rely on such kallithea classes.
As kallithea.model.repo_group was only include kallithea.lib.utils for its repo_name_slug method, which has no dependency on other kallithea classes, move that method (and its dependent recursive_replace) to kallithea.lib.utils2 instead. This fixes the import cycle.
pullrequests: don't show empty "additional changesets" (issue #280)
When opening a pullrequest on a revision range including the tipmost revision, and then pushing a new revision on top of that, the PR page shows: This pullrequest can be updated with changes on ...: and then nothing.
This is because the available revisions looped over are in 'avail_cs' but the guard around the loop is checking on 'avail_revs'. The former, while derived from avail_revs, can become empty under circumstances like this one.
Fix the problem by changing the guard checking avail_cs rather than avail_revs, and making sure the printed message is aligned to 'No additional changes found'.
repos: introduce low level slug check of repo and group names
The high level web forms already slug-ify repo and repo group names. It might thus not create the exact repo that was created, but the name will be "safe".
For API, we would rather have it fail than not doing exactly what was requested.
Thus, always verify at low level that the provided name wouldn't be modified by slugification. This makes sure the API provide allow the same actual names as the web UI.
This will only influence creation and renaming of repositories and repo groups. Existing repositories will continue working as before.
This is a slight API change, but it makes the system more stable and can prevent some security issues - especially XSS attacks.
repos: only allow api repo creation in existing groups
Fix problem with '../something' paths being allowed; '..' will always exist and can't be created.
This also introduce a small API change: Repository groups must now exist before repositories can be created. This makes the API more explicit and simpler.
repos: introduce low level slug check of repo and group names
The high level web forms already slug-ify repo and repo group names. It might thus not create the exact repo that was created, but the name will be "safe".
For API, we would rather have it fail than not doing exactly what was requested.
Thus, always verify at low level that the provided name wouldn't be modified by slugification. This makes sure the API provide allow the same actual names as the web UI.
This will only influence creation and renaming of repositories and repo groups. Existing repositories will continue working as before.
This is a slight API change, but it makes the system more stable and can prevent some security issues - especially XSS attacks.
repos: only allow api repo creation in existing groups
Fix problem with '../something' paths being allowed; '..' will always exist and can't be created.
This also introduce a small API change: Repository groups must now exist before repositories can be created. This makes the API more explicit and simpler.
Some hook names are quite long and are visually truncated in the admin section. Use the same principle as on the System Info: hide overflow and add ellipsis, use a title attribute to let users discover the full name on hover.
admin: system info: add title attribute for truncated items
On the System Info page, the item names may be truncated, e.g. "Kallithea configur...". In these cases, it is not possible for a user to retrieve the full name.
Add a title attribute that will show the full name on hover.