images

Dipal/Backend/Fox/README.md

@@ -2,6 +2,6 @@
 
 _**Fox**_ is a local server located inside the building that is responsible for device management, meter reading, and building data storage. In one section there is one fox. The operator is responsible for this fox, he has access to control devices (such as utilities, cameras and intercoms). Technically, fox is a server with Linux and our Fox application.
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/48/content">
+<img class="op-uc-image op-uc-image_inline" src="fox.png">
 
 Fox connects Kaiser and frontend applications to devices. _**Intercom**_ is connected with both HTTP and Asterisk. _**Cameras**_ are connected using the Owl service, which converts the RTSP stream from cameras into the WebRTC format that smartphones understand. Fox also has its own _**database**_ that stores information about the devices.

Dipal/Backend/Kaiser/Database explanation.md

@@ -1,7 +1,7 @@
 # Database explanation
 You can see the full database diagram [here](https://app.diagrams.net/#G1HSoNpmIZhO9FB5pVuVnkpj8IlVA4h3VU).
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/43/content">
+<img class="op-uc-image op-uc-image_inline" src="database.png">
 
 ### Profiles
 
@@ -19,7 +19,7 @@ Every profile has their own contacts (phone number or email). We store in the da
 
 The _**place**_ collection stores all places available in our system. The place storage is represented as a tree: all places, except the root one, have a parent. For example, `root` has a parent `apartment`, which in turn has a parent `bulding`.
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/44/content">
+<img class="op-uc-image op-uc-image_inline" src="place.png">
 
 ### User place
 
@@ -33,7 +33,7 @@ A _**user place**_ is represented as a separate collection. One user can be in m
 
 There is only one user place owner. He can send a QR code or an invitation by phone number to the user he wants to add to his place. When the user scans the QR code or accepts the invitation, the owner can select the privileges and services he wants to share.
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/47/content">
+<img class="op-uc-image op-uc-image_inline" src="user place.png">
 
 ### Service
 

Dipal/Backend/Kaiser/README.md

@@ -2,7 +2,7 @@
 
 Kaiser is a cloud-based system responsible for managing accounts, payment transactions, location information, etc. It is a core part of the Dipal project and provides an interface for both the frontend application and the admin panel. It is divided into microservices, which are connected between each other using Kafka message broker.
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/42/content">
+<img class="op-uc-image op-uc-image_inline" src="kaiser.png">
 
 The system diagram is divided into 4 layers:
 

Dipal/Backend/Kaiser/Third-party services.md

@@ -37,7 +37,7 @@ Without all this data, a hacker will not be able to gain access to someone else&
 
 We store information about roles (superadmin, admin, user) inside Keycloak. _**Superadmin**_ has full control over the system. _**Admin**_ can handle only those objects he is responsible for. There are different privileges for administrators and users. _**User**_ is just a user of the Dipal app. Only superadmin and admins have access to the admin panel (Zoo).
 
-<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/46/content">
+<img class="op-uc-image op-uc-image_inline" src="roles.png">
 
 #### HTTPS required
 
@@ -106,8 +106,6 @@ Notification example:
 
 Apache Kafka guarantees message delivery and is adapted to microservice architecture.
 
-<img class="op-uc-image op-uc-image_inline" src="https://www.qlik.com/us/-/media/images/global-us/site-content/data-streaming/apache-kafka/01-kafka-cluster-hero.png?rev=a390721debb24a3f80e978e1f6b2a61d&amp;h=560&amp;w=688&amp;hash=A8D3653BF9343AFF36DFBF341C13FE13" alt="Kafka">
-
 #### Rules for sending messages
 
 Early we used the following format for Kakfa topics: `from_<microservice>_to_<miscoservice>_to_<action>_v1_0_0`, e.g `from_zoo_to_crow_to_delete_settings_v1_0_0`. As you can see, source and destination services are defined statically.