c8974135732aa0ceb841cee6df66e29f089b4963 rhodecode-0.0.1.1.8

c252049af24cd98eef5f4143fa3abbff3c912e29 rhodecode-0.0.1.2.0

0b8fba8ab90b01f811a50e6e7384989cced21d38 rhodecode-0.0.1.2.1

22273bec00ba2fd860c60a9277d3d7229e288e18 rhodecode-0.0.1.2.2

1ff606a7858dbd8a5f70b3da5cc89524bd0d84f9 rhodecode-0.0.1.2.3

a7a282a902b207ce34e830d643c79b7ab52e3b35 rhodecode-0.0.1.2.4

b6b611e7722e754abebaae6e265cbb4c823d344d rhodecode-0.0.1.2.5

dbc82e3362a25d2aece42060089824c4342efd17 rhodecode-0.0.1.3.0

79a95f338fd0115b2cdb77118f39e17d22ff505c rhodecode-0.0.1.3.1

9ab21c5ddb84935bea5c743b4e147ed5a398b30c rhodecode-0.0.1.3.2

934906f028b582a254e0028ba25e5d20dd32b9cd rhodecode-0.0.1.3.3

af21362474e3ab5aa0e2fbb1c872356f2c16c4f3 rhodecode-0.0.1.3.4

0e2792e04bd316fe64335cbe6a476031ac60b29b rhodecode-0.0.1.3.5

edfff9f37916389144d3a3644d0a7d7adfd79b11 rhodecode-0.0.1.3.6

9ae95fdeca184f2404205645f06c6597b74ef2db rhodecode-0.0.1.4.0

909143a4dde53c46d4f24abb426ec870471c7de1 rhodecode-0.0.1.4.1

d998cc84cf726798486a438763053f0e1dc1b646 rhodecode-0.0.1.4.2

3f5d40b9dd99ccb009ea2211ee2d4b594c634946 rhodecode-0.0.1.4.3

3148c08cf86f1849917e2d50f7ab7766c1550b0a rhodecode-0.0.1.4.4

a5f0bc867edc88be23eb808693e5393a97d4c54a rhodecode-0.0.1.5.0

3259dc7caea48687eab018ee646ae6ad7e7ef377 rhodecode-0.0.1.5.1

efe23d6c178c11d575a0214181276a3452776e48 rhodecode-0.0.1.5.2

1a498b11f1540f5b94b6f6009298f5dc3eaad9e9 rhodecode-0.0.1.5.3

3447862ad8c9ceba85857774c526e39fde3a2281 rhodecode-0.0.1.5.4

c15d7b336af58df9f1bbc8f8957464e7ea618d4c rhodecode-0.0.1.6.0rc1

78b53ee0d247f90d51b028307ff5717851b6c265 rhodecode-0.0.1.6.0

351ad34d56321349ff5bd38f537bd768b8efef2e rhodecode-0.0.1.7.0

1f71ef689d2a3c9978cea6591a1f4e9107a5ca83 rhodecode-0.0.1.7.1

cc48c1541c7e2e84114bf92a0f9cd4b8b1341545 0.0

d17e88a1a88a29f6fac948c94498129e405a40d3 0.1

ad0ce803b40cb17fc3988373052943e041030b02 0.2

c6e32714336345403adf76abb6ebf9b8116fcdc7 0.2.1

14f488a5dc4ca6647bc6acf12534fd137e968aa8 0.2.2

9b3e9e242f5c97cc0c7657e5ac93dce7de61ca16 0.3

9bf8eb837e785b6856ccfac264e977ce3ebe1535 0.3.1

a84d40e9481fcea4dafadee86b03f0dd401527d6 0.3.2

64ea7ea0923618a0c117acebb816a6f0d162bfdb 0.3.3

cf635c823ea059cc3a1581b82d8672e46b682384 0.3.4

4cca4cc6a0a97f4c4763317184cd41aca4297630 0.3.5

082c9b8f0f17bd34740eb90c69bdc4c80d4b5b31 0.3.6

a18445b85d407294da0b7f1d8be3bedef5ffdea6 0.3.7

8db761c407685e7b08b800c947890035b0d67025 0.4.0rc1

60f726162fd6c515bd819feb423be73cad01d7d3 0.4.0rc2

19086c5de05f4984d7a90cd31624c45dd893f6bb 0.4.0

