Maintenance: Apply formatting fixes

admin/console/hidden-settings.rst

@@ -58,9 +58,9 @@ By default this will be a incoming phone call.
 
 You can choose between
 
-   * ``phone-in`` (incoming call, **default**),
-   * ``phone-out`` (outgoing call) and
-   * ``email-out``  (Sending an email out).
+- ``phone-in`` (incoming call, **default**),
+- ``phone-out`` (outgoing call) and
+- ``email-out``  (Sending an email out).
 
 .. code-block:: irb
 

admin/console/zammad-settings.rst

@@ -118,8 +118,8 @@ seconds, e.g. ``1``:
 
 The following settings are available in a default installation:
 
-   * ``DB`` (database)
-   * ``File`` (Filesystem (``/opt/zammad/storage/``))
+- ``DB`` (database)
+- ``File`` (Filesystem (``/opt/zammad/storage/``))
 
 Configuring Elasticsearch
 -------------------------

api/generic-cti/answer-event.rst

@@ -34,9 +34,9 @@ Call Answered
      - Zammad will look up for a user with given value, the following
        attributes will be evaluated in given order:
 
-          * ``user.phone``
-          * ``user.login``
-          * ``user.id``
+          - ``user.phone``
+          - ``user.login``
+          - ``user.id``
 
        This value is optional.
    * - ``user``
@@ -203,4 +203,4 @@ There's two options on how to ``POST`` the relevant data to Zammad.
                   --form 'caller="Emma Taylor"'
 
 The next logical step within call session context would be:
-   * :doc:`hangup <hangup-event>` (call ending)
+   - :doc:`hangup <hangup-event>` (call ending)

api/generic-cti/generic-cti_context-note-configuration.include.rst

@@ -4,11 +4,11 @@
 
    **Outbound:**
 
-   * Destination caller ID ``4989*`` set outbound caller ID
+   - Destination caller ID ``4989*`` set outbound caller ID
      ``498999998145`` with note "All from munich"
-   * Destination caller ID ``4930*`` set outbound caller ID
+   - Destination caller ID ``4930*`` set outbound caller ID
      ``493023125877`` "All from Berlin"
 
    **Other settings:**
 
-   * Default caller ID for outbound calls ``496990009111``
+   - Default caller ID for outbound calls ``496990009111``

api/generic-cti/hangup-event.rst

@@ -56,9 +56,9 @@ Call Hangup
      - Zammad will look up for a user with given value, the following
        attributes will be evaluated in given order:
 
-          * ``user.phone``
-          * ``user.login``
-          * ``user.id``
+          - ``user.phone``
+          - ``user.login``
+          - ``user.id``
 
        This value is optional.
 

api/generic-cti/index.rst

@@ -5,25 +5,25 @@ This page describes the generic CTI API scopes and functionalities.
 
 .. warning:: **🚧 Limitations / Notes 🚧**
 
-   * Authentication on this endpoint works fundamentally different compared to
+   - Authentication on this endpoint works fundamentally different compared to
      the rest of the API.
-   * API clients *do not* work with the CTI endpoints unless explicitly stated
+   - API clients *do not* work with the CTI endpoints unless explicitly stated
      by the client vendor!
-   * The CTI endpoints are relevant for PBX systems only.
+   - The CTI endpoints are relevant for PBX systems only.
 
 
 Features
    Here's a small condensed list of the possibilities this CTI API provides.
 
    Inbound
-      * :user-docs:`Caller log functions </extras/caller-log.html>` for your
+      - :user-docs:`Caller log functions </extras/caller-log.html>` for your
         agents.
-      * Blocking of CallerIDs during signaling.
+      - Blocking of CallerIDs during signaling.
 
    Outbound
-      * :user-docs:`Caller log functions </extras/caller-log.html>` for your
+      - :user-docs:`Caller log functions </extras/caller-log.html>` for your
         agents.
-      * Set outbound caller IDs depending on the caller ID target.
+      - Set outbound caller IDs depending on the caller ID target.
 
 Endpoint
    The endpoint can be found in the generic CTI integration and contains a
@@ -45,9 +45,9 @@ Events
    There are several events in terms of an ongoing call.
    These actions always come from your PBX system and may be:
 
-      * :doc:`"newCall" event <newcall-event>` (initiation of a call)
-      * :doc:`"hangup" event <hangup-event>` (call ending)
-      * :doc:`"answer" event <answer-event>` (aka picking up the phone)
+   - :doc:`"newCall" event <newcall-event>` (initiation of a call)
+   - :doc:`"hangup" event <hangup-event>` (call ending)
+   - :doc:`"answer" event <answer-event>` (aka picking up the phone)
 
    In some situations Zammad may provide a return on your PBX calls
    (e.g. a reject) if you blocked a specific caller. Zammad will never initiate

api/generic-cti/newcall-event.rst

@@ -259,5 +259,5 @@ configured one or both options, the return will be empty.
             {}
 
 The next logical steps within call session context would be:
