docs: added SAML documentation.

- Remove few obsolete replaces
- update authentication docs
- cleanups and fixes

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/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/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/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/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/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/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/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

rhodecode/authentication/plugins/auth_ldap.py

@@ -1,535 +1,535 b''
 # -*- coding: utf-8 -*-
 
 # Copyright (C) 2010-2018 RhodeCode GmbH
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU Affero General Public License, version 3
 # (only), as published by the Free Software Foundation.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU Affero General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 #
 # This program is dual-licensed. If you wish to learn more about the
 # RhodeCode Enterprise Edition, including its added features, Support services,
 # and proprietary license terms, please see https://rhodecode.com/licenses/
 
 """
 RhodeCode authentication plugin for LDAP
 """
 
 import logging
 import traceback
 
 import colander
 from rhodecode.translation import _
 from rhodecode.authentication.base import (
     RhodeCodeExternalAuthPlugin, AuthLdapBase, hybrid_property)
 from rhodecode.authentication.schema import AuthnPluginSettingsSchemaBase
 from rhodecode.authentication.routes import AuthnPluginResourceBase
 from rhodecode.lib.colander_utils import strip_whitespace
 from rhodecode.lib.exceptions import (
     LdapConnectionError, LdapUsernameError, LdapPasswordError, LdapImportError
 )
 from rhodecode.lib.utils2 import safe_unicode, safe_str
 from rhodecode.model.db import User
 from rhodecode.model.validators import Missing
 
 log = logging.getLogger(__name__)
 
 try:
     import ldap
 except ImportError:
     # means that python-ldap is not installed, we use Missing object to mark
     # ldap lib is Missing
     ldap = Missing
 
 
 class LdapError(Exception):
     pass
 
 
 def plugin_factory(plugin_id, *args, **kwargs):
     """
     Factory function that is called during plugin discovery.
     It returns the plugin instance.
     """
     plugin = RhodeCodeAuthPlugin(plugin_id)
     return plugin
 
 
 class LdapAuthnResource(AuthnPluginResourceBase):
     pass
 
 
 class AuthLdap(AuthLdapBase):
     default_tls_cert_dir = '/etc/openldap/cacerts'
 
     def __init__(self, server, base_dn, port=389, bind_dn='', bind_pass='',
                  tls_kind='PLAIN', tls_reqcert='DEMAND', tls_cert_file=None,
                  tls_cert_dir=None, ldap_version=3,
                  search_scope='SUBTREE', attr_login='uid',
                  ldap_filter='', timeout=None):
         if ldap == Missing:
             raise LdapImportError("Missing or incompatible ldap library")
 
         self.debug = False
         self.timeout = timeout or 60 * 5
         self.ldap_version = ldap_version
         self.ldap_server_type = 'ldap'
 
         self.TLS_KIND = tls_kind
 
         if self.TLS_KIND == 'LDAPS':
             port = port or 689
             self.ldap_server_type += 's'
 
         OPT_X_TLS_DEMAND = 2
         self.TLS_REQCERT = getattr(ldap, 'OPT_X_TLS_%s' % tls_reqcert, OPT_X_TLS_DEMAND)
         self.TLS_CERT_FILE = tls_cert_file or ''
         self.TLS_CERT_DIR = tls_cert_dir or self.default_tls_cert_dir
 
         # split server into list
         self.SERVER_ADDRESSES = self._get_server_list(server)
         self.LDAP_SERVER_PORT = port
 
         # USE FOR READ ONLY BIND TO LDAP SERVER
         self.attr_login = attr_login
 
         self.LDAP_BIND_DN = safe_str(bind_dn)
         self.LDAP_BIND_PASS = safe_str(bind_pass)
 
         self.SEARCH_SCOPE = getattr(ldap, 'SCOPE_%s' % search_scope)
         self.BASE_DN = safe_str(base_dn)
         self.LDAP_FILTER = safe_str(ldap_filter)
 
     def _get_ldap_conn(self):
 
         if self.debug:
             ldap.set_option(ldap.OPT_DEBUG_LEVEL, 255)
 
         if self.TLS_CERT_FILE and hasattr(ldap, 'OPT_X_TLS_CACERTFILE'):
             ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, self.TLS_CERT_FILE)
 
         elif hasattr(ldap, 'OPT_X_TLS_CACERTDIR'):
             ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, self.TLS_CERT_DIR)
 
         if self.TLS_KIND != 'PLAIN':
             ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, self.TLS_REQCERT)
 
         ldap.set_option(ldap.OPT_REFERRALS, ldap.OPT_OFF)
         ldap.set_option(ldap.OPT_RESTART, ldap.OPT_ON)
 
         # init connection now
         ldap_servers = self._build_servers(
             self.ldap_server_type,  self.SERVER_ADDRESSES, self.LDAP_SERVER_PORT)
         log.debug('initializing LDAP connection to:%s', ldap_servers)
         ldap_conn = ldap.initialize(ldap_servers)
         ldap_conn.set_option(ldap.OPT_NETWORK_TIMEOUT, self.timeout)
         ldap_conn.set_option(ldap.OPT_TIMEOUT, self.timeout)
         ldap_conn.timeout = self.timeout
 
         if self.ldap_version == 2:
             ldap_conn.protocol = ldap.VERSION2
         else:
             ldap_conn.protocol = ldap.VERSION3
 
         if self.TLS_KIND == 'START_TLS':
             ldap_conn.start_tls_s()
 
         if self.LDAP_BIND_DN and self.LDAP_BIND_PASS:
             log.debug('Trying simple_bind with password and given login DN: %r',
                       self.LDAP_BIND_DN)
             ldap_conn.simple_bind_s(self.LDAP_BIND_DN, self.LDAP_BIND_PASS)
 
         return ldap_conn
 
     def fetch_attrs_from_simple_bind(self, server, dn, username, password):
         try:
             log.debug('Trying simple bind with %r', dn)
             server.simple_bind_s(dn, safe_str(password))
             user = server.search_ext_s(
                 dn, ldap.SCOPE_BASE, '(objectClass=*)', )[0]
             _, attrs = user
             return attrs
 
         except ldap.INVALID_CREDENTIALS:
             log.debug(
                 "LDAP rejected password for user '%s': %s, org_exc:",
                 username, dn, exc_info=True)
 
     def authenticate_ldap(self, username, password):
         """
         Authenticate a user via LDAP and return his/her LDAP properties.
 
         Raises AuthenticationError if the credentials are rejected, or
         EnvironmentError if the LDAP server can't be reached.
 
         :param username: username
         :param password: password
         """
 
         uid = self.get_uid(username, self.SERVER_ADDRESSES)
         user_attrs = {}
         dn = ''
 
         self.validate_password(username, password)
         self.validate_username(username)
 
         ldap_conn = None
         try:
             ldap_conn = self._get_ldap_conn()
             filter_ = '(&%s(%s=%s))' % (
                 self.LDAP_FILTER, self.attr_login, username)
             log.debug("Authenticating %r filter %s", self.BASE_DN, filter_)
 
             lobjects = ldap_conn.search_ext_s(
                 self.BASE_DN, self.SEARCH_SCOPE, filter_)
 
             if not lobjects:
                 log.debug("No matching LDAP objects for authentication "
                           "of UID:'%s' username:(%s)", uid, username)
                 raise ldap.NO_SUCH_OBJECT()
 
             log.debug('Found matching ldap object, trying to authenticate')
             for (dn, _attrs) in lobjects:
                 if dn is None:
                     continue
 
                 user_attrs = self.fetch_attrs_from_simple_bind(
                     ldap_conn, dn, username, password)
                 if user_attrs:
                     break
             else:
                 raise LdapPasswordError(
                     'Failed to authenticate user `{}`'
                     'with given password'.format(username))
 
         except ldap.NO_SUCH_OBJECT:
             log.debug("LDAP says no such user '%s' (%s), org_exc:",
                       uid, username, exc_info=True)
             raise LdapUsernameError('Unable to find user')
         except ldap.SERVER_DOWN:
             org_exc = traceback.format_exc()
             raise LdapConnectionError(
                 "LDAP can't access authentication "
                 "server, org_exc:%s" % org_exc)
         finally:
             if ldap_conn:
                 log.debug('ldap: connection release')
                 try:
                     ldap_conn.unbind_s()
                 except Exception:
                     # for any reason this can raise exception we must catch it
                     # to not crush the server
                     pass
 
         return dn, user_attrs
 
 
 class LdapSettingsSchema(AuthnPluginSettingsSchemaBase):
     tls_kind_choices = ['PLAIN', 'LDAPS', 'START_TLS']
     tls_reqcert_choices = ['NEVER', 'ALLOW', 'TRY', 'DEMAND', 'HARD']
     search_scope_choices = ['BASE', 'ONELEVEL', 'SUBTREE']
 
     host = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('Host[s] of the LDAP Server \n'
                       '(e.g., 192.168.2.154, or ldap-server.domain.com.\n '
                       'Multiple servers can be specified using commas'),
         preparer=strip_whitespace,
         title=_('LDAP Host'),
         widget='string')
     port = colander.SchemaNode(
         colander.Int(),
         default=389,
         description=_('Custom port that the LDAP server is listening on. '
-                      'Default value is: 389'),
+                      'Default value is: 389, use 689 for LDAPS(SSL)'),
         preparer=strip_whitespace,
         title=_('Port'),
         validator=colander.Range(min=0, max=65536),
         widget='int')
 
     timeout = colander.SchemaNode(
         colander.Int(),
         default=60 * 5,
         description=_('Timeout for LDAP connection'),
         preparer=strip_whitespace,
         title=_('Connection timeout'),
         validator=colander.Range(min=1),
         widget='int')
 
     dn_user = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('Optional user DN/account to connect to LDAP if authentication is required. \n'
                       'e.g., cn=admin,dc=mydomain,dc=com, or '
                       'uid=root,cn=users,dc=mydomain,dc=com, or [e-mail]'),
         missing='',
         preparer=strip_whitespace,
         title=_('Account'),
         widget='string')
     dn_pass = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('Password to authenticate for given user DN.'),
         missing='',
         preparer=strip_whitespace,
         title=_('Password'),
         widget='password')
     tls_kind = colander.SchemaNode(
         colander.String(),
         default=tls_kind_choices[0],
         description=_('TLS Type'),
         title=_('Connection Security'),
         validator=colander.OneOf(tls_kind_choices),
         widget='select')
     tls_reqcert = colander.SchemaNode(
         colander.String(),
         default=tls_reqcert_choices[0],
         description=_('Require Cert over TLS?. Self-signed and custom '
                       'certificates can be used when\n `RhodeCode Certificate` '
                       'found in admin > settings > system info page is extended.'),
         title=_('Certificate Checks'),
         validator=colander.OneOf(tls_reqcert_choices),
         widget='select')
     tls_cert_file = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('This specifies the PEM-format file path containing '
                       'certificates for use in TLS connection.\n'
                       'If not specified `TLS Cert dir` will be used'),
         title=_('TLS Cert file'),
         missing='',
         widget='string')
     tls_cert_dir = colander.SchemaNode(
         colander.String(),
         default=AuthLdap.default_tls_cert_dir,
         description=_('This specifies the path of a directory that contains individual '
                       'CA certificates in separate files.'),
         title=_('TLS Cert dir'),
         widget='string')
     base_dn = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('Base DN to search. Dynamic bind is supported. Add `$login` marker '
                       'in it to be replaced with current user credentials \n'
                       '(e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)'),
         missing='',
         preparer=strip_whitespace,
         title=_('Base DN'),
         widget='string')
     filter = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('Filter to narrow results \n'
                       '(e.g., (&(objectCategory=Person)(objectClass=user)), or \n'
                       '(memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))'),
         missing='',
         preparer=strip_whitespace,
         title=_('LDAP Search Filter'),
         widget='string')
 
     search_scope = colander.SchemaNode(
         colander.String(),
         default=search_scope_choices[2],
         description=_('How deep to search LDAP. If unsure set to SUBTREE'),
         title=_('LDAP Search Scope'),
         validator=colander.OneOf(search_scope_choices),
         widget='select')
     attr_login = colander.SchemaNode(
         colander.String(),
         default='uid',
         description=_('LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)'),
         preparer=strip_whitespace,
         title=_('Login Attribute'),
         missing_msg=_('The LDAP Login attribute of the CN must be specified'),
         widget='string')
     attr_email = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('LDAP Attribute to map to email address (e.g., mail).\n'
                       'Emails are a crucial part of RhodeCode. \n'
                       'If possible add a valid email attribute to ldap users.'),
         missing='',
         preparer=strip_whitespace,
         title=_('Email Attribute'),
         widget='string')
     attr_firstname = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('LDAP Attribute to map to first name (e.g., givenName)'),
         missing='',
         preparer=strip_whitespace,
         title=_('First Name Attribute'),
         widget='string')
     attr_lastname = colander.SchemaNode(
         colander.String(),
         default='',
         description=_('LDAP Attribute to map to last name (e.g., sn)'),
         missing='',
         preparer=strip_whitespace,
         title=_('Last Name Attribute'),
         widget='string')
 
 
 class RhodeCodeAuthPlugin(RhodeCodeExternalAuthPlugin):
     uid = 'ldap'
     # used to define dynamic binding in the
     DYNAMIC_BIND_VAR = '$login'
     _settings_unsafe_keys = ['dn_pass']
 
     def includeme(self, config):
         config.add_authn_plugin(self)
         config.add_authn_resource(self.get_id(), LdapAuthnResource(self))
         config.add_view(
             'rhodecode.authentication.views.AuthnPluginViewBase',
             attr='settings_get',
             renderer='rhodecode:templates/admin/auth/plugin_settings.mako',
             request_method='GET',
             route_name='auth_home',
             context=LdapAuthnResource)
         config.add_view(
             'rhodecode.authentication.views.AuthnPluginViewBase',
             attr='settings_post',
             renderer='rhodecode:templates/admin/auth/plugin_settings.mako',
             request_method='POST',
             route_name='auth_home',
             context=LdapAuthnResource)
 
     def get_settings_schema(self):
         return LdapSettingsSchema()
 
     def get_display_name(self):
         return _('LDAP')
 
     @classmethod
     def docs(cls):
         return "https://docs.rhodecode.com/RhodeCode-Enterprise/auth/auth-ldap.html"
 
     @hybrid_property
     def name(self):
         return u"ldap"
 
     def use_fake_password(self):
         return True
 
     def user_activation_state(self):
         def_user_perms = User.get_default_user().AuthUser().permissions['global']
         return 'hg.extern_activate.auto' in def_user_perms
 
     def try_dynamic_binding(self, username, password, current_args):
         """
         Detects marker inside our original bind, and uses dynamic auth if
         present
         """
 
         org_bind = current_args['bind_dn']
         passwd = current_args['bind_pass']
 
         def has_bind_marker(username):
             if self.DYNAMIC_BIND_VAR in username:
                 return True
 
         # we only passed in user with "special" variable
         if org_bind and has_bind_marker(org_bind) and not passwd:
             log.debug('Using dynamic user/password binding for ldap '
                       'authentication. Replacing `%s` with username',
                       self.DYNAMIC_BIND_VAR)
             current_args['bind_dn'] = org_bind.replace(
                 self.DYNAMIC_BIND_VAR, username)
             current_args['bind_pass'] = password
 
         return current_args
 
     def auth(self, userobj, username, password, settings, **kwargs):
         """
         Given a user object (which may be null), username, a plaintext password,
         and a settings object (containing all the keys needed as listed in
         settings()), authenticate this user's login attempt.
 
         Return None on failure. On success, return a dictionary of the form:
 
             see: RhodeCodeAuthPluginBase.auth_func_attrs
         This is later validated for correctness
         """
 
         if not username or not password:
             log.debug('Empty username or password skipping...')
             return None
 
         ldap_args = {
             'server': settings.get('host', ''),
             'base_dn': settings.get('base_dn', ''),
             'port': settings.get('port'),
             'bind_dn': settings.get('dn_user'),
             'bind_pass': settings.get('dn_pass'),
             'tls_kind': settings.get('tls_kind'),
             'tls_reqcert': settings.get('tls_reqcert'),
             'tls_cert_file': settings.get('tls_cert_file'),
             'tls_cert_dir': settings.get('tls_cert_dir'),
             'search_scope': settings.get('search_scope'),
             'attr_login': settings.get('attr_login'),
             'ldap_version': 3,
             'ldap_filter': settings.get('filter'),
             'timeout': settings.get('timeout')
         }
 
         ldap_attrs = self.try_dynamic_binding(username, password, ldap_args)
 
         log.debug('Checking for ldap authentication.')
 
         try:
             aldap = AuthLdap(**ldap_args)
             (user_dn, ldap_attrs) = aldap.authenticate_ldap(username, password)
             log.debug('Got ldap DN response %s', user_dn)
 
             def get_ldap_attr(k):
                 return ldap_attrs.get(settings.get(k), [''])[0]
 
             # old attrs fetched from RhodeCode database
             admin = getattr(userobj, 'admin', False)
             active = getattr(userobj, 'active', True)
             email = getattr(userobj, 'email', '')
             username = getattr(userobj, 'username', username)
             firstname = getattr(userobj, 'firstname', '')
             lastname = getattr(userobj, 'lastname', '')
             extern_type = getattr(userobj, 'extern_type', '')
 
             groups = []
 
             user_attrs = {
                 'username': username,
                 'firstname': safe_unicode(get_ldap_attr('attr_firstname') or firstname),
                 'lastname': safe_unicode(get_ldap_attr('attr_lastname') or lastname),
                 'groups': groups,
                 'user_group_sync': False,
                 'email': get_ldap_attr('attr_email') or email,
                 'admin': admin,
                 'active': active,
                 'active_from_extern': None,
                 'extern_name': user_dn,
                 'extern_type': extern_type,
             }
 
             log.debug('ldap user: %s', user_attrs)
             log.info('user `%s` authenticated correctly', user_attrs['username'])
 
             return user_attrs
 
         except (LdapUsernameError, LdapPasswordError, LdapImportError):
             log.exception("LDAP related exception")
             return None
         except (Exception,):
             log.exception("Other exception")
             return None
 
 
 def includeme(config):
     plugin_id = 'egg:rhodecode-enterprise-ce#{}'.format(RhodeCodeAuthPlugin.uid)
     plugin_factory(plugin_id).includeme(config)