da65398a62fff50f3d241796cbf17acdea2092ef 0.4.1

bfa0b0a814644f0af3f492d17a9ed169cc3b89fe 0.5.0

d01a8e92936dbd62c76505432f60efba432e9397 0.5.1

aa0a637fa6f635a5e024fa56b19ed2a2dacca857 0.5.2

List of contributors to Kallithea project:

    Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> 2014-2020

    Mads Kiilerich <mads@kiilerich.com> 2016-2020

    Dennis Fink <dennis.fink@c3l.lu> 2020

    Andrej Shadura <andrew@shadura.me> 2012 2014-2017 2019

    Étienne Gilli <etienne.gilli@gmail.com> 2015-2017 2019

    Allan Nordhøy <epost@anotheragency.no> 2017-2019

    ssantos <ssantos@web.de> 2018-2019

    Adi Kriegisch <adi@cg.tuwien.ac.at> 2019

    Danni Randeris <danniranderis@gmail.com> 2019

    Edmund Wong <ewong@crazy-cat.org> 2019

    Elizabeth Sherrock <lizzyd710@gmail.com> 2019

    Hüseyin Tunç <huseyin.tunc@bulutfon.com> 2019

    leela <53352@protonmail.com> 2019

    Manuel Jacob <me@manueljacob.de> 2019

    Mateusz Mendel <mendelm9@gmail.com> 2019

    Nathan <bonnemainsnathan@gmail.com> 2019

    Oleksandr Shtalinberg <o.shtalinberg@gmail.com> 2019

    THANOS SIOURDAKIS <siourdakisthanos@gmail.com> 2019

    Wolfgang Scherer <wolfgang.scherer@gmx.de> 2019

    Христо Станев <hstanev@gmail.com> 2019

    Dominik Ruf <dominikruf@gmail.com> 2012 2014-2018

    Michal Čihař <michal@cihar.com> 2014-2015 2018

    Branko Majic <branko@majic.rs> 2015 2018

    Chris Rule <crule@aegistg.com> 2018

    Jesús Sánchez <jsanchezfdz95@gmail.com> 2018

    Patrick Vane <patrick_vane@lowentry.com> 2018

    Pheng Heong Tan <phtan90@gmail.com> 2018

    Максим Якимчук <xpinovo@gmail.com> 2018

    Марс Ямбар <mjambarmeta@gmail.com> 2018

    Mads Kiilerich <madski@unity3d.com> 2012-2017

    Unity Technologies 2012-2017

    Søren Løvborg <sorenl@unity3d.com> 2015-2017

    Sam Jaques <sam.jaques@me.com> 2015 2017

    Alessandro Molina <alessandro.molina@axant.it> 2017

    Anton Schur <tonich.sh@gmail.com> 2017

    Ching-Chen Mao <mao@lins.fju.edu.tw> 2017

    Eivind Tagseth <eivindt@gmail.com> 2017

    FUJIWARA Katsunori <foozy@lares.dti.ne.jp> 2017

    Holger Schramm <info@schramm.by> 2017

    Karl Goetz <karl@kgoetz.id.au> 2017

    Lars Kruse <devel@sumpfralle.de> 2017

    Marko Semet <markosemet@googlemail.com> 2017

    Viktar Vauchkevich <victorenator@gmail.com> 2017

    Takumi IINO <trot.thunder@gmail.com> 2012-2016

    Jan Heylen <heyleke@gmail.com> 2015-2016

    Robert Martinez <ntttq@inboxen.org> 2015-2016

    Robert Rauch <mail@robertrauch.de> 2015-2016

    Angel Ezquerra <angel.ezquerra@gmail.com> 2016

    Anton Shestakov <av6@dwimlabs.net> 2016

    Brandon Jones <bjones14@gmail.com> 2016

    Kateryna Musina <kateryna@unity3d.com> 2016

    Konstantin Veretennicov <kveretennicov@gmail.com> 2016

    Oscar Curero <oscar@naiandei.net> 2016

    Robert James Dennington <tinytimrob@googlemail.com> 2016

    timeless@gmail.com 2016

    YFdyh000 <yfdyh000@gmail.com> 2016

    Aras Pranckevičius <aras@unity3d.com> 2012-2013 2015

    Sean Farley <sean.michael.farley@gmail.com> 2013-2015

    Bradley M. Kuhn <bkuhn@sfconservancy.org> 2014-2015

    Christian Oyarzun <oyarzun@gmail.com> 2014-2015

    Joseph Rivera <rivera.d.joseph@gmail.com> 2014-2015

    Anatoly Bubenkov <bubenkoff@gmail.com> 2015

    Andrew Bartlett <abartlet@catalyst.net.nz> 2015

    Balázs Úr <urbalazs@gmail.com> 2015

    Ben Finney <ben@benfinney.id.au> 2015

    Daniel Hobley <danielh@unity3d.com> 2015

    David Avigni <david.avigni@ankapi.com> 2015

    Denis Blanchette <dblanchette@coveo.com> 2015

    duanhongyi <duanhongyi@doopai.com> 2015

    EriCSN Chang <ericsning@gmail.com> 2015

    Grzegorz Krason <grzegorz.krason@gmail.com> 2015

    Jiří Suchan <yed@vanyli.net> 2015

    Kazunari Kobayashi <kobanari@nifty.com> 2015

    Kevin Bullock <kbullock@ringworld.org> 2015

    kobanari <kobanari@nifty.com> 2015

    Marc Abramowitz <marc@marc-abramowitz.com> 2015

    Marc Villetard <marc.villetard@gmail.com> 2015

    Matthias Zilk <matthias.zilk@gmail.com> 2015

    Michael Pohl <michael@mipapo.de> 2015

    Michael V. DePalatis <mike@depalatis.net> 2015

    Morten Skaaning <mortens@unity3d.com> 2015

