Use filename prefixes for doc ordering (#164)

docs/introduction.md → docs/10-introduction.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 1
----
-
 # Introduction
 
 ## Welcome to the OpenRemote documentation!
@@ -14,7 +10,7 @@ The core of the OpenRemote system is the [Manager](https://github.com/openremote
 
 Rules can be written in Groovy, a Rules JSON, or Flow model, and dynamically deployed. Rules execute actions when matching asset state or sequence of events are detected. For example, when a mobile asset enters a geographic fence, or when your sensor is not updating anymore, you can notify a group of users via email and on their mobile devices.
 
-Networked things and devices are connected to the manager via [Agents](https://github.com/openremote/openremote/tree/master/agent), they are the interface to 3rd party APIs and service protocols, using the services model. OpenRemote has many built-in protocols and it's easy to create new adapters. Co-locate your agents with the manager or install agents on [Edge gateways](user-guide/gateways-and-devices/edge-gateway.md), close to devices. 
+Networked things and devices are connected to the manager via [Agents](https://github.com/openremote/openremote/tree/master/agent), they are the interface to 3rd party APIs and service protocols, using the services model. OpenRemote has many built-in protocols and it's easy to create new adapters. Co-locate your agents with the manager or install agents on [Edge gateways](./user-guide/080-gateways-and-devices/10-edge-gateway.md), close to devices. 
 
 The [Manager UI](https://github.com/openremote/openremote/tree/master/ui/app/manager) is configurable and suitable both for configuring your IoT system as well as monitoring the performance of your system. The Insight dashboard builder offers a quick way to create one page dashboard apps for your professional users who don't need access to the full manager.  
 
@@ -24,7 +20,7 @@ The manager provides APIs for monitoring and administrating the system:
 * WebSockets event API
 * MQTT event API
 
-The OpenRemote [Frontend](developer-guide/working-on-ui-and-apps.md) simplifies the creation and deployment of user interfaces such as:
+The OpenRemote [Frontend](./developer-guide/110-working-on-ui-and-apps.md) simplifies the creation and deployment of user interfaces such as:
 
 * Multi tenancy monitoring dashboard
 * Home automation control panel

docs/quick-start.md → docs/20-quick-start.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 2
----
-
 # Quick Start
 
 Welcome to OpenRemote; an intuitive user-friendly 100% open source IoT platform. You can build a complete IoT device management solution including: device management and auto provisioning, customisation of asset types, automation via When-Then, Flow and Groovy rules, data analytics, connectivity via several protocol agents and manager APIs (e.g. MQTT broker, HTTP/REST, WS), Multi-tenancy (realms), Users and roles management, Edge gateway, Front-end UI web components and consoles, and an Insights dashboard builder. 
@@ -48,12 +44,12 @@ cmd /C "set OR_HOSTNAME=192.168.1.1 && docker-compose -p openremote up -d"
 ## What next
 Try creating assets, agents, rules, users, realms, etc. using the Manager UI, some things to try:
 
-- [Manager UI Guide](user-guide/manager-ui/manager-ui.md) - Learn more about the User Interface
-- [Creating an HTTP Agent tutorial](tutorials/open-weather-api-using-http-agent.md) - Connect to an online weather service
-- [Custom Deployment](user-guide/deploying/custom-deployment.md) - Style the Manager to your brand
-- [Setting up an IDE](developer-guide/setting-up-an-ide.md) - Set up your development environment
-- [Working on the UI](developer-guide/working-on-ui-and-apps.md) - Create a web application compatible with OpenRemote
-- [Creating a custom project](developer-guide/creating-a-custom-project.md) - Create a project with custom protocols, asset types and setup code
+- [Manager UI Guide](./user-guide/020-manager-ui/10-manager-ui.md) - Learn more about the User Interface
+- [Creating an HTTP Agent tutorial](./tutorials/020-open-weather-api-using-http-agent.md) - Connect to an online weather service
+- [Custom Deployment](./user-guide/010-deploying/10-custom-deployment.md) - Style the Manager to your brand
+- [Setting up an IDE](./developer-guide/020-setting-up-an-ide.md) - Set up your development environment
+- [Working on the UI](./developer-guide/110-working-on-ui-and-apps.md) - Create a web application compatible with OpenRemote
+- [Creating a custom project](./developer-guide/040-creating-a-custom-project.md) - Create a project with custom protocols, asset types and setup code
 
 ## Where's the data stored?
 Persistent data is stored in a PostgreSQL DB which is stored in the `openremote_postgresql-data` Docker volume which is durably stored independently of the running containers (see all with `docker volume ls`).
@@ -63,7 +59,7 @@ See the [Developer Guide](developer-guide/system-administration#backuprestore) f
 
 ## Contributing to OpenRemote
 
-For information and how to set up a development environment, see the [Developer Guide](developer-guide/preparing-the-environment.md).
+For information and how to set up a development environment, see the [Developer Guide](./developer-guide/010-preparing-the-environment.md).
 
 We work with Java, Groovy, TypeScript, Gradle, Docker, and a wide range of APIs and protocol implementations.
 

docs/architecture/overall-architecture.md → docs/architecture/10-overall-architecture.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 1
----
-
 # Overall architecture
 
 At the heart of the manager, is the [Container](https://www.javadoc.io/doc/io.openremote/openremote-container/latest/org/openremote/container/Container.html) class that manages the life cycle of all the services, including loading and starting them at launch.  

docs/architecture/manager-endpoints-and-file-paths.md → docs/architecture/20-manager-endpoints-and-file-paths.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 2
----
-
 # Manager endpoints and file paths
 
 ## Endpoints
@@ -17,7 +13,7 @@ The OpenRemote Manager exposes the following endpoints:
 * `/auth` - Keycloak reverse proxy endpoint
 * `/websocket` - WebSocket endpoint
 * `/*` - Any other path is resolved against `$CUSTOM_APP_DOCROOT` (see paths below)
-* `/manager_config.json` - File that is loaded by the Manager UI to apply custom configuration to the Manager UI (white labelling, menu config, etc.)  (loaded from `$CUSTOM_APP_DOCROOT`) (see [here](../user-guide/deploying/configuring-the-manager-ui.md) for more details)
+* `/manager_config.json` - File that is loaded by the Manager UI to apply custom configuration to the Manager UI (white labelling, menu config, etc.)  (loaded from `$CUSTOM_APP_DOCROOT`) (see [here](../user-guide/010-deploying/20-configuring-the-manager-ui.md) for more details)
 * `/locales` - Path used by Manager UI to find custom `i18n` locale files, each locale should be in it's own directory with a file named `app.json` (e.g. `/locales/en/app.json`) (loaded from `$CUSTOM_APP_DOCROOT`)
 
 ### App Realm

docs/architecture/security.md → docs/architecture/30-security.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 3
----
-
 # Security
 
 ## Realm clients

docs/architecture/asset-validation.md → docs/architecture/40-asset-validation.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 4
----
-
 # Asset Validation
 
 This document summarises how asset validation is performed and how it relates to the asset type model.

docs/architecture/asset-location-tracking.md → docs/architecture/50-asset-location-tracking.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 5
----
-
 # Asset location tracking
 
 ## Terminology

docs/architecture/apps-and-consoles.md → docs/architecture/60-apps-and-consoles.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 6
----
-
 # Apps and consoles
 
 ## Terminology

docs/architecture/esp32-device.md → docs/architecture/70-esp32-device.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 7
----
-
 # ESP32 devices
 
 Many IoT devices are or can be based on an ESP32 microcontroller.  
@@ -39,7 +35,7 @@ The device communicates with OpenRemote over MQTTS, authenticated with a dedicat
 In this typical use case, the device uses Wi-Fi for its internet connectivity.
 
 To integrate a new device into the system, it needs to be provisioned.  
-This can either be done automatically, see [User Guide Auto provisioning](/user-guide/gateways-and-devices/auto-provisioning.md)  
+This can either be done automatically, see [User Guide Auto provisioning](../user-guide/080-gateways-and-devices/20-auto-provisioning.md)  
 or through a manual process performed by the end-user.
 
 For the latter case, the workflow is as follows
@@ -102,6 +98,6 @@ sequenceDiagram
 Communication between the Mobile Application and the Device is based on Espressif [Unified Provisioning](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/provisioning/provisioning.html).  
 This mechanism is used to discover the device, then establish a secure communication channel over BLE.  
 Communication on this channel uses Protocol Buffer payloads, in addition to the messages defined by Espressif, OpenRemote uses messages defined in the following ProtoBuf spec: [ORConfigChannelProtocol](https://github.com/openremote/console-ios-lib/blob/7212bc905c7df34c2f3d62f801f0e4df7529a2f0/ORLib/ORConfigChannelProtocol.proto)  
-OpenRemote includes the [ESP Provision provider](apps-and-consoles.md#esp-provision-provider-espprovision) to support the implementation of the mobile application side.
+OpenRemote includes the [ESP Provision provider](./60-apps-and-consoles.md#esp-provision-provider-espprovision) to support the implementation of the mobile application side.
 
 On the backend, the project must implement a single `/rest/device` endpoint, see [Provision Device API](../provisioning-api/provision-device.api.mdx) for more details.

docs/developer-guide/preparing-the-environment.md → docs/developer-guide/010-preparing-the-environment.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 00
----
-
 # Preparing the environment
 
 To build OpenRemote projects, you have to first prepare the environment on your developer workstation or build machine. Alternatively you can use a [Docker image with tooling](#runtime-tooling).

docs/developer-guide/setting-up-an-ide.md → docs/developer-guide/020-setting-up-an-ide.md

@@ -1,12 +1,8 @@
----
-sidebar_position: 10
----
-
 # Setting up an IDE
 
-This guide helps you set up an environment with an IDE when you are done [Preparing the environment](preparing-the-environment.md), so you can work comfortably on the Manager backend services.
+This guide helps you set up an environment with an IDE when you are done [Preparing the environment](./010-preparing-the-environment.md), so you can work comfortably on the Manager backend services.
 
-This is not necessary if you prefer [Working on the UI](working-on-ui-and-apps.md) only, any file manager and text editor will suffice.
+This is not necessary if you prefer [Working on the UI](./110-working-on-ui-and-apps.md) only, any file manager and text editor will suffice.
 
 If you have successfully cloned the OpenRemote repo or a custom project repo, you can run the Docker containers needed for development by running one of the following commands:
 
@@ -88,7 +84,7 @@ For custom working directory or launch settings, you may need to configure `.vsc
 
 ## Setting the working directory
 
-All Docker and Gradle commands **must be executed in the project root directory**. If you are working on the main OpenRemote repository, this means the root of the repository. If you are [Creating a custom project](creating-a-custom-project.md), this means the root of your project's repository.
+All Docker and Gradle commands **must be executed in the project root directory**. If you are working on the main OpenRemote repository, this means the root of the repository. If you are [Creating a custom project](./040-creating-a-custom-project.md), this means the root of your project's repository.
 
 The working directory in your IDE must also always be set to your project root directory.
 
@@ -132,7 +128,7 @@ The web server binds to only localhost interface (i.e. `127.0.0.1`). You can ove
 
 :::
 
-Go to [Working on the UI](working-on-ui-and-apps.md#working-on-an-app-eg-manager-ui) for more information.
+Go to [Working on the UI](./110-working-on-ui-and-apps.md#working-on-an-app-eg-manager-ui) for more information.
 
 
 ## Building

docs/developer-guide/docker-compose-profiles.md → docs/developer-guide/030-docker-compose-profiles.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 11
----
-
 # Docker Compose profiles
 
 ## Docker services
@@ -67,7 +63,7 @@ docker-compose -f profile/dev-ui.yml up -d
 * PostgreSQL DB: jdbc:postgresql://localhost:5432/openremote
 
 ### Full Stack Development / Running Tests (dev-testing.yml)
-This is for running tests or doing development work on the Manager (in an IDE), see the [Setting up an IDE](setting-up-an-ide.md) guide for running the Manager in an IDE.
+This is for running tests or doing development work on the Manager (in an IDE), see the [Setting up an IDE](./020-setting-up-an-ide.md) guide for running the Manager in an IDE.
 
 #### Exposed Services
 * Keycloak: http://localhost:8081/auth
@@ -76,7 +72,7 @@ This is for running tests or doing development work on the Manager (in an IDE),
 ### Full Stack Development with HTTPS Proxy (dev-proxy.yml)
 This is the same as the Full Stack Development profile but also adds the proxy service to allow development/testing of the Manager running behind the reverse proxy with HTTPS (so development environment matches final deployment configuration).
 
-To use this proxy correctly you will need to set the correct environment variables for the manager running behind SSL proxy as described in [Setting up an IDE](setting-up-an-ide.md).
+To use this proxy correctly you will need to set the correct environment variables for the manager running behind SSL proxy as described in [Setting up an IDE](./020-setting-up-an-ide.md).
 
 #### Exposed Services
 * Manager: https://localhost

docs/developer-guide/creating-a-custom-project.md → docs/developer-guide/040-creating-a-custom-project.md

@@ -1,12 +1,8 @@
----
-sidebar_position: 12
----
-
 # Creating a custom project
 
 ## Quickstart
 
-We have a repo which can be used as a template for a custom project; simply clone the [custom-project](https://github.com/openremote/custom-project) repo and start adding your custom code; see the [Endpoints and file paths](../architecture/manager-endpoints-and-file-paths.md) documentation to understand how to override the various parts of the system.
+We have a repo which can be used as a template for a custom project; simply clone the [custom-project](https://github.com/openremote/custom-project) repo and start adding your custom code; see the [Endpoints and file paths](../architecture/20-manager-endpoints-and-file-paths.md) documentation to understand how to override the various parts of the system.
 
 ## What is a custom project
 
@@ -39,7 +35,7 @@ A custom project always depends on the following released OpenRemote artefacts:
 * Java modules - see [Maven Central](https://search.maven.org/search?q=g:io.openremote)
 * UI components - see [npmjs](https://www.npmjs.com/~openremotedeveloper)
 
-The [Release Management](../user-guide/deploying/release-management.md) documentation describes how to update the OpenRemote version of these artefacts.
+The [Release Management](../user-guide/010-deploying/80-release-management.md) documentation describes how to update the OpenRemote version of these artefacts.
 
 ## Custom Project Template
 
@@ -63,7 +59,7 @@ This module is used to generate a `deployment` Docker image which can be volume
 
 ### Adding new modules
 
-Create directory with appropriate name and copy `/deployment/build.gradle` into it, customize this new `build.gradle` as required and start adding your code/files, ensuring that the `installDist` Gradle task copies any output into the appropriate location within the deployment Docker image build directory (see the [Manager endpoints and file paths](../architecture/manager-endpoints-and-file-paths.md)).
+Create directory with appropriate name and copy `/deployment/build.gradle` into it, customize this new `build.gradle` as required and start adding your code/files, ensuring that the `installDist` Gradle task copies any output into the appropriate location within the deployment Docker image build directory (see the [Manager endpoints and file paths](../architecture/20-manager-endpoints-and-file-paths.md)).
 
 ### Adding UI apps/components
 

docs/developer-guide/agent-protocol-spi.md → docs/developer-guide/050-agent-protocol-spi.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 13
----
-
 # Agent and protocol SPI
 
 See the `HTTPProtocol.java` as an example as this will give you a good guide of what to do to build protocol:

docs/developer-guide/licensing-guidelines-for-contributors.md → docs/developer-guide/060-licensing-guidelines-for-contributors.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 13
----
-
 # Licensing guidelines for contributors
 
 All projects should include a `LICENSE.txt` text file in the root folder. This file should also be in the root of any distributed archive/ZIP file.

docs/developer-guide/gateway-tunnelling-setup.md → docs/developer-guide/070-gateway-tunnelling-setup.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 16
----
-
 # Gateway tunnelling setup
 
 This guide describes the steps necessary to setup the gateway tunnelling functionality which allows remote access to edge gateways using [SISH](https://github.com/antoniomika/sish)

docs/developer-guide/extensions.md → docs/developer-guide/080-extensions.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 17
----
-
 # Extensions
 
 Extensions are a way to add project-specific or domain-specific functionality without adding that functionality directly to the OpenRemote core.

docs/developer-guide/external-services.md → docs/developer-guide/090-external-services.md

@@ -1,7 +1,3 @@
----
-sidebar_position: 17
----
-
 # External Services
 
 External services allow developers to extend the functionality of the OpenRemote platform by integrating their own applications directly into the OpenRemote Manager, giving users a seamless way to configure and manage them.
@@ -36,7 +32,7 @@ There are two types of external services in OpenRemote:
 - Bound to a **specific realm** and only available within that realm (single-tenant)
 - Simpler to implement when multi-tenancy is not required
 
-Both global and regular services must be registered by **Service Users**. Global services specifically require a Super User account in the master realm, while regular services can be registered with a realm-specific Service User. For more information on Service Users, see [Realm Users and Roles](../user-guide/identity-and-security/realms-users-and-roles.md) and [Security](../architecture/security.md).
+Both global and regular services must be registered by **Service Users**. Global services specifically require a Super User account in the master realm, while regular services can be registered with a realm-specific Service User. For more information on Service Users, see [Realm Users and Roles](../user-guide/070-identity-and-security/10-realms-users-and-roles.md) and [Security](../architecture/30-security.md).
 
 ---
 

docs/developer-guide/system-administration.md → docs/developer-guide/100-system-administration.md

@@ -1,13 +1,9 @@
----
-sidebar_position: 20
----
-
 # System Administration
 
 ## Monitoring
 
 Use `docker stats` to show CPU, memory, network read/writes, and total disk read/writes for running containers.
-Also use prometheus metrics to monitor individual container health (see: [Metrics](../user-guide/metrics.md)).
+Also use prometheus metrics to monitor individual container health (see: [Metrics](../user-guide/120-metrics.md)).
 
 ## JVM