release: Merge default into stable for release preparation

docs/auth/auth-saml-duosecurity.rst

@@ -0,0 +1,105 b''
+.. _config-saml-duosecurity-ref:
+
+
+SAML 2.0 with Duo Security
+--------------------------
+
+**This plugin is available only in EE Edition.**
+
+|RCE| supports SAML 2.0 Authentication with Duo Security provider. This allows
+users to log-in to RhodeCode via SSO mechanism of external identity provider
+such as Duo. The login can be triggered either by the external IDP, or internally
+by clicking specific authentication button on the log-in page.
+
+
+Configuration steps
+^^^^^^^^^^^^^^^^^^^
+
+To configure Duo Security SAML authentication, use the following steps:
+
+1. From the |RCE| interface, select
+   :menuselection:`Admin --> Authentication`
+2. Activate the `Duo Security` plugin and select :guilabel:`Save`
+3. Go to newly available menu option called `Duo Security` on the left side.
+4. Check the `enabled` check box in the plugin configuration section,
+   and fill in the required SAML information and :guilabel:`Save`, for more details,
+   see :ref:`config-saml-duosecurity`
+
+
+.. _config-saml-duosecurity:
+
+
+Example SAML Duo Security configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Example configuration for SAML 2.0 with Duo Security provider::
+
+    *option*: `enabled` => `True`
+    # Enable or disable this authentication plugin.
+
+    *option*: `cache_ttl` => `0`
+    # Amount of seconds to cache the authentication and permissions check response call for this plugin.
+    # Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
+
+    *option*: `debug` => `True`
+    # Enable or disable debug mode that shows SAML errors in the RhodeCode logs.
+
+    *option*: `entity_id` => `http://rc-app.com/dag/saml2/idp/metadata.php`
+    # Identity Provider entity/metadata URI.
+    # E.g. https://duo-gateway.com/dag/saml2/idp/metadata.php
+
+    *option*: `sso_service_url` => `http://rc-app.com/dag/saml2/idp/SSOService.php?spentityid=http://rc.local.pl/_admin/auth/duosecurity/saml-metadata`
+    # SSO (SingleSignOn) endpoint URL of the IdP. This can be used to initialize login
+    # E.g. https://duo-gateway.com/dag/saml2/idp/SSOService.php?spentityid=<metadata_entity_id>
+
+    *option*: `slo_service_url` => `http://rc-app.com/dag/saml2/idp/SingleLogoutService.php?ReturnTo=http://rc-app.com/dag/module.php/duosecurity/logout.php`
+    # SLO (SingleLogout) endpoint URL of the IdP.
+    # E.g. https://duo-gateway.com/dag/saml2/idp/SingleLogoutService.php?ReturnTo=http://duo-gateway.com/_admin/saml/sign-out-endpoint
+
+    *option*: `x509cert` => `<CERTIFICATE_STRING>`
+    # Identity provider public x509 certificate. It will be converted to single-line format without headers
+
+    *option*: `name_id_format` => `sha-1`
+    # The format that specifies how the NameID is sent to the service provider.
+
+    *option*: `signature_algo` => `sha-256`
+    # Type of Algorithm to use for verification of SAML signature on Identity provider side
+
+    *option*: `digest_algo` => `sha-256`
+    # Type of Algorithm to use for verification of SAML digest on Identity provider side
+
+    *option*: `cert_dir` => `/etc/saml/`
+    # Optional directory to store service provider certificate and private keys.
+    # Expected certs for the SP should be stored in this folder as:
+    #  * sp.key     Private Key
+    #  * sp.crt     Public cert
+    #  * sp_new.crt Future Public cert
+    #
+    # Also you can use other cert to sign the metadata of the SP using the:
+    #  * metadata.key
+    #  * metadata.crt
+
+    *option*: `user_id_attribute` => `PersonImmutableID`
+    # User ID Attribute name. This defines which attribute in SAML response will be used to link accounts via unique id.
+    # Ensure this is returned from DuoSecurity for example via duo_username
+
+    *option*: `username_attribute` => `User.username`
+    # Username Attribute name. This defines which attribute in SAML response will map to an username.
+
+    *option*: `email_attribute` => `User.email`
+    # Email Attribute name. This defines which attribute in SAML response will map to an email address.
+
+
+Below is example setup from DUO Administration page that can be used with above config.
+
+.. image:: ../images/saml-duosecurity-service-provider-example.png
+   :alt: DUO Security SAML setup example
+   :scale: 50 %
+
+
+Below is an example attribute mapping set for IDP provider required by the above config.
+
+
+.. image:: ../images/saml-duosecurity-attributes-example.png
+   :alt: DUO Security SAML setup example
+   :scale: 50 %
  No newline at end of file

docs/auth/auth-saml-generic.rst

@@ -0,0 +1,18 b''
+.. _config-saml-generic-ref:
+
+
+SAML 2.0 Authentication
+-----------------------
+
+
+**This plugin is available only in EE Edition.**
+
+RhodeCode Supports standard SAML 2.0 SSO for the web-application part.
+
+Please check for reference two example providers:
+
+.. toctree::
+
+   auth-saml-duosecurity
+   auth-saml-onelogin
+

docs/auth/auth-saml-onelogin.rst

@@ -0,0 +1,106 b''
+.. _config-saml-onelogin-ref:
+
+
+SAML 2.0 with One Login
+-----------------------
+
+**This plugin is available only in EE Edition.**
+
+|RCE| supports SAML 2.0 Authentication with OneLogin provider. This allows
+users to log-in to RhodeCode via SSO mechanism of external identity provider
+such as OneLogin. The login can be triggered either by the external IDP, or internally
+by clicking specific authentication button on the log-in page.
+
+
+Configuration steps
+^^^^^^^^^^^^^^^^^^^
+
+To configure OneLogin SAML authentication, use the following steps:
+
+1. From the |RCE| interface, select
+   :menuselection:`Admin --> Authentication`
+2. Activate the `OneLogin` plugin and select :guilabel:`Save`
+3. Go to newly available menu option called `OneLogin` on the left side.
+4. Check the `enabled` check box in the plugin configuration section,
+   and fill in the required SAML information and :guilabel:`Save`, for more details,
+   see :ref:`config-saml-onelogin`
+
+
+.. _config-saml-onelogin:
+
+
+Example SAML OneLogin configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Example configuration for SAML 2.0 with OneLogin provider::
+
+    *option*: `enabled` => `True`
+    # Enable or disable this authentication plugin.
+
+    *option*: `cache_ttl` => `0`
+    # Amount of seconds to cache the authentication and permissions check response call for this plugin.
+    # Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
+
+    *option*: `debug` => `True`
+    # Enable or disable debug mode that shows SAML errors in the RhodeCode logs.
+
+    *option*: `entity_id` => `https://app.onelogin.com/saml/metadata/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
+    # Identity Provider entity/metadata URI.
+    # E.g. https://app.onelogin.com/saml/metadata/<onelogin_connector_id>
+
+    *option*: `sso_service_url` => `https://customer-domain.onelogin.com/trust/saml2/http-post/sso/xxxxxx`
+    # SSO (SingleSignOn) endpoint URL of the IdP. This can be used to initialize login
+    # E.g. https://app.onelogin.com/trust/saml2/http-post/sso/<onelogin_connector_id>
+
+    *option*: `slo_service_url` => `https://customer-domain.onelogin.com/trust/saml2/http-redirect/slo/xxxxxx`
+    # SLO (SingleLogout) endpoint URL of the IdP.
+    # E.g. https://app.onelogin.com/trust/saml2/http-redirect/slo/<onelogin_connector_id>
+
+    *option*: `x509cert` => `<CERTIFICATE_STRING>`
+    # Identity provider public x509 certificate. It will be converted to single-line format without headers
+
+    *option*: `name_id_format` => `sha-1`
+    # The format that specifies how the NameID is sent to the service provider.
+
+    *option*: `signature_algo` => `sha-256`
+    # Type of Algorithm to use for verification of SAML signature on Identity provider side
+
+    *option*: `digest_algo` => `sha-256`
+    # Type of Algorithm to use for verification of SAML digest on Identity provider side
+
+    *option*: `cert_dir` => `/etc/saml/`
+    # Optional directory to store service provider certificate and private keys.
+    # Expected certs for the SP should be stored in this folder as:
+    #  * sp.key     Private Key
+    #  * sp.crt     Public cert
+    #  * sp_new.crt Future Public cert
+    #
+    # Also you can use other cert to sign the metadata of the SP using the:
+    #  * metadata.key
+    #  * metadata.crt
+
+    *option*: `user_id_attribute` => `PersonImmutableID`
+    # User ID Attribute name. This defines which attribute in SAML response will be used to link accounts via unique id.
+    # Ensure this is returned from OneLogin for example via Internal ID
+
+    *option*: `username_attribute` => `User.username`
+    # Username Attribute name. This defines which attribute in SAML response will map to an username.
+
+    *option*: `email_attribute` => `User.email`
+    # Email Attribute name. This defines which attribute in SAML response will map to an email address.
+
+
+
+Below is example setup that can be used with OneLogin SAML authentication that can be used with above config..
+
+.. image:: ../images/saml-onelogin-config-example.png
+   :alt: OneLogin SAML setup example
+   :scale: 50 %
+
+
+Below is an example attribute mapping set for IDP provider required by the above config.
+
+
+.. image:: ../images/saml-onelogin-attributes-example.png
+   :alt: OneLogin SAML setup example
+   :scale: 50 %
  No newline at end of file

docs/release-notes/release-notes-4.15.0.rst

@@ -0,0 +1,81 b''
+|RCE| 4.15.0 |RNS|
+------------------
+
+Release Date
+^^^^^^^^^^^^
+
+- 2018-12-10
+
+
+New Features
+^^^^^^^^^^^^
+
+- Authentication: Added SAML 2.0 Authentication, with support of OneLogin and DUO Security.
+- Core: add debug mode that switches logging to debug.
+  It's no longer required to reconfigure all logging. A `debug=true` set in .ini file
+  does it automatically.
+
+
+General
+^^^^^^^
+
+- Authentication: rename oauth to external identity as it would now be serving both
+  oAuth and SAML.
+- Authentication: allow setting extern type with registration.
+  This will allow external identity plugins to define proper externs instead of always
+  using "rhodecode" one.
+- Authentication: show if plugin is activated and enabled in the list.
+- Authentication: add better logging for ldap related attributes to help track
+  LDAP connection problems more easily.
+- Visual: add change logo header template
+- UI: updated error pages style to be consistent with other pages.
+- Utils: updated request generation so ishell can run some automation scripts.
+- Docs: updated documentation for SVN 1.10 Wandisco repositories.
+- System info: expose base_url set in .ini file.
+- Style: update pygments template styling.
+- Style: updated li style and markdown style.
+- Dependencies: added python-saml library.
+- Dependencies: bumped hgsubversion to 1.9.3 release.
+- Dependencies: bumped gevent to 1.3.7 release.
+- Dependencies: bumped lxml to 4.2.5 release.
+- Dependencies: bumped gevent to 1.3.7 release.
+- Dependencies: bumped alembic to 1.0.5 release.
+- Dependencies: bumped peppercorn to 0.6 release.
+- Dependencies: bumped pyotp to 2.2.7 release.
+- Dependencies: bumped deform to 2.0.7 release
+- Dependencies: bumped py-gfm to 0.1.4 release.
+- Dependencies: bumped colander to 1.5.1 release
+- Dependencies: bumped appenlight-client to 0.6.26 release.
+- Dependencies: bumped bleach to 3.0.2 release.
+- Dependencies: bumped pygments to 2.3.0
+
+
+Security
+^^^^^^^^
+
+- Mercurial: support evolve sub-commands when checking for permissions.
+  Those defaulted to write, while only read is required for evolve.
+- auth/security: enforce that external users cannot reset their password.
+  External users don't use RhodeCode passwords, so resetting them shouldn't be allowed.
+
+
+Performance
+^^^^^^^^^^^
+
+- Markdown: use lazy loaded markdown initialization to speed up app startup.
+- Gevent: changed DNS resolver to ares for better stability on long running processes.
+
+
+Fixes
+^^^^^
+
+- Default Reviewers: use target repo owner as default reviewer in case of CE edition.
+- LDAP: ensure the proper cert files and dirs are set.
+  It's also now possible to specify custom paths for those.
+- Markdown: fixed auto checkbox generation from markdown code
+
+
+Upgrade notes
+^^^^^^^^^^^^^
+
+- LDAP cert dirs
  No newline at end of file

.bumpversion.cfg

@@ -1,6 +1,6 b''
 [bumpversion]
-current_version = 4.14.1
+current_version = 4.15.0
 message = release: Bump version {current_version} to {new_version}
 
 [bumpversion:file:rhodecode/VERSION]
 

.release.cfg

@@ -1,33 +1,28 b''
 [DEFAULT]
 done = false
 
 [task:bump_version]
 done = true
 
 [task:rc_tools_pinned]
-done = true
 
 [task:fixes_on_stable]
-done = true
 
 [task:pip2nix_generated]
-done = true
 
 [task:changelog_updated]
-done = true
 
 [task:generate_api_docs]
-done = true
+
+[task:updated_translation]
 
 [release]
-state = prepared
-version = 4.14.1
-
-[task:updated_translation]
+state = in_progress
+version = 4.15.0
 
 [task:generate_js_routes]
 
 [task:updated_trial_license]
 
 [task:generate_oss_licenses]
 

README.rst

@@ -1,114 +1,116 b''
 =========
 RhodeCode
 =========
 
 About
 -----
 
 ``RhodeCode`` is a fast and powerful management tool for Mercurial_ and GIT_
 and Subversion_ with a built in push/pull server, full text search,
-pull requests and powerful code-review system. It works on http/https and
+pull requests and powerful code-review system. It works on http/https, SSH and
 has a few unique features like:
 
- - plugable architecture
- - advanced permission system with IP restrictions
- - rich set of authentication plugins including LDAP,
-   ActiveDirectory, Atlassian Crowd, Http-Headers, Pam, Token-Auth.
- - live code-review chat
- - full web based file editing
- - unified multi vcs support
- - snippets (gist) system
- - integration with all 3rd party issue trackers
+- plugable architecture from Pyramid web-framework.
+- advanced permission system with IP restrictions, inheritation, and user-groups.
+- rich set of authentication plugins including LDAP, ActiveDirectory, SAML 2.0,
+  Atlassian Crowd, Http-Headers, Pam, Token-Auth, OAuth.
+- live code-review chat, and reviewer rules.
+- full web based file editing.
+- unified multi vcs support.
+- snippets (gist) system.
+- integration framework for Slack, CI systems, Webhooks.
+- integration with all 3rd party issue trackers.
+
 
 RhodeCode also provides rich API, and multiple event hooks so it's easy
 integrable with existing external systems.
 
 RhodeCode is similar in some respects to gitlab_, github_ or bitbucket_,
 however RhodeCode can be run as standalone hosted application on your own server.
 RhodeCode can be installed on \*nix or Windows systems.
 
 RhodeCode uses `PEP386 versioning <http://www.python.org/dev/peps/pep-0386/>`_
 
 Installation
 ------------
 Please visit https://docs.rhodecode.com/RhodeCode-Control/tasks/install-cli.html
 for more details
 
 
 Source code
 -----------
 
 The latest sources can be obtained from official RhodeCode instance
 https://code.rhodecode.com
 
 
 Contributions
 -------------
 
 RhodeCode is open-source; contributions are welcome!
 
 Please see the contribution documentation inside of the docs folder, which is
 also available at
 https://docs.rhodecode.com/RhodeCode-Enterprise/contributing/contributing.html
 
 For additional information about collaboration tools, our issue tracker,
 licensing, and contribution credit, visit https://rhodecode.com/open-source 
 
 
 RhodeCode Features
 ------------------
 
 Check out all features of RhodeCode at https://rhodecode.com/features
 
 License
 -------
 
 ``RhodeCode`` is dual-licensed with AGPLv3 and commercial license.
 Please see LICENSE.txt file for details.
 
 
 Getting help
 ------------
 
 Listed bellow are various support resources that should help.
 
 .. note::
 
    Please try to read the documentation before posting any issues, especially
    the **troubleshooting section**
 
 - Official issue tracker `RhodeCode Issue tracker <https://issues.rhodecode.com>`_
 
 - Official Slack Community Channel `RhodeCode Slack <https://rhodecode.com/join>`_
 
 - Search our community portal `Community portal <https://community.rhodecode.com>`_
 
 - You can also follow RhodeCode on twitter **@RhodeCode** where we often post
   news and other interesting stuff about RhodeCode.
 
 
 Online documentation
 --------------------
 
 Online documentation for the current version of RhodeCode is available at
  - http://rhodecode.com/docs
 
 You may also build the documentation for yourself - go into ``docs/`` and run::
 
     nix-build default.nix -o result && make clean html
 
 (You need to have sphinx_ installed to build the documentation. If you don't
 have sphinx_ installed you can install it via the command:
 ``pip install sphinx``)
 
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _python: http://www.python.org/
 .. _sphinx: http://sphinx.pocoo.org/
 .. _mercurial: http://mercurial.selenic.com/
 .. _bitbucket: http://bitbucket.org/
 .. _github: http://github.com/
 .. _gitlab: http://gitlab.com/
 .. _subversion: http://subversion.tigris.org/
 .. _git: http://git-scm.com/
 .. _celery: http://celeryproject.org/
 .. _vcs: http://pypi.python.org/pypi/vcs

configs/development.ini

@@ -1,724 +1,718 b''
 
 
 ################################################################################
-##                 RHODECODE COMMUNITY EDITION CONFIGURATION                  ##
+##                RHODECODE COMMUNITY  EDITION CONFIGURATION                  ##
 ################################################################################
 
 [DEFAULT]
+## Debug flag sets all loggers to debug, and enables request tracking
 debug = true
 
 ################################################################################
 ##                            EMAIL CONFIGURATION                             ##
 ## Uncomment and replace with the email address which should receive          ##
 ## any error reports after an application crash                               ##
 ## Additionally these settings will be used by the RhodeCode mailing system   ##
 ################################################################################
 
 ## prefix all emails subjects with given prefix, helps filtering out emails
 #email_prefix = [RhodeCode]
 
 ## email FROM address all mails will be sent
 #app_email_from = rhodecode-noreply@localhost
 
 #smtp_server = mail.server.com
 #smtp_username =
 #smtp_password =
 #smtp_port =
 #smtp_use_tls = false
 #smtp_use_ssl = true
 
 [server:main]
 ## COMMON ##
 host = 127.0.0.1
 port = 5000
 
 ###########################################################
 ## WAITRESS WSGI SERVER - Recommended for Development  ####
 ###########################################################
 
 use = egg:waitress#main
 ## number of worker threads
 threads = 5
 ## MAX BODY SIZE 100GB
 max_request_body_size = 107374182400
 ## Use poll instead of select, fixes file descriptors limits problems.
 ## May not work on old windows systems.
 asyncore_use_poll = true
 
 
 ##########################
 ## GUNICORN WSGI SERVER ##
 ##########################
 ## run with gunicorn --log-config rhodecode.ini --paste rhodecode.ini
 
 #use = egg:gunicorn#main
 ## Sets the number of process workers. More workers means more concurent connections
 ## RhodeCode can handle at the same time. Each additional worker also it increases
 ## memory usage as each has it's own set of caches.
 ## Recommended value is (2 * NUMBER_OF_CPUS + 1), eg 2CPU = 5 workers, but no more
 ## than 8-10 unless for really big deployments .e.g 700-1000 users.
 ## `instance_id = *` must be set in the [app:main] section below (which is the default)
 ## when using more than 1 worker.
 #workers = 2
 ## process name visible in process list
 #proc_name = rhodecode
 ## type of worker class, one of sync, gevent
 ## recommended for bigger setup is using of of other than sync one
 #worker_class = gevent
 ## The maximum number of simultaneous clients. Valid only for Gevent
 #worker_connections = 10
 ## max number of requests that worker will handle before being gracefully
 ## restarted, could prevent memory leaks
 #max_requests = 1000
 #max_requests_jitter = 30
 ## amount of time a worker can spend with handling a request before it
 ## gets killed and restarted. Set to 6hrs
 #timeout = 21600
 
 
 ## prefix middleware for RhodeCode.
 ## recommended when using proxy setup.
 ## allows to set RhodeCode under a prefix in server.
 ## eg https://server.com/custom_prefix. Enable `filter-with =` option below as well.
 ## And set your prefix like: `prefix = /custom_prefix`
 ## be sure to also set beaker.session.cookie_path = /custom_prefix if you need
 ## to make your cookies only work on prefix url
 [filter:proxy-prefix]
 use = egg:PasteDeploy#prefix
 prefix = /
 
 [app:main]
 ## The %(here)s variable will be replaced with the absolute path of parent directory
 ## of this file
 ## In addition ENVIRONMENT variables usage is possible, e.g
 ## sqlalchemy.db1.url = {ENV_RC_DB_URL}
 
 use = egg:rhodecode-enterprise-ce
 
 ## enable proxy prefix middleware, defined above
 #filter-with = proxy-prefix
 
 # During development the we want to have the debug toolbar enabled
 pyramid.includes =
     pyramid_debugtoolbar
     rhodecode.lib.middleware.request_wrapper
 
 pyramid.reload_templates = true
 
 debugtoolbar.hosts = 0.0.0.0/0
 debugtoolbar.exclude_prefixes =
     /css
     /fonts
     /images
     /js
 
 ## RHODECODE PLUGINS ##
 rhodecode.includes =
     rhodecode.api
 
 
 # api prefix url
 rhodecode.api.url = /_admin/api
 
 
 ## END RHODECODE PLUGINS ##
 
 ## encryption key used to encrypt social plugin tokens,
 ## remote_urls with credentials etc, if not set it defaults to
 ## `beaker.session.secret`
 #rhodecode.encrypted_values.secret =
 
 ## decryption strict mode (enabled by default). It controls if decryption raises
 ## `SignatureVerificationError` in case of wrong key, or damaged encryption data.
 #rhodecode.encrypted_values.strict = false
 
 ## return gzipped responses from Rhodecode (static files/application)
 gzip_responses = false
 
 ## autogenerate javascript routes file on startup
 generate_js_files = false
 
 ## System global default language.
 ## All available languages: en(default), be, de, es, fr, it, ja, pl, pt, ru, zh
 lang = en
 
 ## Perform a full repository scan and import on each server start.
 ## Settings this to true could lead to very long startup time.
 startup.import_repos = false
 
 ## Uncomment and set this path to use archive download cache.
 ## Once enabled, generated archives will be cached at this location
 ## and served from the cache during subsequent requests for the same archive of
 ## the repository.
 #archive_cache_dir = /tmp/tarballcache
 
 ## URL at which the application is running. This is used for bootstraping
 ## requests in context when no web request is available. Used in ishell, or
 ## SSH calls. Set this for events to receive proper url for SSH calls.
 app.base_url = http://rhodecode.local
 
 ## Unique application ID. Should be a random unique string for security.
 app_instance_uuid = rc-production
 
 ## Cut off limit for large diffs (size in bytes). If overall diff size on
 ## commit, or pull request exceeds this limit this diff will be displayed
 ## partially. E.g 512000 == 512Kb
 cut_off_limit_diff = 512000
 
 ## Cut off limit for large files inside diffs (size in bytes). Each individual
 ## file inside diff which exceeds this limit will be displayed partially.
 ##  E.g 128000 == 128Kb
 cut_off_limit_file = 128000
 
 ## use cached version of vcs repositories everywhere. Recommended to be `true`
 vcs_full_cache = true
 
 ## Force https in RhodeCode, fixes https redirects, assumes it's always https.
 ## Normally this is controlled by proper http flags sent from http server
 force_https = false
 
 ## use Strict-Transport-Security headers
 use_htsts = false
 
 ## git rev filter option, --all is the default filter, if you need to
 ## hide all refs in changelog switch this to --branches --tags
 git_rev_filter = --branches --tags
 
 # Set to true if your repos are exposed using the dumb protocol
 git_update_server_info = false
 
 ## RSS/ATOM feed options
 rss_cut_off_limit = 256000
 rss_items_per_page = 10
 rss_include_diff = false
 
 ## gist URL alias, used to create nicer urls for gist. This should be an
 ## url that does rewrites to _admin/gists/{gistid}.
 ## example: http://gist.rhodecode.org/{gistid}. Empty means use the internal
 ## RhodeCode url, ie. http[s]://rhodecode.server/_admin/gists/{gistid}
 gist_alias_url =
 
 ## List of views (using glob pattern syntax) that AUTH TOKENS could be
 ## used for access.
 ## Adding ?auth_token=TOKEN_HASH to the url authenticates this request as if it
 ## came from the the logged in user who own this authentication token.
 ## Additionally @TOKEN syntaxt can be used to bound the view to specific
 ## authentication token. Such view would be only accessible when used together
 ## with this authentication token
 ##
 ## list of all views can be found under `/_admin/permissions/auth_token_access`
 ## The list should be "," separated and on a single line.
 ##
 ## Most common views to enable:
 #    RepoCommitsView:repo_commit_download
 #    RepoCommitsView:repo_commit_patch
 #    RepoCommitsView:repo_commit_raw
 #    RepoCommitsView:repo_commit_raw@TOKEN
 #    RepoFilesView:repo_files_diff
 #    RepoFilesView:repo_archivefile
 #    RepoFilesView:repo_file_raw
 #    GistView:*
 api_access_controllers_whitelist =
 
 ## Default encoding used to convert from and to unicode
 ## can be also a comma separated list of encoding in case of mixed encodings
 default_encoding = UTF-8
 
 ## instance-id prefix
 ## a prefix key for this instance used for cache invalidation when running
 ## multiple instances of rhodecode, make sure it's globally unique for
 ## all running rhodecode instances. Leave empty if you don't use it
 instance_id =
 
 ## Fallback authentication plugin. Set this to a plugin ID to force the usage
 ## of an authentication plugin also if it is disabled by it's settings.
 ## This could be useful if you are unable to log in to the system due to broken
 ## authentication settings. Then you can enable e.g. the internal rhodecode auth
 ## module to log in again and fix the settings.
 ##
 ## Available builtin plugin IDs (hash is part of the ID):
 ## egg:rhodecode-enterprise-ce#rhodecode
 ## egg:rhodecode-enterprise-ce#pam
 ## egg:rhodecode-enterprise-ce#ldap
 ## egg:rhodecode-enterprise-ce#jasig_cas
 ## egg:rhodecode-enterprise-ce#headers
 ## egg:rhodecode-enterprise-ce#crowd
 #rhodecode.auth_plugin_fallback = egg:rhodecode-enterprise-ce#rhodecode
 
 ## alternative return HTTP header for failed authentication. Default HTTP
 ## response is 401 HTTPUnauthorized. Currently HG clients have troubles with
 ## handling that causing a series of failed authentication calls.
 ## Set this variable to 403 to return HTTPForbidden, or any other HTTP code
 ## This will be served instead of default 401 on bad authnetication
 auth_ret_code =
 
 ## use special detection method when serving auth_ret_code, instead of serving
 ## ret_code directly, use 401 initially (Which triggers credentials prompt)
 ## and then serve auth_ret_code to clients
 auth_ret_code_detection = false
 
 ## locking return code. When repository is locked return this HTTP code. 2XX
 ## codes don't break the transactions while 4XX codes do
 lock_ret_code = 423
 
 ## allows to change the repository location in settings page
 allow_repo_location_change = true
 
 ## allows to setup custom hooks in settings page
 allow_custom_hooks_settings = true
 
 ## Generated license token required for EE edition license.
 ## New generated token value can be found in Admin > settings > license page.
 license_token =
 
 ## supervisor connection uri, for managing supervisor and logs.
 supervisor.uri =
 ## supervisord group name/id we only want this RC instance to handle
 supervisor.group_id = dev
 
 ## Display extended labs settings
 labs_settings_active = true
 
 ## Custom exception store path, defaults to TMPDIR
 ## This is used to store exception from RhodeCode in shared directory
 #exception_tracker.store_path =
 
 
 ####################################
 ###        CELERY CONFIG        ####
 ####################################
 ## run: /path/to/celery worker \
 ##     -E --beat --app rhodecode.lib.celerylib.loader \
 ##     --scheduler rhodecode.lib.celerylib.scheduler.RcScheduler \
 ##     --loglevel DEBUG --ini /path/to/rhodecode.ini
 
 use_celery = false
 
 ## connection url to the message broker (default rabbitmq)
 celery.broker_url = amqp://rabbitmq:qweqwe@localhost:5672/rabbitmqhost
 
 ## maximum tasks to execute before worker restart
 celery.max_tasks_per_child = 100
 
 ## tasks will never be sent to the queue, but executed locally instead.
 celery.task_always_eager = false
 
 #####################################
 ###         DOGPILE CACHE        ####
 #####################################
 ## Default cache dir for caches.  Putting this into a ramdisk
 ## can boost performance, eg. /tmpfs/data_ramdisk, however this directory might require
 ## large amount of space
 cache_dir = %(here)s/data
 
 ## `cache_perms` cache settings for permission tree, auth TTL.
 rc_cache.cache_perms.backend = dogpile.cache.rc.file_namespace
 rc_cache.cache_perms.expiration_time = 300
 
 ## alternative `cache_perms` redis backend with distributed lock
 #rc_cache.cache_perms.backend = dogpile.cache.rc.redis
 #rc_cache.cache_perms.expiration_time = 300
 ## redis_expiration_time needs to be greater then expiration_time
 #rc_cache.cache_perms.arguments.redis_expiration_time = 7200
 #rc_cache.cache_perms.arguments.socket_timeout = 30
 #rc_cache.cache_perms.arguments.host = localhost
 #rc_cache.cache_perms.arguments.port = 6379
 #rc_cache.cache_perms.arguments.db = 0
 #rc_cache.cache_perms.arguments.distributed_lock = true
 
 ## `cache_repo` cache settings for FileTree, Readme, RSS FEEDS
 rc_cache.cache_repo.backend = dogpile.cache.rc.file_namespace
 rc_cache.cache_repo.expiration_time = 2592000
 
 ## alternative `cache_repo` redis backend with distributed lock
 #rc_cache.cache_repo.backend = dogpile.cache.rc.redis
 #rc_cache.cache_repo.expiration_time = 2592000
 ## redis_expiration_time needs to be greater then expiration_time
 #rc_cache.cache_repo.arguments.redis_expiration_time = 2678400
 #rc_cache.cache_repo.arguments.socket_timeout = 30
 #rc_cache.cache_repo.arguments.host = localhost
 #rc_cache.cache_repo.arguments.port = 6379
 #rc_cache.cache_repo.arguments.db = 1
 #rc_cache.cache_repo.arguments.distributed_lock = true
 
 ## cache settings for SQL queries, this needs to use memory type backend
 rc_cache.sql_cache_short.backend = dogpile.cache.rc.memory_lru
 rc_cache.sql_cache_short.expiration_time = 30
 
 ## `cache_repo_longterm` cache for repo object instances, this needs to use memory
 ## type backend as the objects kept are not pickle serializable
 rc_cache.cache_repo_longterm.backend = dogpile.cache.rc.memory_lru
 ## by default we use 96H, this is using invalidation on push anyway
 rc_cache.cache_repo_longterm.expiration_time = 345600
 ## max items in LRU cache, reduce this number to save memory, and expire last used
 ## cached objects
 rc_cache.cache_repo_longterm.max_size = 10000
 
 
 ####################################
 ###       BEAKER SESSION        ####
 ####################################
 
 ## .session.type is type of storage options for the session, current allowed
 ## types are file, ext:memcached, ext:redis, ext:database, and memory (default).
 beaker.session.type = file
 beaker.session.data_dir = %(here)s/data/sessions
 
 ## db based session, fast, and allows easy management over logged in users
 #beaker.session.type = ext:database
 #beaker.session.table_name = db_session
 #beaker.session.sa.url = postgresql://postgres:secret@localhost/rhodecode
 #beaker.session.sa.url = mysql://root:secret@127.0.0.1/rhodecode
 #beaker.session.sa.pool_recycle = 3600
 #beaker.session.sa.echo = false
 
 beaker.session.key = rhodecode
 beaker.session.secret = develop-rc-uytcxaz
 beaker.session.lock_dir = %(here)s/data/sessions/lock
 
 ## Secure encrypted cookie. Requires AES and AES python libraries
 ## you must disable beaker.session.secret to use this
 #beaker.session.encrypt_key = key_for_encryption
 #beaker.session.validate_key = validation_key
 
 ## sets session as invalid(also logging out user) if it haven not been
 ## accessed for given amount of time in seconds
 beaker.session.timeout = 2592000
 beaker.session.httponly = true
 ## Path to use for the cookie. Set to prefix if you use prefix middleware
 #beaker.session.cookie_path = /custom_prefix
 
 ## uncomment for https secure cookie
 beaker.session.secure = false
 
 ## auto save the session to not to use .save()
 beaker.session.auto = false
 
 ## default cookie expiration time in seconds, set to `true` to set expire
 ## at browser close
 #beaker.session.cookie_expires = 3600
 
 ###################################
 ## SEARCH INDEXING CONFIGURATION ##
 ###################################
 ## Full text search indexer is available in rhodecode-tools under
 ## `rhodecode-tools index` command
 
 ## WHOOSH Backend, doesn't require additional services to run
 ## it works good with few dozen repos
 search.module = rhodecode.lib.index.whoosh
 search.location = %(here)s/data/index
 
 ########################################
 ###    CHANNELSTREAM CONFIG         ####
 ########################################
 ## channelstream enables persistent connections and live notification
 ## in the system. It's also used by the chat system
+
 channelstream.enabled = false
 
 ## server address for channelstream server on the backend
 channelstream.server = 127.0.0.1:9800
 
 ## location of the channelstream server from outside world
 ## use ws:// for http or wss:// for https. This address needs to be handled
 ## by external HTTP server such as Nginx or Apache
 ## see nginx/apache configuration examples in our docs
 channelstream.ws_url = ws://rhodecode.yourserver.com/_channelstream
 channelstream.secret = secret
 channelstream.history.location = %(here)s/channelstream_history
 
 ## Internal application path that Javascript uses to connect into.
 ## If you use proxy-prefix the prefix should be added before /_channelstream
 channelstream.proxy_path = /_channelstream
 
 
 ###################################
 ##       APPENLIGHT CONFIG       ##
 ###################################
 
 ## Appenlight is tailored to work with RhodeCode, see
 ## http://appenlight.com for details how to obtain an account
 
 ## appenlight integration enabled
 appenlight = false
 
 appenlight.server_url = https://api.appenlight.com
 appenlight.api_key = YOUR_API_KEY
 #appenlight.transport_config = https://api.appenlight.com?threaded=1&timeout=5
 
 # used for JS client
 appenlight.api_public_key = YOUR_API_PUBLIC_KEY
 
 ## TWEAK AMOUNT OF INFO SENT HERE
 
 ## enables 404 error logging (default False)
 appenlight.report_404 = false
 
 ## time in seconds after request is considered being slow (default 1)
 appenlight.slow_request_time = 1
 
 ## record slow requests in application
 ## (needs to be enabled for slow datastore recording and time tracking)
 appenlight.slow_requests = true
 
 ## enable hooking to application loggers
 appenlight.logging = true
 
 ## minimum log level for log capture
 appenlight.logging.level = WARNING
 
 ## send logs only from erroneous/slow requests
 ## (saves API quota for intensive logging)
 appenlight.logging_on_error = false
 
 ## list of additonal keywords that should be grabbed from environ object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always send following info:
 ## 'REMOTE_USER', 'REMOTE_ADDR', 'SERVER_NAME', 'CONTENT_TYPE' + all keys that
 ## start with HTTP* this list be extended with additional keywords here
 appenlight.environ_keys_whitelist =
 
 ## list of keywords that should be blanked from request object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always blank keys that contain following words
 ## 'password', 'passwd', 'pwd', 'auth_tkt', 'secret', 'csrf'
 ## this list be extended with additional keywords set here
 appenlight.request_keys_blacklist =
 
 ## list of namespaces that should be ignores when gathering log entries
 ## can be string with comma separated list of namespaces
 ## (by default the client ignores own entries: appenlight_client.client)
 appenlight.log_namespace_blacklist =
 