include           .coveragerc

include           Apache-License-2.0.txt

include           CONTRIBUTORS

include           COPYING

include           Jenkinsfile

include           LICENSE-MERGELY.html

include           LICENSE.md

include           MIT-Permissive-License.txt

include           README.rst

include           conftest.py

include           dev_requirements.txt

include           development.ini

include           pytest.ini

include           requirements.txt

include           tox.ini

recursive-include docs *

recursive-include init.d *

recursive-include kallithea/alembic *

include           kallithea/bin/ldap_sync.conf

include           kallithea/lib/paster_commands/template.ini.mako

recursive-include kallithea/front-end *

recursive-include kallithea/i18n *

recursive-include kallithea/public *

recursive-include kallithea/templates *

recursive-include kallithea/tests/fixtures *

recursive-include kallithea/tests/scripts *

include           kallithea/tests/models/test_dump_html_mails.ref.html

include           kallithea/tests/performance/test_vcs.py

include           kallithea/tests/vcs/aconfig

recursive-include scripts *

.. _English title case: https://en.wikipedia.org/wiki/Capitalization#Title_case

Template helpers (that is, everything in ``kallithea.lib.helpers``)

should only be referenced from templates. If you need to call a

helper from the Python code, consider moving the function somewhere

else (e.g. to the model).

Notes on the SQLAlchemy session

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Each HTTP request runs inside an independent SQLAlchemy session (as well

as in an independent database transaction). ``Session`` is the session manager

and factory. ``Session()`` will create a new session on-demand or return the

current session for the active thread. Many database operations are methods on

such session instances. The session will generally be removed by

TurboGears automatically.

Database model objects

(almost) always belong to a particular SQLAlchemy session, which means

that SQLAlchemy will ensure that they're kept in sync with the database

(but also means that they cannot be shared across requests).

Objects can be added to the session using ``Session().add``, but this is

rarely needed:

* When creating a database object by calling the constructor directly,

  it must explicitly be added to the session.

* When creating an object using a factory function (like

  ``create_repo``), the returned object has already (by convention)

  been added to the session, and should not be added again.

* When getting an object from the session (via ``Session().query`` or

  any of the utility functions that look up objects in the database),

  it's already part of the session, and should not be added again.

  SQLAlchemy monitors attribute modifications automatically for all

  objects it knows about and syncs them to the database.

SQLAlchemy also flushes changes to the database automatically; manually

calling ``Session().flush`` is usually only necessary when the Python

code needs the database to assign an "auto-increment" primary key ID to

a freshly created model object (before flushing, the ID attribute will

be ``None``).

Debugging

^^^^^^^^^

``DEBUG`` or ``INFO`` level, especially ``[logger_kallithea]``, but perhaps

also other loggers. It is often easier to add additional ``log`` or ``print``

statements than to use a Python debugger.

Sometimes it is simpler to disable ``errorpage.enabled`` and perhaps also