rhodecode/public/css/type.less

@@ -1,545 +1,545 b''
 //
 // Typography
 // modified from Bootstrap
 // --------------------------------------------------
 
 // Base
 body {
     font-size: @basefontsize;
     font-family: @text-light;
     letter-spacing: .02em;
     color: @grey2;
 }
 
 #content, label{
   font-size: @basefontsize;
 }
 
 label {
   color: @grey2;
 }
 
 ::selection { background: @rchighlightblue; }
 
 // Headings
 // -------------------------
 
 h1, h2, h3, h4, h5, h6,
 .h1, .h2, .h3, .h4, .h5, .h6 {
   margin: 0 0 @textmargin 0;
   padding: 0;
   line-height: 1.8em;
   color: @text-color;
   a {
     color: @rcblue;
   }
 }
 
 h1, .h1 { font-size: 1.54em; font-weight: @text-bold-weight;     font-family: @text-bold; }
 h2, .h2 { font-size: 1.23em; font-weight: @text-semibold-weight; font-family: @text-semibold;  }
 h3, .h3 { font-size: 1.23em;                                     font-family: @text-regular; }
 h4, .h4 { font-size: 1em;    font-weight: @text-bold-weight;     font-family: @text-bold; }
 h5, .h5 { font-size: 1em;    font-weight: @text-bold-weight;     font-family: @text-bold; }
 h6, .h6 { font-size: 1em;    font-weight: @text-bold-weight;     font-family: @text-bold; }
 
 // Breadcrumbs
 .breadcrumbs {
     font-size: @repo-title-fontsize;
     margin: 0;
 }
 
 .breadcrumbs_light {
   float:left;
   font-size: 1.3em;
   line-height: 38px;
 }
 
 // Body text
 // -------------------------
 
 p {
     margin: 0 0 @textmargin 0;
     padding: 0;
     line-height: 2em;
 }
 
 .lead {
   margin-bottom: @textmargin;
   font-weight: 300;
   line-height: 1.4;
 
   @media (min-width: @screen-sm-min) {
     font-size: (@basefontsize * 1.5);
   }
 }
 
 a,
 .link {
     color: @rcblue;
     text-decoration: none;
     outline: none;
     cursor: pointer;
 
     &:focus {
         outline: none;
     }
 
     &:hover {
         color: @rcdarkblue;
     }
 }
 
 img {
     border: none;
     outline: none;
 }
 
 strong {
   font-weight: @text-bold-weight;
   font-family: @text-bold;
 }
 
 em {
   font-family: @text-italic;
   font-style: italic;
 }
 
 strong em,
 em strong {
   font-style: italic;
   font-weight: @text-bold-italic-weight;
   font-family: @text-bold-italic;
 }
 
 //TODO: lisa: b and i are depreciated, but we are still using them in places.
 //            Should probably make some decision whether to keep or lose these.
 b {
 
 }
 
 i {
     font-style: normal;
 }
 
 label {
     color: @text-color;
 
     input[type="checkbox"] {
         margin-right: 1em;
     }
     input[type="radio"] {
         margin-right: 1em;
     }
 }
 
 code,
 .code {
   font-size: .95em;
   font-family: @text-code;
   color: @grey3;
 
   a {
       color: lighten(@rcblue,10%)
   }
 }
 
 pre {
     margin: 0;
     padding: 0;
     border: 0;
     outline: 0;
     font-size: @basefontsize*.95;
     line-height: 1.4em;
     font-family: @text-code;
     color: @grey3;
 }
 
 // Emphasis & misc
 // -------------------------
 
 small,
 .small {
   font-size: 75%;
   font-weight: normal;
   line-height: 1em;
 }
 
 mark,
 .mark {
   background-color: @rclightblue;
   padding: .2em;
 }
 
 // Alignment
 .text-left           { text-align: left; }
 .text-right          { text-align: right; }
 .text-center         { text-align: center; }
 .text-justify        { text-align: justify; }
 .text-nowrap         { white-space: nowrap; }
 
 // Transformation
 .text-lowercase      { text-transform: lowercase; }
 .text-uppercase      { text-transform: uppercase; }
 .text-capitalize     { text-transform: capitalize; }
 
 // Contextual colors
 .text-muted {
   color: @grey4;
 }
 .text-primary {
   color: @rcblue;
 }
 .text-success {
   color: @alert1;
 }
 .text-info {
   color: @alert4;
 }
 .text-warning {
   color: @alert3;
 }
 .text-danger {
   color: @alert2;
 }
 
 // Contextual backgrounds
 .bg-primary {
   background-color: white;
 }
 .bg-success {
   background-color: @alert1;
 }
 .bg-info {
   background-color: @alert4;
 }
 .bg-warning {
   background-color: @alert3;
 }
 .bg-danger {
   background-color: @alert2;
 }
 
 
 // Page header
 // -------------------------
 
 .page-header {
   margin: @pagepadding 0 @textmargin;
   border-bottom: @border-thickness solid @grey5;
 }
 
 .title {
     clear: both;
     float: left;
     width: 100%;
     margin: @pagepadding/2 0 @pagepadding;
 
     .breadcrumbs {
         float: left;
         clear: both;
         width: 700px;
         margin: 0;
 
         .q_filter_box {
           margin-right: @padding;
         }
     }
 
     h1 a {
         color: @rcblue;
     }
 
     input{
         margin-right: @padding;
     }
 
     h5, .h5 {
         color: @grey1;
         margin-bottom: @space;
 
         span {
             display: inline-block;
         }
     }
 
     p {
       margin-bottom: 0;
     }
 
     .links {
         float: right;
         display: inline;
         margin: 0;
         padding-left: 0;
         list-style: none;
         text-align: right;
 
         li {
           float: right;
           list-style-type: none;
         }
 
         a {
             display: inline-block;
             margin-left: @textmargin/2;
         }
     }
 
     .title-content {
       float: left;
       margin: 0;
       padding: 0;
 
       & + .breadcrumbs {
         margin-top: @padding;
       }
 
       & + .links {
         margin-top: -@button-padding;
 
         & + .breadcrumbs {
           margin-top: @padding;
         }
       }
     }
 
     .title-main {
       font-size: @repo-title-fontsize;
     }
 
     .title-description {
       margin-top: .5em;
     }
 
     .q_filter_box {
       width: 200px;
     }
 
 }
 
 #readme .title {
   text-transform: none;
 }
 
 // Lists
 // -------------------------
 
 // Unordered and Ordered lists
 ul,
 ol {
   margin-top: 0;
   margin-bottom: @textmargin;
   ul,
   ol {
     margin-bottom: 0;
   }
 }
 
 li {
   line-height: 2em;
 }
 
 ul li {
   position: relative;
   list-style-type: disc;
 
   p:first-child {
     display:inline;
   }
 }
 
 // List options
 
 // Unstyled keeps list items block level, just removes default browser padding and list-style
 .list-unstyled {
   padding-left: 0;
   list-style: none;
   li:before { content: none; }
 }
 
 // Inline turns list items into inline-block
 .list-inline {
   .list-unstyled();
   margin-left: -5px;
 
   > li {
     display: inline-block;
     padding-left: 5px;
     padding-right: 5px;
   }
 }
 
 // Description Lists
 
 dl {
   margin-top: 0; // Remove browser default
   margin-bottom: @textmargin;
 }
 
 dt,
 dd {
   line-height: 1.4em;
 }
 
 dt {
   margin: @textmargin 0 0 0;
   font-weight: @text-bold-weight;
   font-family: @text-bold;
 }
 
 dd {
   margin-left: 0; // Undo browser default
 }
 
 // Horizontal description lists
 // Defaults to being stacked without any of the below styles applied, until the
 // grid breakpoint is reached (default of ~768px).
 // These are used in forms as well; see style guide.
 // TODO: lisa: These should really not be used in forms.
 
 .dl-horizontal {
 
     overflow: hidden;
     margin-bottom: @space;
 
     dt, dd {
       float: left;
       margin: 5px 0 5px 0;
     }
 
     dt {
         clear: left;
         width: @label-width - @form-vertical-margin;
     }
 
     dd {
         &:extend(.clearfix all); // Clear the floated `dt` if an empty `dd` is  present
         margin-left: @form-vertical-margin;
         max-width: @form-max-width - (@label-width - @form-vertical-margin) - @form-vertical-margin;
     }
 
     pre {
         margin: 0;
     }
 
     &.settings {
       dt {
         text-align: left;
       }
     }
 
     @media (min-width: 768px) {
       dt {
         float: left;
         width: 185px;
         clear: left;
         text-align: right;
       }
       dd {
         margin-left: 20px;
       }
     }
 }
 
 
 // Misc
 // -------------------------
 
 // Abbreviations and acronyms
 abbr[title],
 abbr[data-original-title] {
   cursor: help;
   border-bottom: @border-thickness dotted @grey4;
 }
 .initialism {
   font-size: 90%;
   text-transform: uppercase;
 }
 
 // Blockquotes
 blockquote {
   padding: 1em 2em;
   margin: 0 0 2em;
   font-size: @basefontsize;
   border-left: 2px solid @grey6;
 
   p,
   ul,
   ol {
     &:last-child {
       margin-bottom: 0;
     }
   }
 
   footer,
   small,
   .small {
     display: block;
     font-size: 80%;
 
     &:before {
       content: '\2014 \00A0'; // em dash, nbsp
     }
   }
 }
 
 // Opposite alignment of blockquote
 //
 .blockquote-reverse,
 blockquote.pull-right {
   padding-right: 15px;
   padding-left: 0;
   border-right: 5px solid @grey6;
   border-left: 0;
   text-align: right;
 
   // Account for citation
   footer,
   small,
   .small {
     &:before { content: ''; }
     &:after {
       content: '\00A0 \2014'; // nbsp, em dash
     }
   }
 }
 
 // Addresses
 address {
   margin-bottom: 2em;
   font-style: normal;
   line-height: 1.8em;
 }
 
 .error-message {
     display: block;
     margin: @padding/3 0;
     color: @alert2;
 }
 
 .issue-tracker-link {
     color: @rcblue;
 }
 
 .info_text{
   font-size: @basefontsize;
   color: @grey4;
   font-family: @text-regular;
 }
 
 // help block text
 .help-block {
   display: block;
   margin: 0 0 @padding;
   color: @grey4;
   font-family: @text-light;
   &.pre-formatting {
-      white-space: pre;
+      white-space: pre-wrap;
   }
 }
 
 .error-message {
   display: block;
   margin: @padding/3 0;
   color: @alert2;
 }

