tests: introduce test_context to handle internationalization
As preparation to the migration to Turbogears2, introduce a test_context context manager to wrap certain tests. The context manager provides a translator for tests that need it. This translator was previously provided globally to all tests via the TestController.
When swapping Pylons with Turbogears2, the new file kallithea/tests/test_context.py can be removed, and the test_context from tg2/tg/util/webtest.py should be used.
conftest.py does not contain an import of pylons (only of pylons.test) so usage of e.g. pylons.config can never work, so it cannot be used. Since the tests run fine regardless, we can get rid of this code.
These references are either not used, or do not provide value. The Windows installation and email pages still references documents from the Pylons website -- alternative pages from Turbogears2 need to be found.
The img and style methods in the error controller are standard Pylons boilerplate. They are used from the Pylons default error document template. The purpose of these methods is to serve images and stylesheets from the Pylons module, rather than having to copy these files into a particular application installation.
Since Kallithea uses a custom error template with our own styles and images, these methods are not actually used.
pullrequests: fix 'upgrade' from revision to branch when creating PR
This will do that the default title for the PR created from a non-head revision will contain a short hash instead a long.
org_ref_type was set to 'branch' while org_ref_name remained the full hash. h.short_ref would thus not truncate. Instead, we keep the org_ref_type as 'rev' while storing the branch name in the database.
auth: prevent LDAP query language injection of usernames
This could cause odd LDAP queries that could fail but couldn't give access without a valid user query and credentials. It thus had no security implications.
A location was hardcoded. The location was wrong for many systems and prevented actual TLS from working. Also, it should not be necessary with modern Pythons.
For some reason, instead of removing it, we now decide to expose it to the user. Choice FTW!
These parameterized tests were supposed to (among other things) test what happens when the "api_key" query string parameter is not present. Instead, they literally tested "api_key=None".
The database lookups of the user and repositories are moved outside, into the callers, which have already looked up the relevant objects, thus saving two database lookups when creating a PR.
db: rename UserFollowing.follows_repo_id to follows_repository_id
Since the relationship is 'follows_repository', rename the column to be 'follows_repository_id', not 'follows_repo_id'. This also makes the Python column name match the actual database column name.
(The inconsistency dates back to early RhodeCode days.)
Many calls to Session().flush() were completely superfluous and have been removed. (See also the note on "flush" in the contributor docs.) For the remaining calls, a comment has been added to explain why it's necessary.
style: put all datatable widgets on one line above the table
This makes tables look less messy - especially on the repogroups page where there are 2 datatables.
We put all the info above the template so it is visible and stays in the same place, no matter how many entries are shown or if filtering change the number.
TODO: We should probably get a wrapper around datatable instead of repeating this so many times ...
templates: fix dropdown functionality of current menu item
After 3e46e6b6a27a, the 'current' menu would have two class attributes and it would not work as a dropdown. For example, it was not possible to navigate from Admin>Users to Admin>User Groups.
Instead, get rid of the is_current "helper" and just handle classes explicitly. That might be slightly more verbose but is also more explicit ... and it works.
template: remove obsolete filter textbox and user_group_count
I used grep to find any reference to user_group_count but found none. So there seems to be no code that actually sets this count. So I removed it. And since the table is a datatable the filter is redundant anyway.
To simplify email filtering, add a header indicating the type of email being sent. The 'type_' value corresponds to one of the types defined in class Notification in kallithea/model/db.py, e.g. 'cs_comment', 'pull_request', 'pull_request_comment', ...
lib: move get_custom_lexer from utils to pygmentsutils
get_custom_lexer is the only dependency from helpers to utils. In attempting to get a clearer dependency tree, we can move out get_custom_lexer to a different place so that helpers does not depend on utils.
It so happens that there already is a pygmentsutils.py file in lib, which is a very good fit, since the lexers used in Kallithea are effectively provided by pygments.
To avoid circular imports, we need to determine some 'rules'. Helpers have minimal dependencies to model. Most of the model imports that are currently global are only used in a few methods. Therefore, it makes sense to make these imports local to the method, so they won't 'count' for circular imports at module level.