-   * :doc:`hangup <hangup-event>` (call ending)
-   * :doc:`answer <answer-event>` (aka picking up the phone)
+   - :doc:`hangup <hangup-event>` (call ending)
+   - :doc:`answer <answer-event>` (aka picking up the phone)

api/group.rst

@@ -3,9 +3,9 @@ Group
 
 .. note::
 
-   * Please note that ``follow_up_possible`` may not work as expected.
+   - Please note that ``follow_up_possible`` may not work as expected.
      The possible values are ``yes`` or ``new_ticket``!
-   * If you want to create or update **subgroups**, use ``::`` as delimiter for
+   - If you want to create or update **subgroups**, use ``::`` as delimiter for
      the names. You also have to name the complete hierarchy in the name.
      Example: ``Sales::Europe::South``
 

api/intro.rst

@@ -4387,9 +4387,9 @@ by a different user.
 To do so, add a new HTTP header named ``From`` to your request.
 The value of this header can be one of the following:
 
-   * user ID
-   * user login
-   * user email
+- user ID
+- user login
+- user email
 
 ``From`` is available for all endpoints.
 

api/object.rst

@@ -1078,11 +1078,10 @@ Required permission: ``admin.object``
 
          Zammad input fields can have 4 different types:
 
-            * ``email``
-            * ``tel``
-            * ``text``
-            * | ``url``
-              | ⚠ *URL* does not support link-templates ⚠
+         - ``email``
+         - ``tel``
+         - ``text``
+         - ``url`` (URL does not support link-templates)
 
          Depending on the chosen input type, Zammad expects different formats
          of data. E.g.: *email* demands a email address to be provided.
@@ -1354,10 +1353,10 @@ Required permission: ``admin.object``
 
    The attribute ``object`` controls which context is being used:
 
-      * ``Ticket``
-      * ``User``
-      * ``Organisation``
-      * ``Group``
+   - ``Ticket``
+   - ``User``
+   - ``Organisation``
+   - ``Group``
 
    .. tabs::
 

api/ticket/articles.rst

@@ -89,9 +89,9 @@ internal
 sender
    Indicates which use did create the article. You can choose from:
 
-      * ``Agent``
-      * ``Customer``
-      * ``System``
+      - ``Agent``
+      - ``Customer``
+      - ``System``
 
    .. warning::
 

appendix/backup-and-restore/configuration.rst

@@ -41,8 +41,8 @@ parameter in the table below.
 
       **Examples:**
 
-      * ``1`` will keep backups of the last 25 hours
-      * ``-1`` will remove all available backups (except the new one)
+      - ``1`` will keep backups of the last 25 hours
+      - ``-1`` will remove all available backups (except the new one)
   * - ``FULL_FS_DUMP``
     - ``no``
     - If set to ``yes``, the backup includes also application files.

appendix/backup-and-restore/docker-file-handling.rst

@@ -81,7 +81,7 @@ sure to provide additional volumes for persistence (e.g. for their database).
       .. tab:: Via Portainer
 
          In your Portainer web UI, go to **Containers** in the left menu and
-         click the **Add container** button.
+         click the ``Add container`` button.
 
          Add the following information:
 
@@ -91,7 +91,7 @@ sure to provide additional volumes for persistence (e.g. for their database).
            container.
          - Advanced container settings:
 
-           - Switch to **Volumes** and click the **map additional volume** button.
+           - Switch to **Volumes** and click the ``map additional volume`` button.
            - Enter ``/srv`` in the container section and select the volume
              containing ``zammad-backup``
 

appendix/backup-and-restore/index.rst

@@ -91,18 +91,18 @@ Limitations
 Please note the following limitations which may affect script functionality
 or availability:
 
-   * These scripts won't work in container and source code based installations.
-   * The backup is always a full dump (no incremental backup).
-   * Partial backup and restore (e.g. only specific data like tickets, users)
-     is not possible.
-   * Switching database system **is not** possible. See
-     :doc:`here </appendix/migrate-to-postgresql>` how to manually switch
-     databases.
-   * System settings (like
-     :doc:`environment variables </appendix/environment-variables>`) are
-     not backed up.
-   * Restore to an older Zammad version is not possible.
-   * **Do not** restore backup files from custom scripts with the
-     provided scripts by Zammad. This might cause problems.
+- These scripts won't work in container and source code based installations.
+- The backup is always a full dump (no incremental backup).
+- Partial backup and restore (e.g. only specific data like tickets, users)
+  is not possible.
+- Switching database system **is not** possible. See
+  :doc:`here </appendix/migrate-to-postgresql>` how to manually switch
+  databases.
+- System settings (like
+  :doc:`environment variables </appendix/environment-variables>`) are
+  not backed up.
+- Restore to an older Zammad version is not possible.
+- **Do not** restore backup files from custom scripts with the
+  provided scripts by Zammad. This might cause problems.
 
 

appendix/backup-and-restore/little-helpers.rst

@@ -15,25 +15,25 @@ Database Helper: (Re)set Password
 =================================
 
 Limitations