``trace_errors.enable`` to expose raw errors instead of adding extra

processing. Enabling ``debug`` can be helpful for showing and exploring

tracebacks in the browser, but is also insecure and will add extra processing.

TurboGears2 DebugBar

^^^^^^^^^^^^^^^^^^^^

It is possible to enable the TurboGears2-provided DebugBar_, a toolbar overlayed

over the Kallithea web interface, allowing you to see:

* timing information of the current request, including profiling information

* request data, including GET data, POST data, cookies, headers and environment

  variables

* a list of executed database queries, including timing and result values

DebugBar is only activated when ``debug = true`` is set in the configuration

file. This is important, because the DebugBar toolbar will be visible for all

users, and allow them to see information they should not be allowed to see. Like

is anyway the case for ``debug = true``, do not use this in production!

To enable DebugBar, install ``tgext.debugbar`` and ``kajiki`` (typically via

``pip``) and restart Kallithea (in debug mode).

"Roadmap"

---------

We do not have a road map but are waiting for your contributions. Refer to the

wiki_ for some ideas of places we might want to go -- contributions in these

areas are very welcome.

Thank you for your contribution!

--------------------------------

.. _Weblate: http://weblate.org/

.. _issue tracking: https://bitbucket.org/conservancy/kallithea/issues?status=new&status=open

.. _pull requests: https://bitbucket.org/conservancy/kallithea/pull-requests

.. _bitbucket: http://bitbucket.org/

.. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

.. _kallithea-general: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

.. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/

============

Translations

============

Translations are available on Hosted Weblate at the following URL:

    https://hosted.weblate.org/projects/kallithea/kallithea/

Registered users may contribute to the existing languages, or request a new

language translation.

Translating using Weblate

-------------------------

Weblate_ offers a simple and easy to use interface featuring glossary, machine

translation, suggestions based on similar translations in other projects,

automatic checks etc. Weblate imports the source code tree directly from

the version control system, and commits edits back from time to time.

When registering at Weblate, make sure you use the name and email address you

prefer to be used when your changes are committed. We can and probably will

amend changesets coming from Weblate, but having things right from the beginning

makes things easier.

Weblate performs sanity checks all the time and tries to prevent you from ignoring

them. Most common mistakes are inconsistent punctuation, whitespace, missing or extra

format parameters, untranslated strings copied into the translation. Please perform

necessary corrections when they're needed, or override the false positives.

Merging translations from Weblate (admin-only)

----------------------------------------------

Weblate rebases its changes every time it pulls from our repository. Pulls are triggered

by a web hook from Our Own Kallithea every time it receives new commits. Usually merging

the new translations is a straightforward process consisting of a pull from the Weblate-hosted

repository which is available under the Data Exports tab in the Weblate interface.

Weblate tries to minimise the number of commits, but that doesn't always work, especially

when two translators work with different languages at more or less the same time.

It makes sense sometimes to re-order or fold commits by the same author when they touch

just the same language translation. That, however, may confuse Weblate sometimes, in

which case it should be manually convinced it has to discard the commits it created by

using its administrative interface.

Regenerating translations after source code changes (admin-only)

In the prepared development environment, run the following to ensure

all translation strings are extracted and up-to-date::

    python3 setup.py extract_messages

Create new language by executing following command::

    python3 setup.py init_catalog -l <new_language_code>

This creates a new translation under directory `kallithea/i18n/<new_language_code>`

based on the translation template file, `kallithea/i18n/kallithea.pot`.

Edit the new PO file located in `LC_MESSAGES` directory with poedit or your

favorite PO files editor. After you finished with the translations, check the

translation file for errors by executing::

    msgfmt -f -c kallithea/i18n/<new_language_code>/LC_MESSAGES/<updated_file.po>

Finally, compile the translations::

    python3 setup.py compile_catalog -l <new_language_code>

Manually updating translations

------------------------------

Extract the latest versions of strings for translation by running::

    python3 setup.py extract_messages

Update the PO file by doing::

    python3 setup.py update_catalog -l <new_language_code>

Edit the newly updated translation file. Repeat all steps after the

`init_catalog` step from the 'new translation' instructions above.

Testing translations

--------------------

Edit `kallithea/tests/conftest.py` and set `i18n.lang` to `<new_language_code>`

and run Kallithea tests by executing::

    py.test

.. _Weblate: http://weblate.org/

   installation

   installation_win

   installation_win_old

   installation_iis

   installation_puppet

   upgrade