-
-################################################################################
-## WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT*  ##
-## Debug mode will enable the interactive debugging tool, allowing ANYONE to  ##
-## execute malicious code after an exception is raised.                       ##
-################################################################################
-#set debug = false
-
 # enable debug style page
 debug_style = true
 
 ###########################################
 ###   MAIN RHODECODE DATABASE CONFIG    ###
 ###########################################
 #sqlalchemy.db1.url = sqlite:///%(here)s/rhodecode.db?timeout=30
 #sqlalchemy.db1.url = postgresql://postgres:qweqwe@localhost/rhodecode
 #sqlalchemy.db1.url = mysql://root:qweqwe@localhost/rhodecode?charset=utf8
 # pymysql is an alternative driver for MySQL, use in case of problems with default one
 #sqlalchemy.db1.url = mysql+pymysql://root:qweqwe@localhost/rhodecode
 
 sqlalchemy.db1.url = sqlite:///%(here)s/rhodecode.db?timeout=30
 
 # see sqlalchemy docs for other advanced settings
 
 ## print the sql statements to output
 sqlalchemy.db1.echo = false
 ## recycle the connections after this amount of seconds
 sqlalchemy.db1.pool_recycle = 3600
 sqlalchemy.db1.convert_unicode = true
 
 ## the number of connections to keep open inside the connection pool.
 ## 0 indicates no limit
 #sqlalchemy.db1.pool_size = 5
 
 ## the number of connections to allow in connection pool "overflow", that is
 ## connections that can be opened above and beyond the pool_size setting,
 ## which defaults to five.
 #sqlalchemy.db1.max_overflow = 10
 
 ## Connection check ping, used to detect broken database connections
 ## could be enabled to better handle cases if MySQL has gone away errors
 #sqlalchemy.db1.ping_connection = true
 
 ##################
 ### VCS CONFIG ###
 ##################
 vcs.server.enable = true
 vcs.server = localhost:9900
 
 ## Web server connectivity protocol, responsible for web based VCS operatations
 ## Available protocols are:
 ## `http` - use http-rpc backend (default)
 vcs.server.protocol = http
 
 ## Push/Pull operations protocol, available options are:
 ## `http` - use http-rpc backend (default)
 vcs.scm_app_implementation = http
 
 ## Push/Pull operations hooks protocol, available options are:
 ## `http` - use http-rpc backend (default)
 vcs.hooks.protocol = http
 
 ## Host on which this instance is listening for hooks. If vcsserver is in other location
 ## this should be adjusted.
 vcs.hooks.host = 127.0.0.1
 
 vcs.server.log_level = debug
 ## Start VCSServer with this instance as a subprocess, useful for development
 vcs.start_server = false
 
 ## List of enabled VCS backends, available options are:
 ## `hg`  - mercurial
 ## `git` - git
 ## `svn` - subversion
 vcs.backends = hg, git, svn
 
 vcs.connection_timeout = 3600
 ## Compatibility version when creating SVN repositories. Defaults to newest version when commented out.
 ## Available options are: pre-1.4-compatible, pre-1.5-compatible, pre-1.6-compatible, pre-1.8-compatible, pre-1.9-compatible
 #vcs.svn.compatible_version = pre-1.8-compatible
 
 
 ############################################################
 ### Subversion proxy support (mod_dav_svn)               ###
 ### Maps RhodeCode repo groups into SVN paths for Apache ###
 ############################################################
 ## Enable or disable the config file generation.
 svn.proxy.generate_config = false
 ## Generate config file with `SVNListParentPath` set to `On`.
 svn.proxy.list_parent_path = true
 ## Set location and file name of generated config file.
 svn.proxy.config_file_path = %(here)s/mod_dav_svn.conf
 ## alternative mod_dav config template. This needs to be a mako template
 #svn.proxy.config_template = ~/.rccontrol/enterprise-1/custom_svn_conf.mako
 ## Used as a prefix to the `Location` block in the generated config file.
 ## In most cases it should be set to `/`.
 svn.proxy.location_root = /
 ## Command to reload the mod dav svn configuration on change.
 ## Example: `/etc/init.d/apache2 reload`
 #svn.proxy.reload_cmd = /etc/init.d/apache2 reload
 ## If the timeout expires before the reload command finishes, the command will
 ## be killed. Setting it to zero means no timeout. Defaults to 10 seconds.
 #svn.proxy.reload_timeout = 10
 
 ############################################################
 ### SSH Support Settings                                 ###
 ############################################################
 
 ## Defines if a custom authorized_keys file should be created and written on
 ## any change user ssh keys. Setting this to false also disables posibility
 ## of adding SSH keys by users from web interface. Super admins can still
 ## manage SSH Keys.
 ssh.generate_authorized_keyfile = false
 
 ## Options for ssh, default is `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`
 # ssh.authorized_keys_ssh_opts =
 
 ## Path to the authrozied_keys file where the generate entries are placed.
 ## It is possible to have multiple key files specified in `sshd_config` e.g.
 ## AuthorizedKeysFile %h/.ssh/authorized_keys %h/.ssh/authorized_keys_rhodecode
 ssh.authorized_keys_file_path = ~/.ssh/authorized_keys_rhodecode
 
 ## Command to execute the SSH wrapper. The binary is available in the
 ## rhodecode installation directory.
 ## e.g ~/.rccontrol/community-1/profile/bin/rc-ssh-wrapper
 ssh.wrapper_cmd = ~/.rccontrol/community-1/rc-ssh-wrapper
 
 ## Allow shell when executing the ssh-wrapper command
 ssh.wrapper_cmd_allow_shell = false
 
 ## Enables logging, and detailed output send back to the client during SSH
 ## operations. Usefull for debugging, shouldn't be used in production.
 ssh.enable_debug_logging = true
 
 ## Paths to binary executable, by default they are the names, but we can
 ## override them if we want to use a custom one
 ssh.executable.hg = ~/.rccontrol/vcsserver-1/profile/bin/hg
 ssh.executable.git = ~/.rccontrol/vcsserver-1/profile/bin/git
 ssh.executable.svn = ~/.rccontrol/vcsserver-1/profile/bin/svnserve
 
 
 ## Dummy marker to add new entries after.
 ## Add any custom entries below. Please don't remove.
 custom.conf = 1
 
 
 ################################
 ### LOGGING CONFIGURATION   ####
 ################################
 [loggers]
 keys = root, sqlalchemy, beaker, celery, rhodecode, ssh_wrapper
 
 [handlers]
 keys = console, console_sql
 
 [formatters]
 keys = generic, color_formatter, color_formatter_sql
 
 #############
 ## LOGGERS ##
 #############
 [logger_root]
 level = NOTSET
 handlers = console
 
 [logger_sqlalchemy]
 level = INFO
 handlers = console_sql
 qualname = sqlalchemy.engine
 propagate = 0
 
 [logger_beaker]
 level = DEBUG
 handlers =
 qualname = beaker.container
 propagate = 1
 
 [logger_rhodecode]
 level = DEBUG
 handlers =
 qualname = rhodecode
 propagate = 1
 
 [logger_ssh_wrapper]
 level = DEBUG
 handlers =
 qualname = ssh_wrapper
 propagate = 1
 
 [logger_celery]
 level = DEBUG
 handlers =
 qualname = celery
 
 
 ##############
 ## HANDLERS ##
 ##############
 
 [handler_console]
 class = StreamHandler
 args = (sys.stderr, )
 level = DEBUG
 formatter = color_formatter
 
 [handler_console_sql]
 # "level = DEBUG" logs SQL queries and results.
 # "level = INFO" logs SQL queries.
 # "level = WARN" logs neither.  (Recommended for production systems.)
 class = StreamHandler
 args = (sys.stderr, )
 level = WARN
 formatter = color_formatter_sql
 
 ################
 ## FORMATTERS ##
 ################
 
 [formatter_generic]
 class = rhodecode.lib.logging_formatter.ExceptionAwareFormatter
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S
 
 [formatter_color_formatter]
 class = rhodecode.lib.logging_formatter.ColorFormatter
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S
 
 [formatter_color_formatter_sql]
 class = rhodecode.lib.logging_formatter.ColorFormatterSql
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S

configs/production.ini

@@ -1,696 +1,691 b''
 
 
 ################################################################################
-##                 RHODECODE COMMUNITY EDITION CONFIGURATION                  ##
+##                RHODECODE COMMUNITY  EDITION CONFIGURATION                  ##
 ################################################################################
 
 [DEFAULT]
-debug = true
+## Debug flag sets all loggers to debug, and enables request tracking
+debug = false
 
 ################################################################################
 ##                            EMAIL CONFIGURATION                             ##
 ## Uncomment and replace with the email address which should receive          ##
 ## any error reports after an application crash                               ##
 ## Additionally these settings will be used by the RhodeCode mailing system   ##
 ################################################################################
 
 ## prefix all emails subjects with given prefix, helps filtering out emails
 #email_prefix = [RhodeCode]
 
 ## email FROM address all mails will be sent
 #app_email_from = rhodecode-noreply@localhost
 
 #smtp_server = mail.server.com
 #smtp_username =
 #smtp_password =
 #smtp_port =
 #smtp_use_tls = false
 #smtp_use_ssl = true
 
 [server:main]
 ## COMMON ##
 host = 127.0.0.1
 port = 5000
 
 ###########################################################
 ## WAITRESS WSGI SERVER - Recommended for Development  ####
 ###########################################################
 
 #use = egg:waitress#main
 ## number of worker threads
 #threads = 5
 ## MAX BODY SIZE 100GB
 #max_request_body_size = 107374182400
 ## Use poll instead of select, fixes file descriptors limits problems.
 ## May not work on old windows systems.
 #asyncore_use_poll = true
 
 
 ##########################
 ## GUNICORN WSGI SERVER ##
 ##########################
 ## run with gunicorn --log-config rhodecode.ini --paste rhodecode.ini
 
 use = egg:gunicorn#main
 ## Sets the number of process workers. More workers means more concurent connections
 ## RhodeCode can handle at the same time. Each additional worker also it increases
 ## memory usage as each has it's own set of caches.
 ## Recommended value is (2 * NUMBER_OF_CPUS + 1), eg 2CPU = 5 workers, but no more
 ## than 8-10 unless for really big deployments .e.g 700-1000 users.
 ## `instance_id = *` must be set in the [app:main] section below (which is the default)
 ## when using more than 1 worker.
 workers = 2
 ## process name visible in process list
 proc_name = rhodecode
 ## type of worker class, one of sync, gevent
 ## recommended for bigger setup is using of of other than sync one
 worker_class = gevent
 ## The maximum number of simultaneous clients. Valid only for Gevent
 worker_connections = 10
 ## max number of requests that worker will handle before being gracefully
 ## restarted, could prevent memory leaks
 max_requests = 1000
 max_requests_jitter = 30
 ## amount of time a worker can spend with handling a request before it
 ## gets killed and restarted. Set to 6hrs
 timeout = 21600
 
 
 ## prefix middleware for RhodeCode.
 ## recommended when using proxy setup.
 ## allows to set RhodeCode under a prefix in server.
 ## eg https://server.com/custom_prefix. Enable `filter-with =` option below as well.
 ## And set your prefix like: `prefix = /custom_prefix`
 ## be sure to also set beaker.session.cookie_path = /custom_prefix if you need
 ## to make your cookies only work on prefix url
 [filter:proxy-prefix]
 use = egg:PasteDeploy#prefix
 prefix = /
 
 [app:main]
 ## The %(here)s variable will be replaced with the absolute path of parent directory
 ## of this file
 ## In addition ENVIRONMENT variables usage is possible, e.g
 ## sqlalchemy.db1.url = {ENV_RC_DB_URL}
 
 use = egg:rhodecode-enterprise-ce
 
 ## enable proxy prefix middleware, defined above
 #filter-with = proxy-prefix
 
 ## encryption key used to encrypt social plugin tokens,
 ## remote_urls with credentials etc, if not set it defaults to
 ## `beaker.session.secret`
 #rhodecode.encrypted_values.secret =
 
 ## decryption strict mode (enabled by default). It controls if decryption raises
 ## `SignatureVerificationError` in case of wrong key, or damaged encryption data.
 #rhodecode.encrypted_values.strict = false
 
 ## return gzipped responses from Rhodecode (static files/application)
 gzip_responses = false
 
 ## autogenerate javascript routes file on startup
 generate_js_files = false
 
 ## System global default language.
 ## All available languages: en(default), be, de, es, fr, it, ja, pl, pt, ru, zh
 lang = en
 
 ## Perform a full repository scan and import on each server start.
 ## Settings this to true could lead to very long startup time.
 startup.import_repos = false
 
 ## Uncomment and set this path to use archive download cache.
 ## Once enabled, generated archives will be cached at this location
 ## and served from the cache during subsequent requests for the same archive of
 ## the repository.
 #archive_cache_dir = /tmp/tarballcache
 
 ## URL at which the application is running. This is used for bootstraping
 ## requests in context when no web request is available. Used in ishell, or
 ## SSH calls. Set this for events to receive proper url for SSH calls.
 app.base_url = http://rhodecode.local
 
 ## Unique application ID. Should be a random unique string for security.
 app_instance_uuid = rc-production
 
 ## Cut off limit for large diffs (size in bytes). If overall diff size on
 ## commit, or pull request exceeds this limit this diff will be displayed
 ## partially. E.g 512000 == 512Kb
 cut_off_limit_diff = 512000
 
 ## Cut off limit for large files inside diffs (size in bytes). Each individual
 ## file inside diff which exceeds this limit will be displayed partially.
 ##  E.g 128000 == 128Kb
 cut_off_limit_file = 128000
 
 ## use cached version of vcs repositories everywhere. Recommended to be `true`
 vcs_full_cache = true
 
 ## Force https in RhodeCode, fixes https redirects, assumes it's always https.
 ## Normally this is controlled by proper http flags sent from http server
 force_https = false
 
 ## use Strict-Transport-Security headers
 use_htsts = false
 
 ## git rev filter option, --all is the default filter, if you need to
 ## hide all refs in changelog switch this to --branches --tags
 git_rev_filter = --branches --tags
 
 # Set to true if your repos are exposed using the dumb protocol
 git_update_server_info = false
 
 ## RSS/ATOM feed options
 rss_cut_off_limit = 256000
 rss_items_per_page = 10
 rss_include_diff = false
 
 ## gist URL alias, used to create nicer urls for gist. This should be an
 ## url that does rewrites to _admin/gists/{gistid}.
 ## example: http://gist.rhodecode.org/{gistid}. Empty means use the internal
 ## RhodeCode url, ie. http[s]://rhodecode.server/_admin/gists/{gistid}
 gist_alias_url =
 
 ## List of views (using glob pattern syntax) that AUTH TOKENS could be
 ## used for access.
 ## Adding ?auth_token=TOKEN_HASH to the url authenticates this request as if it
 ## came from the the logged in user who own this authentication token.
 ## Additionally @TOKEN syntaxt can be used to bound the view to specific
 ## authentication token. Such view would be only accessible when used together
 ## with this authentication token
 ##
 ## list of all views can be found under `/_admin/permissions/auth_token_access`
 ## The list should be "," separated and on a single line.
 ##
 ## Most common views to enable:
 #    RepoCommitsView:repo_commit_download
 #    RepoCommitsView:repo_commit_patch
 #    RepoCommitsView:repo_commit_raw
 #    RepoCommitsView:repo_commit_raw@TOKEN
 #    RepoFilesView:repo_files_diff
 #    RepoFilesView:repo_archivefile
 #    RepoFilesView:repo_file_raw
 #    GistView:*
 api_access_controllers_whitelist =
 
 ## Default encoding used to convert from and to unicode
 ## can be also a comma separated list of encoding in case of mixed encodings
 default_encoding = UTF-8
 
 ## instance-id prefix
 ## a prefix key for this instance used for cache invalidation when running
 ## multiple instances of rhodecode, make sure it's globally unique for
 ## all running rhodecode instances. Leave empty if you don't use it
 instance_id =
 
 ## Fallback authentication plugin. Set this to a plugin ID to force the usage
 ## of an authentication plugin also if it is disabled by it's settings.
 ## This could be useful if you are unable to log in to the system due to broken
 ## authentication settings. Then you can enable e.g. the internal rhodecode auth
 ## module to log in again and fix the settings.
 ##
 ## Available builtin plugin IDs (hash is part of the ID):
 ## egg:rhodecode-enterprise-ce#rhodecode
 ## egg:rhodecode-enterprise-ce#pam
 ## egg:rhodecode-enterprise-ce#ldap
 ## egg:rhodecode-enterprise-ce#jasig_cas
 ## egg:rhodecode-enterprise-ce#headers
 ## egg:rhodecode-enterprise-ce#crowd
 #rhodecode.auth_plugin_fallback = egg:rhodecode-enterprise-ce#rhodecode
 
 ## alternative return HTTP header for failed authentication. Default HTTP
 ## response is 401 HTTPUnauthorized. Currently HG clients have troubles with
 ## handling that causing a series of failed authentication calls.
 ## Set this variable to 403 to return HTTPForbidden, or any other HTTP code
 ## This will be served instead of default 401 on bad authnetication
 auth_ret_code =
 
 ## use special detection method when serving auth_ret_code, instead of serving
 ## ret_code directly, use 401 initially (Which triggers credentials prompt)
 ## and then serve auth_ret_code to clients
 auth_ret_code_detection = false
 
 ## locking return code. When repository is locked return this HTTP code. 2XX
 ## codes don't break the transactions while 4XX codes do
 lock_ret_code = 423
 
 ## allows to change the repository location in settings page
 allow_repo_location_change = true
 
 ## allows to setup custom hooks in settings page
 allow_custom_hooks_settings = true
 
 ## Generated license token required for EE edition license.
 ## New generated token value can be found in Admin > settings > license page.
 license_token =
 
 ## supervisor connection uri, for managing supervisor and logs.
 supervisor.uri =
 ## supervisord group name/id we only want this RC instance to handle
 supervisor.group_id = prod
 
 ## Display extended labs settings
 labs_settings_active = true
 
 ## Custom exception store path, defaults to TMPDIR
 ## This is used to store exception from RhodeCode in shared directory
 #exception_tracker.store_path =
 
 
 ####################################
 ###        CELERY CONFIG        ####
 ####################################
 ## run: /path/to/celery worker \
 ##     -E --beat --app rhodecode.lib.celerylib.loader \
 ##     --scheduler rhodecode.lib.celerylib.scheduler.RcScheduler \
 ##     --loglevel DEBUG --ini /path/to/rhodecode.ini
 
 use_celery = false
 
 ## connection url to the message broker (default rabbitmq)
 celery.broker_url = amqp://rabbitmq:qweqwe@localhost:5672/rabbitmqhost
 
 ## maximum tasks to execute before worker restart
 celery.max_tasks_per_child = 100
 
 ## tasks will never be sent to the queue, but executed locally instead.
 celery.task_always_eager = false
 
 #####################################
 ###         DOGPILE CACHE        ####
 #####################################
 ## Default cache dir for caches.  Putting this into a ramdisk
 ## can boost performance, eg. /tmpfs/data_ramdisk, however this directory might require
 ## large amount of space
 cache_dir = %(here)s/data
 
 ## `cache_perms` cache settings for permission tree, auth TTL.
 rc_cache.cache_perms.backend = dogpile.cache.rc.file_namespace
 rc_cache.cache_perms.expiration_time = 300
 
 ## alternative `cache_perms` redis backend with distributed lock
 #rc_cache.cache_perms.backend = dogpile.cache.rc.redis
 #rc_cache.cache_perms.expiration_time = 300
 ## redis_expiration_time needs to be greater then expiration_time
 #rc_cache.cache_perms.arguments.redis_expiration_time = 7200
 #rc_cache.cache_perms.arguments.socket_timeout = 30
 #rc_cache.cache_perms.arguments.host = localhost
 #rc_cache.cache_perms.arguments.port = 6379
 #rc_cache.cache_perms.arguments.db = 0
 #rc_cache.cache_perms.arguments.distributed_lock = true
 
 ## `cache_repo` cache settings for FileTree, Readme, RSS FEEDS
 rc_cache.cache_repo.backend = dogpile.cache.rc.file_namespace
 rc_cache.cache_repo.expiration_time = 2592000
 
 ## alternative `cache_repo` redis backend with distributed lock
 #rc_cache.cache_repo.backend = dogpile.cache.rc.redis
 #rc_cache.cache_repo.expiration_time = 2592000
 ## redis_expiration_time needs to be greater then expiration_time
 #rc_cache.cache_repo.arguments.redis_expiration_time = 2678400
 #rc_cache.cache_repo.arguments.socket_timeout = 30
 #rc_cache.cache_repo.arguments.host = localhost
 #rc_cache.cache_repo.arguments.port = 6379
 #rc_cache.cache_repo.arguments.db = 1
 #rc_cache.cache_repo.arguments.distributed_lock = true
 
 ## cache settings for SQL queries, this needs to use memory type backend
 rc_cache.sql_cache_short.backend = dogpile.cache.rc.memory_lru
 rc_cache.sql_cache_short.expiration_time = 30
 
 ## `cache_repo_longterm` cache for repo object instances, this needs to use memory
 ## type backend as the objects kept are not pickle serializable
 rc_cache.cache_repo_longterm.backend = dogpile.cache.rc.memory_lru
 ## by default we use 96H, this is using invalidation on push anyway
 rc_cache.cache_repo_longterm.expiration_time = 345600
 ## max items in LRU cache, reduce this number to save memory, and expire last used
 ## cached objects
 rc_cache.cache_repo_longterm.max_size = 10000
 
 
 ####################################
 ###       BEAKER SESSION        ####
 ####################################
 
 ## .session.type is type of storage options for the session, current allowed
 ## types are file, ext:memcached, ext:redis, ext:database, and memory (default).
 beaker.session.type = file
 beaker.session.data_dir = %(here)s/data/sessions
 
 ## db based session, fast, and allows easy management over logged in users
 #beaker.session.type = ext:database
 #beaker.session.table_name = db_session
 #beaker.session.sa.url = postgresql://postgres:secret@localhost/rhodecode
 #beaker.session.sa.url = mysql://root:secret@127.0.0.1/rhodecode
 #beaker.session.sa.pool_recycle = 3600
 #beaker.session.sa.echo = false
 
 beaker.session.key = rhodecode
 beaker.session.secret = production-rc-uytcxaz
 beaker.session.lock_dir = %(here)s/data/sessions/lock
 
 ## Secure encrypted cookie. Requires AES and AES python libraries
 ## you must disable beaker.session.secret to use this
 #beaker.session.encrypt_key = key_for_encryption
 #beaker.session.validate_key = validation_key
 
 ## sets session as invalid(also logging out user) if it haven not been
 ## accessed for given amount of time in seconds
 beaker.session.timeout = 2592000
 beaker.session.httponly = true
 ## Path to use for the cookie. Set to prefix if you use prefix middleware
 #beaker.session.cookie_path = /custom_prefix
 
 ## uncomment for https secure cookie
 beaker.session.secure = false
 
 ## auto save the session to not to use .save()
 beaker.session.auto = false
 
 ## default cookie expiration time in seconds, set to `true` to set expire
 ## at browser close
 #beaker.session.cookie_expires = 3600
 
 ###################################
 ## SEARCH INDEXING CONFIGURATION ##
 ###################################
 ## Full text search indexer is available in rhodecode-tools under
 ## `rhodecode-tools index` command
 
 ## WHOOSH Backend, doesn't require additional services to run
 ## it works good with few dozen repos
 search.module = rhodecode.lib.index.whoosh
 search.location = %(here)s/data/index
 
 ########################################
 ###    CHANNELSTREAM CONFIG         ####
 ########################################
 ## channelstream enables persistent connections and live notification
 ## in the system. It's also used by the chat system
+
 channelstream.enabled = false
 
 ## server address for channelstream server on the backend
 channelstream.server = 127.0.0.1:9800
 
 ## location of the channelstream server from outside world
 ## use ws:// for http or wss:// for https. This address needs to be handled
 ## by external HTTP server such as Nginx or Apache
 ## see nginx/apache configuration examples in our docs
 channelstream.ws_url = ws://rhodecode.yourserver.com/_channelstream
 channelstream.secret = secret
 channelstream.history.location = %(here)s/channelstream_history
 
 ## Internal application path that Javascript uses to connect into.
 ## If you use proxy-prefix the prefix should be added before /_channelstream
 channelstream.proxy_path = /_channelstream
 
 
 ###################################
 ##       APPENLIGHT CONFIG       ##
 ###################################
 
 ## Appenlight is tailored to work with RhodeCode, see
 ## http://appenlight.com for details how to obtain an account
 
 ## appenlight integration enabled
 appenlight = false
 
 appenlight.server_url = https://api.appenlight.com
 appenlight.api_key = YOUR_API_KEY
 #appenlight.transport_config = https://api.appenlight.com?threaded=1&timeout=5
 
 # used for JS client
 appenlight.api_public_key = YOUR_API_PUBLIC_KEY
 
 ## TWEAK AMOUNT OF INFO SENT HERE
 
 ## enables 404 error logging (default False)
 appenlight.report_404 = false
 
 ## time in seconds after request is considered being slow (default 1)
 appenlight.slow_request_time = 1
 
 ## record slow requests in application
 ## (needs to be enabled for slow datastore recording and time tracking)
 appenlight.slow_requests = true
 
 ## enable hooking to application loggers
 appenlight.logging = true
 
 ## minimum log level for log capture
 appenlight.logging.level = WARNING
 
 ## send logs only from erroneous/slow requests
 ## (saves API quota for intensive logging)
 appenlight.logging_on_error = false
 
 ## list of additonal keywords that should be grabbed from environ object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always send following info:
 ## 'REMOTE_USER', 'REMOTE_ADDR', 'SERVER_NAME', 'CONTENT_TYPE' + all keys that
 ## start with HTTP* this list be extended with additional keywords here
 appenlight.environ_keys_whitelist =
 
 ## list of keywords that should be blanked from request object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always blank keys that contain following words
 ## 'password', 'passwd', 'pwd', 'auth_tkt', 'secret', 'csrf'
 ## this list be extended with additional keywords set here
 appenlight.request_keys_blacklist =
 
 ## list of namespaces that should be ignores when gathering log entries
 ## can be string with comma separated list of namespaces
 ## (by default the client ignores own entries: appenlight_client.client)
 appenlight.log_namespace_blacklist =
 
 
-################################################################################
-## WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT*  ##
-## Debug mode will enable the interactive debugging tool, allowing ANYONE to  ##
-## execute malicious code after an exception is raised.                       ##
-################################################################################
-set debug = false
-
-
 ###########################################
 ###   MAIN RHODECODE DATABASE CONFIG    ###
 ###########################################
 #sqlalchemy.db1.url = sqlite:///%(here)s/rhodecode.db?timeout=30
 #sqlalchemy.db1.url = postgresql://postgres:qweqwe@localhost/rhodecode
 #sqlalchemy.db1.url = mysql://root:qweqwe@localhost/rhodecode?charset=utf8
 # pymysql is an alternative driver for MySQL, use in case of problems with default one
 #sqlalchemy.db1.url = mysql+pymysql://root:qweqwe@localhost/rhodecode
 
 sqlalchemy.db1.url = postgresql://postgres:qweqwe@localhost/rhodecode
 
 # see sqlalchemy docs for other advanced settings
 
 ## print the sql statements to output
 sqlalchemy.db1.echo = false
 ## recycle the connections after this amount of seconds
 sqlalchemy.db1.pool_recycle = 3600
 sqlalchemy.db1.convert_unicode = true
 
 ## the number of connections to keep open inside the connection pool.
 ## 0 indicates no limit
 #sqlalchemy.db1.pool_size = 5
 
 ## the number of connections to allow in connection pool "overflow", that is
 ## connections that can be opened above and beyond the pool_size setting,
 ## which defaults to five.
 #sqlalchemy.db1.max_overflow = 10
 
 ## Connection check ping, used to detect broken database connections
 ## could be enabled to better handle cases if MySQL has gone away errors
 #sqlalchemy.db1.ping_connection = true
 
 ##################
 ### VCS CONFIG ###
 ##################
 vcs.server.enable = true
 vcs.server = localhost:9900
 
 ## Web server connectivity protocol, responsible for web based VCS operatations
 ## Available protocols are:
 ## `http` - use http-rpc backend (default)
 vcs.server.protocol = http
 
 ## Push/Pull operations protocol, available options are:
 ## `http` - use http-rpc backend (default)
 vcs.scm_app_implementation = http
 
 ## Push/Pull operations hooks protocol, available options are:
 ## `http` - use http-rpc backend (default)
 vcs.hooks.protocol = http
+
 ## Host on which this instance is listening for hooks. If vcsserver is in other location
 ## this should be adjusted.
 vcs.hooks.host = 127.0.0.1
 
 vcs.server.log_level = info
 ## Start VCSServer with this instance as a subprocess, useful for development
 vcs.start_server = false
 
 ## List of enabled VCS backends, available options are:
 ## `hg`  - mercurial
 ## `git` - git
 ## `svn` - subversion
 vcs.backends = hg, git, svn
 
 vcs.connection_timeout = 3600
 ## Compatibility version when creating SVN repositories. Defaults to newest version when commented out.
 ## Available options are: pre-1.4-compatible, pre-1.5-compatible, pre-1.6-compatible, pre-1.8-compatible, pre-1.9-compatible
 #vcs.svn.compatible_version = pre-1.8-compatible
 
 
 ############################################################
 ### Subversion proxy support (mod_dav_svn)               ###
 ### Maps RhodeCode repo groups into SVN paths for Apache ###
 ############################################################
 ## Enable or disable the config file generation.
 svn.proxy.generate_config = false
 ## Generate config file with `SVNListParentPath` set to `On`.
 svn.proxy.list_parent_path = true
 ## Set location and file name of generated config file.
 svn.proxy.config_file_path = %(here)s/mod_dav_svn.conf
 ## alternative mod_dav config template. This needs to be a mako template
 #svn.proxy.config_template = ~/.rccontrol/enterprise-1/custom_svn_conf.mako
 ## Used as a prefix to the `Location` block in the generated config file.
 ## In most cases it should be set to `/`.
 svn.proxy.location_root = /
 ## Command to reload the mod dav svn configuration on change.
 ## Example: `/etc/init.d/apache2 reload`
 #svn.proxy.reload_cmd = /etc/init.d/apache2 reload
 ## If the timeout expires before the reload command finishes, the command will
 ## be killed. Setting it to zero means no timeout. Defaults to 10 seconds.
 #svn.proxy.reload_timeout = 10
 
 ############################################################
 ### SSH Support Settings                                 ###
 ############################################################
 
 ## Defines if a custom authorized_keys file should be created and written on
 ## any change user ssh keys. Setting this to false also disables posibility
 ## of adding SSH keys by users from web interface. Super admins can still
 ## manage SSH Keys.
 ssh.generate_authorized_keyfile = false
 
 ## Options for ssh, default is `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`
 # ssh.authorized_keys_ssh_opts =
 
 ## Path to the authrozied_keys file where the generate entries are placed.
 ## It is possible to have multiple key files specified in `sshd_config` e.g.
 ## AuthorizedKeysFile %h/.ssh/authorized_keys %h/.ssh/authorized_keys_rhodecode
 ssh.authorized_keys_file_path = ~/.ssh/authorized_keys_rhodecode
 
 ## Command to execute the SSH wrapper. The binary is available in the
 ## rhodecode installation directory.
 ## e.g ~/.rccontrol/community-1/profile/bin/rc-ssh-wrapper
 ssh.wrapper_cmd = ~/.rccontrol/community-1/rc-ssh-wrapper
 
 ## Allow shell when executing the ssh-wrapper command
 ssh.wrapper_cmd_allow_shell = false
 
 ## Enables logging, and detailed output send back to the client during SSH
 ## operations. Usefull for debugging, shouldn't be used in production.
 ssh.enable_debug_logging = false
 
 ## Paths to binary executable, by default they are the names, but we can
 ## override them if we want to use a custom one
 ssh.executable.hg = ~/.rccontrol/vcsserver-1/profile/bin/hg
 ssh.executable.git = ~/.rccontrol/vcsserver-1/profile/bin/git
 ssh.executable.svn = ~/.rccontrol/vcsserver-1/profile/bin/svnserve
 
 
 ## Dummy marker to add new entries after.
 ## Add any custom entries below. Please don't remove.
 custom.conf = 1
 
 
 ################################
 ### LOGGING CONFIGURATION   ####
 ################################
 [loggers]
 keys = root, sqlalchemy, beaker, celery, rhodecode, ssh_wrapper
 
 [handlers]
 keys = console, console_sql
 
 [formatters]
 keys = generic, color_formatter, color_formatter_sql
 
 #############
 ## LOGGERS ##
 #############
 [logger_root]
 level = NOTSET
 handlers = console
 
 [logger_sqlalchemy]
 level = INFO
 handlers = console_sql
 qualname = sqlalchemy.engine
 propagate = 0
 
 [logger_beaker]
 level = DEBUG
 handlers =
 qualname = beaker.container
 propagate = 1
 
 [logger_rhodecode]
 level = DEBUG
 handlers =
 qualname = rhodecode
 propagate = 1
 
 [logger_ssh_wrapper]
 level = DEBUG
 handlers =
 qualname = ssh_wrapper
 propagate = 1
 
 [logger_celery]
 level = DEBUG
 handlers =
 qualname = celery
 
 
 ##############
 ## HANDLERS ##
 ##############
 
 [handler_console]
 class = StreamHandler
 args = (sys.stderr, )
 level = INFO
 formatter = generic
 
 [handler_console_sql]
 # "level = DEBUG" logs SQL queries and results.
 # "level = INFO" logs SQL queries.
 # "level = WARN" logs neither.  (Recommended for production systems.)
 class = StreamHandler
 args = (sys.stderr, )
 level = WARN
 formatter = generic
 
 ################
 ## FORMATTERS ##
 ################
 
 [formatter_generic]
 class = rhodecode.lib.logging_formatter.ExceptionAwareFormatter
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S
 
 [formatter_color_formatter]
 class = rhodecode.lib.logging_formatter.ColorFormatter
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S
 
 [formatter_color_formatter_sql]
 class = rhodecode.lib.logging_formatter.ColorFormatterSql
 format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
 datefmt = %Y-%m-%d %H:%M:%S

docs/admin/adding-anonymous-user.rst

@@ -1,22 +1,22 b''
 .. _permissions-info-anon-ref:
 
 Anonymous Users
 ---------------
 
-By default, |RCM| provides |repo| access for registered users only. It can be
+By default, |RCE| provides |repo| access for registered users only. It can be
 configured to be **world-open** in terms of read and write permissions. This
-configuration is called "Anonymous Access" and allows |RCM| to be used as a
+configuration is called "Anonymous Access" and allows |RCE| to be used as a
 public hub where unregistered users have access to your |repos|.
 
 Anonymous access is useful for open source projects, universities,
 or if running inside a restricted internal corporate network to serve
 documents to all employees. Anonymous users get the default user permission