rhodecode/templates/admin/auth/plugin_settings.mako

@@ -1,121 +1,132 b''
 ## -*- coding: utf-8 -*-
 <%inherit file="/base/base.mako"/>
 
 <%def name="title()">
   ${_('Authentication Settings')}
   %if c.rhodecode_name:
     &middot; ${h.branding(c.rhodecode_name)}}
   %endif
 </%def>
 
 <%def name="breadcrumbs_links()">
   ${h.link_to(_('Admin'),h.route_path('admin_home'))}
   &raquo;
   ${h.link_to(_('Authentication Plugins'),request.resource_path(resource.__parent__, route_name='auth_home'))}
   &raquo;
   ${resource.display_name}
 </%def>
 
 <%def name="menu_bar_nav()">
   ${self.menu_items(active='admin')}
 </%def>
 
 <%def name="main()">
   <div class="box">
     <div class="title">
       ${self.breadcrumbs()}
     </div>
     <div class='sidebar-col-wrapper'>
 
       ## TODO: This is repeated in the auth root template and should be merged
       ##       into a single solution.
       <div class="sidebar">
         <ul class="nav nav-pills nav-stacked">
           % for item in resource.get_root().get_nav_list():
             <li ${'class=active' if item == resource else ''}>
               <a href="${request.resource_path(item, route_name='auth_home')}">${item.display_name}</a>
             </li>
           % endfor
         </ul>
       </div>
 
       <div class="main-content-full-width">
         <div class="panel panel-default">
           <div class="panel-heading">
             <h3 class="panel-title">${_('Plugin')}: ${resource.display_name}</h3>
           </div>
           <div class="panel-body">
             <div class="plugin_form">
               <div class="fields">
                 ${h.secure_form(request.resource_path(resource, route_name='auth_home'), request=request)}
                 <div class="form">
 
                   %for node in plugin.get_settings_schema():
                     <%
                       label_to_type = {'label-checkbox': 'bool', 'label-textarea': 'textarea'}
                     %>
 
                     <div class="field">
                       <div class="label ${label_to_type.get(node.widget)}"><label for="${node.name}">${node.title}</label></div>
                       <div class="input">
                         %if node.widget in ["string", "int", "unicode"]:
                           ${h.text(node.name, defaults.get(node.name), class_="large")}
                         %elif node.widget == "password":
                           ${h.password(node.name, defaults.get(node.name), class_="large")}
                         %elif node.widget == "bool":
                           <div class="checkbox">${h.checkbox(node.name, True, checked=defaults.get(node.name))}</div>
                         %elif node.widget == "select":
                           ${h.select(node.name, defaults.get(node.name), node.validator.choices, class_="select2AuthSetting")}
                         %elif node.widget == "textarea":
                           <div class="textarea" style="margin-left: 0px">${h.textarea(node.name, defaults.get(node.name), rows=10)}</div>
                         %elif node.widget == "readonly":
                           ${node.default}
                         %else:
                           This field is of type ${node.typ}, which cannot be displayed. Must be one of [string|int|bool|select].
                         %endif
 
                         %if node.name in errors:
                           <span class="error-message">${errors.get(node.name)}</span>
                           <br />
                         %endif
                         <p class="help-block pre-formatting">${node.description}</p>
                       </div>
                     </div>
                   %endfor
 
                   ## Allow derived templates to add something below the form
                   ## input fields
                   %if hasattr(next, 'below_form_fields'):
                     ${next.below_form_fields()}
                   %endif
 
                   <div class="buttons">
                     ${h.submit('save',_('Save'),class_="btn")}
                   </div>
 
                 </div>
                 ${h.end_form()}
               </div>
             </div>
+
+% if request.GET.get('schema'):
+## this is for development and creation of example configurations for documentation
+<pre>
+    % for node in plugin.get_settings_schema():
+    *option*: `${node.name}` => `${defaults.get(node.name)}`${'\n    # '.join(['']+node.description.splitlines())}
+
+    % endfor
+</pre>
+
+% endif
+
           </div>
         </div>
       </div>
 
     </div>
   </div>
 
-## TODO: Ugly hack to get ldap select elements to work.
-##       Find a solution to integrate this nicely.
+
 <script>
 $(document).ready(function() {
   var select2Options = {
         containerCssClass: 'drop-menu',
         dropdownCssClass: 'drop-menu-dropdown',
         dropdownAutoWidth: true,
         minimumResultsForSearch: -1
   };
   $('.select2AuthSetting').select2(select2Options);
 
 });
 </script>
 </%def>