-   * Only local database servers are supported (script changes user).
-   * This script requires to be run as ``root`` or similar privileged user.
-   * Be aware that the script will automatically stop and start Zammad!
+   - Only local database servers are supported (script changes user).
+   - This script requires to be run as ``root`` or similar privileged user.
+   - Be aware that the script will automatically stop and start Zammad!
 
 Scopes
    Mostly the following installation types will be affected / relevant:
 
-      * package installations (especially CentOS & SUSE)
-      * possibly source code installations
+   - package installations (especially CentOS & SUSE)
+   - possibly source code installations
 
 Functionality
    The script will do the following actions automatically for you, depending
    on the situation. It will ask for your confirmation before performing
    actions.
 
-      * If ``database.yml`` contains an empty password line, a new password
+   - If ``database.yml`` contains an empty password line, a new password
         will be generated and set for the database user of Zammad. It will also
         be saved to the configuration file.
-      * If ``database.yml`` contains a password, it will be used to set
+   - If ``database.yml`` contains a password, it will be used to set
         the password of the Zammad database user.
 
 Usage

appendix/backup-and-restore/migrate-hosts.rst

@@ -29,8 +29,8 @@ Step 2: Install Zammad on the destination host
 
    Have a look at the installation instructions:
 
-      * :doc:`Package Installation </install/package>`
-      * :doc:`Install with Docker </install/docker-compose>`
+   - :doc:`Package Installation </install/package>`
+   - :doc:`Install with Docker </install/docker-compose>`
 
 Step 3: Activate maintenance mode
    This ends all agent and customer sessions.
@@ -97,9 +97,9 @@ Step 9: Run required maintenance tasks after restoring
 
             This step is only needed, if one of the following points is met:
 
-            * The source and destination Zammad versions are not the same
-            * The Zammad installation is not a source code installation
-            * The Zammad backup is not an export from our hosted setup
+            - The source and destination Zammad versions are not the same
+            - The Zammad installation is not a source code installation
+            - The Zammad backup is not an export from our hosted setup
 
             Full dumps for source code installations are not covered, however,
             basically the same below applies to you: You have to ensure that

appendix/backup-and-restore/restore.rst

@@ -17,17 +17,17 @@ your data.
 - The restoration process **stops & restarts** Zammad. Therefore you have to
   run the restore script with appropriate permissions (e.g. as ``root``).
 
-   * This is **mandatory** for *package installations*
-   * On *source code installations*, this does not work because of different
+   - This is **mandatory** for *package installations*
+   - On *source code installations*, this does not work because of different
      environments. You could load it beforehand as root user to have
      access to Zammad specific commands.
-   * If both approaches above do not fit your case, consider
+   - If both approaches above do not fit your case, consider
      adjusting the backup and restore scripts to your need in an
      independent directory. You're working out of script and
      documentation scope!
 
-* It will drop and re-create the database!
-* You require at least twice the backed up Zammad instance size of free
+- It will drop and re-create the database!
+- You require at least twice the backed up Zammad instance size of free
   storage. If you have the dump only, factor 3 could be a good number.
 
 Restore

appendix/custom-kb-url.rst

@@ -15,8 +15,8 @@ Configure Zammad
 - Go to "Knowledge Base" in Zammad's admin settings and select the "Custom URL"
   tab
 - Add the URL you want to publish your knowledge base under and click the
-  **Submit** button
-- Click on the **Web Server Configuration** button to get the configuration for
+  ``Submit`` button
+- Click on the ``Web Server Configuration`` button to get the configuration for
   your NPM. You can already copy the snippet or just leave it open, it is
   needed for the NPM configuration.
 

appendix/privacy.rst

@@ -18,7 +18,7 @@ Tickets and users
    (*e.g.* in compliance with a “Right to Forget” request under the GDPR),
    you can use the
    :admin-docs:`data privacy functions </system/data-privacy.html>`
-   in the admin panel or
+   in the admin settings or
    :doc:`use the console </admin/console/dangerzone-for-experts>`.
 
 Chat sessions
@@ -46,7 +46,7 @@ User sessions
    Zammad maintains session information about every user currently logged in.
 
    This information is automatically purged when a user logs out,
-   and can be viewed or manually deleted via the admin panel (under **System → Sessions**).
+   and can be viewed or manually deleted via the admin settings (under **System → Sessions**).
    Users may also delete their own session information
    via the user preferences menu, under **Device**.
 
@@ -61,7 +61,7 @@ External Services
 
 Zammad utilizes third party web services for certain functions,
 meaning that user data may occasionally be sent or exposed to third parties.
-These functions can be individually disabled in the admin panel
+These functions can be individually disabled in the admin settings
 under **Settings → System → Services**.
 
 .. note:: By default, the third party services that Zammad relies on

appendix/reporting-tools-thirdparty.rst

@@ -34,9 +34,9 @@ This guide will discuss how to set up third party reporting tools with Zammad.
 Getting Started
 ---------------
 
-You will need
+You will need:
 
-   * An instance of the reporting tool of your choice (hosted or self-hosted)
+- An instance of the reporting tool of your choice (hosted or self-hosted)
 
 .. include:: reporting-tools-thirdparty/include-requirements.rst