-settings that are applied across the whole |RCM| system.
+settings that are applied across the whole |RCE| system.
 
 To enable anonymous access to your |repos|, use the following steps:
 
-1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`.
+1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`.
 2. On the Application tab, check the :guilabel:`Allow anonymous access` box.
 3. Select :guilabel:`Save`.
 4. To set the anonymous user access permissions, which are based on the
    default user settings, see :ref:`permissions-default-ref`.

docs/admin/admin-tricks.rst

@@ -1,241 +1,241 b''
 .. _admin-tricks:
 
 One-time Admin Tasks
 --------------------
 
 * :ref:`web-analytics`
 * :ref:`admin-tricks-license`
 * :ref:`announcements`
 * :ref:`md-rst`
 * :ref:`repo-stats`
 * :ref:`server-side-merge`
 * :ref:`remap-rescan`
 * :ref:`custom-hooks`
 * :ref:`clear-repo-cache`
 * :ref:`set-repo-pub`
 * :ref:`ping`
 
 .. _web-analytics:
 
 Adding Web Analytics
 ^^^^^^^^^^^^^^^^^^^^
 
 If you wish to add a Google Analytics, or any other kind of tracker to your
 |RCE| instance you can add the necessary codes to the header or footer
 section of each instance using the following steps:
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. To add a tracking code to you instance, enter it in the header or footer
    section and select **Save**
 
 Use the example templates in the drop-down menu to set up your configuration.
 
 .. _admin-tricks-license:
 
 Licence Key Management
 ^^^^^^^^^^^^^^^^^^^^^^
 
 To manage your license key, go to
 :menuselection:`Admin --> Settings --> License`.
 On this page you can see the license key details. If you need a new license,
 or have questions about your current one, contact [e-mail]
 
 .. _announcements:
 
 Server-wide Announcements
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you need to make a server-wide announcement to all users,
 you can add a message to be displayed using the following steps:
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. To add a message that will be displayed to all users,
    select :guilabel:`Server Announcement` from the drop-down menu and
    change the ``var message = "TYPE YOUR MESSAGE HERE";`` example line.
 3. Select :guilabel:`Save`, and you will see the message once your page
    refreshes.
 
 .. image:: ../images/server-wide-announcement.png
    :alt: Server Wide Announcement
 
 .. _md-rst:
 
 
 Suppress license warnings or errors
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In case you're running on maximum allowed users, RhodeCode will display a
 warning message on pages that you're close to the license limits.
 It's often not desired to show that all the time. Here's how you can suppress
 the license messages.
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. Select :guilabel:`Flash message filtering` from the drop-down menu.
 3. Select :guilabel:`Save`, and you will no longer see the license message
    once your page refreshes.
 
 .. _admin-tricks-suppress-license-messages:
 
 
 Markdown or RST Rendering
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 |RCE| can use `Markdown`_ or `reStructured Text`_ in commit message,
 code review messages, and inline comments. To set the default to either,
 select your preference from the drop-down menu on the
 :menuselection:`Admin --> Settings --> Visual` page and select
 :guilabel:`Save settings`.
 
 .. _repo-stats:
 
 Enabling Repository Statistics
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To enable |repo| statistics, use the following steps:
 
 1. From the |RCE| interface, open
    :menuselection:`Admin --> Repositories` and select
    :guilabel:`Edit` beside the |repo| for which you wish to enable statistics.
 2. Check the :guilabel:`Enable statistics` box, and select :guilabel:`Save`
 
 .. _server-side-merge:
 
 Enabling Server-side Merging
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To enable server-side merging, use the following steps:
 
 1. From the |RCE| interface, open :menuselection:`Admin --> Settings --> VCS`
 2. Check the :guilabel:`Server-side merge` box, and select
    :guilabel:`Save Settings`
 
 If you encounter slow performance with server-side merging enabled, check the
 speed at which your server is performing actions. When server-side merging is
 enabled, the following actions occurs on the server.
 
 * A |pr| is created in the database.
 * A shadow |repo| is created as a working environment for the |pr|.
 * On display, |RCE| checks if the |pr| can be merged.
 
 To check how fast the shadow |repo| creation is occurring on your server, use
 the following steps:
 
 1. Log into your server and create a directory in your |repos| folder.
 2. Clone a |repo| that is showing slow performance and time the action.
 
 .. code-block:: bash
 
    # One option is to use the time command
    $ time hg clone SOURCE_REPO TARGET
 
 .. _remap-rescan:
 
 Remap and Rescan Repositories
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You may want to Remap and rescan the |repos| that |RCE| is managing to ensure
 the system is always up-to-date. This is useful after importing, deleting,
 or carrying out general cleaning up operations. To do this use the
 following steps:
 
 1. From the |RCE|, open
    :menuselection:`Admin --> Settings --> Remap and rescan`
 2. Click :guilabel:`Rescan Repositories`
 
 Check the additional options if needed:
 
 * :guilabel:`Destroy old data`: Useful for purging deleted repository
   information from the database.
 * :guilabel:`Invalidate cache for all repositories`: Use this to completely
   remap all |repos|. Useful when importing or migrating |repos| to ensure all
   new information is picked up.
 
 .. _custom-hooks:
 
 Adding Custom Hooks
 ^^^^^^^^^^^^^^^^^^^
 
 To add custom hooks to your instance, use the following steps:
 
 1. Open :menuselection:`Admin --> Settings --> Hooks`
 2. Add your custom hook details, you can use a file path to specify custom
    hook scripts, for example:
    ``pretxnchangegroup.example`` with value ``python:/path/to/custom_hook.py:my_func_name``
 3. Select :guilabel:`Save`
 
-Also, see the |RC| Extensions section of the :ref:`rc-tools` guide. |RC|
+Also, see the RhodeCode Extensions section of the :ref:`rc-tools` guide. RhodeCode
 Extensions can be used to add additional hooks to your instance and comes
 with a number of pre-built plugins if you chose to install them.
 
 .. _clear-repo-cache:
 
 Clearing |repo| cache
 ^^^^^^^^^^^^^^^^^^^^^
 
 If you need to clear the cache for a particular |repo|, use the following steps:
 
 1. Open :menuselection:`Admin --> Repositories` and select :guilabel:`Edit`
    beside the |repo| whose cache you wish to clear.
 2. On the |repo| settings page, go to the :guilabel:`Caches` tab and select
    :guilabel:`Invalidate repository cache`.
 
 .. _set-lang:
 
 Changing Default Language
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To change the default language of a |RCE| instance, change the language code
 in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file. To
 do this, use the following steps.
 
 1. Open the :file:`rhodecode.ini` file and set the required language code.
 
 .. code-block:: ini
 
    ## Optional Languages
    ## en(default), de, fr, it, ja, pl, pt, ru, zh
    lang = de
 
 2. Restart the |RCE| instance and check that the language has been updated.
 
 .. code-block:: bash
 
    $ rccontrol restart enterprise-2
    Instance "enterprise-2" successfully stopped.
    Instance "enterprise-2" successfully started.
 
 .. image:: ../images/language.png
 
 .. _set-repo-pub:
 
 Setting Repositories to Publish
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To automatically promote your local |repos| to public after pushing to |RCE|,
 enable the :guilabel:`Set repositories as publishing` option on the
 :menuselection:`Admin --> Settings --> VCS` page.
 
 .. note::
 
    This option is enabled by default on most |RCE| versions, but if upgrading
    from a 1.7.x version it could be disabled on upgrade due to inheriting
    older default settings.
 
 .. _ping:
 
 Pinging the |RCE| Server
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can check the IP Address of your |RCE| instance using the
 following URL: ``{instance-URL}/_admin/ping``.
 
 .. code-block:: bash
 
    $ curl https://your.rhodecode.url/_admin/ping
    pong[rce-7880] => 203.0.113.23
 
 .. _Markdown: http://daringfireball.net/projects/markdown/
 .. _reStructured Text: http://docutils.sourceforge.net/docs/index.html

docs/admin/apache-wsgi-coding.rst

@@ -1,55 +1,55 b''
 .. _apache-wsgi-ref:
 
 Apache WSGI Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-|RCM| can also be set up with Apache under ``mod_wsgi``. To configure this
+|RCE| can also be set up with Apache under ``mod_wsgi``. To configure this
 use the following steps.
 
 1. Install ``mod_wsgi`` using the following command:
    ``aptitude install libapache2-mod-wsgi``.
 2. Enable ``mod_wsgi`` using the following command: ``a2enmod wsgi``
 3. Create a ``wsgi`` dispatch script, using the following examples.
 
 .. code-block:: bash
 
    WSGIDaemonProcess pylons \
    threads=4 \
    # check the python virtual env location
    python-path=/home/web/rhodecode/pyenv/lib/python2.6/site-packages
    # Check the install location
    WSGIScriptAlias / /home/web/rhodecode/dispatch.wsgi
    WSGIPassAuthorization On
      # user=www-data group=www-data # Enable if running Apache as root
 
 .. note::
 
    Do not set ``processes=num`` in this configuration file. Running |RCE| in
    multiprocess mode with Apache is not supported.
 
 The following is an example ``wsgi`` dispatch script.
 
 .. code-block:: python
 
     import os
     os.environ["HGENCODING"] = "UTF-8"
     os.environ['PYTHON_EGG_CACHE'] = '/home/web/rhodecode/.egg-cache'
 
     # Set the current dir
     os.chdir('/home/web/rhodecode/')
 
     import site
     site.addsitedir("/home/web/rhodecode/pyenv/lib/python2.6/site-packages")
 
     from paste.deploy import loadapp
     from paste.script.util.logging_config import fileConfig
 
     fileConfig('/home/web/rhodecode/production.ini')
     application = loadapp('config:/home/web/rhodecode/production.ini')
 
 .. note::
 
    When using `mod_wsgi` the same version of |hg| must be running in your
-   system's |PY| environment and on |RCM|. To check the |RCM| version,
+   system's |PY| environment and on |RCE|. To check the |RCE| version,
    on the interface go to
    :menuselection:`Admin --> Settings --> System Info`

docs/admin/config-files-overview.rst