**Setup and configuration**

.. toctree::

   :maxdepth: 1

   setup

   administrator_guide/auth

   administrator_guide/vcs_setup

   usage/email

   usage/customization

**Maintenance**

.. toctree::

   :maxdepth: 1

   usage/backup

   usage/performance

   usage/debugging

   usage/troubleshooting

User guide

**********

.. toctree::

   :maxdepth: 1

   usage/general

   usage/vcs_notes

   usage/statistics

   api/api

Developer guide

***************

.. toctree::

   :maxdepth: 1

   contributing

   dev/dbmigrations

.. _python: http://www.python.org/

.. _django: http://www.djangoproject.com/

.. _mercurial: https://www.mercurial-scm.org/

.. _bitbucket: http://bitbucket.org/

.. _subversion: http://subversion.tigris.org/

.. _git: http://git-scm.com/

.. _celery: http://celeryproject.org/

.. _Sphinx: http://sphinx.pocoo.org/

.. _vcs: http://pypi.python.org/pypi/vcs

- users and admins can manage SSH public keys in the web UI

- in their SSH client configuration, users can configure how the client should

  control access to their SSH key - without passphrase, with passphrase, and

  optionally with passphrase caching in the local shell session (``ssh-agent``).

  This is standard SSH functionality, not something Kallithea provides or

  interferes with.

- network communication between client and server happens in a bidirectional

  stateful stream, and will in some cases be faster than HTTP/HTTPS with several

  stateless round-trips.

.. note:: At this moment, repository access via SSH has been tested on Unix

    only. Windows users that care about SSH are invited to test it and report

    problems, ideally contributing patches that solve these problems.

Users and admins can upload SSH public keys (e.g. ``.ssh/id_rsa.pub``) through

the web interface. The server's ``.ssh/authorized_keys`` file is automatically

maintained with an entry for each SSH key. Each entry will tell ``sshd`` to run

``kallithea-cli`` with the ``ssh-serve`` sub-command and the right Kallithea user ID

when encountering the corresponding SSH key.

To enable SSH repository access, Kallithea must be configured with the path to

the ``.ssh/authorized_keys`` file for the Kallithea user, and the path to the

``kallithea-cli`` command. Put something like this in the ``.ini`` file::

    ssh_enabled = true

    ssh_authorized_keys = /home/kallithea/.ssh/authorized_keys

    kallithea_cli_path = /srv/kallithea/venv/bin/kallithea-cli

The SSH service must be running, and the Kallithea user account must be active

(not necessarily with password access, but public key access must be enabled),

all file permissions must be set as sshd wants it, and ``authorized_keys`` must

be writeable by the Kallithea user.

.. note:: The ``authorized_keys`` file will be rewritten from scratch on

    each update. If it already exists with other data, Kallithea will not

    overwrite the existing ``authorized_keys``, and the server process will

    instead throw an exception. The system administrator thus cannot ssh

    directly to the Kallithea user but must use su/sudo from another account.

    If ``/home/kallithea/.ssh/`` (the directory of the path specified in the

    ``ssh_authorized_keys`` setting of the ``.ini`` file) does not exist as a

    directory, Kallithea will attempt to create it. If that path exists but is

    *not* a directory, or is not readable-writable-executable by the server

    process, the server process will raise an exception each time it attempts to

    write the ``authorized_keys`` file.

.. warning:: The handling of SSH access is steered directly by the command

    specified in the ``authorized_keys`` file. There is no interaction with the

    web UI.  Once SSH access is correctly configured and enabled, it will work

    regardless of whether the Kallithea web process is actually running. Hence,

    if you want to perform repository or server maintenance and want to fully

    disable all access to the repositories, disable SSH access by setting

    ``ssh_enabled = false`` in the correct ``.ini`` file (i.e. the ``.ini`` file

    specified in the ``authorized_keys`` file.)

The ``authorized_keys`` file can be updated manually with ``kallithea-cli

ssh-update-authorized-keys -c my.ini``. This command is not needed in normal

operation but is for example useful after changing SSH-related settings in the

``.ini`` file or renaming that file. (The path to the ``.ini`` file is used in

the generated ``authorized_keys`` file).

Setting up Whoosh full text search

----------------------------------

Kallithea provides full text search of repositories using `Whoosh`__.

.. __: https://whoosh.readthedocs.io/en/latest/

