controllers: changeset: always allow status changes
Don't disallow status changes on changesets that are part of a pull request and on which the last status change happened via the pull request.
This odd restriction was already previously highlighted by Mads Kiilerich as 'RLY?' in commit 7834f845505aec3086f525600c81209a40b495ef, so it seems fair to remove it.
When dont_allow_on_closed_pull_request no longer is set, StatusChangeOnClosedPullRequestError will no longer be raised.
Rename the oddly named method '_get_is_allowed_change_status' to '_is_allowed_to_change_status'. Not only does this read more easily, but also it is more in line with the variable to which the result is assigned to 'allowed_to_change_status'.
controllers: forward pullrequests.delete_comment to changeset
Remove duplication between pullrequests and changeset. We move the code outside ChangesetController to make it callable from PullrequestsController.
Note: - instead of keeping the method pullrequests.delete_comment itself and letting it forward to changeset.delete_comment, an alternative solution would have been to change the routing table directly. However, the chosen solution makes it more explicit which operations are supported on each controller.
tests: small improvements to test_changeset_comments
- response checking is incorrectly placed under 'Test DB' comment - no response check on the comment text was done - related: use different text for the comments in different tests - commit_id should be comment_id - remove duplicate checking of comment count in DB
cli: convert 'gearbox celeryd' into 'kallithea-cli celery-run'
Note: - '--' is never explicitly present in the arguments when using Click. The click parser will take care of '--' as separator between dash-dash-arguments and positional arguments, following standard UNIX conventions.
cli: initial introduction of 'kallithea-cli' command
This commit adds a command 'kallithea-cli' that intends to replace the existing set of 'gearbox' commands that relate to setting up kallithea. Gearbox would still be used for 'gearbox serve', but other commands like 'make-config', 'setup-db', etc. would be converted to 'kallithea-cli' commands.
The python package 'Click' is used to generate the CLI. Using decorators, this package makes it very easy to generate a CLI out of simple methods. See: http://click.pocoo.org/7/
Using Gearbox for custom commands is possible, but documentation on this topic is limited. As the added value of Gearbox for that use case is not clear, we can well switch to something else if it seems better/easier.
graph: don't try to get obsolete status for fake parent revisions
Fake parents use negative revision numbers as internal placeholders. Previous Mercurial versions could handle negative non-existing revision numbers, but Mercurial 4.8 will fail on this invalid input when getting the obsolete status. Instead, make sure we only get obsolete status for actual revisions.
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).