@@ -1,74 +1,74 b''
 .. _config-files:
 
 Configuration Files Overview
 ============================
 
 |RCE| and |RCC| have a number of different configuration files. The following
 is a brief explanation of each, and links to their associated configuration
 sections.
 
 .. rst-class:: dl-horizontal
 
     \- **rhodecode.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
         This is the main |RCE| configuration file and controls much of its
         default behaviour. It is also used to configure certain customer
         settings. Here are some of the most common reasons to make changes to
         this file.
 
         * :ref:`config-database`
         * :ref:`set-up-mail`
         * :ref:`increase-gunicorn`
         * :ref:`x-frame`
 
     \- **mapping.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/{instance-id}/mapping.ini`
 
         This file is used to control the |RCE| indexer. It comes configured
         to index your instance. To change the default configuration, see
         :ref:`advanced-indexing`.
 
     \- **vcsserver.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`
 
         The VCS Server handles the connection between your |repos| and |RCE|.
         See the :ref:`vcs-server` section for configuration options and more
         detailed information.
 
     \- **supervisord.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/supervisor/supervisord.ini`
 
         |RCC| uses Supervisor to monitor and manage installed instances of
         |RCE| and the VCS Server. |RCC| will manage this file completely,
         unless you install |RCE| in self-managed mode. For more information,
         see the :ref:`Supervisor Setup<control:supervisor-setup>` section.
 
     \- **.rccontrol.ini**
         Default location: :file:`/home/{user}/.rccontrol.ini`
 
         This file contains the instances that |RCC| starts at boot, which is all
         by default, but for more information, see
         the :ref:`Manually Start At Boot <control:set-start-boot>` section.
 
     \- **.rhoderc**
         Default location: :file:`/home/{user}/.rhoderc`
 
         This file is used by the |RCE| API when accessing an instance from a
         remote machine. The API checks this file for connection and
         authentication details. For more details, see the :ref:`config-rhoderc`
         section.
 
     \- **MANIFEST**
         Default location: :file:`/home/{user}/.rccontrol/cache/MANIFEST`
 
         |RCC| uses this file to source the latest available builds from the
-        secure |RC| download channels. The only reason to mess with this file
+        secure RhodeCode download channels. The only reason to mess with this file
         is if you need to do an offline installation,
         see the :ref:`Offline Installation<control:offline-installer-ref>`
         instructions, otherwise |RCC| will completely manage this file.
 

docs/admin/enable-debug.rst

@@ -1,112 +1,148 b''
 .. _debug-mode:
 
 Enabling Debug Mode
 -------------------
 
+Debug Mode will enable debug logging, and request tracking middleware. Debug Mode
+enabled DEBUG log-level which allows tracking various information about authentication
+failures, LDAP connection, email etc.
+
+The request tracking will add a special
+unique ID: `| req_id:00000000-0000-0000-0000-000000000000` at the end of each log line.
+The req_id is the same for each individual requests, it means that if you want to
+track particular user logs only, and exclude other concurrent ones
+simply grep by `req_id` uuid which you'll have to find for the individual request.
+
 To enable debug mode on a |RCE| instance you need to set the debug property
 in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file. To
 do this, use the following steps
 
 1. Open the file and set the ``debug`` line to ``true``
 2. Restart you instance using the ``rccontrol restart`` command,
    see the following example:
 
-You can also set the log level, the follow are the valid options;
-``debug``, ``info``, ``warning``, or ``fatal``.
-
 .. code-block:: ini
 
     [DEFAULT]
     debug = true
-    pdebug = false
 
 .. code-block:: bash
 
     # Restart your instance
     $ rccontrol restart enterprise-1
     Instance "enterprise-1" successfully stopped.
     Instance "enterprise-1" successfully started.
 
+
 Debug and Logging Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Further debugging and logging settings can also be set in the
 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
 
 In the logging section, the various packages that run with |RCE| can have
 different debug levels set. If you want to increase the logging level change
 ``level = DEBUG`` line to one of the valid options.
 
 You also need to change the log level for handlers. See the example
 ``##handler`` section below. The ``handler`` level takes the same options as
 the ``debug`` level.
 
 .. code-block:: ini
 
     ################################
     ### LOGGING CONFIGURATION   ####
     ################################
     [loggers]
-    keys = root, sqlalchemy, rhodecode, ssh_wrapper
+    keys = root, sqlalchemy, beaker, celery, rhodecode, ssh_wrapper
 
     [handlers]
     keys = console, console_sql, file, file_rotating
 
     [formatters]
     keys = generic, color_formatter, color_formatter_sql
 
     #############
     ## LOGGERS ##
     #############
     [logger_root]
     level = NOTSET
     handlers = console
 
-    [logger_routes]
+    [logger_sqlalchemy]
+    level = INFO
+    handlers = console_sql
+    qualname = sqlalchemy.engine
+    propagate = 0
+
+    [logger_beaker]
     level = DEBUG
     handlers =
-    qualname = routes.middleware
-    ## "level = DEBUG" logs the route matched and routing variables.
+    qualname = beaker.container
     propagate = 1
 
     [logger_rhodecode]
     level = DEBUG
     handlers =
     qualname = rhodecode
     propagate = 1
 
-    [logger_sqlalchemy]
-    level = INFO
-    handlers = console_sql
-    qualname = sqlalchemy.engine
-    propagate = 0
+    [logger_ssh_wrapper]
+    level = DEBUG
+    handlers =
+    qualname = ssh_wrapper
+    propagate = 1
+
+    [logger_celery]
+    level = DEBUG
+    handlers =
+    qualname = celery
 
     ##############
     ## HANDLERS ##
     ##############
 
     [handler_console]
     class = StreamHandler
-    args = (sys.stderr,)
-    level = INFO
+    args = (sys.stderr, )
+    level = DEBUG
     formatter = generic
 
     [handler_console_sql]
     class = StreamHandler
-    args = (sys.stderr,)
-    level = WARN
+    args = (sys.stderr, )
+    level = INFO
     formatter = generic
 
     [handler_file]
     class = FileHandler
-    args = ('rhodecode.log', 'a',)
+    args = ('rhodecode_debug.log', 'a',)
     level = INFO
     formatter = generic
 
     [handler_file_rotating]
     class = logging.handlers.TimedRotatingFileHandler
     # 'D', 5 - rotate every 5days
     # you can set 'h', 'midnight'
-    args = ('rhodecode.log', 'D', 5, 10,)
+    args = ('rhodecode_debug_rotated.log', 'D', 5, 10,)
     level = INFO
     formatter = generic
+
+    ################
+    ## FORMATTERS ##
+    ################
+
+    [formatter_generic]
+    class = rhodecode.lib.logging_formatter.ExceptionAwareFormatter
+    format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
+    datefmt = %Y-%m-%d %H:%M:%S
+
+    [formatter_color_formatter]
+    class = rhodecode.lib.logging_formatter.ColorFormatter
+    format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
+    datefmt = %Y-%m-%d %H:%M:%S
+
+    [formatter_color_formatter_sql]
+    class = rhodecode.lib.logging_formatter.ColorFormatterSql
+    format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
+    datefmt = %Y-%m-%d %H:%M:%S
  No newline at end of file

docs/admin/glossary.rst

@@ -1,50 +1,50 b''
 .. _glossary:
 
 Glossary
 ========
 
 .. glossary::
 
     DVCS
         Distributed Version Control System, usually referring to |git| or |hg|.
 
     Extension
         An extension extends the capabilities of, or the data available to,
         an existing software application.
 
     Full-text Search
         Indexing all files and |repos| managed by |RCE| and
         making this data searchable from the interface.
 
     Gist
         A note that can only be edited by the author and shared using its
         link within others. The sharing permissions can be set during
         its creation.
 
     Gunicorn
         A Python WSGI HTTP Server used by |RCE|.
 
     Hook
         A hook intercepts function calls, messages, or events passed between
         software components and can be used to trigger plugins, or their
         extensions.
 
     Horizontal scaling
         Adding more machines or workers into your pool of resources.
 
     Instance
-        A single installed version of one of the |RC| products. It could
+        A single installed version of one of the RhodeCode products. It could
         refer to |RCE| or the VCS server depending on the context.
 
     Plugin
         A Plugin is software that adds a specific feature to an existing
         software application.
 
     tmpfs
         Temporary file storage kept in volatile memory instead of persistent
         storage.
 
     VCS Server
         The VCS Server handles the abstraction layer between the
         supported version control systems and RhodeCode Enterprise.
 

docs/admin/indexing.rst

@@ -1,276 +1,276 b''
 .. _indexing-ref:
 
 Full-text Search
 ----------------
 
-By default |RC| is configured to use `Whoosh`_ to index |repos| and
+By default RhodeCode is configured to use `Whoosh`_ to index |repos| and
 provide full-text search.
 
 |RCE| also provides support for `Elasticsearch`_ as a backend for scalable
 search. See :ref:`enable-elasticsearch` for details.
 
 Indexing
 ^^^^^^^^
 
 To run the indexer you need to use an |authtoken| with admin rights to all
 |repos|.
 
 To index new content added, you have the option to set the indexer up in a
 number of ways, for example:
 
 * Call the indexer via a cron job. We recommend running this nightly,
   unless you need everything indexed immediately.
 * Set the indexer to infinitely loop and reindex as soon as it has run its
   cycle.
 * Hook the indexer up with your CI server to reindex after each push.
 
 The indexer works by indexing new commits added since the last run. If you
 wish to build a brand new index from scratch each time,
 use the ``force`` option in the configuration file.
 
 .. important::
 
    You need to have |RCT| installed, see :ref:`install-tools`. Since |RCE|
    3.5.0 they are installed by default.
 
 To set up indexing, use the following steps:
 
 1. :ref:`config-rhoderc`, if running tools remotely.
 2. :ref:`run-index`
 3. :ref:`set-index`
 4. :ref:`advanced-indexing`
 
 .. _config-rhoderc:
 
 Configure the ``.rhoderc`` File
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 |RCT| uses the :file:`/home/{user}/.rhoderc` file for connection details
-to |RCM| instances. If this file is not automatically created,
+to |RCE| instances. If this file is not automatically created,
 you can configure it using the following example. You need to configure the
 details for each instance you want to index.
 
 .. code-block:: bash
 
     # Check the instance details
     # of the instance you want to index
     $ rccontrol status
 
      - NAME: enterprise-1
      - STATUS: RUNNING
      - TYPE: Momentum
      - VERSION: 1.5.0
      - URL: http://127.0.0.1:10000
 
-To get your API Token, on the |RCM| interface go to
+To get your API Token, on the |RCE| interface go to
 :menuselection:`username --> My Account --> Auth tokens`
 
 .. code-block:: ini
 
     # Configure .rhoderc with matching details
     # This allows the indexer to connect to the instance
     [instance:enterprise-1]
     api_host = http://127.0.0.1:10000
     api_key = <auth token goes here>
     repo_dir = /home/<username>/repos
 
 .. _run-index:
 
 Run the Indexer
 ^^^^^^^^^^^^^^^
 
 Run the indexer using the following command, and specify the instance you
 want to index:
 
 .. code-block:: bash
 
    # From inside a virtualevv
    (venv)$ rhodecode-index --instance-name=enterprise-1
 
    # Using default installation
    $ /home/user/.rccontrol/enterprise-1/profile/bin/rhodecode-index \
        --instance-name=enterprise-1
 
    # Using a custom mapping file
    $ /home/user/.rccontrol/enterprise-1/profile/bin/rhodecode-index \
        --instance-name=enterprise-1 \
        --mapping=/home/user/.rccontrol/enterprise-1/mapping.ini
 
 .. note::
 
    In case of often indexing the index may become fragmented. Most often a result of that
    is error about `too many open files`. To fix this indexer needs to be executed with
    --optimize flag. E.g `rhodecode-index --instance-name=enterprise-1 --optimize`
    This should be executed regularly, once a week is recommended.
 
 
 .. _set-index:
 
 Schedule the Indexer
 ^^^^^^^^^^^^^^^^^^^^
 
 To schedule the indexer, configure the crontab file to run the indexer inside
 your |RCT| virtualenv using the following steps.
 
 1. Open the crontab file, using ``crontab -e``.
 2. Add the indexer to the crontab, and schedule it to run as regularly as you
    wish.
 3. Save the file.
 
 .. code-block:: bash
 
     $ crontab -e
 
     # The virtualenv can be called using its full path, so for example you can
     # put this example into the crontab
 
     # Run the indexer daily at 4am using the default mapping settings
     * 4 * * * /home/ubuntu/.virtualenv/rhodecode-venv/bin/rhodecode-index \
     --instance-name=enterprise-1
 
     # Run the indexer every Sunday at 3am using default mapping
     * 3 * * 0 /home/ubuntu/.virtualenv/rhodecode-venv/bin/rhodecode-index \
     --instance-name=enterprise-1
 
     # Run the indexer every 15 minutes
     # using a specially configured mapping file
     */15 * * * * ~/.rccontrol/enterprise-4/profile/bin/rhodecode-index \
        --instance-name=enterprise-4 \
        --mapping=/home/user/.rccontrol/enterprise-4/mapping.ini
 
 .. _advanced-indexing:
 
 Advanced Indexing
 ^^^^^^^^^^^^^^^^^
 
 |RCT| indexes based on the :file:`mapping.ini` file. To configure your index,
 you can specify different options in this file. The default location is:
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/mapping.ini`, using default
   |RCT|.
 * :file:`~/venv/lib/python2.7/site-packages/rhodecode_tools/templates/mapping.ini`,
   when using ``virtualenv``.
 
 .. note::
 
     If you need to create the :file:`mapping.ini` file, use the |RCT|
     ``rhodecode-index --create-mapping path/to/file`` API call. For details,
     see the :ref:`tools-cli` section.
 
 The indexer runs in a random order to prevent a failing |repo| from stopping
 a build. To configure different indexing scenarios, set the following options
 inside the :file:`mapping.ini` and specify the altered file using the
 ``--mapping`` option.
 
 * ``index_files`` : Index the specified file types.
 * ``skip_files`` : Do not index the specified file types.
 * ``index_files_content`` : Index the content of the specified file types.
 * ``skip_files_content`` : Do not index the content of the specified files.
 * ``force`` : Create a fresh index on each run.
 * ``max_filesize`` : Files larger than the set size will not be indexed.
 * ``commit_parse_limit`` : Set the batch size when indexing commit messages.
   Set to a lower number to lessen memory load.
 * ``repo_limit`` : Set the maximum number or |repos| indexed per run.
 * ``[INCLUDE]`` : Set |repos| you want indexed. This takes precedent over
   ``[EXCLUDE]``.
 * ``[EXCLUDE]`` : Set |repos| you do not want indexed. Exclude can be used to
   not index branches, forks, or log |repos|.
 
 At the end of the file you can specify conditions for specific |repos| that
 will override the default values. To configure your indexer,
 use the following example :file:`mapping.ini` file.
 
 .. code-block:: ini
 
     [__DEFAULT__]
     # default patterns for indexing files and content of files.
     # Binary files are skipped by default.
 
     # Index python and markdown files
     index_files = *.py, *.md
 
     # Do not index these file types
     skip_files = *.svg, *.log, *.dump, *.txt
 
     # Index both file types and their content
     index_files_content = *.cpp, *.ini, *.py
 
     # Index file names, but not file content
     skip_files_content = *.svg,
 
     # Force rebuilding an index from scratch. Each repository will be rebuild
     # from scratch with a global flag. Use local flag to rebuild single repos
     force = false
 
     # Do not index files larger than 385KB
     max_filesize = 385KB
 
     # Limit commit indexing to 500 per batch
     commit_parse_limit = 500
 
     # Limit each index run to 25 repos
     repo_limit = 25
 
     # __INCLUDE__ is more important that __EXCLUDE__.
 
     [__INCLUDE__]
     # Include all repos with these names
 
     docs/* = 1
     lib/* = 1
 
     [__EXCLUDE__]
     # Do not include the following repo in index
 
     dev-docs/* = 1
     legacy-repos/* = 1
     *-dev/* = 1
 
     # Each repo that needs special indexing is a separate section below.
     # In each section set the options to override the global configuration
     # parameters above.
     # If special settings are not configured, the global configuration values
     # above are inherited. If no special repositories are
     # defined here RhodeCode will use the API to ask for all repositories
 
     # For this repo use different settings
     [special-repo]
     commit_parse_limit = 20,
     skip_files = *.idea, *.xml,
 
     # For another repo use different settings
     [another-special-repo]
     index_files = *,
     max_filesize = 800MB
     commit_parse_limit = 20000
 
 .. _enable-elasticsearch:
 
 Enabling Elasticsearch
 ^^^^^^^^^^^^^^^^^^^^^^
 
 1. Open the :file:`rhodecode.ini` file for the instance you wish to edit. The
    default location is
    :file:`home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 2. Find the search configuration section:
 
 .. code-block:: ini
 
     ###################################
     ## SEARCH INDEXING CONFIGURATION ##
     ###################################
 
     search.module = rhodecode.lib.index.whoosh
     search.location = %(here)s/data/index
 
 and change it to:
 
 .. code-block:: ini
 
     search.module = rc_elasticsearch
     search.location = http://localhost:9200/
 
 where ``search.location`` points to the elasticsearch server.
 
 .. _Whoosh: https://pypi.python.org/pypi/Whoosh/
 .. _Elasticsearch: https://www.elastic.co/
  No newline at end of file

docs/admin/public-access.rst

@@ -1,12 +1,12 b''
 .. _public-access:
 
 Public Access
 -------------
 
-By default |RCM| allows users to read all **public** |repos|. User
+By default |RCE| allows users to read all **public** |repos|. User
 permissions and |repo| access can be configured explicitly,
 and those permissions will override any default settings. The default
 settings can be found under the following section:
 
 * :menuselection:`Admin --> Permissions --> Object`
 * :menuselection:`Admin --> Permissions --> Global`

docs/admin/repo-extra-fields.rst

@@ -1,77 +1,77 b''
 .. _repo-xtra:
 
 Repository Extra Fields
 =======================
 
 Extra fields attached to a |repo| allow you to configure additional fields for
 each repository. This allows storing custom data per-repository.
 
 It can be used in :ref:`integrations-webhook` or in |RCX|.
-To install and read more about |RCX|, see the :ref:`install-rcx` section.
+To read more about |RCX|, see the :ref:`integrations-rcextensions` section.
 
 
 Enabling Extra Fields
 ---------------------
 
 To enable extra fields on |repos|, use the following steps:
 
 1. Go to the :menuselection:`Admin --> Settings --> Visual` page.
 2. Check the :guilabel:`Use repository extra fields` box.
 3. Save your changes.
 
 
 Configuring Extra Fields
 ------------------------
 
 To configure extra fields per repository, use the following steps:
 
 1. Go to :menuselection:`Admin --> Repositories` and select :guilabel:`Edit`
    beside the |repo| to which you wish to add extra fields.
 2. On the |repo| settings page, select the :guilabel:`Extra fields` tab.
 
 .. image:: ../images/extra-repo-fields.png
 
 The most important is the `New field key` variable which under the value will
 be stored. It needs to be unique for each repository. The label and description
 will be generated in repository settings where users can actually save some
 values inside generated extra fields.
 
 
 Example Usage in extensions
 ---------------------------
 
 To use the extra fields in an extension, see the example below. For more
 information and examples, see the :ref:`extensions-hooks-ref` section.
 
 .. code-block:: python
 
     call = load_extension('http_notify.py')
     if call:
         url = 'http://default.url' # <url for post data>
 
         # possibly extract the URL from extra fields
         call = load_extension('extra_fields.py')
         if call:
             repo_extra_fields = call(**kwargs)
             # now update if we have extra fields, they have precedence
             # this way users can store any configuration inside the database per
             # repo
             for key, data in repo_extra_fields.items():
                 kwargs[key] = data['field_value']
 
         # an endpoint url data will be sent to, fetched from extra fields
         # if exists, or fallback to default
         kwargs['URL'] = kwargs.pop('webhook_url', None) or url
 
         # fetch pushed commits, from commit_ids list
         call = load_extension('extract_commits.py')
         extracted_commits = {}
         if call:
             extracted_commits = call(**kwargs)
             # store the commits for the next call chain
         kwargs['COMMITS'] = extracted_commits
 
         # set additional keys and values to be sent via POST to given URL
         kwargs['caller_type'] = 'rhodecode'
         kwargs['date'] = time.time() # import time before
         call(**kwargs)

docs/admin/repo-hooks.rst

@@ -1,56 +1,51 b''
 .. _repo-hooks:
 
 |RCE| Repository Hooks
 ======================
 
 |RCE| installs hooks inside each of the |repos| that it manages. These
 hooks enable users to execute custom actions based on certain events.
 This is the complete list of |repos| hooks and the events which trigger them:
 
 .. rst-class:: dl-horizontal
 
     \--CREATE_REPO_HOOK
         Any time a |repo| is created.
 
     \--CREATE_REPO_GROUP_HOOK
         Any time a |repo| group is created.
 
     \--CREATE_USER_HOOK
         Any time a user is created.
 
     \--DELETE_REPO_HOOK
         Any time a |repo| is created.
 
     \--DELETE_USER_HOOK
         Any time a user is deleted.
 
     \--PRE_CREATE_USER_HOOK
         Any time a user is created but before the action is executed by |RCE|.
 
     \--PRE_PULL
         Any pull from a |repo| but before the action is executed by |RCE|.
 
     \--PRE_PUSH
         Any push to a |repo| but before the action is executed by |RCE|.
 
     \--POST_PUSH
         After any push to a |repo|.
 
     \--PUSH_HOOK
         Any push to a |repo|, including editing tags or branches.
         Commits via API actions that update references are also counted.
 
     \--PULL_HOOK
         Any pull from a Repository.
 
 Using Repository Hooks
 ----------------------
 
-To use these hooks you need to install |RCX|. For more information, see the
-:ref:`install-rcx` section.
+To use these hooks you need to setup |RCX|. For more information, see the
+:ref:`integrations-rcextensions` section.
 
-Creating Extensions
--------------------
-
-To create your own extensions using these hooks, see the :ref:`dev-plug`
-section.

docs/admin/setting-default-permissions.rst

@@ -1,69 +1,69 b''
 .. _permissions-default-ref:
 
 Setting Default Permissions
 ---------------------------
 
-Default permissions allow you to configure |RCM| so that when a new |repo|, user group,
+Default permissions allow you to configure |RCE| so that when a new |repo|, user group,
 or user is created their permissions are already defined. To set default permissions you need administrator
 privileges. See the following sections for setting up your permissions system:
 
 * :ref:`user-default-ref`
 * :ref:`user-group-default-ref`
 * :ref:`repo-default-ref`
 * :ref:`repo-group-default-ref`
 
 .. _user-default-ref:
 
 Setting User defaults
 ^^^^^^^^^^^^^^^^^^^^^
 
 To set default user permissions, use the following steps.
 
-1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`
+1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`
 2. Select the :guilabel:`Global` tab from the left-hand menu. The permissions
    set on this screen apply to users and user-groups across the whole instance.
 3. Save your changes
 
 .. _user-group-default-ref:
 
 Setting User Group defaults
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To set default user group permissions, use the following steps.
 
-1. From the |RCM| interface, select :menuselection:`Admin --> User groups`
+1. From the |RCE| interface, select :menuselection:`Admin --> User groups`
 2. Select :guilabel:`Permissions`, and configure the default user
    permissions. All users will get these permissions unless
    individually set.
 3. Select :guilabel:`Global permissions`, and if you wish to configure
    non-standard behaviour, uncheck the
    :guilabel:`inherit from default settings` box and configure the desired
    permissions
 4. Save your changes
 
 .. _repo-default-ref:
 
 Setting Repository defaults
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To set default |repo| permissions, use the following steps.
 
-1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`
+1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`
 2. Select the :guilabel:`Object` tab from the left-hand menu and set the
    |perm| permissions
 3. Save your changes
 
 .. _repo-group-default-ref:
 
 Setting Repository Group defaults
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To set default Repository Group permissions, use the following steps.
 
-1. From the |RCM| interface, select :menuselection:`Admin --> Repository Groups`
+1. From the |RCE| interface, select :menuselection:`Admin --> Repository Groups`
 2. Select :guilabel:`Edit` beside the |repo| group you wish to configure
 3. On the left-hand pane select :guilabel:`Permissions`
 4. Set the default permissions for all |repos| created in this group
 5. Save your changes
 
 .. |perm| replace:: :guilabel:`None, Read, Write, or Admin`

docs/admin/setting-repo-perms.rst

@@ -1,26 +1,26 b''
 .. _permissions-info-add-group-ref:
 
 Repository Administration
 =========================
 
-Repository permissions in |RCM| can be managed in a number of different ways.
+Repository permissions in |RCE| can be managed in a number of different ways.
 This overview should give you an insight into how you could adopt particular
 settings for your needs:
 
 * Global |repo| permissions: This allows you to set the default permissions
-  for each new |repo| created within |RCM|, see :ref:`repo-default-ref`. All
+  for each new |repo| created within |RCE|, see :ref:`repo-default-ref`. All
   |repos| created will inherit these permissions unless explicitly configured.
 * Individual |repo| permissions: To set individual |repo| permissions,
   see :ref:`set-repo-perms`.
 * Repository Group permissions: This allows you to define the permissions for
   a group, and all |repos| created within that group will inherit the same
   permissions.
 
 .. toctree::
 
     repo-perm-steps
     repo-extra-fields
     repo-hooks
     repo-issue-tracker
     repo-vcs
 

docs/admin/svn-http.rst

@@ -1,200 +1,207 b''
 .. _svn-http:
 
 |svn| With Write Over HTTP
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To use |svn| with read/write support over the |svn| HTTP protocol, you have to
 configure the HTTP |svn| backend.
 
 Prerequisites
 =============
 
 - Enable HTTP support inside the admin VCS settings on your |RCE| instance
 - You need to install the following tools on the machine that is running an
   instance of |RCE|:
   ``Apache HTTP Server`` and ``mod_dav_svn``.
 
 
 .. tip::
 
    We recommend using Wandisco repositories which provide latest SVN versions
-   for most platforms.
+   for most platforms. If you skip this version you'll have to ensure the Client version
+   is compatible with installed SVN version which might differ depending on the operating system.
    Here is an example how to add the Wandisco repositories for Ubuntu.
 
     .. code-block:: bash
 
-        $ sudo sh -c 'echo "deb http://opensource.wandisco.com/ubuntu `lsb_release -cs` svn19" >> /etc/apt/sources.list.d/subversion19.list'
-        $ sudo wget -q http://opensource.wandisco.com/wandisco-debian.gpg -O- | sudo apt-key add -
+        $ sudo sh -c 'echo "deb http://opensource.wandisco.com/ubuntu `lsb_release -cs` svn110" >> /etc/apt/sources.list.d/subversion110.list'
+        $ sudo wget -q http://opensource.wandisco.com/wandisco-debian-new.gpg -O- | sudo apt-key add -
         $ sudo apt-get update
 
     Here is an example how to add the Wandisco repositories for Centos/Redhat. Using
     a yum config
 
     .. code-block:: bash
 
         [wandisco-Git]
         name=CentOS-6 - Wandisco Git
         baseurl=http://opensource.wandisco.com/centos/6/git/$basearch/
         enabled=1
         gpgcheck=1
         gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco
 
 
 
 Example installation of required components for Ubuntu platform:
 
 .. code-block:: bash
 
     $ sudo apt-get install apache2
-    $ sudo apt-get install libapache2-mod-svn
+    $ sudo apt-get install libapache2-svn
 
 Once installed you need to enable ``dav_svn`` on Ubuntu:
 
 .. code-block:: bash
 
     $ sudo a2enmod dav_svn
     $ sudo a2enmod headers
     $ sudo a2enmod authn_anon
 
 
 Example installation of required components for RedHat/CentOS platform:
 
 .. code-block:: bash
 
     $ sudo yum install httpd
     $ sudo yum install subversion mod_dav_svn
 
 
 Once installed you need to enable ``dav_svn`` on RedHat/CentOS:
 
 .. code-block:: bash
 
     sudo vi /etc/httpd/conf.modules.d/10-subversion.conf
     ## The file should read:
 
     LoadModule dav_svn_module     modules/mod_dav_svn.so
     LoadModule headers_module     modules/mod_headers.so
     LoadModule authn_anon_module  modules/mod_authn_anon.so
 
+.. tip::
+
+   To check the installed mod_dav_svn module version, you can use such command.
+
+   `strings /usr/lib/apache2/modules/mod_dav_svn.so | grep 'Powered by'`
+
 
 Configuring Apache Setup
 ========================
 
 .. tip::
 
    It is recommended to run Apache on a port other than 80, due to possible
    conflicts with other HTTP servers like nginx. To do this, set the
    ``Listen`` parameter in the ``/etc/apache2/ports.conf`` file, for example
    ``Listen 8090``.
 
 
 .. warning::
 
    Make sure your Apache instance which runs the mod_dav_svn module is
    only accessible by |RCE|. Otherwise everyone is able to browse
    the repositories or run subversion operations (checkout/commit/etc.).
 
 It is also recommended to run apache as the same user as |RCE|, otherwise
 permission issues could occur. To do this edit the ``/etc/apache2/envvars``
 
    .. code-block:: apache
 
       export APACHE_RUN_USER=rhodecode
       export APACHE_RUN_GROUP=rhodecode
 
 1. To configure Apache, create and edit a virtual hosts file, for example
    :file:`/etc/apache2/sites-enabled/default.conf`. Below is an example
    how to use one with auto-generated config ```mod_dav_svn.conf```
    from configured |RCE| instance.
 
 .. code-block:: apache
 
     <VirtualHost *:8090>
         ServerAdmin rhodecode-admin@localhost
         DocumentRoot /var/www/html
         ErrorLog ${'${APACHE_LOG_DIR}'}/error.log
         CustomLog ${'${APACHE_LOG_DIR}'}/access.log combined
         LogLevel info
         # allows custom host names, prevents 400 errors on checkout
         HttpProtocolOptions Unsafe
         Include /home/user/.rccontrol/enterprise-1/mod_dav_svn.conf
     </VirtualHost>
 
 
 2. Go to the :menuselection:`Admin --> Settings --> VCS` page, and
    enable :guilabel:`Proxy Subversion HTTP requests`, and specify the
    :guilabel:`Subversion HTTP Server URL`.
 
 3. Open the |RCE| configuration file,
    :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
 4. Add the following configuration option in the ``[app:main]``
    section if you don't have it yet.
 
    This enables mapping of the created |RCE| repo groups into special
    |svn| paths. Each time a new repository group is created, the system will
    update the template file and create new mapping. Apache web server needs to
    be reloaded to pick up the changes on this file.
    To do this, simply configure `svn.proxy.reload_cmd` inside the .ini file.
    Example configuration:
 
 
 .. code-block:: ini
 
     ############################################################
     ### Subversion proxy support (mod_dav_svn)               ###
     ### Maps RhodeCode repo groups into SVN paths for Apache ###
     ############################################################
     ## Enable or disable the config file generation.
     svn.proxy.generate_config = true
     ## Generate config file with `SVNListParentPath` set to `On`.
     svn.proxy.list_parent_path = true
     ## Set location and file name of generated config file.
     svn.proxy.config_file_path = %(here)s/mod_dav_svn.conf
     ## Used as a prefix to the <Location> block in the generated config file.
     ## In most cases it should be set to `/`.
     svn.proxy.location_root = /
     ## Command to reload the mod dav svn configuration on change.
     ## Example: `/etc/init.d/apache2 reload`
     svn.proxy.reload_cmd = /etc/init.d/apache2 reload
     ## If the timeout expires before the reload command finishes, the command will
     ## be killed. Setting it to zero means no timeout. Defaults to 10 seconds.
     #svn.proxy.reload_timeout = 10
 
 
 This would create a special template file called ```mod_dav_svn.conf```. We
 used that file path in the apache config above inside the Include statement.
 It's also possible to manually generate the config from the
 :menuselection:`Admin --> Settings --> VCS` page by clicking a
 `Generate Apache Config` button.
 
 5. Now only things left is to enable svn support, and generate the initial
    configuration.
 
    - Select `Proxy subversion HTTP requests` checkbox
    - Enter http://localhost:8090 into `Subversion HTTP Server URL`
    - Click the `Generate Apache Config` button.
 
 This config will be automatically re-generated once an user-groups is added
 to properly map the additional paths generated.
 
 
 
 Using |svn|
 ===========
 
 Once |svn| has been enabled on your instance, you can use it with the
 following examples. For more |svn| information, see the `Subversion Red Book`_
 
 .. code-block:: bash
 
     # To clone a repository
     svn checkout http://my-svn-server.example.com/my-svn-repo
 
     # svn commit
     svn commit
 
 
 .. _Subversion Red Book: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn
 
 .. _Ask Ubuntu: http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue
  No newline at end of file

docs/admin/system-overview.rst

@@ -1,171 +1,171 b''
 .. _system-overview-ref:
 
 System Overview
 ===============
 
 Latest Version
 --------------
 
 * |release| on Unix and Windows systems.
 
 System Architecture
 -------------------
 
 The following diagram shows a typical production architecture.
 
 .. image:: ../images/architecture-diagram.png
   :align: center
 
 Supported Operating Systems
 ---------------------------
 
 Linux
 ^^^^^
 
 * Ubuntu 14.04
 * CentOS 6.2 and 7
 * Debian 7.8
 * RedHat Fedora
 * Arch Linux
 * SUSE Linux
 
 Windows
 ^^^^^^^
 
 * Windows Vista Ultimate 64bit
 * Windows 7 Ultimate 64bit
 * Windows 8 Professional 64bit
 * Windows 8.1 Enterprise 64bit
 * Windows Server 2008 64bit
 * Windows Server 2008-R2 64bit
 * Windows Server 2012 64bit
 
 Supported Databases
 -------------------
 
 * SQLite
 * MySQL
 * MariaDB
 * PostgreSQL
 
 Supported Browsers
 ------------------
 
 * Chrome
 * Safari
 * Firefox
 * Internet Explorer 10 & 11
 
 System Requirements
 -------------------
 
-|RCM| performs best on machines with ultra-fast hard disks. Generally disk
+|RCE| performs best on machines with ultra-fast hard disks. Generally disk
 performance is more important than CPU performance. In a corporate production
 environment handling 1000s of users and |repos| you should deploy on a 12+
 core 64GB RAM server. In short, the more RAM the better.
 
 
 For example:
 
  - for team of 1 - 5 active users you can run on 1GB RAM machine with 1CPU
- - above 250 active users, |RCM| needs at least 8GB of memory.
+ - above 250 active users, |RCE| needs at least 8GB of memory.
    Number of CPUs is less important, but recommended to have at least 2-3 CPUs
 
 
 .. _config-rce-files:
 
 Configuration Files
 -------------------
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 * :file:`/home/{user}/.rccontrol/{instance-id}/mapping.ini`
 * :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`
 * :file:`/home/{user}/.rccontrol/supervisor/supervisord.ini`
 * :file:`/home/{user}/.rccontrol.ini`
 * :file:`/home/{user}/.rhoderc`
 * :file:`/home/{user}/.rccontrol/cache/MANIFEST`
 
 For more information, see the :ref:`config-files` section.
 
 Log Files
 ---------
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/enterprise.log`
 * :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.log`
 * :file:`/home/{user}/.rccontrol/supervisor/supervisord.log`
 * :file:`/tmp/rccontrol.log`
 * :file:`/tmp/rhodecode_tools.log`
 
 Storage Files
 -------------
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/data/index/{index-file.toc}`
 * :file:`/home/{user}/repos/.rc_gist_store`
 * :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.db`
 * :file:`/opt/rhodecode/store/{unique-hash}`
 
 Default Repositories Location
 -----------------------------
 
 * :file:`/home/{user}/repos`
 
 Connection Methods
 ------------------
 
 * HTTPS
 * SSH
-* |RCM| API
+* |RCE| API
 
 Internationalization Support
 ----------------------------
 
 Currently available in the following languages, see `Transifex`_ for the
 latest details. If you want a new language added, please contact us. To
 configure your language settings, see the :ref:`set-lang` section.
 
 .. hlist::
 
   * Belorussian
   * Chinese
   * French
   * German
   * Italian
   * Japanese
   * Portuguese
   * Polish
   * Russian
   * Spanish
 
 Licencing Information
 ---------------------
 
 * See licencing information `here`_
 
 Peer-to-peer Failover Support
 -----------------------------
 
 * Yes
 
 Additional Binaries
 -------------------
 
 * Yes, see :ref:`rhodecode-nix-ref` for full details.
 
 Remote Connectivity
 -------------------
 
 * Available
 
 Executable Files
 ----------------
 
 Windows: :file:`RhodeCode-installer-{version}.exe`
 
 Deprecated Support
 ------------------
 
 - Internet Explorer 8 support deprecated since version 3.7.0.
 - Internet Explorer 9 support deprecated since version 3.8.0.
 
 .. _here: https://rhodecode.com/licenses/
 .. _Transifex: https://www.transifex.com/projects/p/RhodeCode/

docs/admin/tuning-scale-horizontally-cluster.rst

@@ -1,395 +1,395 b''
 .. _scale-horizontal-cluster:
 
 
 Scale Horizontally / RhodeCode Cluster
 --------------------------------------
 
 |RCE| is built in a way it support horizontal scaling across multiple machines.
 There are three main pre-requisites for that:
 
 - Shared storage that each machine can access. Using NFS or other shared storage system.
 - Shared DB connection across machines. Using `MySQL`/`PostgreSQL` that each node can access.
 - |RCE| user sessions and caches need to use a shared storage (e.g `Redis`_/`Memcached`)
 
 
 Horizontal scaling means adding more machines or workers into your pool of
 resources. Horizontally scaling |RCE| gives a huge performance increase,
 especially under large traffic scenarios with a high number of requests.
 This is very beneficial when |RCE| is serving many users simultaneously,
 or if continuous integration servers are automatically pulling and pushing code.
 It also adds High-Availability to your running system.
 
 
 Cluster Overview
 ^^^^^^^^^^^^^^^^
 
 Below we'll present a configuration example that will use two separate nodes to serve
 |RCE| in a load-balanced environment. The 3rd node will act as a shared storage/cache
 and handle load-balancing. In addition 3rd node will be used as shared database instance.
 
 This setup can be used both in Docker based configuration or with individual
 physical/virtual machines. Using the 3rd node for Storage/Redis/PostgreSQL/Nginx is
 optional. All those components can be installed on one of the two nodes used for |RCE|.
 We'll use following naming for our nodes:
 
  - `rc-node-1` (NFS, DB, Cache node)
  - `rc-node-2` (Worker node1)
  - `rc-node-3` (Worker node2)
 
 Our shares NFS storage in the example is located on `/home/rcdev/storage` and
 it's RW accessible on **each** node.
 
 In this example we used certain recommended components, however many
 of those can be replaced by other, in case your organization already uses them, for example:
 
 - `MySQL`/`PostgreSQL`: Aren't replaceable and are the two only supported databases.
 - `Nginx`_ on `rc-node-1` can be replaced by: `Hardware Load Balancer (F5)`, `Apache`_, `HA-Proxy` etc.
 - `Nginx`_ on rc-node-2/3 acts as a reverse proxy and can be replaced by other HTTP server
   acting as reverse proxy such as `Apache`_.
 - `Redis`_ on `rc-node-1` can be replaced by: `Memcached`
 
 
 Here's an overview what components should be installed/setup on each server in our example:
 
 - **rc-node-1**:
 
  - main storage acting as NFS host.
  - `nginx` acting as a load-balancer.
  - `postgresql-server` used for database and sessions.
  - `redis-server` used for storing shared caches.
  - optionally `rabbitmq-server` for `Celery` if used.
  - optionally if `Celery` is used Enterprise/Community instance + VCSServer.
  - optionally mailserver that can be shared by other instances.
  - optionally channelstream server to handle live communication for all instances.
 
 
 - **rc-node-2/3**:
 
  - `nginx` acting as a reverse proxy to handle requests to |RCE|.
  - 1x RhodeCode Enterprise/Community instance.
  - 1x VCSServer instance.
  - optionally for testing connection: postgresql-client, redis-client (redis-tools).
 
 
 Before we start here are few assumptions that should be fulfilled:
 
 - make sure each node can access each other.
 - make sure `Redis`_/`MySQL`/`PostgreSQL`/`RabbitMQ`_ are running on `rc-node-1`
 - make sure both `rc-node-2`/`3` can access NFS storage with RW access
 - make sure rc-node-2/3 can access `Redis`_/`PostgreSQL`, `MySQL` database on `rc-node-1`.
 - make sure `Redis`_/Database/`RabbitMQ`_ are password protected and accessible only from rc-node-2/3.
 
 
 
 Setup rc-node-2/3
 ^^^^^^^^^^^^^^^^^
 
 Initially before `rc-node-1` we'll configure both nodes 2 and 3 to operate as standalone
 nodes with their own hostnames. Use a default installation settings, and use
 the default local addresses (127.0.0.1) to configure VCSServer and Community/Enterprise instances.
 All external connectivity will be handled by the reverse proxy (`Nginx`_ in our example).
 
 This way we can ensure each individual host works,
 accepts connections, or do some operations explicitly on chosen node.
 
 In addition this would allow use to explicitly direct certain traffic to a node, e.g
 CI server will only call directly `rc-node-3`. This should be done similar to normal
 installation so check out `Nginx`_/`Apache`_ configuration example to configure each host.
 Each one should already connect to shared database during installation.
 
 
 1) Assuming our final url will be http://rc-node-1, Configure `instances_id`, `app.base_url`
 
 a) On **rc-node-2** find the following settings and edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
 .. code-block:: ini
 
     ## required format is: *NAME-
     instance_id = *rc-node-2-
     app.base_url = http://rc-node-1
 
 
 b) On **rc-node-3** find the following settings and edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
 .. code-block:: ini
 
     ## required format is: *NAME-
     instance_id = *rc-node-3-
     app.base_url = http://rc-node-1
 
 
 
 2) Configure `User Session` to use a shared database. Example config that should be
    changed on both **rc-node-2** and **rc-node-3** .
    Edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
 .. code-block:: ini
 
     ####################################
     ###       BEAKER SESSION        ####
     ####################################
 
     ## Disable the default `file` sessions
     #beaker.session.type = file
     #beaker.session.data_dir = %(here)s/data/sessions
 
     ## use shared db based session, fast, and allows easy management over logged in users
     beaker.session.type = ext:database
     beaker.session.table_name = db_session
     # use our rc-node-1 here
     beaker.session.sa.url = postgresql://postgres:qweqwe@rc-node-1/rhodecode
     beaker.session.sa.pool_recycle = 3600
     beaker.session.sa.echo = false
 
 In addition make sure both instances use the same `session.secret` so users have
 persistent sessions across nodes. Please generate other one then in this example.
 
 .. code-block:: ini
 
-    # use an unique generated long string
+    # use a unique generated long string
     beaker.session.secret = 70e116cae2274656ba7265fd860aebbd
 
 3) Configure stored cached/archive cache to our shared NFS `rc-node-1`
 
 .. code-block:: ini
 
     # note the `_` prefix that allows using a directory without
     # remap and rescan checking for vcs inside it.
     cache_dir = /home/rcdev/storage/_cache_dir/data
     # note archive cache dir is disabled by default, however if you enable
     # it also needs to be shared
     #archive_cache_dir = /home/rcdev/storage/_tarball_cache_dir
 
 
 4) Use shared exception store. Example config that should be
    changed on both **rc-node-2** and **rc-node-3**, and also for VCSServer.
    Edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` and
    :file:`/home/{user}/.rccontrol/{vcsserver-instance-id}/vcsserver.ini`
    and add/change following setting.
 
 .. code-block:: ini
 
     exception_tracker.store_path = /home/rcdev/storage/_exception_store_data
 
 
 5) Change cache backends to use `Redis`_ based caches. Below full example config
    that replaces default file-based cache to shared `Redis`_ with Distributed Lock.
 
 
 .. code-block:: ini
 
     #####################################
     ###         DOGPILE CACHE        ####
     #####################################
 
     ## `cache_perms` cache settings for permission tree, auth TTL.
     #rc_cache.cache_perms.backend = dogpile.cache.rc.file_namespace
     #rc_cache.cache_perms.expiration_time = 300
 
     ## alternative `cache_perms` redis backend with distributed lock
     rc_cache.cache_perms.backend = dogpile.cache.rc.redis
     rc_cache.cache_perms.expiration_time = 300
     ## redis_expiration_time needs to be greater then expiration_time
     rc_cache.cache_perms.arguments.redis_expiration_time = 7200
     rc_cache.cache_perms.arguments.socket_timeout = 30
     rc_cache.cache_perms.arguments.host = rc-node-1
     rc_cache.cache_perms.arguments.password = qweqwe
     rc_cache.cache_perms.arguments.port = 6379
     rc_cache.cache_perms.arguments.db = 0
     rc_cache.cache_perms.arguments.distributed_lock = true
 
     ## `cache_repo` cache settings for FileTree, Readme, RSS FEEDS
     #rc_cache.cache_repo.backend = dogpile.cache.rc.file_namespace
     #rc_cache.cache_repo.expiration_time = 2592000
 
     ## alternative `cache_repo` redis backend with distributed lock
     rc_cache.cache_repo.backend = dogpile.cache.rc.redis
     rc_cache.cache_repo.expiration_time = 2592000
     ## redis_expiration_time needs to be greater then expiration_time
     rc_cache.cache_repo.arguments.redis_expiration_time = 2678400
     rc_cache.cache_repo.arguments.socket_timeout = 30
     rc_cache.cache_repo.arguments.host = rc-node-1
     rc_cache.cache_repo.arguments.password = qweqwe
     rc_cache.cache_repo.arguments.port = 6379
     rc_cache.cache_repo.arguments.db = 1
     rc_cache.cache_repo.arguments.distributed_lock = true
 
     ## cache settings for SQL queries, this needs to use memory type backend
     rc_cache.sql_cache_short.backend = dogpile.cache.rc.memory_lru
     rc_cache.sql_cache_short.expiration_time = 30
 
     ## `cache_repo_longterm` cache for repo object instances, this needs to use memory
     ## type backend as the objects kept are not pickle serializable
     rc_cache.cache_repo_longterm.backend = dogpile.cache.rc.memory_lru
     ## by default we use 96H, this is using invalidation on push anyway
     rc_cache.cache_repo_longterm.expiration_time = 345600
     ## max items in LRU cache, reduce this number to save memory, and expire last used
     ## cached objects
     rc_cache.cache_repo_longterm.max_size = 10000
 
 
 6) Configure `Nginx`_ as reverse proxy on `rc-node-2/3`:
    Minimal `Nginx`_ config used:
 
 
 .. code-block:: nginx
 
     ## rate limiter for certain pages to prevent brute force attacks
     limit_req_zone  $binary_remote_addr  zone=req_limit:10m   rate=1r/s;
 
     ## custom log format
     log_format log_custom '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" '
                           '$request_time $upstream_response_time $pipe';
 
     server {
         listen          80;
         server_name     rc-node-2;
         #server_name     rc-node-3;
 
         access_log   /var/log/nginx/rhodecode.access.log log_custom;
         error_log    /var/log/nginx/rhodecode.error.log;
 
         # example of proxy.conf can be found in our docs.
         include     /etc/nginx/proxy.conf;
 
         ## serve static files by Nginx, recommended for performance
         location /_static/rhodecode {
             gzip on;
             gzip_min_length  500;
             gzip_proxied     any;
             gzip_comp_level 4;
             gzip_types  text/css text/javascript text/xml text/plain text/x-component application/javascript application/json application/xml application/rss+xml font/truetype font/opentype application/vnd.ms-fontobject image/svg+xml;
             gzip_vary on;
             gzip_disable     "msie6";
             #alias /home/rcdev/.rccontrol/community-1/static;
             alias /home/rcdev/.rccontrol/enterprise-1/static;
         }
 
 
         location /_admin/login {
             limit_req  zone=req_limit  burst=10  nodelay;
             try_files $uri @rhode;
         }
 
         location / {
             try_files $uri @rhode;
         }
 
         location @rhode {
             # Url to running RhodeCode instance.
             # This is shown as `- URL: <host>` in output from rccontrol status.
             proxy_pass      http://127.0.0.1:10020;
         }
 
         ## custom 502 error page. Will be displayed while RhodeCode server
         ## is turned off
         error_page 502 /502.html;
         location = /502.html {
            #root  /home/rcdev/.rccontrol/community-1/static;
            root  /home/rcdev/.rccontrol/enterprise-1/static;
         }
     }
 
 
 7) Optional: Full text search, in case you use `Whoosh` full text search we also need a
    shared storage for the index. In our example our NFS is mounted at `/home/rcdev/storage`
    which represents out storage so we can use the following:
 
 .. code-block:: ini
 
     # note the `_` prefix that allows using a directory without
     # remap and rescan checking for vcs inside it.
     search.location = /home/rcdev/storage/_index_data/index
 
 
 .. note::
 
     If you use ElasticSearch it's by default shared, and simply running ES node is
     by default cluster compatible.
 
 
 8) Optional: If you intend to use mailing all instances need to use either a shared
    mailing node, or each will use individual local mail agent. Simply put node-1/2/3
    needs to use same mailing configuration.
 
 
 
 Setup rc-node-1
 ^^^^^^^^^^^^^^^
 
 
 Configure `Nginx`_ as Load Balancer to rc-node-2/3.
 Minimal `Nginx`_ example below:
 
 .. code-block:: nginx
 
     ## define rc-cluster which contains a pool of our instances to connect to
     upstream rc-cluster {
         # rc-node-2/3 are stored in /etc/hosts with correct IP addresses
         server rc-node-2:80;
         server rc-node-3:80;
     }
 
     server {
         listen          80;
         server_name     rc-node-1;
 
         location / {
             proxy_pass http://rc-cluster;
         }
     }
 
 
 .. note::
 
    You should configure your load balancing accordingly. We recommend writing
    load balancing rules that will separate regular user traffic from
    automated process traffic like continuous servers or build bots. Sticky sessions
    are not required.
 
 
 Show which instance handles a request
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can easily check if load-balancing is working as expected. Visit our main node
 `rc-node-1` URL which at that point should already handle incoming requests and balance
 it across node-2/3.
 
 Add a special GET param `?showrcid=1` to show current instance handling your request.
 
 For example: visiting url `http://rc-node-1/?showrcid=1` will show, in the bottom
 of the screen` cluster instance info.
 e.g: `RhodeCode instance id: rc-node-3-rc-node-3-3246`
 which is generated from::
 
     <NODE_HOSTNAME>-<INSTANCE_ID>-<WORKER_PID>
 
 
 Using Celery with cluster
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
 If `Celery` is used we recommend setting also an instance of Enterprise/Community+VCSserver
 on the node that is running `RabbitMQ`_. Those instances will be used to executed async
 tasks on the `rc-node-1`. This is the most efficient setup. `Celery` usually
 handles tasks such as sending emails, forking repositories, importing
 repositories from external location etc. Using workers on instance that has
 the direct access to disks used by NFS as well as email server gives noticeable
 performance boost. Running local workers to the NFS storage results in faster
 execution of forking large repositories or sending lots of emails.
 
 Those instances need to be configured in the same way as for other nodes.
 The instance in rc-node-1 can be added to the cluser, but we don't recommend doing it.
 For best results let it be isolated to only executing `Celery` tasks in the cluster setup.
 
 
 .. _Gunicorn: http://gunicorn.org/
 .. _Whoosh: https://pypi.python.org/pypi/Whoosh/
 .. _Elasticsearch: https://www.elastic.co/..
 .. _RabbitMQ: http://www.rabbitmq.com/
 .. _Nginx: http://nginx.io
 .. _Apache: http://nginx.io
 .. _Redis: http://redis.io
 

docs/admin/user-admin.rst

@@ -1,23 +1,23 b''
 .. _user-admin-set:
 
 User Administration
 ===================
 
-|RCM| enables you to define permissions for the following entities within the
+|RCE| enables you to define permissions for the following entities within the
 system; **users**, **user groups**, **repositories**, **repository groups**.
 
 Within each one of these entities you can set default settings,
 and then all users or |repos| inherit those default permission settings
 unless individually defined. Each of these entities can have the following
 permissions applied to it; |perm|.
 
 .. toctree::
 
     public-access
     default-user-perms
     adding-anonymous-user
     adding-new-user
     setting-default-permissions
     setting-usergroup-permissions
 
 .. |perm| replace:: **None**, **Read**, **Write**, or **Admin**
  No newline at end of file

docs/admin/vcs-server.rst

@@ -1,324 +1,324 b''
 .. _vcs-server:
 
 VCS Server Management
 ---------------------
 
-The VCS Server handles |RCM| backend functionality. You need to configure
-a VCS Server to run with a |RCM| instance. If you do not, you will be missing
-the connection between |RCM| and its |repos|. This will cause error messages
+The VCS Server handles |RCE| backend functionality. You need to configure
+a VCS Server to run with a |RCE| instance. If you do not, you will be missing
+the connection between |RCE| and its |repos|. This will cause error messages
 on the web interface. You can run your setup in the following configurations,
 currently the best performance is one of following:
 
-* One VCS Server per |RCM| instance.
+* One VCS Server per |RCE| instance.
 * One VCS Server handling multiple instances.
 
 .. important::
 
    If your server locale settings are not correctly configured,
    |RCE| and the VCS Server can run into issues. See this `Ask Ubuntu`_ post
    which explains the problem and gives a solution.
 
 For more information, see the following sections:
 
 * :ref:`install-vcs`
 * :ref:`config-vcs`
 * :ref:`vcs-server-options`
 * :ref:`vcs-server-versions`
 * :ref:`vcs-server-maintain`
 * :ref:`vcs-server-config-file`
 * :ref:`svn-http`
 
 .. _install-vcs:
 
 VCS Server Installation
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 To install a VCS Server, see
 :ref:`Installing a VCS server <control:install-vcsserver>`.
 
 .. _config-vcs:
 
 Hooking |RCE| to its VCS Server
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To configure a |RCE| instance to use a VCS server, see
 :ref:`Configuring the VCS Server connection <control:manually-vcsserver-ini>`.
 
 .. _vcs-server-options:
 
 |RCE| VCS Server Options
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-The following list shows the available options on the |RCM| side of the
+The following list shows the available options on the |RCE| side of the
 connection to the VCS Server. The settings are configured per
 instance in the
 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
 
 .. rst-class:: dl-horizontal
 
     \vcs.backends <available-vcs-systems>
         Set a comma-separated list of the |repo| options available from the
         web interface. The default is ``hg, git, svn``,
         which is all |repo| types available. The order of backends is also the
         order backend will try to detect requests type.
 
     \vcs.connection_timeout <seconds>
         Set the length of time in seconds that the VCS Server waits for
         requests to process. After the timeout expires,
         the request is closed. The default is ``3600``. Set to a higher
         number if you experience network latency, or timeout issues with very
         large push/pull requests.
 
     \vcs.server.enable <boolean>
         Enable or disable the VCS Server. The available options are ``true`` or
         ``false``. The default is ``true``.
 
     \vcs.server <host:port>
         Set the host, either hostname or IP Address, and port of the VCS server
-        you wish to run with your |RCM| instance.
+        you wish to run with your |RCE| instance.
 
 .. code-block:: ini
 
     ##################
     ### VCS CONFIG ###
     ##################
     # set this line to match your VCS Server
     vcs.server = 127.0.0.1:10004
     # Set to False to disable the VCS Server
     vcs.server.enable = True
     vcs.backends = hg, git, svn
     vcs.connection_timeout = 3600
 
 
 .. _vcs-server-versions:
 
 VCS Server Versions
 ^^^^^^^^^^^^^^^^^^^
 
 An updated version of the VCS Server is released with each |RCE| version. Use
 the VCS Server number that matches with the |RCE| version to pair the
 appropriate ones together. For |RCE| versions pre 3.3.0,
 VCS Server 1.X.Y works with |RCE| 3.X.Y, for example:
 
 * VCS Server 1.0.0 works with |RCE| 3.0.0
 * VCS Server 1.2.2 works with |RCE| 3.2.2
 
 For |RCE| versions post 3.3.0, the VCS Server and |RCE| version numbers
 match, for example:
 
 * VCS Server |release| works with |RCE| |release|
 
 .. _vcs-server-maintain:
 
 VCS Server Memory Optimization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To optimize the VCS server to manage the cache and memory usage efficiently, you need to
 configure the following options in the
 :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini` file. Once
 configured, restart the VCS Server. By default we use an optimal settings, but in certain
 conditions tunning expiration_time and max_size can affect memory usage and performance
 
 .. code-block:: ini
 
     ## cache region for storing repo_objects cache
     rc_cache.repo_object.backend = dogpile.cache.rc.memory_lru
 
     ## cache auto-expires after N seconds, setting this to 0 disabled cache
     rc_cache.repo_object.expiration_time = 300
 
     ## max size of LRU, old values will be discarded if the size of cache reaches max_size
     ## Sets the maximum number of items stored in the cache, before the cache
     ## starts to be cleared.
 
     ## As a general rule of thumb, running this value at 120 resulted in a
     ## 5GB cache. Running it at 240 resulted in a 9GB cache. Your results
     ## will differ based on usage patterns and |repo| sizes.
 
     ## Tweaking this value to run at a fairly constant memory load on your
     ## server will help performance.
 
     rc_cache.repo_object.max_size = 120
 
 
 To clear the cache completely, you can restart the VCS Server.
 
 .. important::
 
    While the VCS Server handles a restart gracefully on the web interface,
    it will drop connections during push/pull requests. So it is recommended
    you only perform this when there is very little traffic on the instance.
 
 Use the following example to restart your VCS Server,
 for full details see the :ref:`RhodeCode Control CLI <control:rcc-cli>`.
 
 .. code-block:: bash
 
     $ rccontrol status
 
 .. code-block:: vim
 
     - NAME: vcsserver-1
     - STATUS: RUNNING
       logs:/home/ubuntu/.rccontrol/vcsserver-1/vcsserver.log
     - VERSION: 4.7.2 VCSServer
     - URL: http://127.0.0.1:10008
     - CONFIG: /home/ubuntu/.rccontrol/vcsserver-1/vcsserver.ini
 
     $ rccontrol restart vcsserver-1
     Instance "vcsserver-1" successfully stopped.
     Instance "vcsserver-1" successfully started.
 
 .. _vcs-server-config-file:
 
 VCS Server Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can configure settings for multiple VCS Servers on your
 system using their individual configuration files. Use the following
 properties inside the configuration file to set up your system. The default
 location is :file:`home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`.
 For a more detailed explanation of the logger levers, see :ref:`debug-mode`.
 
 .. rst-class:: dl-horizontal
 
     \host <ip-address>
         Set the host on which the VCS Server will run. VCSServer is not
         protected by any authentication, so we *highly* recommend running it
         under localhost ip that is `127.0.0.1`
 
     \port <int>
         Set the port number on which the VCS Server will be available.
 
     \locale <locale_utf>
         Set the locale the VCS Server expects.
 
     \workers <int>
         Set the number of process workers.Recommended
         value is (2 * NUMBER_OF_CPUS + 1), eg 2CPU = 5 workers
 
     \max_requests <int>
         The maximum number of requests a worker will process before restarting.
         Any value greater than zero will limit the number of requests a work
         will process before automatically restarting. This is a simple method
         to help limit the damage of memory leaks.
 
     \max_requests_jitter <int>
         The maximum jitter to add to the max_requests setting.
         The jitter causes the restart per worker to be randomized by
         randint(0, max_requests_jitter). This is intended to stagger worker
         restarts to avoid all workers restarting at the same time.
 
 
 .. note::
 
    After making changes, you need to restart your VCS Server to pick them up.
 
 .. code-block:: ini
 
     ################################################################################
     # RhodeCode VCSServer with HTTP Backend - configuration                        #
     #                                                                              #
     ################################################################################
 
 
     [server:main]
     ## COMMON ##
     host = 127.0.0.1
     port = 10002
 
     ##########################
     ## GUNICORN WSGI SERVER ##
     ##########################
     ## run with gunicorn --log-config vcsserver.ini --paste vcsserver.ini
     use = egg:gunicorn#main
     ## Sets the number of process workers. Recommended
     ## value is (2 * NUMBER_OF_CPUS + 1), eg 2CPU = 5 workers
     workers = 3
     ## process name
     proc_name = rhodecode_vcsserver
     ## type of worker class, one of sync, gevent
     ## recommended for bigger setup is using of of other than sync one
     worker_class = sync
     ## The maximum number of simultaneous clients. Valid only for Gevent
     #worker_connections = 10
     ## max number of requests that worker will handle before being gracefully
     ## restarted, could prevent memory leaks
     max_requests = 1000
     max_requests_jitter = 30
     ## amount of time a worker can spend with handling a request before it
     ## gets killed and restarted. Set to 6hrs
     timeout = 21600
 
     [app:main]
     use = egg:rhodecode-vcsserver
 
     pyramid.default_locale_name = en
     pyramid.includes =
 
     ## default locale used by VCS systems
     locale = en_US.UTF-8
 
     # cache regions, please don't change
     beaker.cache.regions = repo_object
     beaker.cache.repo_object.type = memorylru
     beaker.cache.repo_object.max_items = 100
     # cache auto-expires after N seconds
     beaker.cache.repo_object.expire = 300
     beaker.cache.repo_object.enabled = true
 
 
     ################################
     ### LOGGING CONFIGURATION   ####
     ################################
     [loggers]
     keys = root, vcsserver, beaker
 
     [handlers]
     keys = console
 
     [formatters]
     keys = generic
 
     #############
     ## LOGGERS ##
     #############
     [logger_root]
     level = NOTSET
     handlers = console
 
     [logger_vcsserver]
     level = DEBUG
     handlers =
     qualname = vcsserver
     propagate = 1
 
     [logger_beaker]
     level = DEBUG
     handlers =
     qualname = beaker
     propagate = 1
 
 
     ##############
     ## HANDLERS ##
     ##############
 
     [handler_console]
     class = StreamHandler
     args = (sys.stderr,)
     level = DEBUG
     formatter = generic
 
     ################
     ## FORMATTERS ##
     ################
 
     [formatter_generic]
     format = %(asctime)s.%(msecs)03d %(levelname)-5.5s [%(name)s] %(message)s
     datefmt = %Y-%m-%d %H:%M:%S
 
 
 .. _Subversion Red Book: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn
 
 .. _Ask Ubuntu: http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue

docs/api/api.rst

@@ -1,208 +1,208 b''
 .. _api:
 
 API Documentation
 =================
 
 The |RCE| API uses a single scheme for calling all API methods. The API is
 implemented with JSON protocol in both directions. To send API requests to
 your instance of |RCE|, use the following URL format
 ``<your_server>/_admin``
 
 .. note::
 
    To use the API, you should configure the :file:`~/.rhoderc` file with
    access details per instance. For more information, see
    :ref:`config-rhoderc`.
 
 
 API ACCESS FOR WEB VIEWS
 ------------------------
 
 API access can also be turned on for each web view in |RCE| that is
 decorated with a `@LoginRequired` decorator. To enable API access, change
 the standard login decorator to `@LoginRequired(api_access=True)`.
 
-From |RCM| version 1.7.0 you can configure a white list
+From |RCE| version 1.7.0 you can configure a white list
 of views that have API access enabled by default. To enable these,
-edit the |RCM| configuration ``.ini`` file. The default location is:
+edit the |RCE| configuration ``.ini`` file. The default location is:
 
-* |RCM| Pre-2.2.7 :file:`root/rhodecode/data/production.ini`
-* |RCM| 3.0 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+* |RCE| Pre-2.2.7 :file:`root/rhodecode/data/production.ini`
+* |RCE| 3.0 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 
 To configure the white list, edit this section of the file. In this
 configuration example, API access is granted to the patch/diff raw file and
 archive.
 
 .. code-block:: ini
 
     ## List of controllers (using glob syntax) that AUTH TOKENS could be used for access.
     ## Adding ?auth_token = <token> to the url authenticates this request as if it
     ## came from the the logged in user who own this authentication token.
     ##
     ## Syntax is <ControllerClass>:<function_pattern>.
     ## The list should be "," separated and on a single line.
     ##
     api_access_controllers_whitelist = RepoCommitsView:repo_commit_raw,RepoCommitsView:repo_commit_patch,RepoCommitsView:repo_commit_download
 
 After this change, a |RCE| view can be accessed without login by adding a
 GET parameter ``?auth_token=<auth_token>`` to a url. For example to
 access the raw diff.
 
 .. code-block:: html
 
    http://<server>/<repo>/changeset-diff/<sha>?auth_token=<auth_token>
 
 By default this is only enabled on RSS/ATOM feed views. Exposing raw diffs is a
 good way to integrate with 3rd party services like code review, or build farms
 that could download archives.
 
 API ACCESS
 ----------
 
 All clients are required to send JSON-RPC spec JSON data.
 
 .. code-block:: bash
 
     {
         "id:"<id>",
         "auth_token":"<auth_token>",
         "method":"<method_name>",
         "args":{"<arg_key>":"<arg_val>"}
     }
 
 Example call for auto pulling from remote repositories using curl:
 
 .. code-block:: bash
 
     curl https://server.com/_admin/api -X POST -H 'content-type:text/plain' --data-binary '{"id":1,
     "auth_token":"xe7cdb2v278e4evbdf5vs04v832v0efvcbcve4a3","method":"pull", "args":{"repoid":"CPython"}}'
 
 Provide those parameters:
  - **id** A value of any type, which is used to match the response with the
    request that it is replying to.
  - **auth_token** for access and permission validation.
  - **method** is name of method to call
  - **args** is an ``key:value`` list of arguments to pass to method
 
 .. note::
 
     To get your |authtoken|, from the |RCE| interface,
     go to:
     :menuselection:`username --> My account --> Auth tokens`
 
     For security reasons you should always create a dedicated |authtoken| for
     API use only.
 
 
 The |RCE| API will always return a JSON-RPC response:
 
 .. code-block:: bash
 
     {
         "id": <id>, # matching id sent by request
         "result": "<result>"|null, # JSON formatted result, null if any errors
         "error": "null"|<error_message> # JSON formatted error (if any)
     }
 
 All responses from API will be with `HTTP/1.0 200 OK` status code.
 If there is an error when calling the API, the *error* key will contain a
 failure description and the *result* will be `null`.
 
 API CLIENT
 ----------
 
 To install the |RCE| API, see :ref:`install-tools`. To configure the API per
 instance, see the :ref:`rc-tools` section as you need to configure a
 :file:`~/.rhoderc` file with your |authtokens|.
 
 Once you have set up your instance API access, use the following examples to
 get started.
 
 .. code-block:: bash
 
     # Getting the 'rhodecode' repository
     # from a RhodeCode Enterprise instance
     rhodecode-api --instance-name=enterprise-1 get_repo repoid:rhodecode
 
     Calling method get_repo => http://127.0.0.1:5000
     Server response
     {
         <json data>
     }
 
     # Creating a new mercurial repository called 'brand-new'
     # with a description 'Repo-description'
     rhodecode-api --instance-name=enterprise-1 create_repo repo_name:brand-new repo_type:hg description:Repo-description
     {
       "error": null,
       "id": 1110,
       "result": {
         "msg": "Created new repository `brand-new`",
         "success": true,
         "task": null
       }
     }
 
 A broken example, what not to do.
 
 .. code-block:: bash
 
     # A call missing the required arguments
     # and not specifying the instance
     rhodecode-api get_repo
 
     Calling method get_repo => http://127.0.0.1:5000
     Server response
     "Missing non optional `repoid` arg in JSON DATA"
 
 You can specify pure JSON using the ``--format`` parameter.
 
 .. code-block:: bash
 
     rhodecode-api --format=json get_repo repoid:rhodecode
 
 In such case only output that this function shows is pure JSON, we can use that
 and pipe output to some json formatter.
 
 If output is in pure JSON format, you can pipe output to a JSON formatter.
 
 .. code-block:: bash
 
     rhodecode-api --instance-name=enterprise-1 --format=json get_repo repoid:rhodecode | python -m json.tool
 
 API METHODS
 -----------
 
 Each method by default required following arguments.
 
 .. code-block:: bash
 
     id :      "<id_for_response>"
     auth_token : "<auth_token>"
     method :  "<method name>"
     args :    {}
 
 Use each **param** from docs and put it in args, Optional parameters
 are not required in args.
 
 .. code-block:: bash
 
     args: {"repoid": "rhodecode"}
 
 .. Note: From this point on things are generated by the script in
    `scripts/fabfile.py`. To change things below, update the docstrings in the
    ApiController.
 
 .. --- API DEFS MARKER ---
 .. toctree::
 
    methods/views
    methods/license-methods
    methods/deprecated-methods
    methods/gist-methods
    methods/pull-request-methods
    methods/repo-methods
    methods/repo-group-methods
    methods/server-methods
    methods/user-methods
    methods/user-group-methods

docs/auth/auth-crowd.rst

@@ -1,15 +1,15 b''
 .. _config-crowd-ref:
 
 Crowd
 -----
 
 To enable Crowd authentication, use the following steps:
 
-1. From the |RCM| interface, go to :menuselection:`Admin --> Authentication`
-2. Enable the ``rhodecode.lib.auth_modules.auth_crowd`` library and select
+1. From the |RCE| interface, go to :menuselection:`Admin --> Authentication`
+2. Activate the ``rhodecode.lib.auth_modules.auth_crowd`` library and select
    :guilabel:`Save`
 3. On the Crowd plugin settings section, do the following:
 
    * Check the :guilabel:`Enable` checkbox
    * Enter your Crowd server settings
    * Select :guilabel:`Save`

docs/auth/auth-ldap-groups.rst

@@ -1,112 +1,160 b''
 .. _config-ldap-groups-ref:
 
 LDAP/AD With User Groups Sync
 -----------------------------
 
-|RCM| supports LDAP (Lightweight Directory Access Protocol) or
+**This plugin is available only in EE Edition.**
+
+|RCE| supports LDAP (Lightweight Directory Access Protocol) or
 AD (active Directory) authentication.
-All LDAP versions are supported, with the following |RCM| plugins managing each:
-
-* For LDAP/AD with user group sync use ``LDAP + User Groups (egg:rhodecode-enterprise-ee#ldap_group)``
+All LDAP versions are currently supported.
 
 RhodeCode reads all data defined from plugin and creates corresponding
 accounts on local database after receiving data from LDAP. This is done on
 every user log-in including operations like pushing/pulling/checkout.
 In addition group membership is read from LDAP and following operations are done:
 
-- automatic addition of user to |RCM| user group
-- automatic removal of user from any other  |RCM| user groups not specified in LDAP.
+- automatic addition of user to |RCE| user group
+- automatic removal of user from any other  |RCE| user groups not specified in LDAP.
   The removal is done *only* on groups that are marked to be synced from ldap.
   This setting can be changed in advanced settings on user groups
-- automatic creation of user groups if they aren't yet existing in |RCM|
+- automatic creation of user groups if they aren't yet existing in |RCE|
 - marking user as super-admins if he is a member of any admin group defined in plugin settings
 
-This plugin is available only in EE Edition.
 
 .. important::
 
    The email used with your |RCE| super-admin account needs to match the email
    address attached to your admin profile in LDAP. This is because
    within |RCE| the user email needs to be unique, and multiple users
    cannot share an email account.
 
    Likewise, if as an admin you also have a user account, the email address
    attached to the user account needs to be different.
 
 
 LDAP Configuration Steps
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 To configure |LDAP|, use the following steps:
 
-1. From the |RCM| interface, select
+1. From the |RCE| interface, select
    :menuselection:`Admin --> Authentication`
-2. Enable the ldap+ groups plugin and select :guilabel:`Save`
-3. Select the :guilabel:`Enabled` check box in the plugin configuration section
-4. Add the required LDAP information and :guilabel:`Save`, for more details,
+2. Activate the `LDAP + User Groups` plugin and select :guilabel:`Save`
+3. Go to newly available menu option called `LDAP + User Groups` on the left side.
+4. Check the `enabled` check box in the plugin configuration section,
+   and fill in the required LDAP information and :guilabel:`Save`, for more details,
    see :ref:`config-ldap-groups-examples`
 
 For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
 
 .. _config-ldap-groups-examples:
 
 Example LDAP configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. code-block:: bash
+
+Below is example setup that can be used with Active Directory and LDAP server with groups sync::
+
+    *option*: `enabled` => `True`
+    # Enable or disable this authentication plugin.
+
+    *option*: `cache_ttl` => `360`
+    # Amount of seconds to cache the authentication and permissions check response call for this plugin.
+    # Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
+
+    *option*: `host` => `192.168.245.143,192.168.1.240`
+    # Host[s] of the LDAP Server
+    # (e.g., 192.168.2.154, or ldap-server.domain.com.
+    #  Multiple servers can be specified using commas
+
+    *option*: `port` => `389`
+    # Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
+
+    *option*: `timeout` => `300`
+    # Timeout for LDAP connection
+
+    *option*: `dn_user` => `[e-mail]`
+    # Optional user DN/account to connect to LDAP if authentication is required.
+    # e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or [e-mail]
+
+    *option*: `dn_pass` => `SomeSecret`
+    # Password to authenticate for given user DN.
+
+    *option*: `tls_kind` => `PLAIN`
+    # TLS Type
+
+    *option*: `tls_reqcert` => `NEVER`
+    # Require Cert over TLS?. Self-signed and custom certificates can be used when
+    #  `RhodeCode Certificate` found in admin > settings > system info page is extended.
+
+    *option*: `tls_cert_file` => ``
+    # This specifies the PEM-format file path containing certificates for use in TLS connection.
+    # If not specified `TLS Cert dir` will be used
+
+    *option*: `tls_cert_dir` => `/etc/openldap/cacerts`
+    # This specifies the path of a directory that contains individual CA certificates in separate files.
+
+    *option*: `base_dn` => `dc=rhodecode,dc=com`
+    # Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
+    # (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
+
+    *option*: `user_search_base` => `ou=RC-Users`
+    # User search base will extend the Base DN
+    # (e.g., ou=Users will result in ou=Users,dc=mydomain,dc=com root DN)
 
-        # Auth Cache TTL, Defines the caching for authentication to offload LDAP server.
-        # This means that cache result will be saved for 3600 before contacting LDAP server to verify the user access
-        3600
-        # Host, comma seperated format is optionally possible to specify more than 1 server
-        https://ldap1.server.com/ldap-admin/,https://ldap2.server.com/ldap-admin/
-        # Default LDAP Port, use 689 for LDAPS
-        389
-        # Account, used for SimpleBind if LDAP server requires an authentication
-        e.g [e-mail]
-        # Password used for simple bind
-        ldap-user-password
-        # LDAP connection security
-        LDAPS
-        # Certificate checks level
-        DEMAND
-        # Base DN
-        cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com
-        # User Search Base
-        ou=groups,ou=users
-        # LDAP search filter to narrow the results
-        (objectClass=person)
-        # LDAP search scope
-        SUBTREE
-        # Login attribute
-        sAMAccountName
-        # First Name Attribute to read
-        givenName
-        # Last Name Attribute to read
-        sn
-        # Email Attribute to read email address from
-        mail
-        # group extraction method
-        rfc2307bis
-        # Group search base
-        ou=RC-Groups
-        # Group Name Attribute, field to read the group name from
-        sAMAAccountName
-        # User Member of Attribute, field in which groups are stored
-        memberOf
-        # LDAP Group Search Filter, allows narrowing the results
+    *option*: `user_search_filter` => ``
+    # Filter to narrow results
+    # (e.g., (&(objectCategory=Person)(objectClass=user)), or
+    # (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
+
+    *option*: `search_scope` => `SUBTREE`
+    # How deep to search LDAP. If unsure set to SUBTREE
+
+    *option*: `attr_login` => `sAMAccountName`
+    # LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
+
+    *option*: `attr_email` => `mail`
+    # LDAP Attribute to map to email address (e.g., mail).
+    # Emails are a crucial part of RhodeCode.
+    # If possible add a valid email attribute to ldap users.
+
+    *option*: `attr_firstname` => `givenName`
+    # LDAP Attribute to map to first name (e.g., givenName)
+
+    *option*: `attr_lastname` => `sn`
+    # LDAP Attribute to map to last name (e.g., sn)
+
+    *option*: `group_extraction_type` => `rfc2307bis`
+    # With rfc2307, group members are listed by name in the memberUid attribute
+    # With rfc2307bis (Microsoft AD compatible) group members are listed by DN and stored in the member attribute
 
-        # Admin Groups. Comma separated list of groups. If user is member of
-        # any of those he will be marked as super-admin in RhodeCode
-        admins, management
+    *option*: `group_search_base` => `ou=RC-Groups`
+    # Group search base will extend the Base DN (e.g. ou=Groups will result in ou=Groups,dc=mydomain,dc=com)
 
+    *option*: `group_name_attr` => `sAMAccountName`
+    # LDAP Attribute to map to group name (e.g., cn, or sAMAccountName)
+
+    *option*: `user_member_of` => `memberOf`
+    # Users Attribute used to fetch the group membership.
+    # Use if users have stored group membership inside their attributes
+    # (e.g., memberOf, or userMemberOf)
 
-Below is example setup that can be used with Active Directory and ldap groups.
+    *option*: `group_search_filter` => ``
+    # Filter to narrow results (e.g., (&(objectCategory=Group)(objectClass=group)), etc)
+
+    *option*: `group_member_of` => `memberOf`
+    # LDAP Attribute used to resolve the parent group (e.g., memberOf)
 
-.. image:: ../images/ldap-groups-example.png
-   :alt: LDAP/AD setup example
-   :scale: 50 %
+    *option*: `admin_groups` => `Admins,Management`
+    # A comma separated list of group names that identify users as RhodeCode Administrators (e.g., admins)
+
+    *option*: `admin_groups_sync` => `full`
+    # Way to sync Admin groups.
+    # Full means admin flag is set to on or off according to membership in administrator group defined above.
+    # On-only means the flag is only set to on, and not turned off once user is no longer a member
+
 
 .. toctree::
 
    ldap-active-directory
    ldap-authentication
  No newline at end of file

docs/auth/auth-ldap.rst

@@ -1,89 +1,117 b''
 .. _config-ldap-ref:
 
 LDAP/AD
 -------
 
-|RCM| supports LDAP (Lightweight Directory Access Protocol) or
+|RCE| supports LDAP (Lightweight Directory Access Protocol) or
 AD (active Directory) authentication.
-All LDAP versions are supported, with the following |RCM| plugins managing each:
-
-* For LDAP or Active Directory use ``LDAP (egg:rhodecode-enterprise-ce#ldap)``
+All LDAP versions are currently supported.
 
 RhodeCode reads all data defined from plugin and creates corresponding
 accounts on local database after receiving data from LDAP. This is done on
 every user log-in including operations like pushing/pulling/checkout.
 
 
 .. important::
 
    The email used with your |RCE| super-admin account needs to match the email
    address attached to your admin profile in LDAP. This is because
    within |RCE| the user email needs to be unique, and multiple users
    cannot share an email account.
 
    Likewise, if as an admin you also have a user account, the email address
    attached to the user account needs to be different.
 
 
 LDAP Configuration Steps
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 To configure |LDAP|, use the following steps:
 
-1. From the |RCM| interface, select
+1. From the |RCE| interface, select
    :menuselection:`Admin --> Authentication`
-2. Enable the ldap plugin and select :guilabel:`Save`
-3. Select the :guilabel:`Enabled` check box in the plugin configuration section
-4. Add the required LDAP information and :guilabel:`Save`, for more details,
+2. Activate the `LDAP` plugin and select :guilabel:`Save`
+3. Go to newly available menu option called `LDAP` on the left side.
+4. Check the `enabled` check box in the plugin configuration section,
+   and fill in the required LDAP information and :guilabel:`Save`, for more details,
    see :ref:`config-ldap-examples`
 
 For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
 
 .. _config-ldap-examples:
 
 Example LDAP configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. code-block:: bash
+
+Below is example setup that can be used with Active Directory/LDAP server::
+
+    *option*: `enabled` => `True`
+    # Enable or disable this authentication plugin.
+
+    *option*: `cache_ttl` => `360`
+    # Amount of seconds to cache the authentication and permissions check response call for this plugin.
+    # Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
+
+    *option*: `host` => `192.168.245.143,192.168.1.240`
+    # Host[s] of the LDAP Server
+    # (e.g., 192.168.2.154, or ldap-server.domain.com.
+    #  Multiple servers can be specified using commas
+
+    *option*: `port` => `389`
+    # Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
+
+    *option*: `timeout` => `300`
+    # Timeout for LDAP connection
+
+    *option*: `dn_user` => `[e-mail]`
+    # Optional user DN/account to connect to LDAP if authentication is required.
+    # e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or [e-mail]
+
+    *option*: `dn_pass` => `SomeSecret`
+    # Password to authenticate for given user DN.
+
+    *option*: `tls_kind` => `PLAIN`
+    # TLS Type
 
-        # Auth Cache TTL, Defines the caching for authentication to offload LDAP server.
-        # This means that cache result will be saved for 3600 before contacting LDAP server to verify the user access
-        3600
-        # Host, comma seperated format is optionally possible to specify more than 1 server
-        https://ldap1.server.com/ldap-admin/,https://ldap2.server.com/ldap-admin/
-        # Default LDAP Port, use 689 for LDAPS
-        389
-        # Account, used for SimpleBind if LDAP server requires an authentication
-        e.g [e-mail]
-        # Password used for simple bind
-        ldap-user-password
-        # LDAP connection security
-        LDAPS
-        # Certificate checks level
-        DEMAND
-        # Base DN
-        cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com
-        # LDAP search filter to narrow the results
-        (objectClass=person)
-        # LDAP search scope
-        SUBTREE
-        # Login attribute
-        sAMAccountName
-        # First Name Attribute to read
-        givenName
-        # Last Name Attribute to read
-        sn
-        # Email Attribute to read email address from
-        mail
+    *option*: `tls_reqcert` => `NEVER`
+    # Require Cert over TLS?. Self-signed and custom certificates can be used when
+    #  `RhodeCode Certificate` found in admin > settings > system info page is extended.
+
+    *option*: `tls_cert_file` => ``
+    # This specifies the PEM-format file path containing certificates for use in TLS connection.
+    # If not specified `TLS Cert dir` will be used
+
+    *option*: `tls_cert_dir` => `/etc/openldap/cacerts`
+    # This specifies the path of a directory that contains individual CA certificates in separate files.
+
+    *option*: `base_dn` => `cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com`
+    # Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
+    # (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
 
+    *option*: `filter` => `(objectClass=person)`
+    # Filter to narrow results
+    # (e.g., (&(objectCategory=Person)(objectClass=user)), or
+    # (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
 
-Below is example setup that can be used with Active Directory/LDAP server.
+    *option*: `search_scope` => `SUBTREE`
+    # How deep to search LDAP. If unsure set to SUBTREE
+
+    *option*: `attr_login` => `sAMAccountName`
+    # LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
 
-.. image:: ../images/ldap-example.png
-   :alt: LDAP/AD setup example
-   :scale: 50 %
+    *option*: `attr_email` => `mail`
+    # LDAP Attribute to map to email address (e.g., mail).
+    # Emails are a crucial part of RhodeCode.
+    # If possible add a valid email attribute to ldap users.
+
+    *option*: `attr_firstname` => `givenName`
+    # LDAP Attribute to map to first name (e.g., givenName)
+
+    *option*: `attr_lastname` => `sn`
+    # LDAP Attribute to map to last name (e.g., sn)
 
 
 .. toctree::
 
    ldap-active-directory
    ldap-authentication

docs/auth/auth-pam.rst

@@ -1,14 +1,14 b''
 .. _config-pam-ref:
 
 PAM
 ---
 
 To enable PAM authentication, use the following steps:
 
-1. From the |RCM| interface, go to :menuselection:`Admin --> Authentication`
-2. Enable the ``rhodecode.lib.auth_modules.auth_pam`` library and select save
+1. From the |RCE| interface, go to :menuselection:`Admin --> Authentication`
+2. Activate the ``rhodecode.lib.auth_modules.auth_pam`` library and select save
 3. On the PAM plugin settings section, do the following:
 
    * Check the :guilabel:`Enable` checkbox
    * Enter your PAM server settings
    * Select :guilabel:`Save`

docs/auth/auth-token.rst

@@ -1,76 +1,80 b''
 .. _config-token-ref:
 
 Authentication Tokens
 ---------------------
 
-|RCE| has 4 different kinds of authentication tokens.
+|RCE| has 4 different kinds of authentication tokens. `API token`, `Feed tokens` work
+without a need to enable any additional authentication. `VCS tokens` require dedicated
+authentication plugin to be activated. `Web Interface tokens` are controlled by the
+white_list configuration.
 
 * *API tokens*: API tokens can only be used to execute |RCE| API operations.
   You can store your API token and assign it to each instance in
   the :file:`/home/{user}/.rhoderc` file. See the
   example in :ref:`indexing-ref` section for more details.
 
 * *Feed tokens*: The feed token can only be used to access the RSS feed.
-   Usually those are safe to store inside your RSS feed reader.
-
-* *VCS tokens*: You can use these to authenticate with |git|, |hg| and |svn|
-  operations instead of a password. They are designed to be used with
-  CI Servers or other third party tools that require |repo| access.
-  They are also a good replacement for SSH based access.
-  To use these tokens you need be enabled special authentication method on
-  |RCE|, as they are disabled by default.
-  See :ref:`enable-vcs-tokens`.
+  Usually those are safe to store inside your RSS feed reader.
 
 * *Web Interface tokens*: These token allows users to access the web
   interface of |RCE| without logging in.
 
   You can add these tokens to an |RCE| server url, to expose the page content
   based on the given token.
 
   This is useful to integrate 3rd party systems, good example is to expose
   raw diffs to another code-review system without having to worry about
   authentication.
 
   These tokens only work if a certain view is whitelisted
   under `api_access_controllers_whitelist` inside
   the :file:`rhodecode.ini` file.
 
 .. code-block:: bash
 
    # To download a repo without logging into Web UI
    https://rhodecode.com/repo/archive/tip.zip?auth_token=<web-api-token>
 
    # To show commit diff without logging into Web UI
-   https://rhodecode.com/repo/changeset-diff/<sha>?auth_token=<web-api-token>
+   https://rhodecode.com/repo/raw-diff/<sha>?auth_token=<web-api-token>
+
+* *VCS tokens*: You can use these to authenticate with |git|, |hg| and |svn|
+  operations instead of a password. They are designed to be used with
+  CI Servers or other third party tools that require |repo| access.
+  They are also a good replacement for SSH based access.
+  To use these tokens you need be enabled special authentication method on
+  |RCE|, as they are disabled by default.
+  See :ref:`enable-vcs-tokens`.
+
 
 .. _enable-vcs-tokens:
 
 Enabling VCS Tokens
 ^^^^^^^^^^^^^^^^^^^
 
 To enable VCS Tokens, use the following steps:
 
 1. Go to :menuselection:`Admin --> Authentication`.
-2. Enable the ``rhodecode.lib.auth_modules.auth_token`` plugin.
+2. Activate the ``rhodecode.lib.auth_modules.auth_token`` plugin.
 3. Click :guilabel:`Save`.
 
 Authentication Token Tips
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 * Use Authentication Tokens instead of your password with external services.
 * Create multiple Authentication Tokens on your account to enable
   access to your |repos| with a different |authtoken| per method used.
 * Set an expiry limit on certain tokens if you think it would be a good idea.
 
 Creating Tokens
 ^^^^^^^^^^^^^^^
 
 To create authentication tokens for an user, use the following steps:
 
-1. From the |RCM| interface go to
+1. From the |RCE| interface go to
    :menuselection:`Username --> My Account --> Auth tokens`.
 
 2. Label and Add the tokens you wish to use with |RCE|.
 
 .. image:: ../images/tokens.png
 

docs/auth/auth.rst

@@ -1,32 +1,34 b''
 .. _authentication-ref:
 
 Authentication Options
 ======================
 
 |RCE| provides a built in authentication against its own database. This is
-implemented using ``rhodecode.lib.auth_rhodecode`` plugin. This plugin is
-enabled by default.
+implemented using ``RhodeCode Internal`` plugin. This plugin is enabled by default.
 Additionally, |RCE| provides a Pluggable Authentication System. This gives the
 administrator greater control over how users authenticate with the system.
 
 .. important::
 
-  You can disable the built in |RCM| authentication plugin
-  ``rhodecode.lib.auth_rhodecode`` and force all authentication to go
+  You can disable the built in |RCE| authentication plugin
+  ``RhodeCode Internal`` and force all authentication to go
   through your authentication plugin of choice e.g LDAP only.
   However, if you do this, and your external authentication tools fails,
-  you will be unable to access |RCM|.
+  accessing |RCE| will be blocked unless a fallback plugin is
+  enabled via :file: rhodecode.ini
 
-|RCM| comes with the following user authentication management plugins:
+
+|RCE| comes with the following user authentication management plugins:
 
 
 .. toctree::
 
+    auth-token
     auth-ldap
     auth-ldap-groups
+    auth-saml-generic
+    auth-saml-onelogin
+    auth-saml-duosecurity
     auth-crowd
     auth-pam
-    auth-token
     ssh-connection
-
-

docs/auth/ldap-active-directory.rst

@@ -1,29 +1,75 b''
 .. _ldap-act-dir-ref:
 
 Active Directory
 ----------------
 
-|RCM| can use Microsoft Active Directory for user authentication. This is
+|RCE| can use Microsoft Active Directory for user authentication. This is
 done through an LDAP or LDAPS connection to Active Directory. Use the
 following example LDAP configuration setting to set your Active Directory
-authentication.
-
-.. code-block:: ini
-    
-    # Set the Base DN
-    Base DN              = OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local
-    # Set the Active Directory SAM-Account-Name
-    Login Attribute      = sAMAccountName
-    # Set the Active Directory user name
-    First Name Attribute = usernameame
-    # Set the Active Directory user surname
-    Last Name Attribute  = user_surname
-    # Set the Active Directory user email
-    E-mail Attribute     = userEmail
+authentication::
 
 
-Below is example setup that can be used with Active Directory and ldap groups.
+    *option*: `enabled` => `True`
+    # Enable or disable this authentication plugin.
+
+    *option*: `cache_ttl` => `360`
+    # Amount of seconds to cache the authentication and permissions check response call for this plugin.
+    # Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
+
+    *option*: `host` => `192.168.245.143,192.168.1.240`
+    # Host[s] of the LDAP Server
+    # (e.g., 192.168.2.154, or ldap-server.domain.com.
+    #  Multiple servers can be specified using commas
+
+    *option*: `port` => `389`
+    # Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
+
+    *option*: `timeout` => `300`
+    # Timeout for LDAP connection
+
+    *option*: `dn_user` => `[e-mail]`
+    # Optional user DN/account to connect to LDAP if authentication is required.
+    # e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or [e-mail]
+
+    *option*: `dn_pass` => `SomeSecret`
+    # Password to authenticate for given user DN.
+
+    *option*: `tls_kind` => `PLAIN`
+    # TLS Type
+
+    *option*: `tls_reqcert` => `NEVER`
+    # Require Cert over TLS?. Self-signed and custom certificates can be used when
+    #  `RhodeCode Certificate` found in admin > settings > system info page is extended.
 
-.. image:: ../images/ldap-groups-example.png
-   :alt: LDAP/AD setup example
-   :scale: 50 %
  No newline at end of file
+    *option*: `tls_cert_file` => ``
+    # This specifies the PEM-format file path containing certificates for use in TLS connection.
+    # If not specified `TLS Cert dir` will be used
+
+    *option*: `tls_cert_dir` => `/etc/openldap/cacerts`
+    # This specifies the path of a directory that contains individual CA certificates in separate files.
+
+    *option*: `base_dn` => `OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local`
+    # Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
+    # (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
+
+    *option*: `filter` => `(objectClass=person)`
+    # Filter to narrow results
+    # (e.g., (&(objectCategory=Person)(objectClass=user)), or
+    # (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
+
+    *option*: `search_scope` => `SUBTREE`
+    # How deep to search LDAP. If unsure set to SUBTREE
+
+    *option*: `attr_login` => `sAMAccountName`
+    # LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
+
+    *option*: `attr_email` => `userEmail`
+    # LDAP Attribute to map to email address (e.g., mail).
+    # Emails are a crucial part of RhodeCode.
+    # If possible add a valid email attribute to ldap users.
+
+    *option*: `attr_firstname` => `user_firstname`
+    # LDAP Attribute to map to first name (e.g., givenName)
+
+    *option*: `attr_lastname` => `user_surname`
+    # LDAP Attribute to map to last name (e.g., sn)

docs/auth/ldap-authentication.rst

@@ -1,113 +1,107 b''
 .. _ldap-gloss-ref:
 
 |LDAP| Glossary
 ---------------
 
 This topic aims to give you a concise overview of the different settings and
 requirements that enabling |LDAP| on |RCE| requires.
 
 Required settings
 ^^^^^^^^^^^^^^^^^
 
 The following LDAP attributes are required when enabling |LDAP| on |RCE|.
 
 * **Hostname** or **IP Address**: Use a comma separated list for failover
   support.
 * **First Name**
 * **Surname**
 * **Email**
 * **Port**: Port `389` for unencrypted LDAP or port `636` for SSL-encrypted
   LDAP (LDAPS).
 * **Base DN (Distinguished Name)**: The Distinguished Name (DN)
   is how searches for users will be performed, and these searches can be
   controlled by using an LDAP Filter or LDAP Search Scope. A DN is a sequence of
   relative distinguished names (RDN) connected by commas. For example,
       
 .. code-block:: vim
     
     DN: cn='Monty Python',ou='people',dc='example',dc='com'
             
 * **Connection security level**: The following are the valid types:
    
   * *No encryption*: This connection type uses a plain non-encrypted connection.
   * *LDAPS connection*: This connection type uses end-to-end SSL. To enable
     an LDAPS connection you must set the following requirements:
 
       * You must specify port `636`
       * Certificate checks are required.
       * To enable ``START_TLS`` on LDAP connection, set the path to the SSL
         certificate in the default LDAP configuration file. The default
         `ldap.conf` file is located in `/etc/openldap/ldap.conf`.
 
 .. code-block:: vim
     
    TLS_CACERT	/etc/ssl/certs/ca.crt
 
 * The LDAP username or account used to connect to |RCE|. This will be added
   to the LDAP filter for locating the user object.
 * For example, if an LDAP filter is specified as `LDAPFILTER`,
-  the login attribute is specified as `uid`, and the user connects as
+  the login/username attribute is specified as `uid`, and the user connects as
   `jsmith`, then the LDAP Filter will be like the following example.
       
 .. code-block:: vim
                       
    (&(LDAPFILTER)(uid=jsmith))
     
 * The LDAP search scope must be set. This limits how far LDAP will search for
   a matching object.
 
   * ``BASE`` Only allows searching of the Base DN.
   * ``ONELEVEL`` Searches all entries under the Base DN,
     but not the Base DN itself.
   * ``SUBTREE`` Searches all entries below the Base DN, but not Base DN itself.
       
 .. note::
             
    When using ``SUBTREE`` LDAP filtering it is useful to limit object location.
  
 Optional settings
 ^^^^^^^^^^^^^^^^^
 
-The following are optional when enabling LDAP on |RCM|
+The following are optional when enabling LDAP on |RCE|
  
 * An LDAP account is only required if the LDAP server does not allow
   anonymous browsing of records.
 * An LDAP password is only required if the LDAP server does not allow
   anonymous browsing of records
 * Using an LDAP filter is optional. An LDAP filter defined by `RFC 2254`_. This
   is more useful that the LDAP Search Scope if set to `SUBTREE`. The filter
   is useful for limiting which LDAP objects are identified as representing
   Users for authentication. The filter is augmented by Login Attribute
   below. This can commonly be left blank.
 * Certificate Checks are only required if you need to use LDAPS.
   You can use the following levels of LDAP service with RhodeCode Enterprise:
 
    * **NEVER** : A serve certificate will never be requested or checked.
    * **ALLOW** : A server certificate is requested. Failure to provide a
      certificate or providing a bad certificate will not terminate the session.
    * **TRY** : A server certificate is requested. Failure to provide a
      certificate does not halt the session; providing a bad certificate
      halts the session.
    * **DEMAND** : A server certificate is requested and must be provided
      and authenticated for the session to proceed.
    * **HARD** : The same as DEMAND.
 
 .. note::
 
    Only **DEMAND** or **HARD** offer full SSL security while the other
    options are vulnerable to man-in-the-middle attacks.
 
    |RCE| uses ``OPENLDAP`` libraries. This allows **DEMAND** or
    **HARD** LDAPS connections to use self-signed certificates or
    certificates that do not have traceable certificates of authority.
    To enable this functionality install the SSL certificates in the
    following directory: `/etc/openldap/cacerts`
 
 
-Below is example setup that can be used with Active Directory and ldap groups.
-
-.. image:: ../images/ldap-groups-example.png
-   :alt: LDAP/AD setup example
-   :scale: 50 %
-
 .. _RFC 2254: http://www.rfc-base.org/rfc-2254.html
  No newline at end of file

docs/code-review/code-review.rst

@@ -1,27 +1,27 b''
 .. _code-review-ref:
 
 Code Review
 ===========
 
-|RCM| provides two ways in which you can review code. You can review |prs| or
+|RCE| provides two ways in which you can review code. You can review |prs| or
 commits. To better understand |prs|, see the :ref:`pull-requests-ref`
 and :ref:`collaborate-ref` sections. For more information about why
 code review matters, see these posts on the topic:
 
 * `Code Review - Fix Bugs Early and Often`_
 * `Code Review - How to Convince a Skeptic`_
 * `Code Review - Learn How NASA Codes`_
 
 You can also use the |RCE| API set up continuous integration servers to leave
 comments from a test suite. See the :ref:`api` and
 :ref:`extensions-hooks-ref` sections for examples on how to set this up.
 
 .. toctree::
 
    review-diffs
    approve-changes
    reviewing-best-practices
 
 .. _Code Review - Fix Bugs Early and Often: https://rhodecode.com/blog/code-review-fix-bugs-early-often/
 .. _Code Review - How to Convince a Skeptic: https://rhodecode.com/blog/code-review-convince-skeptic/
 .. _Code Review - Learn How NASA Codes: https://rhodecode.com/blog/code-review-learn-nasa-codes/

docs/code-review/review-diffs.rst

@@ -1,42 +1,42 b''
 .. _code-diff-side-ref:
 
 Reviewing Diffs
 ---------------
 
 Diffs are representations of changes made between different changesets of
 a file. |RCE| provides 4 different types of diffs for each commit or
 changeset, and depending on your preference you can use whichever for code
 review purposes.
 
 * Plain diff
 * Full diff
 * Side-by-side diff
 * Raw diff
 
 Reviewing Changes
 -----------------
 
-|RCM| displays all code changes made with each commit. Removed content is
+|RCE| displays all code changes made with each commit. Removed content is
 marked in red and new content in green.
 
 .. image:: ../images/plain-diff.png
    :alt: Plain Diff
 
 Side-By-Side Diffs
 ------------------
 
 To review code with a side-by-side diff, use the following steps:
 
 1. Open the repository in which you wish to review a file
 2. Select the revision you wish to review
 3. Select the side-by-side diff icon beside the file name
 
 .. image:: ../images/side-by-side-diff.png
    :alt: Side by side diff
 
 
 Notifying Users
 ---------------
 
 To notify other users of you comments, or requests for feedback,
 see :ref:`review-notifications-ref`

docs/collaboration/approve-pull-request.rst

@@ -1,19 +1,19 b''
 Approve |prs|
 -------------
 
 To approve a |pr|, use the following steps:
 
 1. Select :menuselection:`username --> Notifications --> Pull Requests`
    and open the |pr| you with to approve
 2. Leave your review comments inline, or in the commit message.
 3. Leave a commit message that outlines the review.
 4. Set the review status to :guilabel:`Approved`
 5. Select :guilabel:`Comment`
 
-If you approve the |pr|, you will be able to merge automatically if |RCM|
+If you approve the |pr|, you will be able to merge automatically if |RCE|
 detects that it can do so safely. You will see this message:
 
 :guilabel:`This pull request can be automatically merged.`
 
 Otherwise you will need to merge the |pr| locally and push your changes, see
 :ref:`manual-merge-requests-ref`.

docs/collaboration/collaboration.rst

@@ -1,24 +1,24 b''
 .. _collaborate-ref:
 
 Collaboration
 =============
 
 .. note::
 
    Forking and branching does not work with |svn| |repos|.
 
-Collaboration in |RCM| is accomplished through a combination of the following
+Collaboration in |RCE| is accomplished through a combination of the following
 functions:
 
 .. only:: latex
 
     * :ref:`review-notifications-ref`
     * :ref:`forks-branches-ref`
     * :ref:`pull-requests-ref`
 
 .. toctree::
 
     workflow
     forks-branches
     repo-locking
 

docs/collaboration/forks-branches.rst

@@ -1,101 +1,101 b''
 .. _forks-branches-ref:
 
 Forking and Branching
 ---------------------
 
 Forking clones the original |repo| and creates an independent |repo|.
 Branching allows you to develop independently
 of the main branch based on the changeset branched, but remains linked to the
 main |repo|.
 
 Both provide excellent collaboration functionality,
 and do not differ greatly, but you can find many online discussions
 where people fight about the differences.
 
 Fork a |repo|
 ^^^^^^^^^^^^^
 
 To fork a |repo|, use the following steps:
 
 1. Select :menuselection:`Admin --> repositories`
 2. Select the |repo| you wish to fork.
 3. Select :menuselection:`Options --> Fork`
 4. On the :guilabel:`Create fork` page, set the following properties:
 
    * The fork name
    * The fork description
    * If the fork is private or public
    * The copy permissions
 
 Branch a |git| |repo|
 ^^^^^^^^^^^^^^^^^^^^^
 
 Currently branching is only supported from the command line but is picked up
 on the web interface. To branch a |git| |repo| use the following example:
 
 .. code-block:: bash
 
     # branch and checkout
     git branch new-branch
     git checkout new-branch
 
     # same function shorthand
     git checkout -b new-branch
 
     # Example usage
     $ git checkout -b example-branch
     Switched to a new branch 'example-branch'
 
     $ git status
     On branch example-branch
     Initial commit
     nothing to commit (create/copy files and use "git add" to track)
     $ vi example-script.sh
     $ git add example-script.sh
     $ git commit -a -m "ghost script: initial file"
     $ git push
 
-Once it is pushed to the |RCM| server, you can switch to the newly created
+Once it is pushed to the |RCE| server, you can switch to the newly created
 branch using the following steps:
 
 1. Select :menuselection:`Admin --> Repositories`.
 2. Select the |repo| you branched.
 3. Select :menuselection:`Switch To --> Branches` and choose the new branch.
 
 For more information, your can read more here on the Git website,
 `Git Branching`_.
 
 Branch a |hg| |repo|
 ^^^^^^^^^^^^^^^^^^^^
 
 .. note::
 
     To use branches in |hg| like |git|, use the `hg bookmark` option instead.
     Also see the :ref:`bvb` section for more information.
 
 To branch a |hg| |repo|, use the following example and push your changes to
 the main |repo|. Once pushed, you can view the new branch in |RCE| by
 selecting :menuselection:`Switch To --> Branches` from the |repo| page.
 
 .. code-block:: bash
 
     $ hg branch example-456
     $ hg ci -m "branch: ticket #456"
     $ hg push --new-branch
 
 Bookmark a |hg| |repo|
 ^^^^^^^^^^^^^^^^^^^^^^
 
 Bookmarks are used in |hg| in much the same way as branches are in |git|. See
 the `Mercurial Bookmarks`_ documentation for more information.
 
 .. code-block:: bash
 
     $ hg bookmark example-456
     $ hg ci -m "branch: ticket #456"
     $ hg push -B example-456
 
 .. image:: ../images/branch-example.png
 
 .. _Git Branching: http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
 .. _Mercurial Bookmarks: https://mercurial.selenic.com/wiki/Bookmarks

docs/collaboration/mention-reviewer-function.rst

@@ -1,39 +1,39 b''
 .. _user-notify-ref:
 
 Using Notifications
 -------------------
 
 To notify users of items that require their attention you can use the mention
-function. The mention function allows you to use ``@username`` within |RCM|.
+function. The mention function allows you to use ``@username`` within |RCE|.
 The notification function can be used within the following
 items to highlight their need for attention:
   
 * Commit messages
 * Pull requests
 * Inline comments
 * Code review
 
 .. note::
   
      Mentioned users will receive an email and a notification.
 
 Pull Request Notifications
 --------------------------
 
 To notify a user of a pull request, use the following steps.
 
 1. Open the repository fork
 2. Select :guilabel:`Open new pull request`
 3. Add the :guilabel:`@username` in the :guilabel:`Pull request viewers`
    input field.
 4. Select :guilabel:`Submit Pull Request`
 
 Commit Message Notifications
 ----------------------------
 
 To notify a user in a commit message, use the following steps.
 
 1. Open a repository with commits in it.
 2. Click on the commit message or revision number.
 3. Add an :guilabel:`@username` in an inline comment or in your approval
    comment and commit.

docs/collaboration/merge-pull-request.rst

@@ -1,35 +1,35 b''
 .. _merge-requests-ref:
 
 Merge a |pr|
 ------------
 
-|RCM| can detect if it can automatically merge the changes in a |pr|. If it
+|RCE| can detect if it can automatically merge the changes in a |pr|. If it
 can, you will see the following message:
 :guilabel:`This pull request can be automatically merged.` To merge,
 click the big blue button! To enable this feature, see :ref:`server-side-merge`.
 
 .. image:: ../images/merge-pr-button.png
 
 If you cannot automatically merge a |pr|, you will see one of the following
 messages:
 
 * :guilabel:`This pull request cannot be merged because of conflicts`
 * :guilabel:`Reviewer approval is pending`
 
 .. _manual-merge-requests-ref:
 
 Manual Merge a |PR|
 ^^^^^^^^^^^^^^^^^^^
 
-If |RCM| cannot safely merge the changes in a |pr|,
+If |RCE| cannot safely merge the changes in a |pr|,
 usually due to conflicts, you need to manually merge the changes on the
 command line. You can see more information for each |repo| type at the
 following links:
 
 * `Git Manual Merging`_
 * `Mercurial Manual Merging`_
 * `Subversion Manual Merging`_
 
 .. _Git Manual Merging: http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
 .. _Mercurial Manual Merging: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
 .. _Subversion Manual Merging: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html

docs/collaboration/notifications-overview.rst

@@ -1,22 +1,22 b''
 Notifications Overview
 ----------------------
 
-|RCM| has an integrated notification system which alerts users to requests
+|RCE| has an integrated notification system which alerts users to requests
 that they have received. Notifications can occur for the following reasons:
 
 * Pull request reviews
 * Commit message mentions
 
 When someone opens a |pr| on one of your |repos|, or adds you as a |pr|
 reviewer, you will receive a notification in |RCE| and an email,
 if not configured see :ref:`set-up-mail`. Also, during the review process you
 receive notifications on the following actions:
 
 * New comments
 * Status changes
 * Inline code review comments
 
 Each notifications provides a link to take you directly to the issue.
 
 .. image:: ../images/notifications.png
    :alt: Notifying Colleagues

docs/collaboration/pull-req-mgmt.rst

@@ -1,47 +1,47 b''
 Pull request management
 -----------------------
 
 .. only:: html
 
-    There are two ways of tracking |prs| within |RCM|.
+    There are two ways of tracking |prs| within |RCE|.
 
     1. :ref:`prs-your-review`
     2. :ref:`prs-per-repo`
 
 .. _prs-your-review:
 
 Pull requests for your review
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To view pull requests for your review, use the following steps:
 
-1. From the |RCM| interface, Select
+1. From the |RCE| interface, Select
    :menuselection:`username --> Notifications`
 2. Select :guilabel:`Pull Requests`
 
 .. image:: ../images/prs-for-my-review.png
    :alt: pull requests for my review
 
 .. _prs-per-repo:
 
 Pull requests per |repo|
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 To view pull requests going to and from a |repo|, use the following steps:
 
 1. Select the |repo| you wish to view
 2. Select :guilabel:`Pull Requests` from the top menu
 3. On the left-hand pane you will see the following options for |pr|
    management on that |repo|:
 
    * :guilabel:`Opened`: Pull requests opened on this |repo|.
    * :guilabel:`Opened by me`: Pull requests you opened on this |repo|.
    * :guilabel:`Awaiting my review`: Pull requests awaiting your review.
    * :guilabel:`Closed`: Closed |prs| on this |repo|.
    * :guilabel:`Awaiting review`: Pull requests still awaiting review on
      this |repo|.
    * :guilabel:`From this repo`: Pull requests opened on another |repo| with
      the changes coming from this |repo|.
 
 .. image:: ../images/pr-screen.png
    :alt: pull request dashboard

docs/collaboration/review-pull-request.rst

@@ -1,27 +1,27 b''
 .. _review-requests-ref:
 
 Review a |pr|
 -------------
 
 To review a pull request, use the following steps:
 
 1. Open the review request from
    :menuselection:`Admin --> Repositories --> repo name --> Pull Requests --> Awaiting my review`
 2. Leave your review comments inline, or in the commit message.
 3. Set the review status from one of the following options:
 
    * :guilabel:`Not Reviewed`
    * :guilabel:`Approved`
    * :guilabel:`Approved & Closed`
    * :guilabel:`Rejected`
    * :guilabel:`Rejected & Closed`
    * :guilabel:`Under Review`
 
 4. Select Comment
 
 When the |pr| is approved by all reviewers you will be able to merge
-automatically if |RCM| detects that it can do so safely. You will see this
+automatically if |RCE| detects that it can do so safely. You will see this
 message: `This pull request can be automatically merged.`
 
 If rejected, you can fix the issues raised during review and then update the
 |pr|.

docs/collaboration/supported-workflows.rst

@@ -1,9 +1,9 b''
 Supported Workflows
 -------------------
 
-|RCM| can be used to develop using a variety of different workflows.
+|RCE| can be used to develop using a variety of different workflows.
 
 * Centralized, using |svn|, |git|, or |hg| |repos|
 * Feature-Branch, using |git| or |hg| |repos|
 * Fork-Pull, using |git| or |hg| |repos|
 * Gitflow, using |git| |repos|

docs/common.py

@@ -1,36 +1,32 b''
 # Try and keep this list alphabetical
 # ui is for user interface elements and messages
 # button - that's obvious
 
 rst_epilog = '''
 .. |AE| replace:: Appenlight
 .. |authtoken| replace:: Authentication Token
 .. |authtokens| replace:: **Auth Tokens**
 .. |RCCEshort| replace:: Community
 .. |RCEEshort| replace:: Enterprise
 .. |git| replace:: Git
 .. |hg| replace:: Mercurial
 .. |svn| replace:: Subversion
 .. |LDAP| replace:: LDAP / Active Directory
 .. |os| replace:: operating system
 .. |OS| replace:: Operating System
 .. |PY| replace:: Python
 .. |pr| replace:: pull request
 .. |prs| replace:: pull requests
 .. |psf| replace:: Python Software Foundation
 .. |repo| replace:: repository
 .. |repos| replace:: repositories
-.. |RCI| replace:: RhodeCode Control
 .. |RCC| replace:: RhodeCode Control
-.. |RCV| replace:: RhodeCode Enterprise
-.. |RCM| replace:: RhodeCode Enterprise
 .. |RCE| replace:: RhodeCode Enterprise
 .. |RCCE| replace:: RhodeCode Community
 .. |RCEE| replace:: RhodeCode Enterprise
 .. |RCX| replace:: RhodeCode Extensions
 .. |RCT| replace:: RhodeCode Tools
 .. |RCEBOLD| replace:: **RhodeCode Enterprise**
 .. |RCEITALICS| replace:: `RhodeCode Enterprise`
-.. |RC| replace:: RhodeCode
 .. |RNS| replace:: Release Notes
 '''

docs/extensions/extensions-hooks.rst

@@ -1,36 +1,36 b''
 .. _extensions-hooks-ref:
 
 Extensions & Hooks
 ==================
 
 The extensions & hooks section references three concepts regularly,
 so to clarify what is meant each time, read the following definitions:
 
 * **Plugin**: A Plugin is software that adds a specific feature to
   an existing software application.
 * **Extension**: An extension extends the capabilities of,
   or the data available to, an existing software application.
 * **Hook**: A hook intercepts function calls, messages, or events passed
   between software components and can be used to trigger plugins, or their
   extensions.
 
 
 Hooks
 -----
 
-Within |RCM| there are two types of supported hooks.
+Within |RCE| there are two types of supported hooks.
 
 * **Internal built-in hooks**: The internal |hg|, |git| or |svn| hooks are
   triggered by different VCS operations, like push, pull,
   or clone and are non-configurable, but you can add your own VCS hooks,
   see :ref:`custom-hooks`.
 * **Custom rcextensions hooks**: User defined hooks centre around the lifecycle of
   certain actions such are |repo| creation, user creation etc. The actions
   these hooks trigger can be rejected based on the API permissions of the
   user calling them.
 
 On instructions how to use the custom `rcextensions`
 see :ref:`integrations-rcextensions` section.
 
 
 

docs/index.rst

@@ -1,87 +1,87 b''
-|RCM|
+|RCE|
 =====
 
-|RCM| is a high-performance source code management and collaboration system.
+|RCE| is a high-performance source code management and collaboration system.
 It enables you to develop projects securely behind the firewall while
 providing collaboration tools that work with |git|, |hg|,
 and |svn| |repos|. The user interface allows you to create, edit,
 and commit files and |repos| while managing their security permissions.
 
-|RCM| provides the following features:
+|RCE| provides the following features:
 
 * Source code management.
 * Extended permissions management.
 * Integrated code collaboration tools.
 * Integrated code review and notifications.
 * Scalability provided by multi-node setup.
 * Fully programmable automation API.
 * Web-based hook management.
 * Native |svn| support.
 * Migration from existing databases.
-* |RCM| SDK.
+* |RCE| SDK.
 * Built-in analytics
 * Built in integrations including: Slack, Webhooks (used for Jenkins/TeamCity and other CIs), Jira, Redmine, Hipchat
 * Pluggable authentication system.
 * Support for AD, |LDAP|, Crowd, CAS, PAM.
 * Support for external authentication via Oauth Google, Github, Bitbucket, Twitter.
 * Debug modes of operation.
 * Private and public gists.
 * Gists with limited lifetimes and within instance only sharing.
 * Fully integrated code search function.
 * Always on SSL connectivity.
 
 .. only:: html
 
    Table of Contents
    -----------------
 
 .. toctree::
    :maxdepth: 1
    :caption: Admin Documentation
 
    install/quick-start
    install/install-database
    install/install-steps
    admin/system-overview
    nix/default-env
    admin/system-admin
    admin/user-admin
    admin/setting-repo-perms
    admin/security-tips
    auth/auth
    issue-trackers/issue-trackers
    admin/lab-settings
 
 .. toctree::
    :maxdepth: 1
    :caption: Feature Documentation
 
    collaboration/collaboration
    collaboration/review-notifications
    collaboration/pull-requests
    code-review/code-review
    integrations/integrations
 
 .. toctree::
    :maxdepth: 1
    :caption: Developer Documentation
 
    api/api
    tools/rhodecode-tools
    extensions/extensions-hooks
    contributing/contributing
 
 .. toctree::
    :maxdepth: 1
    :caption: User Documentation
 
    usage/basic-usage
    tutorials/tutorials
 
 .. toctree::
    :maxdepth: 1
    :caption: About
 
    known-issues/known-issues
    release-notes/release-notes
    admin/glossary

docs/install/install-database.rst

@@ -1,68 +1,66 b''
 .. _rhodecode-database-ref:
 
 Supported Databases
 ===================
 
 .. important::
 
-   We do not recommend using SQLite in a production environment. It is
-   supported by |RCE| for evaluation purposes.
+   We do not recommend using SQLite in a production environment of more than 5 people.
+   It is not suited for higher usage and mayb cause problems.
+
+
+|RCE| supports the following databases. The recommended encoding is UTF-8.
+
+.. only:: latex
+
+   * :ref:`install-sqlite-database`
+   * :ref:`install-mysql-database`
+   * :ref:`install-postgresql-database`
+
+.. toctree::
+
+   using-mysql
+   using-postgresql
+   using-sqllite
+
 
 Database Overview
 -----------------
 
 Prior to installing |RCE| you should install and set up your database.
 This means carrying out the following tasks:
 
 1. Install the database software of your choice.
 2. Using the relevant instructions, create a user on that database to use
    with |RCE|.
 3. Create a database, granting that user read/write access.
 4. During |RCE| installation you will be prompted for these user credentials,
    enter them where appropriate. These credentials will be what |RCE| uses
    to read/write from the database tables.
 
 Version Differences
 -------------------
 
 |RCE| releases 2(Major).x(Minor).x(Bug Fix) and 3.x.x use different database
 schemas. Therefore, if you wish to run multiple instances using one database,
 you can only do so using the same Minor Release numbered versions.
 Though Bug Fix updates rarely have a database change, it is recommended to use
 identical |RCE| version numbers for multi-instance setups.
 
 You can use the same database server to run multiple databases for differing
 version numbers, but you will need separate databases for each |RCE| version on
 that server. You can specify the database during installation, use the
 following example to configure the correct one.
 
 .. code-block:: bash
 
      Database type - [s]qlite, [m]ysql, [p]ostresql:
      PostgreSQL selected
      Database host [127.0.0.1]:
      Database port [5432]:
      Database username: rhodecode
      Database password: somepassword
      # Specify the database you with to use on that server
      # for the RCE instance you are installing
      Database name: example-db-name-for-2xx # The 2xx version database
      Database name: example-db-name-for-3xx # The 3xx version database
-
-Supported Databases
--------------------
-
-|RCM| supports the following databases. The recommended encoding is Unicode
-UTF-8.
-
-.. only:: latex
-
-   * :ref:`install-sqlite-database`
-   * :ref:`install-mysql-database`
-   * :ref:`install-postgresql-database`
-
-.. toctree::
-
-   using-mysql
-   using-postgresql
-   using-sqllite

docs/install/install-steps.rst

@@ -1,14 +1,14 b''
 .. _rhodecode-post-instal-ref:
 
 Post Installation Tasks
 =======================
 
 The following tasks are the most common post installation requirements. Use
-the information in these sections to configure your instance of |RCM|.
+the information in these sections to configure your instance of |RCE|.
 
 .. toctree::
 
    setup-email
    database-string
    configure-celery
    migrate-repos

docs/install/migrate-repos.rst

@@ -1,23 +1,23 b''
 .. _mig-repos:
 
 Migrating |repos|
 -----------------
 
-If you have installed |RCM| and have |repos| that you wish to migrate into
+If you have installed |RCE| and have |repos| that you wish to migrate into
 the system, use the following instructions.
 
-1. On the |RCM| interface, check your |repo| storage location under
+1. On the |RCE| interface, check your |repo| storage location under
    :menuselection:`Admin --> Settings --> System Info`. For example,
    Storage location: /home/{username}/repos.
 
-2. Copy the |repos| that you want |RCM| to manage to this location.
+2. Copy the |repos| that you want |RCE| to manage to this location.
 3. Remap and rescan the |repos|, see :ref:`remap-rescan`
 
 .. important::
 
-   Directories create |repo| groups inside |RCM|.
+   Directories create |repo| groups inside |RCE|.
 
-   Importing adds |RCM| git hooks to your |repos|.
+   Importing adds |RCE| git hooks to your |repos|.
 
    You should verify if custom ``.hg`` or ``.hgrc`` files inside
-   repositories should be adjusted since |RCM| reads the content of them.
+   repositories should be adjusted since |RCE| reads the content of them.

docs/install/quick-start.rst

@@ -1,110 +1,113 b''
 .. _quick-start:
 
 Quick Start Installation Guide
 ==============================
 
 .. important::
 
     These are quick start instructions. To optimize your |RCE|,
     |RCC|, and |RCT| usage, read the more detailed instructions in our guides.
     For detailed installation instructions, see
     :ref:`RhodeCode Control Documentation <control:rcc>`
 
 .. tip::
 
    If using a non-SQLite database, install and configure the database, create
    a new user, and grant permissions. You will be prompted for this user's
    credentials during |RCE| installation. See the relevant database
    documentation for more details.
 
 To get |RCE| up and running, run through the below steps:
 
 1. Download the latest |RCC| installer from `rhodecode.com/download`_.
    If you don't have an account, sign up at `rhodecode.com/register`_.
 
 2. Run the |RCC| installer and accept the End User Licence using the
    following example:
 
 .. code-block:: bash
 
-    $ chmod 755 RhodeCode-installer-linux-*
+    $ chmod +x RhodeCode-installer-linux-*
     $ ./RhodeCode-installer-linux-*
 
+    Do you accept the RhodeCode Control license?
+    Press [Y] to accept license and [V] to view license text: y
+
 3. Install a VCS Server, and configure it to start at boot.
 
 .. code-block:: bash
 
     $ rccontrol install VCSServer
 
     Agree to the licence agreement? [y/N]: y
     IP to start the server on [127.0.0.1]:
     Port for the server to start [10005]:
     Creating new instance: vcsserver-1
     Installing RhodeCode VCSServer
     Configuring RhodeCode VCS Server ...
     Supervisord state is: RUNNING
     Added process group vcsserver-1
 
 
 4. Install |RCEE| or |RCCE|. If using MySQL or PostgreSQL, during
    installation you'll be asked for your database credentials, so have them at hand.
    Mysql or Postgres needs to be running and a new database needs to be created.
    You don't need any credentials or to create a database for SQLite.
 
 .. code-block:: bash
    :emphasize-lines: 11-16
 
     $ rccontrol install Community
 
     or
 
     $ rccontrol install Enterprise
 
     Username [admin]: username
     Password (min 6 chars):
     Repeat for confirmation:
     Email: [e-mail]
     Respositories location [/home/brian/repos]:
     IP to start the Enterprise server on [127.0.0.1]:
     Port for the Enterprise server to use [10004]:
     Database type - [s]qlite, [m]ysql, [p]ostresql:
     PostgreSQL selected
     Database host [127.0.0.1]:
     Database port [5432]:
     Database username: db-user-name
     Database password: somepassword
     Database name: example-db-name
 
 5. Check the status of your installation. You |RCEE|/|RCCE| instance runs
    on the URL displayed in the status message.
 
 .. code-block:: bash
 
     $ rccontrol status
 
     - NAME: enterprise-1
     - STATUS: RUNNING
     - TYPE: Enterprise
     - VERSION: 4.1.0
     - URL: http://127.0.0.1:10003
 
     - NAME: vcsserver-1
     - STATUS: RUNNING
     - TYPE: VCSServer
     - VERSION: 4.1.0
     - URL: http://127.0.0.1:10001
 
 .. note::
 
    Recommended post quick start install instructions:
 
    * Read the documentation
    * Carry out the :ref:`rhodecode-post-instal-ref`
    * Set up :ref:`indexing-ref`
    * Familiarise yourself with the :ref:`rhodecode-admin-ref` section.
 
 .. _rhodecode.com/download/: https://rhodecode.com/download/
 .. _rhodecode.com: https://rhodecode.com/
 .. _rhodecode.com/register: https://rhodecode.com/register/
 .. _rhodecode.com/download: https://rhodecode.com/download/
 

docs/install/setup-email.rst

@@ -1,30 +1,30 b''
 .. _set-up-mail:
 
 Set up Email
 ------------
 
-To setup email with your |RCM| instance, open the default
+To setup email with your |RCE| instance, open the default
 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
 file and uncomment and configure the email section. If it is not there,
 use the below example to insert it.
 
-Once configured you can check the settings for your |RCM| instance on the
+Once configured you can check the settings for your |RCE| instance on the
 :menuselection:`Admin --> Settings --> Email` page.
 
 .. code-block:: ini
 
     ################################################################################
     ## Uncomment and replace with the email address which should receive          ##
     ## any error reports after an application crash                               ##
     ## Additionally these settings will be used by the RhodeCode mailing system   ##
     ################################################################################
     #email_to = admin@localhost
     #app_email_from = rhodecode-noreply@localhost
     #email_prefix = [RhodeCode]
 
     #smtp_server = mail.server.com
     #smtp_username =
     #smtp_password =
     #smtp_port =
     #smtp_use_tls = false
     #smtp_use_ssl = true

docs/install/using-mysql.rst

@@ -1,26 +1,26 b''
 .. _install-mysql-database:
 
 MySQL or MariaDB
 ----------------
 
 To use a MySQL or MariaDB database you should install and configure the
-database before installing |RCM|. This is because during |RCM| installation
+database before installing |RCE|. This is because during |RCE| installation
 you will setup a connection to your MySQL or MariaDB database. To work with
 either, use the following steps:
 
 1. Depending on your |os|, install a MySQL or MariaDB database following the
    appropriate instructions from the `MySQL website`_ or `MariaDB website`_.
 2. Configure the database with a username and password which you will use
-   with |RCM|.
-3. Install |RCM|, and during installation select MySQL as your database.
+   with |RCE|.
+3. Install |RCE|, and during installation select MySQL as your database.
 4. Enter the following information during the database setup:
 
    * Your network IP Address
    * The port number for MySQL or MariaDB access.
      The default port for both is ``3306``
    * Your database username
    * Your database password
    * A new database name
 
 .. _MySQL website: http://www.mysql.com/
 .. _MariaDB website: https://mariadb.com/

docs/install/using-postgresql.rst

@@ -1,24 +1,24 b''
 .. _install-postgresql-database:
 
 PostgreSQL
 ----------
 
 To use a PostgreSQL database, you should install and configure the database
-before installing |RCV|. This is because during |RCV| installation you will
+before installing |RCE|. This is because during |RCE| installation you will
 setup the connection to your PostgreSQL database. To work with PostgreSQL,
 use the following steps:
 
 1. Depending on your |os|, install a PostgreSQL database following the
    appropriate instructions from the `PostgreSQL website`_.
 2. Configure the database with a username and password, which you will use
-   with |RCV|.
-3. Install |RCV|, and during installation select PostgreSQL as your database.
+   with |RCE|.
+3. Install |RCE|, and during installation select PostgreSQL as your database.
 4. Enter the following information during the database setup:
 
    * Your network IP Address
    * The port number for PostgreSQL access; the default port is ``5434``
    * Your database username
    * Your database password
    * A new database name
 
 .. _PostgreSQL website: http://www.postgresql.org/

docs/install/using-sqllite.rst

@@ -1,32 +1,32 b''
 .. _install-sqlite-database:
 
 SQLite
 ------
 
 .. important::
 
     We do not recommend using SQLite in a large development environment
     as it has an internal locking mechanism which can become a performance
     bottleneck when there are more than 5 concurrent users.
 
-|RCM| installs SQLite as the default database if you do not specify another
+|RCE| installs SQLite as the default database if you do not specify another
 during installation. SQLite is suitable for small teams,
 projects with a low load, and evaluation purposes since it is built into
-|RCM| and does not require any additional database server.
+|RCE| and does not require any additional database server.
 
 Using MySQL or PostgreSQL in an large setup gives you much greater
 performance, and while migration tools exist to move from one database type
 to another, it is better to get it right first time and to immediately use
-MySQL or PostgreSQL when you deploy |RCM| in a production environment.
+MySQL or PostgreSQL when you deploy |RCE| in a production environment.
 
 Migrating From SQLite to PostgreSQL
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you started working with SQLite and now need to migrate your database
 to PostgreSQL, you can contact [e-mail] for some help. We have a
 set of scripts that enable SQLite to PostgreSQL migration. These scripts have
 been tested, and work with PostgreSQL 9.1+.
 
 .. note::
 
     There are no SQLite to MySQL or MariaDB scripts available.

docs/integrations/integrations.rst

@@ -1,60 +1,60 b''
 .. _integrations:
 
 Integrations
 ------------
 
 |RCE| supports integrations with external services for various events,
 such as commit pushes and pull requests. Multiple integrations of the same type
 can be added at the same time; this is useful for posting different events to
 different Slack channels, for example.
 
 Supported integrations
 ^^^^^^^^^^^^^^^^^^^^^^
 
-================================    ============    ========================================
-Type/Name                           |RC| Edition    Description
-================================    ============    ========================================
-:ref:`integrations-webhook`         |RCCEshort|     Trigger events as `json` to a custom url
-:ref:`integrations-slack`           |RCCEshort|     Integrate with https://slack.com/
-:ref:`integrations-hipchat`         |RCCEshort|     Integrate with https://www.hipchat.com/
-:ref:`integrations-email`           |RCCEshort|     Send repo push commits by email
-:ref:`integrations-ci`              |RCCEshort|     Trigger Builds for Common CI Systems
-:ref:`integrations-rcextensions`    |RCCEshort|     Advanced low-level integration framework
+================================    ==================    ========================================
+Type/Name                           RhodeCode Edition     Description
+================================    ==================    ========================================
+:ref:`integrations-webhook`         |RCCEshort|           Trigger events as `json` to a custom url
+:ref:`integrations-slack`           |RCCEshort|           Integrate with https://slack.com/
+:ref:`integrations-hipchat`         |RCCEshort|           Integrate with https://www.hipchat.com/
+:ref:`integrations-email`           |RCCEshort|           Send repo push commits by email
+:ref:`integrations-ci`              |RCCEshort|           Trigger Builds for Common CI Systems
+:ref:`integrations-rcextensions`    |RCCEshort|           Advanced low-level integration framework
 
-:ref:`integrations-jenkins`         |RCEEshort|     Trigger Builds for Jenkins CI System
-:ref:`integrations-redmine`         |RCEEshort|     Close/Resolve/Reference Redmine issues
-:ref:`integrations-jira`            |RCEEshort|     Close/Resolve/Reference JIRA issues
-================================    ============    ========================================
+:ref:`integrations-jenkins`         |RCEEshort|           Trigger Builds for Jenkins CI System
+:ref:`integrations-redmine`         |RCEEshort|           Close/Resolve/Reference Redmine issues
+:ref:`integrations-jira`            |RCEEshort|           Close/Resolve/Reference JIRA issues
+================================    ==================    ========================================
 
 .. _creating-integrations:
 
 Creating an Integration
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Integrations can be added globally via the admin UI:
 
 :menuselection:`Admin --> Integrations`
 
 or per repository in each repository's settings:
 
 :menuselection:`Admin --> Repositories --> Edit --> Integrations`
 
 To create an integration, select the type from the list in the *Create New
 Integration* section.
 
 The *Current Integrations* section shows existing integrations that have been
 created along with their type (eg. Slack) and enabled status.
 
 See pages specific to each type of integration for more instructions:
 
 .. toctree::
 
    slack
    hipchat
    redmine
    jira
    webhook
    email
    ci
    jenkins
    integrations-rcextensions

docs/issue-trackers/issue-trackers.rst

@@ -1,81 +1,81 b''
 .. _rhodecode-issue-trackers-ref:
 
 Issue Tracker Integration
 =========================
 
 You can set an issue tracker connection in two ways with |RCE|.
 
 * At the instance level, you can set a default issue tracker.
 * At the |repo| level, you can configure an integration with a different issue
   tracker.
 
-To integrate |RCM| with an issue tracker, you need to define a regular
+To integrate |RCE| with an issue tracker, you need to define a regular
 expression that will fetch the issue ID stored in commit messages, and replace
 it with a URL. This enables |RCE| to generate a link matching each issue to the
 target |repo|.
 
 Default Issue Tracker Configuration
 -----------------------------------
 
 To integrate your issue tracker, use the following steps:
 
 1. Open :menuselection:`Admin --> Settings --> Issue Tracker`.
 2. In the new entry field, enter the following information:
 
     * :guilabel:`Description`: A name for this set of rules.
     * :guilabel:`Pattern`: The regular expression that will match issues
       tagged in commit messages, or more see :ref:`issue-tr-eg-ref`.
     * :guilabel:`URL`: The URL to your issue tracker.
     * :guilabel:`Prefix`: The prefix with which you want to mark issues.
 
 3. Select **Add** so save the rule to your issue tracker configuration.
 
 Repository Issue Tracker Configuration
 --------------------------------------
 
 You can configure specific |repos| to use a different issue tracker than the
 default one. See the instructions in :ref:`repo-it`
 
 .. _issue-tr-eg-ref:
 
 Jira Integration
 ----------------
 
 * Regex = ``(?:^#|\s#)(\w+-\d+)``
 * URL = ``https://myissueserver.com/browse/${id}``
 * Issue Prefix = ``#``
 
 Confluence (Wiki)
 -----------------
 
 * Regex = ``(?:conf-)([A-Z0-9]+)``
 * URL = ``https://example.atlassian.net/display/wiki/${id}/${repo_name}``
 * issue prefix = ``CONF-``
 
 Redmine Integration
 -------------------
 
 * Regex = ``(issue-+\d+)``
 * URL = ``https://myissueserver.com/redmine/issue/${id}``
 * Issue Prefix = ``issue-``
 
 Redmine (wiki)
 --------------
 
 * Regex = ``(?:wiki-)([a-zA-Z0-9]+)``
 * URL = ``https://example.com/redmine/projects/wiki/${repo_name}``
 * Issue prefix = ``Issue-``
 
 Pivotal Tracker
 ---------------
 
 * Regex = ``(?:pivot-)(?<project_id>\d+)-(?<story>\d+)``
 * URL = ``https://www.pivotaltracker.com/s/projects/${project_id}/stories/${story}``
 * Issue prefix = ``Piv-``
 
 Trello
 ------
 
 * Regex = ``(?:trello-)(?<card_id>[a-zA-Z0-9]+)``
 * URL = ``https://trello.com/example.com/${card_id}``
 * Issue prefix = ``Trello-``

docs/known-issues/error-msg-guide.rst

@@ -1,15 +1,15 b''
 .. _err-msg-ref:
 
 Error Message Guide
 ===================
 
 Error Message
 Error creating repository repo-name
 
 Cause
-As of |RCM| 3.0, a VCS Server is required to run backend operations.
+As of |RCE| 3.0, a VCS Server is required to run backend operations.
 
 Solution
 Install a VCS Server. See the `Install a VCS Server`_ section of |RCC|
 
 .. _Install a VCS Server: https://docs.rhodecode.com/RhodeCode-Control/tasks/upgrade-from-cli.html#install-a-vcs-server
  No newline at end of file

docs/nix/nix.rst

@@ -1,31 +1,31 b''
 .. _rhodecode-nix-ref:
 
 Nix Packaging
 =============
 
-|RCM| is installed using |Nix Package Manager|. The Nix environment provides
+|RCE| is installed using |Nix Package Manager|. The Nix environment provides
 the following features for maintenance and deployment:
 
 * Atomic upgrades and rollbacks
 * Complete dependency management
 * Garbage collection
 * Binary patching
 * Secure channel updates
 * Nix works on Windows, Linux, and OSX
 
 The complete list of dependencies can be found in
 :file:`/opt/rhodecode/store/{unique-hash}`.
 
 .. note::
 
    No |RCE| data is stored in this location.
    
 .. warning::
 
    Never alter any of the packages in the store. Always use the
    :ref:`RhodeCode Control CLI <control:rcc-cli>` update functions to keep
    the packages and instances updated.
 
 .. |Nix Package Manager| raw:: html
 
    <a href="http://nixos.org/nix/" target="_blank">Nix</a>

docs/python-packages-generated.nix

@@ -1,221 +1,221 b''
 # Generated by pip2nix 0.8.0.dev1
 # See https://github.com/johbo/pip2nix
 
 { pkgs, fetchurl, fetchgit, fetchhg }:
 
 self: super: {
   "alabaster" = super.buildPythonPackage {
-    name = "alabaster-0.7.11";
+    name = "alabaster-0.7.12";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/3f/46/9346ea429931d80244ab7f11c4fce83671df0b7ae5a60247a2b588592c46/alabaster-0.7.11.tar.gz";
-      sha256 = "1mvm69xsn5xf1jc45kdq1mn0yq0pfn54mv2jcww4s1vwqx6iyfxn";
+      url = "https://files.pythonhosted.org/packages/cc/b4/ed8dcb0d67d5cfb7f83c4d5463a7614cb1d078ad7ae890c9143edebbf072/alabaster-0.7.12.tar.gz";
+      sha256 = "00nwwjj2d2ym4s2kk217x7jkx1hnczc3fvm8yxbqmsp6b0nxfqd6";
     };
   };
   "babel" = super.buildPythonPackage {
     name = "babel-2.6.0";
     doCheck = false;
     propagatedBuildInputs = [
       self."pytz"
     ];
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/be/cc/9c981b249a455fa0c76338966325fc70b7265521bad641bf2932f77712f4/Babel-2.6.0.tar.gz";
       sha256 = "08rxmbx2s4irp0w0gmn498vns5xy0fagm0fg33xa772jiks51flc";
     };
   };
   "certifi" = super.buildPythonPackage {
-    name = "certifi-2018.8.24";
+    name = "certifi-2018.11.29";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/e1/0f/f8d5e939184547b3bdc6128551b831a62832713aa98c2ccdf8c47ecc7f17/certifi-2018.8.24.tar.gz";
-      sha256 = "0f0nhrj9mlrf79iway4578wrsgmjh0fmacl9zv8zjckdy7b90rip";
+      url = "https://files.pythonhosted.org/packages/55/54/3ce77783acba5979ce16674fc98b1920d00b01d337cfaaf5db22543505ed/certifi-2018.11.29.tar.gz";
+      sha256 = "1dvccavd2fzq4j37w0sznylp92ps14zi6gvlxzm23in0yhzciya7";
     };
   };
   "chardet" = super.buildPythonPackage {
     name = "chardet-3.0.4";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/fc/bb/a5768c230f9ddb03acc9ef3f0d4a3cf93462473795d18e9535498c8f929d/chardet-3.0.4.tar.gz";
       sha256 = "1bpalpia6r5x1kknbk11p1fzph56fmmnp405ds8icksd3knr5aw4";
     };
   };
   "docutils" = super.buildPythonPackage {
     name = "docutils-0.14";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/84/f4/5771e41fdf52aabebbadecc9381d11dea0fa34e4759b4071244fa094804c/docutils-0.14.tar.gz";
       sha256 = "0x22fs3pdmr42kvz6c654756wja305qv6cx1zbhwlagvxgr4xrji";
     };
   };
   "idna" = super.buildPythonPackage {
     name = "idna-2.7";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/65/c4/80f97e9c9628f3cac9b98bfca0402ede54e0563b56482e3e6e45c43c4935/idna-2.7.tar.gz";
       sha256 = "05jam7d31767dr12x0rbvvs8lxnpb1mhdb2zdlfxgh83z6k3hjk8";
     };
   };
   "imagesize" = super.buildPythonPackage {
     name = "imagesize-1.1.0";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/41/f5/3cf63735d54aa9974e544aa25858d8f9670ac5b4da51020bbfc6aaade741/imagesize-1.1.0.tar.gz";
       sha256 = "1dg3wn7qpwmhgqc0r9na2ding1wif9q5spz3j9zn2riwphc2k0zk";
     };
   };
   "jinja2" = super.buildPythonPackage {
     name = "jinja2-2.9.6";
     doCheck = false;
     propagatedBuildInputs = [
       self."markupsafe"
     ];
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/90/61/f820ff0076a2599dd39406dcb858ecb239438c02ce706c8e91131ab9c7f1/Jinja2-2.9.6.tar.gz";
       sha256 = "1zzrkywhziqffrzks14kzixz7nd4yh2vc0fb04a68vfd2ai03anx";
     };
   };
   "markupsafe" = super.buildPythonPackage {
     name = "markupsafe-1.0";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/4d/de/32d741db316d8fdb7680822dd37001ef7a448255de9699ab4bfcbdf4172b/MarkupSafe-1.0.tar.gz";
       sha256 = "0rdn1s8x9ni7ss8rfiacj7x1085lx8mh2zdwqslnw8xc3l4nkgm6";
     };
   };
   "packaging" = super.buildPythonPackage {
-    name = "packaging-17.1";
+    name = "packaging-18.0";
     doCheck = false;
     propagatedBuildInputs = [
       self."pyparsing"
       self."six"
     ];
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/77/32/439f47be99809c12ef2da8b60a2c47987786d2c6c9205549dd6ef95df8bd/packaging-17.1.tar.gz";
-      sha256 = "0nrpayk8kij1zm9sjnk38ldz3a6705ggvw8ljylqbrb4vmqbf6gh";
+      url = "https://files.pythonhosted.org/packages/cf/50/1f10d2626df0aa97ce6b62cf6ebe14f605f4e101234f7748b8da4138a8ed/packaging-18.0.tar.gz";
+      sha256 = "01wq9c53ix5rz6qg2c98gy8n4ff768rmanifm8m5jpjiaizj51h8";
     };
   };
   "pygments" = super.buildPythonPackage {
-    name = "pygments-2.2.0";
+    name = "pygments-2.3.0";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/71/2a/2e4e77803a8bd6408a2903340ac498cb0a2181811af7c9ec92cb70b0308a/Pygments-2.2.0.tar.gz";
-      sha256 = "1k78qdvir1yb1c634nkv6rbga8wv4289xarghmsbbvzhvr311bnv";
+      url = "https://files.pythonhosted.org/packages/63/a2/91c31c4831853dedca2a08a0f94d788fc26a48f7281c99a303769ad2721b/Pygments-2.3.0.tar.gz";
+      sha256 = "1z34ms51dh4jq4h3cizp7vd1dmsxcbvffkjsd2xxfav22nn6lrl2";
     };
   };
   "pyparsing" = super.buildPythonPackage {
-    name = "pyparsing-2.2.0";
+    name = "pyparsing-2.3.0";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/3c/ec/a94f8cf7274ea60b5413df054f82a8980523efd712ec55a59e7c3357cf7c/pyparsing-2.2.0.tar.gz";
-      sha256 = "016b9gh606aa44sq92jslm89bg874ia0yyiyb643fa6dgbsbqch8";
+      url = "https://files.pythonhosted.org/packages/d0/09/3e6a5eeb6e04467b737d55f8bba15247ac0876f98fae659e58cd744430c6/pyparsing-2.3.0.tar.gz";
+      sha256 = "14k5v7n3xqw8kzf42x06bzp184spnlkya2dpjyflax6l3yrallzk";
     };
   };
   "pytz" = super.buildPythonPackage {
     name = "pytz-2018.4";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/10/76/52efda4ef98e7544321fd8d5d512e11739c1df18b0649551aeccfb1c8376/pytz-2018.4.tar.gz";
       sha256 = "0jgpqx3kk2rhv81j1izjxvmx8d0x7hzs1857pgqnixic5wq2ar60";
     };
   };
   "requests" = super.buildPythonPackage {
-    name = "requests-2.19.1";
+    name = "requests-2.20.1";
     doCheck = false;
     propagatedBuildInputs = [
       self."chardet"
       self."idna"
       self."urllib3"
       self."certifi"
     ];
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/54/1f/782a5734931ddf2e1494e4cd615a51ff98e1879cbe9eecbdfeaf09aa75e9/requests-2.19.1.tar.gz";
-      sha256 = "0snf8xxdzsgh1x2zv3vilvbrv9jbpmnfagzzb1rjmmvflckdh8pc";
+      url = "https://files.pythonhosted.org/packages/40/35/298c36d839547b50822985a2cf0611b3b978a5ab7a5af5562b8ebe3e1369/requests-2.20.1.tar.gz";
+      sha256 = "0qzj6cgv3k9wyj7wlxgz7xq0cfg4jbbkfm24pp8dnhczwl31527a";
     };
   };
   "setuptools" = super.buildPythonPackage {
-    name = "setuptools-40.2.0";
+    name = "setuptools-40.6.2";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/ef/1d/201c13e353956a1c840f5d0fbf0461bd45bbd678ea4843ebf25924e8984c/setuptools-40.2.0.zip";
-      sha256 = "19ng5m7kigllg3x96c91y3a2k28g6kwnbb1v4warrnp4xma1v227";
+      url = "https://files.pythonhosted.org/packages/b0/d1/8acb42f391cba52e35b131e442e80deffbb8d0676b93261d761b1f0ef8fb/setuptools-40.6.2.zip";
+      sha256 = "0r2c5hapirlzm34h7pl1lgkm6gk7bcrlrdj28qgsvaqg3f74vfw6";
     };
   };
   "six" = super.buildPythonPackage {
     name = "six-1.11.0";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz";
       sha256 = "1scqzwc51c875z23phj48gircqjgnn3af8zy2izjwmnlxrxsgs3h";
     };
   };
   "snowballstemmer" = super.buildPythonPackage {
     name = "snowballstemmer-1.2.1";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/20/6b/d2a7cb176d4d664d94a6debf52cd8dbae1f7203c8e42426daa077051d59c/snowballstemmer-1.2.1.tar.gz";
       sha256 = "0a0idq4y5frv7qsg2x62jd7rd272749xk4x99misf5rcifk2d7wi";
     };
   };
   "sphinx" = super.buildPythonPackage {
-    name = "sphinx-1.7.8";
+    name = "sphinx-1.8.2";
     doCheck = false;
     propagatedBuildInputs = [
       self."six"
       self."jinja2"
       self."pygments"
       self."docutils"
       self."snowballstemmer"
       self."babel"
       self."alabaster"
       self."imagesize"
       self."requests"
       self."setuptools"
       self."packaging"
       self."sphinxcontrib-websupport"
       self."typing"
     ];
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/ac/54/4ef326d0c654da1ed91341a7a1f43efc18a8c770ddd2b8e45df97cb79d82/Sphinx-1.7.8.tar.gz";
-      sha256 = "1ryz0w4c31930f1br2sjwrxwx9cmsy7cqdb0d81g98n9bj250w50";
+      url = "https://files.pythonhosted.org/packages/4c/ea/7388faba7cf02999e1bc42f6a8eb1ea0120aec3dd93474cee21cea2d693f/Sphinx-1.8.2.tar.gz";
+      sha256 = "1sia2h5rfzy76rbsd69ghr8bbidhsjzzinf3f523dcmivp5k41qj";
     };
   };
   "sphinx-rtd-theme" = super.buildPythonPackage {
     name = "sphinx-rtd-theme-0.4.1";
     doCheck = false;
     propagatedBuildInputs = [
       self."sphinx"
     ];
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/f2/b0/a1933d792b806118ddbca6699f2e2c844d9b1b16e84a89d7effd5cd2a800/sphinx_rtd_theme-0.4.1.tar.gz";
       sha256 = "1xkyqam8dzbjaymdyvkiif85m4y3jf8crdiwlgcfp8gqcj57aj9v";
     };
   };
   "sphinxcontrib-websupport" = super.buildPythonPackage {
     name = "sphinxcontrib-websupport-1.1.0";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/07/7a/e74b06dce85555ffee33e1d6b7381314169ebf7e31b62c18fcb2815626b7/sphinxcontrib-websupport-1.1.0.tar.gz";
       sha256 = "1ff3ix76xi1y6m99qxhaq5161ix9swwzydilvdya07mgbcvpzr4x";
     };
   };
   "typing" = super.buildPythonPackage {
     name = "typing-3.6.6";
     doCheck = false;
     src = fetchurl {
       url = "https://files.pythonhosted.org/packages/bf/9b/2bf84e841575b633d8d91ad923e198a415e3901f228715524689495b4317/typing-3.6.6.tar.gz";
       sha256 = "0ba9acs4awx15bf9v3nrs781msbd2nx826906nj6fqks2bvca9s0";
     };
   };
   "urllib3" = super.buildPythonPackage {
-    name = "urllib3-1.23";
+    name = "urllib3-1.24.1";
     doCheck = false;
     src = fetchurl {
-      url = "https://files.pythonhosted.org/packages/3c/d2/dc5471622bd200db1cd9319e02e71bc655e9ea27b8e0ce65fc69de0dac15/urllib3-1.23.tar.gz";
-      sha256 = "1bvbd35q3zdcd7gsv38fwpizy7p06dr0154g5gfybrvnbvhwb2m6";
+      url = "https://files.pythonhosted.org/packages/b1/53/37d82ab391393565f2f831b8eedbffd57db5a718216f82f1a8b4d381a1c1/urllib3-1.24.1.tar.gz";
+      sha256 = "08lwd9f3hqznyf32vnzwvp87pchx062nkbgyrf67rwlkgj0jk5fy";
     };
   };
 
 ### Test requirements
 
   
 }

docs/release-notes/release-notes-3.0.0.rst

@@ -1,166 +1,166 b''
 |RCE| 3.0.0 |RNS|
 -----------------
 
-As |RCM| 3.0 is a big release, the release notes have been split into the following sections:
+As |RCE| 3.0 is a big release, the release notes have been split into the following sections:
 
 * :ref:`general-rn-ref`
 * :ref:`security-rn-ref`
 * :ref:`api-rn-ref`
 * :ref:`performance-rn-ref`
 * :ref:`prs-rn-ref`
 * :ref:`gists-rn-ref`
 * :ref:`search-rn-ref`
 * :ref:`fixes-rn-ref`
 
 .. _general-rn-ref:
 
 General
 ^^^^^^^
  * Released 2015-01-27
  * Basic |svn| support added
  * GPLv3 components removed
  * Server/Client architecture for VCS systems created
  * Python 2.5 and 2.6 support deprecated
  * Server info pages now show gist/archive cache storage, and also CPU/Memory/Load information.
  * Added new bulk commit (changeset) status comment form into compare view which enables bulk code-reviews without
    opening a pull-request.
  * License checks and limits now only apply to active users.
  * Removed CLI command for |repo| scans as it can be done via an API call.
  * VCS backends can be globally enabled/disabled from the :file:`rhodecode.ini` file.
  * Added a UI option to set default rendering to rst or markdown.
  * Added syntax highlighting to 2 way compare diff.
  * Markup rendering can now render checkboxes for easy checklists generation.
  * Gravatars are now retina ready.
  * Admins can define custom CSS or JavaScript in the header or footer via new pre/post code options.
  * Replaced ``graph.js`` with ``commits-graph.js`` html5 implementation.
  * Added editable owner field for repository groups, and user group.
  * Added an option to detach/delete user repositories when deleting users from the system.
  * Added a Supervisor control page that shows status of processes.
  * User admin grid can now filter by username OR email.
  * Added personal |repo| group link for easier fork creation.
  * Added support for using subdirectories when creating and uploading new files.
  * Added option to rename a file from the web interface.
  * Added arrow key navigation to file filter and fixed the back button behaviour.
  * Added fuzzy matching to file filter.
  * Added functionality to create folder structures along with files when adding content via the web interface.
  * Separated default permissions UI into `global`, `user`, or `object` permissions management.
  * Added an inheritance flag to object permissions which allows for explicit permissions which disregard global
    permissions.
  * Added post create repository group hook.
  * Added trigger push hooks on online file editor.
  * Added default title for pull request.
  * More detailed logs during Authentication.
  * More explicit logging when permission checks occur.
  * Switched the implementation of |git| ``fetch clone pull checkout`` commands to pure |py| without any subprocess
    calls.
  * Introduced the ``rcserver`` command for custom development.
  * Added the ability to force no cache archived via the ``GET no_cache`` flag
 
 .. _security-rn-ref:
 
 Security
 ^^^^^^^^
 
  * CSRF (Cross-Site Request Forgery) tokens now in all pages that use forms.
  * The ``clone_url`` field is now AES encrypted inside the database.
  * ACLs (Access Control Lists) are checked on the gist edit page for logged in users.
  * New repository groups and repositories are created with 0755 permissions and not not 0777.
  * Explicit RSS tokens are used for the RSS journal, when leaked, limits access to RSS only.
  * Fixed XSS issues when rendering raw SVG files.
  * Added force password reset option for users.
  * IP list now accepts comma-separated values, and also ranges using `-` to specify multiple addresses.
  * Added ``auth tokens``, these authentication tokens can be used as an alternative to passwords.
  * Added roles (``http, api, rss, all, vcs``) into authentication tokens (previously called ``apikeys``).
  * LDAP Group Support added.
  * Added JASIG CAS auth plugin support.
  * Added a plugin parameter that defines if a plugin can create new users on the fly.
 
 .. _api-rn-ref:
 
 API
 ^^^
  * Added permissions delegation when creating |repos| or |repo| groups.
  * Added ``strip`` support for |hg| and |git| |repos|.
  * Added comments API for commits.
  * Added add/remove methods for extra fields in repositories.
  * ``get_*`` calls now use ``permission()`` and ``permission_user_group()`` methods for unified permissions structure.
  * ``get_repo_nodes`` information sending has changed and is no longer a boolean flag, it's now ``basic`` or ``full``.
  * Due to configurable backends ``repo_type`` is now mandatory parameter for the ``create_repo`` call.
 
 .. _performance-rn-ref:
 
 Performance
 ^^^^^^^^^^^
 
  * Significant performance improvements across all application functions.
  * HTTP Authentication performance enhancements.
  * Added a ``scope`` variable to the permissions fetching function which improves building permission trees in large
    amounts by a factor of 10.
  * Implemented caching logic for all authentication plugins. The ``AUTH_CACHE_TTL = <int>`` property now allow you to
    set the cache in seconds.
 
 .. _prs-rn-ref:
 
 Pull Requests
 ^^^^^^^^^^^^^
 
  * Pull requests can be now updated and merged from the web interface
  * Fixed creating a Mercurial |pr| from a bookmark.
  * Forbid closing pull requests when calculated status is different that the approved or rejected version.
  * Properly display calculated pull request review status on listing page.
  * Disable delete comment button if |pr| is closed.
 
 .. _gists-rn-ref:
 
 Gists
 ^^^^^
  * New UI based on grids with filtering.
  * Super-admins can see all gists.
  * Gists can now be created with a custom names.
 
 .. _search-rn-ref:
 
 Search
 ^^^^^^
 
  * New API based indexer.
  * Added the ability to create size limits for indexed files.
  * Added a new mapping configuration file which gives a very high level of flexibility when creating full text search.
 
 .. _fixes-rn-ref:
 
 Fixes
 ^^^^^
 
  * General: fixed issues with dependent objects, such as ``users`` in ``user groups``. Cleaning up these dependent
    objects is now done in a safe way.
  * General: deleting a ``user group`` from **settings > advanced** will use force removal and cleanup from all
    associations.
  * General: fixed issue with filter proxy middleware it's now more error prone.
  * General: fixed issues with unable to create fork inside a group.
  * General: fixed bad logic in ``ext_json`` lib, that checked bool on microseconds, in case it was 0 bool it returned False.
  * General: authors in annotation mode shows authors of current source, not from all history (that is in normal mode)
  * Permissions: fix issue when inherit flag for user group stopped working after initial permissions set.
  * |git|: fixed shallow clones.
  * |git|: added ``\n`` into the service line of |git| protocol. It is in the specifications and some python clients
    require this.
  * |hg|: fix thread safety for mercurial ``in-memory`` commits.
  * Windows: fixed issue with shebang and env headers.
  * MySQL: fixed database fields with 256 char length with added indexes. Mysql had problems with them.
  * Database: fixed bad usage of matching using ``ILIKE``. Previously it could happen that if you had
    ``[e-mail]`` and ``[e-mail]`` emails, using ``[e-mail]`` would match both.
  * VCS: fixed issues with double new lines on the commit patches.
  * VCS: repository locking now requires write permission to repository. If we allowed locking with read,
    people can lock repository without an option to unlock it.
  * Models: removed the ``isdigit`` call that can create issues when names are actually numbers on fetching objects.
  * Files: Fix bug with show authors in annotate view.
  * Hooks: truncate excessive commit lists on ``post_push`` hook.
  * Hooks: in |git|, support added to set the default branch if it is not ``master``.
  * Notifications: now can be marked as read when you are not admin.
  * Notifications: marking all notifications as read will hide the counter.
  * Frontend: fixed branch-tag switcher multiple ajax calls.
  * Repository group: |repo| group owners can now change group settings even if they don't have access to top-level
    permissions.
  * Repositories: if you set ``Fork of`` in advanced repository settings it will now only show valid repositories
    with the same type.
 

docs/release-notes/release-notes.rst

@@ -1,125 +1,126 b''
 .. _rhodecode-release-notes-ref:
 
 Release Notes
 =============
 
 |RCE| 4.x Versions
 ------------------
 
 .. toctree::
    :maxdepth: 1
 
+   release-notes-4.15.0.rst
    release-notes-4.14.1.rst
    release-notes-4.14.0.rst
    release-notes-4.13.3.rst
    release-notes-4.13.2.rst
    release-notes-4.13.1.rst
    release-notes-4.13.0.rst
    release-notes-4.12.4.rst
    release-notes-4.12.3.rst
    release-notes-4.12.2.rst
    release-notes-4.12.1.rst
    release-notes-4.12.0.rst
    release-notes-4.11.6.rst
    release-notes-4.11.5.rst
    release-notes-4.11.4.rst
    release-notes-4.11.3.rst
    release-notes-4.11.2.rst
    release-notes-4.11.1.rst
    release-notes-4.11.0.rst
    release-notes-4.10.6.rst
    release-notes-4.10.5.rst
    release-notes-4.10.4.rst
    release-notes-4.10.3.rst
    release-notes-4.10.2.rst
    release-notes-4.10.1.rst
    release-notes-4.10.0.rst
    release-notes-4.9.1.rst
    release-notes-4.9.0.rst
    release-notes-4.8.0.rst
    release-notes-4.7.2.rst
    release-notes-4.7.1.rst
    release-notes-4.7.0.rst
    release-notes-4.6.1.rst
    release-notes-4.6.0.rst
    release-notes-4.5.2.rst
    release-notes-4.5.1.rst
    release-notes-4.5.0.rst
    release-notes-4.4.2.rst
    release-notes-4.4.1.rst
    release-notes-4.4.0.rst
    release-notes-4.3.1.rst
    release-notes-4.3.0.rst
    release-notes-4.2.1.rst
    release-notes-4.2.0.rst
    release-notes-4.1.2.rst
    release-notes-4.1.1.rst
    release-notes-4.1.0.rst
    release-notes-4.0.1.rst
    release-notes-4.0.0.rst
 
 |RCE| 3.x Versions
 ------------------
 
 .. toctree::
    :maxdepth: 1
 
    release-notes-3.8.4.rst
    release-notes-3.8.3.rst
    release-notes-3.8.2.rst
    release-notes-3.8.1.rst
    release-notes-3.8.0.rst
    release-notes-3.7.1.rst
    release-notes-3.7.0.rst
    release-notes-3.6.1.rst
    release-notes-3.6.0.rst
    release-notes-3.5.2.rst
    release-notes-3.5.1.rst
    release-notes-3.5.0.rst
    release-notes-3.4.1.rst
    release-notes-3.4.0.rst
    release-notes-3.3.4.rst
    release-notes-3.3.3.rst
    release-notes-3.3.2.rst
    release-notes-3.3.1.rst
    release-notes-3.3.0.rst
    release-notes-3.2.3.rst
    release-notes-3.2.2.rst
    release-notes-3.2.1.rst
    release-notes-3.2.0.rst
    release-notes-3.1.1.rst
    release-notes-3.1.0.rst
    release-notes-3.0.2.rst
    release-notes-3.0.1.rst
    release-notes-3.0.0.rst
 
 |RCE| 2.x Versions
 ------------------
 
 .. toctree::
    :maxdepth: 1
 
    release-notes-2.2.8.rst
    release-notes-2.2.7.rst
    release-notes-2.2.6.rst
    release-notes-2.2.5.rst
    release-notes-2.2.4.rst
    release-notes-2.2.3.rst
    release-notes-2.2.2.rst
    release-notes-2.2.1.rst
    release-notes-2.2.0.rst
    release-notes-2.1.0.rst
    release-notes-2.0.2.rst
    release-notes-2.0.1.rst
    release-notes-2.0.0.rst
 
 |RCE| 1.x Versions
 ------------------
 
 .. toctree::
    :maxdepth: 1
 
    release-notes-1.7.2.rst
    release-notes-1.7.1.rst
    release-notes-1.7.0.rst
    release-notes-1.6.0.rst

docs/requirements_docs.txt

@@ -1,8 +1,8 b''
-sphinx==1.7.8
+sphinx==1.8.2
 six==1.11.0
 sphinx_rtd_theme==0.4.1
 docutils==0.14.0
-pygments==2.2.0
+pygments==2.3.0
 markupsafe==1.0.0
 jinja2==2.9.6
 pytz==2018.4

docs/tools/install-tools.rst

@@ -1,85 +1,85 b''
 .. _install-tools:
 
 |RCT| Installation
 ------------------
 
 As of |RCE| 3.4.1 |RCT| is installed automatically on the server with |RCE|. You
 do not need to install |RCT| on the server, but you will need to install them
 on machines that need remote access. The tools are linked to the instance
 folder, for example :file:`~/.rccontrol/{instance-id}/profile/bin`
 
 You can list the available tools using the following example, and the valid
 tools options are those which correspond with those in the :ref:`rc-tools`
 section.
 
 .. code-block:: bash
 
     $ ls ~/.rccontrol/enterprise-4/profile/bin/
 
     gen_js_i18n    rhodecode-cleanup-gists   rhodecode-tools  svnrdump
     gen_js_routes  rhodecode-cleanup-repos   supervisorctl    svnserve
     git            rhodecode-config          supervisord      svnsync
     gunicorn       rhodecode-extensions      svn              svnversion
     hg             rhodecode-gist            svnadmin         vcsserver
     paster         rhodecode-index           svndumpfilter
     rc-server      rhodecode-list-instances  svnlook
     rhodecode-api  rhodecode-setup-config    svnmucc
 
 You can then use the tools as described in the :ref:`rc-tools` section using the
 following example:
 
 .. code-block:: bash
 
     # Running the indexer
     $ ~/.rccontrol/enterprise-1/profile/bin/rhodecode-index \
         --instance-name=enterprise-1
 
     # Cleaning up gists
     $ ~/.rccontrol/enterprise-4/profile/bin/rhodecode-cleanup-gists \
         --instance-name=enterprise-4
 
     Scanning for gists in /home/brian/repos/.rc_gist_store...
     preparing to remove [1] found gists
 
 Installing |RCT|
 ^^^^^^^^^^^^^^^^
 
-|RCT| enable you to automate many of the most common |RCM| functions through
+|RCT| enable you to automate many of the most common |RCE| functions through
 the API. Installing them on a local machine lets you carry out maintenance on
 the server remotely. Once installed you can use them to index your |repos|
-to setup full-text search, strip commits, or install |RC| Extensions for
+to setup full-text search, strip commits, or install RhodeCode Extensions for
 additional functionality.
 
 For more detailed instructions about using |RCT| for indexing and full-text
 search, see :ref:`indexing-ref`
 
 To install |RCT|, use the following steps:
 
 1. Set up a ``virtualenv`` on your local machine, see virtualenv_ instructions
    here.
 2. Install |RCT| using pip. Full url with token is available at https://rhodecode.com/u/#rhodecode-tools
    ``pip install -I https://dls.rhodecode.com/dls/<token>/rhodecode-tools/latest``
 
 
 Once |RCT| is installed using these steps there are a few extra
 configuration changes you can make. These are explained in more detail in the
 :ref:`indexing-ref` section, and the :ref:`rc-tools` section.
 
 .. code-block:: bash
 
     # Create a virtualenv
     brian@ubuntu:~$ virtualenv venv
     New python executable in venv/bin/python
     Installing setuptools, pip...done.
 
     # Activate the virtualenv
     brian@ubuntu:~$ . venv/bin/activate
 
     # Install RhodeCode Tools inside the virtualenv, full url with token is available at https://rhodecode.com/u/#rhodecode-tools
     $ pip install -I https://dls.rhodecode.com/dls/<token>/rhodecode-tools/latest
 
     # Check the installation
     $ rhodecode-tools --help
 
 .. _virtualenv: https://virtualenv.pypa.io/en/latest/index.html
 

docs/tools/rhodecode-tools.rst

@@ -1,14 +1,14 b''
 .. _rc-tools:
 
 |RCT|
 =====
 
-|RCT| enable you to automate many of the most common |RCM| functions through
+|RCT| enable you to automate many of the most common |RCE| functions through
 the API.
 
 .. toctree::
    :maxdepth: 1
 
    tools-overview
    install-tools
    tools-cli

docs/tools/tools-cli.rst

@@ -1,578 +1,578 b''
 .. _tools-cli:
 
 |RCT| CLI
 ---------
 
 The commands available with |RCT| can be split into three categories:
 
 - Remotely executable commands that can be run from your local machine once you
   have your connection details to |RCE| configured.
 - Locally executable commands the can be run on the server to carry out
   general maintenance.
 - Local configuration commands used to help set up your |RCT| configuration.
 
 
 rhodecode-tools
 ---------------
 
 Use |RCT| to setup automation, run the indexer, and install extensions for
-your |RCM| instances. Options:
+your |RCE| instances. Options:
 
 .. rst-class:: dl-horizontal
 
     \ - -apihost <api_host>
         Set the API host value.
 
     \ - -apikey <apikey_value>
         Set the API key value.
 
     \-c, - -config <config_file>
         Create a configuration file. The default file is created
         in ``~/.rhoderc``
 
     \ - -save-config
         Save the configuration file.
 
     \ - -show-config
         Show the current configuration values.
 
     \ - -format {json,pretty}
         Set the formatted representation.
 
 Example usage:
 
 .. code-block:: bash
 
    $ rhodecode-tools --apikey=key --apihost=http://rhodecode.server \
        --save-config
 
 rhodecode-api
 -------------
 
-The |RC| API lets you connect to |RCE| and carry out management tasks from a
+The RhodeCode API lets you connect to |RCE| and carry out management tasks from a
 remote machine, for more information about the API, see the :ref:`api`. To
 pass arguments on the command-line use the ``method:option`` syntax.
 
 Example usage:
 
 .. code-block:: bash
 
     # Run the get_repos API call and sample output
     $ rhodecode-api --instance-name=enterprise-1 create_repo \
         repo_name:brand-new repo_type:hg description:repo-desc
 
     {
       "error": null,
       "id": 1110,
       "result": {
         "msg": "Created new repository `brand-new`",
         "success": true,
         "task": null
       }
     }
 
 Options:
 
 .. rst-class:: dl-horizontal
 
     \ - -api-cache-only
         Requires a cache to be present when running this call
 
     \ - -api-cache-rebuild
         Replaces existing cached values with new ones from server
 
     \ - -api-cache <PATH>
         Use a special cache dir to read responses from instead of the server
 
     \ - -api-cert-verify
          Verify the endpoint ssl certificate
 
     \ - -api-cert <PATH>
          Path to alternate CA bundle.
 
     \ - -apihost <api_host>
         Set the API host value.
 
     \ - -apikey <apikey_value>
         Set the API key value.
 
     \ - -instance-name <instance-id>
         Set the instance name
 
     \-I, - -install-dir <DIR>
         Location of application instances
 
     \-c, - -config <.rhoderc-file>
         Location of the :file:`.rhoderc`
 
     \-F, - -format {json,pretty}
         Set the formatted representation.
 
     \-h, - -help
         Show help messages.
 
     \-v, - -verbose
         Enable verbose messaging
 
 rhodecode-cleanup-gists
 -----------------------
 
-Use this to delete gists within |RCM|. Options:
+Use this to delete gists within |RCE|. Options:
 
 .. rst-class:: dl-horizontal
 
     \-c, - -config <config_file>
         Set the file path to the configuration file. The default file is
         :file:`/home/{user}/.rhoderc`
 
     \ - -corrupted
         Remove gists with corrupted metadata.
 
     \ - -dont-ask
         Remove gists without asking for confirmation.
 
     \-h, - -help
         Show help messages. current configuration values.
 
     \ - -instance-name <instance-id>
         Set the instance name.
 
     \-R, - -repo-dir
         Set the repository file path.
 
     \ - -version
         Display your |RCT| version.
 
 Example usage:
 
 .. code-block:: bash
 
     # Clean up gists related to an instance
     $ rhodecode-cleanup-gists --instance-name=enterprise-1
     Scanning for gists in /home/brian/repos/.rc_gist_store...
     preparing to remove [3] found gists
 
     # Clean up corrupted gists in an instance
     $ rhodecode-cleanup-gists --instance-name=enterprise-1 --corrupted
     Scanning for gists in /home/brian/repos/.rc_gist_store...
     preparing to remove [2] found gists
     the following gists will be archived:
       * EXPIRED: BAD METADATA        | /home/brian/repos/.rc_gist_store/5
       * EXPIRED: BAD METADATA        | /home/brian/repos/.rc_gist_store/8FtC
     are you sure you want to archive them? [y/N]: y
     removing gist /home/brian/repos/.rc_gist_store/5
     removing gist /home/brian/repos/.rc_gist_store/8FtCKdcbRKmEvRzTVsEt
 
 rhodecode-cleanup-repos
 -----------------------
 
-Use this to manage |repos| and |repo| groups within |RCM|. Options:
+Use this to manage |repos| and |repo| groups within |RCE|. Options:
 
 .. rst-class:: dl-horizontal
 
     \-c, - -config <config_file>
         Set the file path to the configuration file. The default file is
         :file:`/home/{user}/.rhoderc`.
 
     \-h, - -help
         Show help messages. current configuration values.
 
     \ - -interactive
         Enable an interactive prompt for each repository when deleting.
 
     \ - -include-groups
         Remove repository groups.
 
     \ - -instance-name <instance-id>
         Set the instance name.
 
     \ - -list-only
         Display repositories selected for deletion.
 
     \ - -older-than <str>
         Delete repositories older that a specified time.
         You can use the following suffixes; d for days, h for hours,
         m for minutes, s for seconds.
 
     \-R, - -repo-dir
         Set the repository file path
 
 Example usage:
 
 .. code-block:: bash
 
     # Cleaning up repos using tools installed with RCE 350 and above
     $ ~/.rccontrol/enterprise-4/profile/bin/rhodecode-cleanup-repos \
         --instance-name=enterprise-4 --older-than=1d
     Scanning for repositories in /home/brian/repos...
     preparing to remove [2] found repositories older than 1 day, 0:00:00 (1d)
 
     the following repositories will be deleted completely:
     * REMOVED: 2015-08-05 00:23:18 | /home/brian/repos/rm__20150805_002318_831
     * REMOVED: 2015-08-04 01:22:10 | /home/brian/repos/rm__20150804_012210_336
     are you sure you want to remove them? [y/N]:
 
     # Clean up repos older than 1 year
     # If using virtualenv and pre RCE 350 tools installation
     (venv)$ rhodecode-cleanup-repos --instance-name=enterprise-1 \
         --older-than=365d
 
     Scanning for repositories in /home/brian/repos...
     preparing to remove [343] found repositories older than 365 days
 
     # clean up repos older than 3 days
     # If using virtualenv and pre RCE 350 tools installation
     (venv)$ rhodecode-cleanup-repos --instance-name=enterprise-1 \
         --older-than=3d
     Scanning for repositories in /home/brian/repos...
     preparing to remove [3] found repositories older than 3 days
 
 .. _tools-config:
 
 rhodecode-config
 ----------------
 
 Use this to create or update a |RCE| configuration file on the local machine.
 
 .. rst-class:: dl-horizontal
 
     \- -filename </path/to/config_file>
         Set the file path to the |RCE| configuration file.
 
     \- -show-defaults
         Display the defaults set in the |RCE| configuration file.
 
     \- -update
         Update the configuration with the new settings passed on the command
         line.
 
 .. code-block:: bash
 
     # Create a new config file
     $ rhodecode-config --filename=dev.ini
     Wrote new config file in /Users/user/dev.ini
 
     # Update config value for given section:
     $ rhodecode-config --update --filename=prod.ini [handler_console]level=INFO
 
     $ rhodecode-config --filename=dev.ini --show-defaults
     lang=en
     cpu_number=4
     uuid=<function <lambda> at 0x10d86ac08>
     license_token=ff1e-aa9c-bb66-11e5
     host=127.0.0.1
     here=/Users/brian
     error_aggregation_service=None
     database_url=sqlite:///%(here)s/rhodecode.db?timeout=30
     git_path=git
     http_server=waitress
     port=5000
 
 .. _tools-rhodecode-extensions:
 
 rhodecode-extensions
 --------------------
 
 The `rcextensions` since version 4.14 are now shipped together with |RCE| please check
 the using :ref:`integrations-rcextensions` section.
 
 
 rhodecode-gist
 --------------
 
-Use this to create, list, show, or delete gists within |RCM|. Options:
+Use this to create, list, show, or delete gists within |RCE|. Options:
 
 .. rst-class:: dl-horizontal
 
     \ - -api-cache-only
         Requires a cache to be present when running this call
 
     \ - -api-cache-rebuild
         Replaces existing cached values with new ones from server
 
     \ - -api-cache PATH
         Use a special cache dir to read responses from instead of the server
 
     \ - -api-cert-verify
          Verify the endpoint ssl certificate
 
     \ - -api-cert PATH
          Path to alternate CA bundle.
 
     \ - -apihost <api_host>
         Set the API host value.
 
     \ - -apikey <apikey_value>
         Set the API key value.
 
     \-c, - -config <config_file>
         Create a configuration file.
         The default file is created in :file:`~/.rhoderc`
 
     \ - -create <gistname>
         create the gist
 
     \-d, - -description <str>
         Set gist description
 
     \ - -delete <gistid>
         Delete the gist
 
     \-f, - -file
         Specify the filename The file extension will enable syntax highlighting.
 
     \-F, - -format {json,pretty}
         Set the formatted representation.
 
     \ - -help
         Show help messages.
 
     \-I, - -install-dir <DIR>
         Location of application instances
 
     \ - -instance-name <instance-id>
         Set the instance name.
 
     \ - -list
         Display instance gists.
 
     \-l, --lifetime <minutes>
         Set the gist lifetime. The default value is (-1) forever
 
     \ - -show <gistname>
         Show the content of the gist
 
     \-o, - -open
         After creating Gist open it in browser
 
     \-p, - -private
         Create a private gist
 
     \ - -version
          Display your |RCT| version.
 
 Example usage:
 
 .. code-block:: bash
 
     # List the gists in an instance
     (venv)brian@ubuntu:~$ rhodecode-gist --instance-name=enterprise-1 list
     {
       "error": null,
       "id": 7102,
       "result": [
         {
           "access_id": "2",
           "content": null,
           "created_on": "2015-01-19T12:52:26.494",
           "description": "A public gust",
           "expires": -1.0,
           "gist_id": 2,
           "type": "public",
           "url": "http://127.0.0.1:10003/_admin/gists/2"
         },
         {
           "access_id": "7gs6BsSEC4pKUEPLz5AB",
           "content": null,
           "created_on": "2015-01-19T11:27:40.812",
           "description": "Gist testing API",
           "expires": -1.0,
           "gist_id": 1,
           "type": "private",
           "url": "http://127.0.0.1:10003/_admin/gists/7gs6BsSEC4pKUEPLz5AB"
         }
       ]
     }
 
     # delete a particular gist
     # You use the access_id to specify the gist to delete
     (venv)brian@ubuntu:~$ rhodecode-gist delete 2  --instance-name=enterprise-1
     {
       "error": null,
       "id": 6284,
       "result": {
         "gist": null,
         "msg": "deleted gist ID:2"
       }
     }
 
     # cat a file and pipe to new gist
     # This is if you are using virtualenv
     (venv)$ cat ~/.rhoderc | rhodecode-gist --instance-name=enterprise-1 \
         -d '.rhoderc copy' create
 
     {
       "error": null,
       "id": 5374,
       "result": {
         "gist": {
           "access_id": "7",
           "content": null,
           "created_on": "2015-01-26T11:31:58.774",
           "description": ".rhoderc copy",
           "expires": -1.0,
           "gist_id": 7,
           "type": "public",
           "url": "http://127.0.0.1:10003/_admin/gists/7"
         },
         "msg": "created new gist"
       }
     }
 
     # Cat a file and pipe to gist
     # in RCE 3.5.0 tools and above
     $ cat ~/.rhoderc | ~/.rccontrol/{instance-id}/profile/bin/rhodecode-gist \
        --instance-name=enterprise-4 -d '.rhoderc copy' create
     {
       "error": null,
       "id": 9253,
       "result": {
         "gist": {
           "access_id": "4",
           "acl_level": "acl_public",
           "content": null,
           "created_on": "2015-08-20T05:54:11.250",
           "description": ".rhoderc copy",
           "expires": -1.0,
           "gist_id": 4,
           "modified_at": "2015-08-20T05:54:11.250",
           "type": "public",
           "url": "http://127.0.0.1:10000/_admin/gists/4"
         },
         "msg": "created new gist"
       }
     }
 
 
 rhodecode-index
 ---------------
 
 More detailed information regarding setting up the indexer is available in
 the :ref:`indexing-ref` section. Options:
 
 .. rst-class:: dl-horizontal
 
     \ - -api-cache-only
         Requires a cache to be present when running this call
 
     \ - -api-cache-rebuild
         Replaces existing cached values with new ones from server
 
     \ - -api-cache PATH
         Use a special cache dir to read responses from instead of the server
 
     \ - -api-cert-verify
          Verify the endpoint ssl certificate
 
     \ - -api-cert PATH
          Path to alternate CA bundle.
 
     \ - -apihost <api_host>
         Set the API host value.
 
     \ - -apikey <apikey_value>
         Set the API key value.
 
     \-c, --config <config_file>
         Create a configuration file.
         The default file is created in :file:`~/.rhoderc`
 
     \ - -create-mapping <PATH>
          Creates an example mapping configuration for indexer.
 
     \-F, - -format {json,pretty}
          Set the formatted representation.
 
     \-h, - -help
          Show help messages.
 
     \ - -instance-name <instance-id>
         Set the instance name
 
     \-I, - -install-dir <DIR>
         Location of application instances
 
     \-m, - -mapping <file_name>
          Parse the output to the .ini mapping file.
 
     \ - -optimize
          Optimize index for performance by amalgamating multiple index files
          into one. Greatly increases incremental indexing speed.
 
     \-R, - -repo-dir <DIRECTORY>
          Location of repositories
 
     \ - -source <PATH>
          Use a special source JSON file to feed the indexer
 
     \ - -version
          Display your |RCT| version.
 
 Example usage:
 
 .. code-block:: bash
 
     # Run the indexer
     $ ~/.rccontrol/enterprise-4/profile/bin/rhodecode-index \
         --instance-name=enterprise-4
 
     # Run indexer based on mapping.ini file
     # This is using pre-350 virtualenv
     (venv)$ rhodecode-index --instance-name=enterprise-1
 
     # Index from the command line without creating
     # the .rhoderc file
     $ rhodecode-index --apikey=key --apihost=http://rhodecode.server \
         --instance-name=enterprise-2 --save-config
 
     # Create the indexing mapping file
     $ ~/.rccontrol/enterprise-4/profile/bin/rhodecode-index \
         --create-mapping mapping.ini --instance-name=enterprise-4
 
 .. _tools-rhodecode-list-instance:
 
 rhodecode-list-instances
 ------------------------
 
 Use this command to list the instance details configured in the
 :file:`~/.rhoderc` file.
 
 .. code-block:: bash
 
    $ .rccontrol/enterprise-1/profile/bin/rhodecode-list-instances
    [instance:production] - Config only
    API-HOST: https://some.url.com
    API-KEY:  some.auth.token
 
    [instance:development] - Config only
    API-HOST: http://some.ip.address
    API-KEY:  some.auth.token
 
 
 .. _tools-setup-config:
 
 rhodecode-setup-config
 ----------------------
 
 Use this command to create the ``~.rhoderc`` file required by |RCT| to access
 remote instances.
 
 .. rst-class:: dl-horizontal
 
     \- -instance-name <name>
         Specify the instance name in the :file:`~/.rhoderc`
 
     \api_host <hostname>
         Create a configuration file. The default file is created
         in ``~/.rhoderc``
 
     \api_key <auth-token>
         Create a configuration file. The default file is created
         in ``~/.rhoderc``
 
 
 .. code-block:: bash
 
     (venv)$ rhodecode-setup-config --instance-name=tea api_host=URL api_key=xyz
     Config not found under /Users/username/.rhoderc, creating a new one
     Wrote new configuration into /Users/username/.rhoderc

docs/tools/tools-overview.rst

@@ -1,66 +1,66 b''
 .. _tools-overview:
 
 |RCT| Overview
 --------------
 
 To install |RCT| correctly, see the installation steps covered in
 :ref:`install-tools`, and :ref:`config-rhoderc`.
 
 Once |RCT| is installed, and the :file:`/home/{user}/.rhoderc` file is
-configured you can then use |RCT| on each |RCM| instance to carry out admin
+configured you can then use |RCT| on each |RCE| instance to carry out admin
 tasks. Use the following example to configure that file,
 and once configured see the :ref:`tools-cli` for more details.
 
 .. note::
 
    |RCT| require |PY| 2.7 to run.
 
 .. code-block:: bash
 
     # Get the status of each instance you wish to use with Tools
     (venv)brian@ubuntu:~$ rccontrol status
 
      - NAME: momentum-1
      - STATUS: RUNNING
      - TYPE: Momentum
      - VERSION: 3.0.0-nightly-momentum
      - URL: http://127.0.0.1:10003
 
      - NAME: momentum-3
      - STATUS: RUNNING
      - TYPE: Momentum
      - VERSION: 3.0.0-nightly-momentum
      - URL: http://127.0.0.1:10007
 
 Example :file:`/home/{user}/.rhoderc` file.
 
 .. code-block:: ini
 
     # Configure the .rhoderc file for each instance
     # API keys found in your instance
     [instance:enterprise-1]
     api_host = http://127.0.0.1:10003/
     api_key = 91fdbdc257289c46633ef5aab274412911de1ba9
     repo_dir = /home/brian/repos
 
     [instance:enterprise-3]
     api_host = http://127.0.0.1:10007/
     api_key = 5a925f65438d29f8d6ced8ab8e8c3d305998d1d9
     repo_dir = /home/brian/testing-repos/
 
 
 Example usage of |RCT| after |RCE| 3.5.0. From this version onwards |RCT| is
 packaged with |RCE| by default.
 
 .. code-block:: bash
 
     $ .rccontrol/enterprise-4/profile/bin/rhodecode-api --instance-name=enterprise-4 get_ip                                                                                                                                                                                                                                                                                                                                                                     [11:56:57 on 05/10/2018]
 
     {
       "error": null,
       "id": 1000,
       "result": {
         "server_ip_addr": "1.2.3.4",
         "user_ips": []
       }
     }

docs/tutorials/deploy-from-host.rst

@@ -1,220 +1,220 b''
 .. _hosted-solution:
 
 Deploy |RCE| From a Hosted Server
 =================================
 
 If you wish to deploy your own |RCE| instance from something like a
 `Digital Ocean`_ droplet, or a `hetzner`_ server use the following
 instructions to get it setup.
 
 I'm using an Ubuntu 14.04 image for the purposes of this
 tutorial, but all other Unix environments will be pretty similar. You can
 check out the full lists of supported platforms and versions in the
 :ref:`system-overview-ref` section.
 
 
 Create a Digital Ocean Droplet
 ------------------------------
 
 1. Sign into Digital Ocean.
 2. Create a Droplet choosing Ubuntu 14.04 as your |os|.
 3. (Optional) Add SSH keys if you have them set up.
 
 Configure Your Server
 ---------------------
 
 Once you have your server created, you need to sign into it and set it up to
 host |RCE|.
 
 1. Open a terminal and sign into your server. Digital Ocean will mail you the
    IP address. You'll need to change your password on the first login if you
    don not have SSH keys set up.
 
 .. code-block:: bash
 
     $ ssh root@203.0.113.113
 
 2. It is not advised to install |RCE| as the ``root`` user. So create a user
    with sudo permissions and then carry out the rest of the steps from that user
    account.
 
 .. code-block:: bash
 
     # Create a user with sudo permissions
     root@rhodecode:~# sudo useradd -m -s /bin/bash -d /home/brian -U brian
     root@rhodecode:~# sudo usermod -a -G sudo brian
 
     # Set the password for that user
     root@rhodecode:~# passwd brian
     Enter new UNIX password:
     Retype new UNIX password:
     passwd: password updated successfully
 
     # Switch to that user for the rest of the steps
     root@rhodecode:~# su brian
 
     # You should see your home dir change to what was set during installation
     brian@rhodecode:~$ cd ~
     brian@rhodecode:~$ pwd
     /home/brian
 
 Once you have this set up, you are ready to install |RCC|.
 
 Install |RCC|
 -------------
 
 |RCC| will install and manage the package dependencies for your |RCE| instance.
 
 1. Download the |RCC| installer from https://rhodecode.com/download/
 2. Once downloaded to your computer, transfer the package to your server
 
 .. note::
 
    These steps happen on your computer, not on the server.
 
 .. code-block:: bash
 
     # Change to where the file is downloaded
     $ cd Downloads/
 
     # SFTP to your server
     $ sftp brian@203.0.113.113
 
     # Use mput to transfer the file
     sftp> mput RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d520e3
     Uploading RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d520e3 to /home/brian/RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d520e3
     RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d 100%  289MB   4.1MB/s   01:11
     sftp> exit
 
 The |RCC| installer is now on your server, and you can read the full
 instructions here
 :ref:`Install RhodeCode Control <control:rcc-linux-ref>` ,
 but below is the example shortcut.
 
 .. code-block:: bash
 
     # Check that the script is uploaded to your home directory
     $ ls -1
-    RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d520e3
+    RhodeCode-installer-linux-buildYYYYXXXX_ZZZZ
 
     # Change the script permissions
-    $ chmod 755 RhodeCode-installer-linux*
+    $ chmod +x RhodeCode-installer-linux*
 
     # Run the installer and accept the prompts
     $ ./RhodeCode-installer-linux-*
 
 .. important::
 
    Once finished, exit the terminal and sign in again. This is to refresh you
    session to pick up the new commands.
 
 Install |RCE|
 -------------
 
 Now that |RCC| is installed, you can install |RCE|. For the full
 instructions, see
 :ref:`Install RhodeCode Enterprise <control:rce-cli-install-ref>`,
 but the below is an example shortcut.
 
 .. code-block:: bash
 
     # Install a VCS Server and follow the prompts
     $ rccontrol install VCSServer --start-at-boot
 
     Extracting VCSServer ...
     Configuring RhodeCode VCS Server ...
     Supervisord state is: RUNNING
     Added process group vcsserver-1
 
     # Install a RhodeCode Enterprise instance and follow the prompts
     $ rccontrol install Enterprise --start-at-boot
 
     Configuration of RhodeCode Enterprise passed.
     Supervisord state is: RUNNING
     Added process group enterprise-1
 
 |RCE| is now installed on your server, and is running on the port displayed
 by the ``rccontrol status`` command.
 
 .. code-block:: bash
 
     brian@rhodecode:~$ rccontrol status
 
      - NAME: enterprise-1
      - STATUS: RUNNING
      - TYPE: Enterprise
      - VERSION: 3.1.1
      - URL: http://127.0.0.1:10002
 
      - NAME: vcsserver-1
      - STATUS: RUNNING
      - TYPE: VCSServer
      - VERSION: 1.1.1
      - URL: http://127.0.0.1:10001
 
 Serve |RCE| using Nginx
 -----------------------
 
 Now that |RCE| is running, you need to use Nginx or Apache to serve it to
 users. For detailed instructions about setting up your webserver, see the
 :ref:`rhodecode-admin-ref` section. But the below shortcut should help serve
 it.
 
 1. Install Nginx on your server.
 
 .. code-block:: bash
 
     # Install nginx
     $ sudo apt-get install nginx
 
 2. Create a virtual hosts file for RhodeCode Enterprise. Create
    the file in this location :file:`/etc/nginx/sites-available`. In this demo
    I have called it ``vcs.conf``
 
 .. code-block:: bash
 
    # Create the file
    $ sudo vi /etc/nginx/sites-available/vcs.conf
 
 Use the following example to create yours.
 
 .. code-block:: nginx
 
     server {
         listen 80;
         # Change to your IP, or a domain name if you've set that up
         server_name     203.0.113.113 ;
 
         location / {
         # Set this line to match the RhodeCode Enterprise Instance URL
             proxy_pass		http://127.0.0.1:10002/;
             proxy_set_header	Host $Host;
             proxy_buffering		off;
         # Setting this to a high number allows large repo pushes
             client_max_body_size	4G;
             }
         }
 
 3. Symlink the virtual hosts file to the ``sites-enabled`` folder,
    and then restart Nginx.
 
 .. code-block:: bash
 
    # Symlink the virtual hosts file
    $ ln -s /etc/nginx/sites-available/vcs.conf /etc/nginx/sites-enabled/vcs.conf
 
    # You can also delete the Nginx default symlink
    $ rm /etc/nginx/sites-enabled/default
 
    # Restart Nginx
    $ sudo  /etc/init.d/nginx restart
      * Restarting nginx nginx                                     [ OK ]
 
 Once restarted, you should see a clean |RCE| instance running on the IP
 address, or the domain you have set up.
 
 .. image:: ../images/clean-rce.png
    :alt: A fresh RhodeCode Enterprise Instance
 
 .. _Digital Ocean: https://www.digitalocean.com/
 .. _hetzner: https://www.hetzner.de/en/

docs/tutorials/git-lfs-ext.rst

@@ -1,93 +1,93 b''
 .. _git-lfs-files:
 
 |git| LFS Extension
 ===================
 
 
 Git Large File Storage (or LFS) is a new, open-source extension to Git that
 aims to improve handling of large files. It does this by replacing large files
 in your repository—such as graphics and videos—with simple text pointers.
-|RC| Server includes an embedded LFS object store server, allowing storage of
+RhodeCode Server includes an embedded LFS object store server, allowing storage of
 large files without the need for an external object store.
 Git LFS is disabled by default, globally, and for each individual repository.
 
 .. note::
 
-    |RC| implements V2 API of Git LFS. Please make sure your git client is
+    RhodeCode implements V2 API of Git LFS. Please make sure your git client is
     using the latest version (2.0.X recommended) to leverage full feature set
     of the V2 API.
 
 
 
 Enabling Git LFS
 ++++++++++++++++
 
-Git LFS is disabled by default within |RC| Server.
+Git LFS is disabled by default within RhodeCode Server.
 
 To enable Git LFS Globally:
 
     - Go to :menuselection:`Admin --> Settings --> VCS`
 
     - Scroll down into `Git settings`
 
     - Tick `Enable lfs extension`
 
     - Save your settings.
 
 Those settings apply globally to each repository that inherits from the defaults
 You can leave `lfs extension` disabled globally, and only enable it per
 repository that would use the lfs.
 
 
 .. note::
 
     You might want to adjust the global storage location at that point, however
     we recommend leaving the default one created.
 
 
 Installing and using the Git LFS command line client
 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Git LFS aims to integrate with the standard Git workflow as seamlessly
 as possible. To push your first Git LFS files to an existing repository
 Download and install the git-lfs command line client
 Install the Git LFS filters::
 
     git lfs install
 
 This adds the following lines to the .gitconfig file located in your home directory::
 
     [filter "lfs"]
         clean = git-lfs clean %f
         smudge = git-lfs smudge %f
         required = true
 
 The above change applies globally, so it is not necessary to run this for
 each repository you work with. Choose the file types you would like LFS to
 handle by executing the git lfs track command. The git lfs track command
 creates or updates the .gitattributes file in your repository.
 Change to your cloned repository, then execute git add to ensure updates
 to the .gitattributes are later committed::
 
     git lfs track "*.jpg"
     git add .gitattributes
 
 Add, commit, and push your changes as you normally would::
 
     git add image.jpg
     git commit -m "Added an image"
     git push
 
 When pushed, the Git tree updates to include a pointer to the file actual
 file content. This pointer will include the SHA256 hash of the object and its
 size in bytes. For example::
 
     oid sha256:4fa32d6f9b1461c4a53618a47324ee43e36ce7ceaea2ad440cc811a7e6881be1
     size 2580390
 
 
 The object itself will be uploaded to a separate location via the Git LFS Batch API.
-The transfer is validated and authorized by |RC| server itself.
+The transfer is validated and authorized by RhodeCode server itself.
 
 If give repository has Git LFS disabled, a proper message will be sent back to
 the client and upload of LFS objects will be forbidden.

docs/tutorials/hg-large-ext.rst

@@ -1,69 +1,69 b''
 .. _hg-big-files:
 
 |hg| Large Files Extension
 ==========================
 
 Large files, such as image or zip files can cause a lot of bandwidth overhead
 during clone, push, and pull operations. To remove this inefficiency, |hg|
 has a large files extension which tracks their revisions by checksums. This
 means that the large files are only downloaded when they are needed as part
 of the current revision. This saves both disk space and bandwidth.
 
 
 Enabling HG Largefiles
 ++++++++++++++++++++++
 
-Mercurial Largefiles extension is disabled by default within |RC| Server.
+Mercurial Largefiles extension is disabled by default within RhodeCode Server.
 
 To enable Mercurial Largefiles Globally:
 
     - Go to :menuselection:`Admin --> Settings --> VCS`
 
     - Scroll down into `Mercurial settings`
 
     - Tick `Enable largefiles extension`
 
     - Save your settings.
 
 Those settings apply globally to each repository that inherits from the defaults
 You can leave `largefiles extension` disabled globally, and only enable it per
 repository that would use the largefiles.
 
 
 .. note::
 
     You might want to adjust the global storage location at that point, however
     we recommend leaving the default one created.
 
 
 Installing and using the |hg| Largefiles
 ++++++++++++++++++++++++++++++++++++++++
 
 To find out more, see the |hg| `Large Files Extensions Documentation`_.
 
 To configure the large files extension, you need to set up your
 :file:`~/.hgrc` file.
 
 1. Open your :file:`~/.hgrc` file.
 2. Add ``largefiles =`` to the ``[extensions]`` section.
 3. Configure the ``[largefiles]`` section with the patterns and file size you
    wish |hg| to handle as large. The ``minsize`` option is specified in
    megabytes.
 4. Save your changes.
 
 .. code-block:: ini
 
     [extensions]
     hgext.churn =
     largefiles =
     rebase =
     record =
     histedit =
 
     [largefiles]
     patterns = re:.*\.(png|bmp|jpg|zip|tar|tar.gz|rar)$
     minsize = 10
 
 For a complete :file:`~/.hgrc` file example, see :ref:`config-hgrc`.
 
 .. _Large Files Extensions Documentation: http://mercurial.selenic.com/wiki/LargefilesExtension

docs/tutorials/windows-to-linux.rst

@@ -1,121 +1,121 b''
 Moving From Windows to Linux
 ============================
 
 If you are moving from a Windows server to a Linux server, especially from
 running an older version of |RCE| pre 2.x, use the following information to
 successfully migrate your instances and database.
 
 Overview
 --------
 
 * Install |RCC| on your Linux server, use the
   :ref:`RhodeCode Control Docs <control:rcc>` to guide you through this.
 * Copy your |repos| directory to the Linux server.
 * Copy your original :file:`rhodecode.ini` file to the Linux server, named
   :file:`production.ini` in older versions, and make a minor edit to
   point to the copied database.
 * Copy your original instance database and update Windows paths to Linux
   paths pointing to your |repos| directory.
 * Use |RCC| to import and upgrade your |RCE| instance, using the copied and
   edited file and database.
 
 Pre-requisites
 --------------
 
 * For MySQL, do not use `localhost` in the database connection string of the
   :file:`rhodecode.ini` file.
 * InnoDB must be the database tables engine.
-* Contact |RC| for a new licence Key/Token pair. If you don't, a trial licence
+* Contact RhodeCode for a new licence Key/Token pair. If you don't, a trial licence
   will be applied so you are not locked out of the upgraded instance.
 
 You can find the specific instructions to carry out these pre-requisite steps
 in the :ref:`RhodeCode Control upgrade <control:rce-upgrade-2x>` docs.
 
 Configuration File Update
 -------------------------
 
 Configure the copied :file:`rhodecode.ini` file to connect to your copied
 database. Use the following steps:
 
 1. Open the copied :file:`rhodecode.ini` file.
 2. When you open the file, find the database configuration section,
    and use the below example to change the connection details:
 
 .. code-block:: ini
 
     #########################################################
     ### DB CONFIGS - EACH DB WILL HAVE IT'S OWN CONFIG    ###
     #########################################################
 
     # Point to copied DB
     sqlalchemy.db1.url = postgresql://postgres:qwe@localhost/rhodecode.db.copy
     sqlalchemy.db1.url = mysql://root:qweqwe@127.0.0.1/rhodecode.db.copy
 
 Database Update
 ---------------
 
 Update the Windows paths in the ``rhodecode.rhodecode_ui`` database tables.
 To do this log into the database and reset the file paths to
 Unix format. One login option is to use iShell, see usage examples in the
 :ref:`rhodecode-reset-ref` section.
 
 .. code-block:: python
 
     In [28]: from rhodecode.model.settings import SettingsModel
     In [29]: paths = SettingsModel().get_ui_by_section('paths')
     In [30]: paths[0].value = '/home/user/repos'
     In [32]: Session().add(paths[0])
     In [33]: Session().commit()
 
 Import and Upgrade
 ------------------
 
 Once you have made your changes, use |RCC| to import and upgrade your |RCE|
 instance to the latest version.
 
 .. code-block:: bash
 
     # Import original instance as explained above
     $ rccontrol import Enterprise path/to/rhodecode.ini
 
     # Install a VCS Server as explained above
     $ rccontrol install VCSServer
 
     # Check the status of them
     $ rccontrol status
 
      - NAME: enterprise-1
      - STATUS: RUNNING
      - TYPE: Enterprise
      - VERSION: 1.5.0
      - URL: http://127.0.0.1:10000
 
      - NAME: vcsserver-1
      - STATUS: RUNNING
      - TYPE: VCSServer
      - VERSION: 3.5.0
      - URL: http://127.0.0.1:10001
 
     # Upgrade from version 1.5.0 to 3.5.0
     $ rccontrol upgrade enterprise-1 --version 3.5.0
 
     Checking for available update for enterprise-1 @ 1.5.0
     Stopped enterprise-1
     Initiating upgrade to version 3.5.0
     ...
     ****************************************
     *** UPGRADE TO VERSION 45 SUCCESSFUL ***
     ****************************************
 
     Note that RCE 3.x requires a new license please contact [e-mail]
 
     Upgrade of RhodeCode Enterprise successful.
     Auto starting enterprise-1
 
 Post Migration Tasks
 --------------------
 
 * From the |RCE| :menuselection:`Admin --> Settings --> VCS` page, check that
   the :guilabel:`Repositories Location` is correctly pointing to your |repos|.
 * Remap and rescan |repos| so that the new instance picks them up, see
   :ref:`remap-rescan`.

docs/usage/basic-vcs-commands.rst

@@ -1,28 +1,28 b''
 .. _basic-vcs-cmds:
 
 Getting Started with VCS
 ------------------------
 
-When using |RCM|, you will be working with |git|, |svn| or |hg| |repos| from the
+When using |RCE|, you will be working with |git|, |svn| or |hg| |repos| from the
 command line or using a GUI client such as Tortoise, Tower or SourceTree.
 
-|RCM| uses a standard |git|, |svn| and |hg| protocols. So all tools that
+|RCE| uses a standard |git|, |svn| and |hg| protocols. So all tools that
 can interact with there protocols are supported, including Eclipse or PyCharm
 plugins.
 
 
 If you have never used either before, the following information should
 help you set up your local machine so that you can sync changes with the
-|RCM| server.
+|RCE| server.
 
-All of the following instructions assume you have a |RCM| account,
+All of the following instructions assume you have a |RCE| account,
 and you can access your |repos| from the web interface.
 
 .. note::
 
    |svn| |repo| management is currently only available from the web interface.
 
 .. toctree::
 
     get-start-hg
     get-start-git

docs/usage/file-editing.rst

@@ -1,17 +1,17 b''
 File Editing
 ^^^^^^^^^^^^
 
 To edit files using the online editor, use the following steps.
 
-1. From the |RCM| interface, select :menuselection:`Admin --> Repositories`
+1. From the |RCE| interface, select :menuselection:`Admin --> Repositories`
 2. Select the |repo| in which you want to edit a file.
 3. Select the :guilabel:`file` view of the |repo|, and double-click on the file.
 4. To open the editor, select the :guilabel:`edit on branch:default` button.
 
-   * If the filename has an extension |RCM| recognises,
+   * If the filename has an extension |RCE| recognises,
      the syntax highlighting will appear automatically.
-   * If the filename does not have an extension |RCM| recognises,
+   * If the filename does not have an extension |RCE| recognises,
      you can set the language syntax highlighter by
      choosing from the file type drop down menu.
 5. To save your changes, select :guilabel:`Commit changes`
 

docs/usage/gist-editing.rst

@@ -1,33 +1,33 b''
 .. _gist-edit:
 
 Gist Editing
 ^^^^^^^^^^^^
 
 Gists are standalone files that only the creator can edit. To work with
-gists, click on the :guilabel:`Gists` tab on the |RCM| header. The gist
+gists, click on the :guilabel:`Gists` tab on the |RCE| header. The gist
 editor also has syntax highlighting.
 
 You can set the following properties for each gist:
 
 * :guilabel:`Public`: Public gists are as the name suggests,
   and will show up in searches.
 * :guilabel:`Gist Lifetime`: You can set a gist to expire after a set
   period by using the :guilabel:`Gist Lifetime` dropdown menu.
-  This means that when the gist expires it will be deleted from the |RCM|
+  This means that when the gist expires it will be deleted from the |RCE|
   gist database.
 * :guilabel:`Private`: This means that the gist will not show up in searches.
 * :guilabel:`Gist access level`: If you create a private gist you can have
   two levels of privacy with the gist link.
 
   * :guilabel:`Requires registered account`: This option requires users to
     have a registered account on the |RCE| instance, otherwise they will not
     have access to the gist.
   * :guilabel:`Can be accessed by anonymous users`: This option hides the
     link so that it does not show up in searches, but you can still share it
     with people outside of your organisation.
 
 For more advanced use of gists, see the gist API options in the :ref:`api`
 
 .. image:: ../images/gists-acl.png
    :alt: Gist Management
    :scale: 50 %

docs/usage/online-editing.rst

@@ -1,11 +1,11 b''
 Online Editing
 --------------
 
-|RCM| has an integrated online editor, allowing you to edit files in the
+|RCE| has an integrated online editor, allowing you to edit files in the
 browser. The online editor has syntax highlighting and the ability to fork,
 merge, and commit changes to files.
 
 .. toctree::
 
    file-editing
    gist-editing
  No newline at end of file