For an incremental index build, run::

    kallithea-cli index-create -c my.ini

For a full index rebuild, run::

    kallithea-cli index-create -c my.ini --full

The ``--repo-location`` option allows the location of the repositories to be overridden;

usually, the location is retrieved from the Kallithea database.

The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::

    kallithea-cli index-create -c my.ini --index-only=vcs,kallithea

To keep your index up-to-date it is necessary to do periodic index builds;

for this, it is recommended to use a crontab entry. Example::

    0  3  *  *  *  /path/to/virtualenv/bin/kallithea-cli index-create -c /path/to/kallithea/my.ini

When using incremental mode (the default), Whoosh will check the last

modification date of each file and add it to be reindexed if a newer file is

available. The indexing daemon checks for any removed files and removes them

from index.

# -*- coding: utf-8 -*-

# This program is free software: you can redistribute it and/or modify

# it under the terms of the GNU General Public License as published by

# the Free Software Foundation, either version 3 of the License, or

# (at your option) any later version.

#

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

# GNU General Public License for more details.

#

# You should have received a copy of the GNU General Public License

# along with this program.  If not, see <http://www.gnu.org/licenses/>.

"""

kallithea

~~~~~~~~~

Kallithea, a web based repository management system.

Versioning implementation: http://www.python.org/dev/peps/pep-0386/

This file was forked by the Kallithea project in July 2014.

Original author and date, and relevant copyright and licensing information is below:

:created_on: Apr 9, 2010

:author: marcink

:copyright: (c) 2013 RhodeCode GmbH, (C) 2014 Bradley M. Kuhn, and others.

:license: GPLv3, see LICENSE.md for more details.

"""

import platform

import sys

if sys.version_info < (3, 6):

    raise Exception('Kallithea requires python 3.6 or later')

BACKENDS = {

    'hg': 'Mercurial repository',

    'git': 'Git repository',

}

CELERY_APP = None  # set to Celery app instance if using Celery

CELERY_EAGER = False

CONFIG = {}

# Linked module for extensions

EXTENSIONS = {}

__version__ = '.'.join(str(each) for each in VERSION)

__platform__ = platform.system()

__license__ = 'GPLv3'

__py_version__ = sys.version_info

__author__ = "Various Authors"

__url__ = 'https://kallithea-scm.org/'

is_windows = __platform__ in ['Windows']

is_unix = not is_windows

# -*- coding: utf-8 -*-

# This program is free software: you can redistribute it and/or modify

# it under the terms of the GNU General Public License as published by

# the Free Software Foundation, either version 3 of the License, or

# (at your option) any later version.

#

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

# GNU General Public License for more details.

#

# You should have received a copy of the GNU General Public License

# along with this program.  If not, see <http://www.gnu.org/licenses/>.

"""

kallithea.controllers.error

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kallithea error controller

This file was forked by the Kallithea project in July 2014.

Original author and date, and relevant copyright and licensing information is below:

:created_on: Dec 8, 2010

:author: marcink

:copyright: (c) 2013 RhodeCode GmbH, and others.

:license: GPLv3, see LICENSE.md for more details.

"""

import html

import logging

from tg import config, expose, request

from tg import tmpl_context as c

from tg.i18n import ugettext as _

from kallithea.lib.base import BaseController

log = logging.getLogger(__name__)

class ErrorController(BaseController):

    """Generates error documents as and when they are required.

    related status codes are returned from the application.

    """

    def _before(self, *args, **kwargs):

        # disable all base actions since we don't need them here

        pass

    @expose('/errors/error_document.html')

    def document(self, *args, **kwargs):

        resp = request.environ.get('tg.original_response')

        c.site_name = config.get('title')

        log.debug('### %s ###', resp and resp.status or 'no response')

        e = request.environ

        c.serv_p = r'%(protocol)s://%(host)s/' % {

            'protocol': e.get('wsgi.url_scheme'),

            'host': e.get('HTTP_HOST'), }

        if resp:

            c.error_message = html.escape(request.GET.get('code', str(resp.status)))

            c.error_explanation = self.get_error_explanation(resp.status_int)

        else:

            c.error_message = _('No response')

            c.error_explanation = _('Unknown error')

        return dict()

    def get_error_explanation(self, code):

        """ get the error explanations of int codes

            [400, 401, 403, 404, 500]"""

        try:

            code = int(code)