GETTING STARTED

Usages

Fundamentally, when starting a development of almost whatever app — you'll need a database and an admin panel, and those combined are the huge slice of the overall time, costs and efforts — often many tens of percents, so here is where Indi Engine AI kicks in to be used for:

• Instant prototyping of apps — based on your natural language prompt and with ingestion of any attached PDF files, Google Docs, Notion documents (planned), GitHub contents (planned) or Figma designs (planned), so that AI model will generate all the relevant entities, fields, data-views, role, permissions, and fill all this with the sample data, so that it will be possible to explore the working app immediately, i.e. in the matter of minutes.

• Specialized domain software — specialized industries often need tools that can't be served by generic SaaS. Indi Engine AI lets you design database apps for niche workflows — whether for voice ads recording, DNA / heredity lab tests or superhero birthday events for children — by ability to tailor data models and UIs.

• Data-scraping and storage apps — you can configure an Indi Engine app to be a storage for your parsed data to make it previewable / filterable / navigable / versionable / exportable for yourself and also generally better deliverable for your end clients, so they can evaluate the job you've done.

• BIM and engineering data systems — those kinds of projects produce complex, multi-layered data that traditional tools struggle to present. With Indi Engine AI, you can configure realtime interfaces for complex, structured, multi-dimensional datasets with simplified navigation, enabling users to browse, filter, and collaborate.

Any Indi Engine AI app is built on a standard MySQL database that you fully own and control, and you can enable external access from any 3rd party tool, framework, or front-end using regular MySQL credentials — whether that’s a public web application, a mobile client, a REST API service, or anything else. Also, you can extend container setup by integrating the needed services directly into the Indi Engine’s Docker Compose setup. Anyway, you get a ready-to-use database and admin panel that are the backbone for any system or interface you need.

Installation

Technically, Indi Engine is designed to run as a Git-based Docker Compose project, and it's recommended to have at least 1x3 GHz CPU, 3GB RAM and 10GB disk space, so once you have that with Git and Docker installed — execute the following 3 commands:

git clone https://github.com/indi-engine/newapp myapp

cd myapp

source start

3rd command will ask you to define at least 4 configuration variables (further saved to .env file) before starting getting your Indi Engine instance up and running, and typically it takes around 5 minutes to reach the point where the instance is ready - this will be indicated by one of the following messages depending on values you've defined for APP_ENV and LETS_ENCRYPT_DOMAIN variables:

---

▶05:03

On the screencaptures above it is demonstrated how the installation process looks like for a staging deployment on a VPS server at whatever cloud, with an SSL certificate for your arbitrary subdomain, which assumes you’ll have to create a special DNS record in your domain name management service like GoDaddy or other. Anyway, once installation is done, you should open the URL printed by installation script and then you'll see the Indi Engine login screen where you should use dev both as username and password, and press or click Enter.

FLAGSHIP FEATURES

AI prompt-to-app. With sample data.

Building new apps from scratch

Indi Engine's AI prompt-to-app feature allows you to build an entire database app from just a few plain text sentences and attached files (optionally), so the system generates a database schema relevant for your prompt along with the realtime data-views on top, organized into a foreign-key based hierarchies preloaded with sample data to showcase the resulting app in a natural way — all in minutes.

To do that, you should do the following steps:

1. Navigate to Entities-section,
2. Open the Build with AI-dialog by clicking on the corresponding button
3. Optionally attach some files from your device or Google Drive
4. Describe the app you need in a textarea field, e.g. "I need a zoo management app" or "I need a zoo management app based on attached docs"
5. Select some model in the AI model-dropdown (optional, keep as it is to use the default model)
6. Press OK-button

Once OK-button pressed, Indi Engine will do the remaining steps:

1. Preparing background process
2. Getting app design from AI model - mm:ss
3. Importing app design: 100%
4. Getting sample data from AI model - mm:ss
5. Importing sample data: 100%

Those steps are indicated as bottom-left messages, with AI request duration timers and importing progress percentages.

Once those steps are completed, you can explore the resulting app, as well as refine and extend it because it remains fully editable using a wide range of other Indi Engine's zero-code capabilities, specifically designed to handle high on-screen data-density, along with a flexible access system.

Example 1: Zoo management app

• Prompt: “i need a zoo management app based on attached docs”
• Attached docs:

• Functional specification.docx
• Staff & ticketing reports.xlsx
• Food supplier invoice.pdf

When you use an AI model of a certain vendor for the very first time, Indi Engine will ask you to provide the corresponding API key either when you submit the prompt or when you attach the file(s) - whatever happens first. In the latter case the API key is prompted at the point when the first file is already uploaded into your Indi Engine app filesystem, but is not yet uploaded to the AI model.

▶04:37

BTW, at the timecode 03:39 within the first screencapture above, you may notice some data-changes happened, e.g. the animal name for one of two Comodo Dragons changed from “Raja” to “Big Raja”, and this was done to demonstrate a different flagship feature than the current one, and that is why the corresponding chunk was cut out of the above video - to be further shown in the different paragraph.

Example 2: Real estate company app

• Prompt: “i need an app for a real estate company”
• Attached docs:

• Functional specification.docx
• Property inspection checklist.pdf
• Agents payouts.xlsx

▶04:29

Also, you can try to submit the same prompt again (or another prompt) and then decide which attempt's resulting app is better for your needs, read Restoring apps from AI response history paragraph for more details.

Context ingestion / attachments

When prompting the AI model, you can also attach context such as PDF documents, Google Docs or Figma designs (planned), allowing the AI to make the resulting app design to be much more accurate and relevant to your requirements. This approach turns weeks of early-stage work into minutes, giving the individuals and teams a fast track to usable prototypes.

This allows you to feed the AI model with functional specifications, UI mockups or other docs you have prepared by yourself and / or received from your client, and this dramatically reduces the gap between business requirements and working software, enabling faster prototyping, client demonstrations, and iteration with reduced traditional development cycles.

PDF files

This is the primary format currently supported for being fed to the AI model, and it's possible to attach multiple PDF documents to an individual prompt. This goes beyond simple text extraction due to using native vision to understand entire document contexts, so it allows to analyze and interpret content including text, images, diagrams, charts, and tables, even in long documents up to 1000 pages.

Technically, you can attach files of other types to be ingested, like TXT, Markdown, HTML, XML, etc. However, document vision only meaningfully understands PDFs. Other types will be extracted as pure text, and the model won't be able to interpret what we see in the rendering of those files, so any file-type specifics like charts, diagrams, HTML tags, Markdown formatting, etc., will be lost.

Also, keep in mind that the combined size of the attached documents plus the text prompt itself must stay within the selected model's context window limitations, which is different for different models.

Google Drive files

Indi Engine AI has an integration with Google Drive and this allows users to attach their existing documents there - to the AI prompt when generating apps. Whether it’s a functional specifications and requirements document, an operational or financial reports, or a planning file, Drive attachments will guide the Indi Engine AI to create more accurate entities, forms, relationships and data-views on top.

This reduces friction: instead of exporting or reformatting data, users can attach familiar files to their prompts, letting the AI align the generated app with real business documentation. The feature ensures a smoother path from planning documents to working software, accelerating adoption across teams, as the existing knowledge sources will directly drive the development of usable applications.

Notion documents

Planned Notion integration will let Indi Engine AI interpret workspace content as structured context for backend generation. Many teams already use Notion to organize specifications, feature outlines, and data models — and this integration will turn that planning material into a practical input source for building apps.

By analyzing attached Notion pages or databases, Indi Engine AI will be able to recognize entities, relationships, and field structures directly from written documentation or table layouts. Instead of starting from a blank prompt, users will leverage the work they have already captured in Notion to accelerate the creation of database schemas and admin panels.

GitHub contents

Planned GitHub integration will allow Indi Engine AI to attach repositories or selected source files as contextual input for backend generation, so users will be able to connect existing projects and let the AI interpret their structure to propose database schemas and admin panels that match the project’s logic.

The AI model will scan the code for recognizable data structures — such as entity definitions, ORM models, SQL schemas, or migration scripts — and infer how those structures can be represented within a database. By understanding models, migrations, or other files within a repository, Indi Engine AI will be able to produce a compatible backend foundation with minimal manual setup.

Figma designs

Planned support for Figma will let Indi Engine AI use design prototypes as intelligent context for backend generation. Instead of producing pixel-perfect front-end code (which other tools already handle well), Indi Engine will interpret Figma layouts to auto-generate a matching database schema and admin panel.

The result will be a backend that is immediately usable and closely aligned with the design vision. This approach accelerates development by turning early design artifacts into functional data systems. Teams will gain a working backend even before front-end coding begins, while still retaining full freedom to build the client-side experience separately.

Restoring apps from AI response history

As previously mentioned, when you submit a prompt to the AI model via Build with AI-dialog, under the hood Indi Engine makes two requests to the AI model — first for getting app design, and second for getting sample data.

However, it might be the case that the resulting app is not good enough from your perspective, or is, but you still want to do some more experiments (possibly with different prompts and/or attachments) - to take a look at further resulting apps and decide which of them are better than others.

This is why Indi Engine has Configuration » Prompts-section where the history of all your prompts is saved each with a pair of AI responses, so you can select some record there and click on Restore-action to switch to the any app design and sample data you have previously received from the AI model. Also, you can mark certain resulting apps that are better than others by clicking on the color-box in the Result ↴ Candidate to proceed-column.

▶01:40

However, there are two things to keep in mind about the screencaptures above. The first one is that the demonstration above - is starting at the chronological point where we already have two records in the AI response history, and the last one of them (appears at the most-top of the list) is the one that is currently imported into the Indi Engine app instance shown there - it is the real estate company app.

Also, the above demonstration is demonstrating how AI responses received for completely different apps (i.e. prompts) are re-imported to the Indi Engine instance - just for the restore results to be much more visually recognizable here in docs. But, in real life usage, you’ll likely be re-importing AI responses received based on the same or similar AI prompts. This will be that way for the reason, already outlined before: the resulting app might not be good enough from your perspective, or might, but you still want to do some more experiments to take a look at further resulting apps and decide which of them are better than others.

Supported AI models

There are multiple AI models shown in the AI Models-dropdown in the Entities-section's Build with AI-dialog, but right now only Google Gemini ones are supported, and this means that everything written above about using PDF files as context attachments — is relevant only for Gemini AI models, and is sourced from Document understanding page in their docs.

The awesome things about Google Gemini AI are:

1. Native vision for PDF attachments up to 1000 pages of a combined size (already mentioned before)
2. Free tier is sufficient for usage with Indi Engine AI — both for their 2.5 and 2.0 models
3. Huge limit of 1,048,576 input tokens — both for their 2.5 and 2.0 models

However, here are some things to keep in mind:

1. Gemini 2.5 Pro has a big limit of 65,536 output tokens, but takes 3-5 minutes to respond
2. Gemini 2.0 Flash-Lite takes just 30-50 seconds to respond, but has a small limit of 8,192 output tokens

Some time ago, Gemini 2.5 Flash-Lite model became available, and it has the best of both - same output tokens limit as for 2.5 Pro and similar response time as 2.0 (around 40-80 seconds), and that is why it is now a recommended and therefore a default AI model for Indi Engine.

Also, there might be various restrictions and limits applied for usage of AI models under the free tier, but the only one that has ever popped up so far on local development Indi Engine app instance - was the Requests per day limit, which might be different for different models, but was solvable with using VPN connection from another country (i.e. different IP-address) back then, though.

Hallucinations handling

Hallucinations are the major problem popping when dealing with AI responses, and they were really underestimated at the early versions of how the interaction between Indi Engine and AI models was implemented. Back then, there was a hope that this would be solvable just by improving the AI prompt with something like:

1. "Please define entities before they're used in foreign keys"
2. "Please use camelCase instead of snake_case for background names"
3. "For multi-word foreground names of entities, fields, etc - please capitalize only the first word."
4. "For elementId use 'calendar' instead of 'date'"
5. "Please do NOT use the following db table names for entities, because they are already in use by Indi Engine internally: ..."
6. "If section have a foreground name ending with 'types' or 'categories' - then it must be added under 'Dictionaries' menu"
7. "Always create filters for all foreign-key fields that exist in data-source entities used by top-level sections (i.e. left menu ones)"
8. "Please make sure the PHP code syntax is valid in your response"
9. etc

But it turned out that relying on "don't do that", "do this that way', "do first this and then that" — just does not work, as AI models can follow the X% of instructions on attempt #1 but Y% on attempt #2, with unpredictable intersection between X and Y, no matter how precise and detailed the instructions are.

This means that the only reliable way was to:

1. Parse the raw AI response using regular expressions to prepare a draft of an initial database schema (or sample data),
2. Validate it for logical inconsistencies and other hallucinations
3. Fix hallucinations, fill the gaps and enrich with some useful defaults where possible
4. And only then — import to Indi Engine.

In addition, when working with models having low output tokens limit, the responses can be just interrupted when limit reached, so you get an incomplete response with syntax error just because it was cut somewhere in the middle. For sure, this could be solved by auto-prompting the AI model again with original prompt plus original response and an appeal to continue from where we’ve interrupted, but this is not implemented so far.

Basically, the resulting app for an individual AI prompt is consisting of the following 3 parts, so the following AI requests in the earlier versions of Indi Engine AI were made:

1. Request 1:

1. Data-structures (entities with fields, foreign keys, etc)
2. Data-views hierarchy (sections with grid columns, filters, access, etc)

2. Request 2:

1. Sample data

However, hallucinations, output token limit and the response time — were the main reasons of why the implementation was later changed in a way that the only responsibilities of the AI model — became to suggest the database schema relevant for user prompt, and to suggest sample data relevant for the pre-sanitized schema.

This means that Indi Engine AI still relies on the general idea of how the database schema should look like (i.e relevant for the user prompt) from the AI model perspective, and still relies on the suggested sample data, but does NOT rely anymore on the actual PHP/SQL code that the AI model responded with, on either request.

Also, the part 1.b (Data-views hierarchy)  — is now completely moved out of the AI model's responsibility, so all the sections, grid columns, filters and user roles and permissions — are generated by Indi Engine itself according to a fixed algorithm.

AI-assisted evolution for existing apps

Today, Indi Engine apps can already be evolved manually through its zero-code UI: developers can add fields, adjust forms, or restructure hierarchies at any time. Planned support for AI-driven evolution will take this further by allowing users to refine an existing app with follow-up prompts.

This means you'll be able to ask AI model to "add a payments section" or "extend the customer entity with contact history," and Indi Engine will update the existing app accordingly, allowing to leverage the AI for iterative database app development, so apps can grow alongside the business while keeping data intact, turning such a development into a natural, low-effort process.

Realtime desktop-style multi-window UI

Indi Engine uses MySQL binary log, RabbitMQ and WebSocket for realtime data updates across multi-window UI that feels like a native desktop application, so data changes made by any user, script or pure SQL query are immediately reflected in all relevant grids and forms for all users in all currently opened browser tabs — enhancing collaboration and efficiency.

So, unlike traditional single-page web apps, Indi Engine's multi-window interface brings the power of desktop software into a modern web app. Users can open and arrange multiple floating (or maximized) windows at once, each neatly auto-sized and connected to live data that updates in realtime. This means no more losing focus, navigating back and forth or reloading pages when switching between todos.

Desktop-style: windows and taskbar

Just like in any modern desktop environment, Indi Engine has a taskbar — at the very top of the UI, so that each floating, maximized or minimized window currently opened in the Indi Engine has the corresponding button in this taskbar. It provides a quick overview of all currently opened windows, allowing users to easily switch between them or close unnecessary ones with a single click.

For the taskbar and each UI window to behave much like a window in a desktop environment —  the natural focus and layering needs to be maintained, and that is why Indi Engine automatically manages the z-index (stacking order) of all open windows. Whenever a user clicks or interacts with a specific window, that window is brought to the front while preserving the relative order of all others. See that in the screencaptures below, as that is where the above screencapture was cropped from.

▶00:32

This ensures a predictable, intuitive experience — the active window is always visually prioritized, yet previously opened windows remain accessible in the background. The z-index system also works seamlessly with batch window opening, so when several Details-windows are opened in a cascade, their z-index values are assigned in sequence so each next window mostly overlaps the previous one, preserving both visual depth and usability. See below.

Batch opening / cascading windows

Just like on a real desktop, Indi Engine allows you to open multiple windows at once. For example, when several records are selected and the Details-action is triggered, each record opens in its own floating window (or maximized one if its contents takes too much space). The floating ones appear with a slight offset on the X and Y axes, forming a cascading layout.

As you can see above, batch opening assumes more than one record needs to be selected. Also, apart from the support for Details-action, it is also supported for Index-action — in cases when you are opening some child section for multiple selected records in parent section - you can see that on the screencaptures below.

▶00:27

This behavior not only feels natural for multitasking but also helps you visually distinguish between multiple opened entities without losing context.

However, keep in mind that you can’t open more than 15 windows in total, but you can change that limit via Maximum number of windows-field for any needed Role.

Auto-sizing based on content

Indi Engine automatically adjusts each floating window to fit its content precisely. The system measures the actual vertical and horizontal space usage by every UI element — including grid multi-level column headings and cell values, form field labels and inputs, toolbars and their items, and even nested child tabs, e.g. Viewings, Offers, etc tabs inside a Property-record Details-window in real estate company app (see at the screencapture #4 above).

This dynamic sizing ensures that windows always appear neatly proportioned, without unnecessary empty space or scrollbars. The result is a clean, well-balanced interface that feels as if every window was manually arranged by a designer — but it all happens automatically, and you’ve highly likely noticed that already in the tens of the screencaptures above.

Also, whenever records are changed, added or removed from a grid, Indi Engine recalculates the inner layout and updates the window height and width accordingly. The adjustment happens smoothly and in real time, preserving the visual balance of the entire workspace. To see how it works, take a look at Example 2 in the next paragraph.

However, for those changes to be reflected for the Indi Engine users in their browser tabs opened - some preliminary things are set up by Indi Engine, see below.

Change data capture / CDC

Change Data Capture (CDC) is a mechanism that continuously monitors the database for insert, update, and delete operations and streams those changes to the desired or intermediate destinations. In Indi Engine, this job is done by Zendesk’s Maxwell Daemon which is a Java process that connects to MySQL as a Replication client and streams any data-changes written to the database - into the RabbitMQ exchange for further transformation and delivery to the end users’ UI.

To be able to deliver changes only to the relevant data-views, Indi Engine keeps track on everything involved — starting from how many sessions using which languages each user has, and ending with what filtering, sorting and paging is currently applied for each data-view along with which records and their data-fields are currently shown there.

With that in mind, Indi Engine consumes the data-changes stream from RabbitMQ, transforms that stream into a format compatible with Indi Engine interface components and delivers the transformed data into the relevant browser tabs opened by the users — via WebSocket connections.

For both of the below examples, you might notice that the changes on the screencaptures are made via pure SQL queries rather than via interaction with Indi Engine interface, and this is done that way to emphasize that any data-changes made to the database - are all pure SQL queries in the end, no matter whether those changes are made by users via interface or any scripts.

Example 1: reflecting data-changes for records affected by a sequence of pure SQL UPDATE queries (zoo management app)

▶01:55

In the above screencaptures its shown how the SQL UPDATE queries were used to modify the data within our first example app (i.e. zoo management app): to multiply the values of Capacity-field by 2 for all Enclosure-records, to change the type of a certain enclosure from “Terrarium” to “Cage” and to rename the certain animal from “Raja” to “Big Raja”.

Example 2: auto-sizing of a floating window based on records creation and deletion via pure SQL INSERT and DELETE queries (real estate company app)

▶00:48

In the above screencaptures it is shown how in our second example app (i.e. a real estate company app) the Viewings-section’s Index-window (opened for a certain Property-record) adjusted its size to fit the new Viewing-records that were created via pure SQL query for that Property-record. Also, when those records were deleted - the viewings window reduced its size again to stay fit.

WebSocket connections

From a user perspective, 'realtime' means that any data changes made by no matter who and for whatever reason - are immediately reflected in the UI. So, as long as the UI is shown within the browser tab — the changes must be somehow delivered to each browser tab opened by each user, and in Indi Engine this job is done by RabbitMQ Web STOMP plugin, which allows to deliver realtime updates directly to users’ browser tabs over standard WebSocket connections.

STOMP (Simple Text Oriented Messaging Protocol) is a lightweight, text-based protocol that allows clients (i.e. browser tabs) to subscribe to message queues and receive updates in a standardized way. When the Web STOMP plugin is enabled, RabbitMQ acts as a WebSocket server, translating between WebSocket frames and STOMP messages, so to make any message to be delivered to a browser tab — Indi Engine has just to push that message to a certain queue.

In Indi Engine’s architecture, this plugin forms the final bridge between backend change events and the frontend interface. After Indi Engine prepares and publishes user-specific JSON updates into the relevant per-tab RabbitMQ queues, the Web STOMP plugin ensures that each connected browser tab receives those updates in real time — without requiring any polling or page reloads. This makes the communication channel persistent, allowing the UI to stay continuously synchronized with the backend as soon as data changes occur.

You can read more technical details here, including how Indi Engine decides which data-changes should be delivered to which users.

Free GitHub backups, up to 1.9TB each

Indi Engine backup/restore system rely on GitHub, which means you'll have to create your own repo there and create a fine-grained personal access token granted with read-write access to that repo, so Indi Engine will ask you to specify those on attempt to make the very first backup, no matter if your attempt will be made via CLI (i.e. source backup command) or via UI (i.e. Backup-action in Entities-section).

Example 1: very first backup - with preliminary setup of GitHub repo and access token. In this example it’s the backup for the zoo management app.

▶02:07

Example 2: second (or any further) backup. In this example it’s the backup for the real estate company app.

▶00:44

Rotation

By default, any Indi Engine app instance uploads and keeps 0 'hourly', 7 'daily', 5 'weekly', 12 'monthly', 5 'custom' and 5 'before' backups on GitHub, but for sure you can amend those numbers by editing BACKUPS variable in .env file.

As you can notice, the last two kinds of rotated backups - are not periodical ones (unlike the first four):

1. Custom - those are the backups that you create by yourself - either via CLI (i.e. source backup command) or via UI (i.e. Backup-action in Entities-section)

2. Before - those are backups created by Indi Engine each time you commit a restore, to make it possible to get back to 'before restore' version, You can read more here about how restore works.

Environment isolation

Any Indi Engine app instance can be one of 3 environment types (production, staging or development) and it is mandatory to choose the environment during initial setup, so your choice is then written to APP_ENV variable in .env file

So, as outlined in the comment for the APP_ENV variable above, backups environment isolation is implemented to prevent collisions between the backups uploaded on GitHub by different instances of your Indi Engine app.

This is useful in cases when you have a production instance of your app which is up and running somewhere, and you want to work on some improvements on your local development instance, but you want to get the most recent production app state locally before you start your work, and for sure you don't want backups uploaded by your local development instance to conflict with the production ones.

Limits and chunking

Each backup created by Indi Engine is then uploaded on GitHub as a release, and there is no limit for how many releases can be created for a repository. However, there are some limits applied by GitHub to assets (i.e. non-source-code files) of a release, and those are:

1. Maximum 1000 assets per release
2. Maximum 2GB per asset

However, the real maximum size per asset is 2000mb rather than 2GB (=2048mb), because GitHub fails with HTTP Code 500 on attempt to upload a 2048mb asset, and this is why GH_ASSET_MAX_SIZE variable is set to 2000mb in .env file

So, the real size limit for an individual backup is 1.9TB, and this is the combined limit for database dump and uploaded files.

Chunking

When you create a backup in Indi Engine, this actually means that minimum two files are created locally and then uploaded on GitHub:

1. data/dump.sql.gz - the gzipped sql dump created by mysqldump and gzip CLI tools
2. data/uploads.zip - the zipped (but not compressed) contents of custom/data/upload directory

However, if any of those are getting bigger than GH_ASSET_MAX_SIZE during creation - then they are chunked into pieces to comply with GitHub requirements, and yeah — chunking is done during creation rather than after creation, so there is no double disk space usage needed.

1. If your database gzipped dump is, for example, 3GB, then the chunks are:

1. data/dump.sql.gz01 - 1.95GB
2. data/dump.sql.gz02 - 1.05GB

2. If the size of your custom/data/upload directory is, for example 5GB, then the chunks are:

1. data/uploads.z01 - 1.95GB
2. data/uploads.z02 - 1.95GB
3. data/uploads.zip - 1.1GB

Timing and progress tracking

How fast are backups and restores? That mostly depends on your local (or VPS) host disk I/O and internet connection bandwidth.

For example, let's take a look at the numbers in the table below that are from the VPS host having:

1. 1x3 GHz CPU Core
2. 6 GB RAM
3. 60 GB disk space
4. 250Mbps bandwidth

As mentioned above, a 21GB database having ~13 mln records can be exported to a 428MB gzipped sql dump in ~7 minutes and the rest is up to your internet connection bandwidth. But at the same time, the re-importing of such a gzipped sql dump takes 20 minutes, which is almost 3 times slower than exporting time.

However, in most cases the size of your uploads directory - is really the main aspect that relies on bandwidth from the timing perspective: for 250Mbps bandwidth it usually takes around 22 mins to upload and 8 minutes to download chunked 11GB backup into/from GitHub.

Progress tracking

For every time-consuming operation such as exporting (with gzipping) / uploading / downloading / importing for database dump, as well as zipping / uploading / downloading / unzipping for file uploads - the progress bars are shown, so you can track what's going on and where you are at the moment. For the full backups - you might already have seen that on the screencaptures above, and for the other two backup scenarios along with restore ones - you can see that below.

Backup scenarios

Indi Engine supports 3 backup scenarios, which are shown when Backup-action is clicked in Entities-section:

1. Create a new custom backup (includes source code, database and uploads)
2. Patch the most recent backup with the current database state
3. Patch the most recent backup with current uploads

So, as you can see, apart from the full backup which is itself pretty clear (and has been already demonstrated by the screencaptures at the very beginning of the current chapter), it's also possible to patch some already existing backup with database dump or uploads from your current Indi Engine app instance.

PATCH THE MOST RECENT BACKUP WITH THE CURRENT DATABASE STATE

This is useful in cases when you want to apply some fix or improvement for a database dump within a backup already existing on GitHub, but you don't want to create a new backup due to, for example, you don't want to wait for zipping and uploading on GitHub a big-sized contents of your local custom/data/upload directory which will be exactly the same as you already have there.

PATCH THE MOST RECENT BACKUP WITH CURRENT UPLOADS

This is useful in cases when you want to apply some fix or improvement for the zipped uploads within a backup already existing on GitHub, but you don't want to create a new backup due to, for example, you don't want to wait for exporting and gzipping of an SQL dump for a big database which will be exactly the same as you already have there.

However, when triggering either of these patch-scenarios via UI, for security reasons it's only possible to patch the most recent backup created by your current instance, so backups created by other instances, if any - won't be affected, except if those instances have the same APP_ENV as your current one. If there are no patchable backups yet - a very first full backup from your current instance will be created instead.

Also, you can do a patch via CLI by executing source backup dump or source backup uploads commands, and in that case Indi Engine will ask you to choose the backup to be patched.

Restore scenarios

Similar to backups, Indi Engine supports 3 restore scenarios, which are shown when Restore-action is clicked in Entities-section, so you can trigger a needed scenario for any backup already existing on GitHub:

1. Full restore (source code, database and uploads)
2. Restore only database state
3. Restore only file uploads

FULL RESTORE

This restore scenario assumes that not only database and uploads, but also the source code will be restored at the version you choose. However, the DevOps-files will still be at the latest version, ensuring you have the freshest Docker Compose setup and Bash scripts, so that only the contents of custom/ directory (where your app-specific source code resides) will be really restored at the version you select.

Example 1: full restore from the state representing one app (real estate company app) to the state representing another app (zoo management app).

▶01:32

In the screencaptures above it’s shown how the Indi Engine instance is restored from its whatever current state (in this example it is an app for a real estate company) to some version representing another state for which you have a backup on GitHub (in this example it is a zoo management app).

Example 2: full restore from the app state with Chinese UI translations to the app state without these translations.

▶01:28

In the screencaptures above you may notice the Languages grid indicating that Chinese translations are enabled for app’s custom UI before the full restore, and are not yet enabled after the restore is done, because when we do a restore it means we switch the app to some preliminary backed-up state, so some changes (e.g. translations) might not yet happened compared to the point from where the restore was triggered. Also, keep in mind that the process of UI translation to Chinese is not itself demonstrated in the above screencaptures, because that’s the different topic, and that is why you can see that in the Localization chapter rather than here.

When you do a full restore, your Indi Engine app instance will enter into an 'uncommitted restore' state, so you can look around and decide whether the version you've just restored - is REALLY the right one for keeping your instance at and for auto-restoring (not yet implemented) other instances to, if any, once any updated. If so - you can commit the current restore, else you can either restore (i.e. switch to) another version, or cancel the restore to get back to the original version that Indi Engine saved locally before restore.

However, keep in mind that creation of ANY new backups for your instance - will be prevented until you commit or cancel your current restore.

Example 1: Cancel the full restore.

In this specific example, the full restore from the above Example 1 - is used for cancellation demonstration. The cancellation itself is switching the Indi Engine instance back to the ‘before restore’ state, which was backed up locally within the Indi Engine instance’s filesystem, as otherwise the restore cancellation wouldn’t be possible.

▶01:10

Example 2: Commit the full restore.

In this specific example, the full restore from the above Example 2 - is used for demonstration of full restore commit, so the restore to the app state where no Chinese translations are there yet - will be committed. At the same time, the locally created ‘before restore’ version with Chinese translations - will now be backed up on GitHub for being also restorable, if needed further.

▶01:29

As you can see, once you commit your restore, two things will happen:

1. The local 'before restore' version - will be uploaded on GitHub, to make it to be also restorable

2. An empty new commit will be added to your app's GitHub repository with the message like this:

RESTORE COMMITTED: Staging · C0 · 19 Oct 25, 15:36 · d61ade1

to make it traceable which versions created when have been restored when.

Restore only database state or uploads

RESTORE ONLY DATABASE STATE

This restore scenario allows you to patch your Indi Engine app instance with the database state from a backup you choose among the ones already existing on GitHub. This can be useful in cases when there are no differences in source code and/or uploads between your current instance and the version from which you want to restore, or there are differences but they're not meaningful for you right now.

For example, this can be the case when you have a production instance of your app which is up and running somewhere, and you want to work on some improvements on your local development instance, but you want to get the most recent production database state locally before you start your work, and you don't want to do a full restore from the latest production backup as there is no need neither for an 'uncommitted restore' state for your local instance nor need for wasting time on downloading production instance's uploads from GitHub.

RESTORE ONLY FILE UPLOADS

This restore scenario allows you to patch your Indi Engine app instance with the file uploads from a backup you choose among the ones already existing on GitHub. This can be useful in cases when there are no differences in source code and/or database state between your current instance and the version from which you want to restore, but your instance's file uploads are outdated and you want to sync them to make them to be matching the production database state.

For example, in the further explained sample app, this can be the case when you have production instance up and running, and you do some ongoing development on your local instance, but in the meantime some new Teacher-records were added each with a photo, and you want to have those photos on your local instance in addition to those new Teacher-records.

Percona XtraBackup

Indi Engine also plans to integrate with Percona XtraBackup, a high-performance hot backup tool for MySQL that enables full and incremental backups without slowing down the database or interrupting normal operations.

Unlike mysqldump, XtraBackup works directly at the physical file level, making backup and restore operations significantly faster, more efficient, and far more suitable for production environments.

This will be especially valuable for large installations, reducing downtime while minimizing the impact on running applications, as this approach will improve the backup / restore timing drastically, but may increase upload / download durations, since physical backups are generally less compressible compared to logical ones.

Encryption

Indi Engine also plans to secure backups using a hybrid encryption model. Each backup will be encrypted with a randomly generated AES key for speed and efficiency, and that AES key, in its turn, will be then encrypted with the user's public key, and the encrypted key will be then stored alongside the backup.

On restore, the matching private key will be required to unlock the AES key, which in turn decrypts the backup data. This design will allow backups to be created safely in any environment with only the public key, while keeping restores strictly limited to private key holders. For key storage, it's planned to support local files, interactive prompts, and enterprise systems such as HashiCorp Vault.

This feature will add another layer of security to Indi Engine's GitHub-based backup system, so backups will be piped via an encryption algorithm when exporting to data/dump.sql.gz and data/uploads.zip — i.e. even prior written to disk. This ensures sensitive information remains protected even if backup files are copied directly from the data/ directory or if GitHub release assets are exposed.

This will help businesses strengthen data protection and compliance, meeting requirements such as GDPR or HIPAA by guaranteeing that sensitive information remains unreadable outside authorized systems. Once implemented, it will complement Indi Engine's existing backup mechanism, reinforcing trust for storing sensitive or mission-critical data.

Sharding with Vitess

The next major step in Indi Engine's evolution is the integration of Vitess — the cloud-native horizontal scaling engine originally built by YouTube to manage MySQL at massive scale. Vitess orchestrates tens of thousands of MySQL nodes today and is trusted by GitHub, Slack, Shopify, and other global platforms.

This means apps built on Indi Engine will be able to scale seamlessly from millions to tens of billions of records without hitting single-database limits. Developers will also be able to configure sharding strategies directly inside Indi Engine, unlocking enterprise-grade scalability with zero-code simplicity.

With Vitess, Indi Engine will inherit proven resilience features such as automatic failover, traffic routing, and online schema management, ensuring high availability even under heavy load. By embedding Vitess into the platform, Indi Engine will offer not just a zero-code experience but also the same backend scalability techniques trusted in the cloud-native ecosystem.

Modern UI for legacy databases

Many businesses still rely on legacy databases that may have obsolete look and feel but are expensive to replace or upgrade, and here is where Indi Engine will be able to help — scan the legacy database and generate a bright modern multi-window UI on top.

So, instead of being locked into outdated admin tools or planning risky migrations, organizations will be able to get a clean, intuitive UI automatically generated from their schema. Developers can refine data-view hierarchies and layouts, if needed, but the heavy lifting will be done by Indi Engine's zero-code system.

THINGS TO KNOW

.env variables

Any Indi Engine installation comes with a .env.dist file, which is copied line-by-line to .env file when running source start command for the very first time, and there are more than 10 variables. However, values for not every variable are asked from the user during setup, and values for some of those are asked only in specific circumstances.

This is done that way to simplify the initial setup, so that the variables not needed for the initial setup - are not asked:

1. Always asked on initial setup:

• GH_TOKEN_SYSTEM_RO

needed for Composer ability to install private indi-engine/* packages

• APP_ENV

needed to decide whether LETS_ENCRYPT_DOMAIN and EMAIL_SENDER_DOMAIN should be asked as well, which is the case when APP_ENV is 'production' or 'staging'

• MYSQL_EXPOSE_PORT

needed to define whether external connections should be allowed, and if yes - you must specify port number, e.g. 3306, 13306, or other

• MYSQL_ROOT_PASSWORD

needed to setup MySQL-level privileges and pre-restore graceful shutdown, but can be left empty if you want to have it randomly generated

2. Asked on initial setup, but only in specific circumstances:

• GH_TOKEN_CUSTOM_RW

needed if the repo you've cloned — is a private one (i.e. it's not the indi-engine/newapp repo, and is not a public repo), so this means the access token is needed to check if there is at least one backup on GitHub to import database dump and uploads from — to get your instance up and running.

• GH_TOKEN_PARENT_RO

needed if the repo you've cloned —  was generated or forked from some private parent repo. The latter case means you are a developer who joined the existing project so you are setting up your own instance but you need to import database dump and uploads from a backup that belongs to the parent repo.

• LETS_ENCRYPT_DOMAIN

asked if APP_ENV is 'production' or 'staging', but can be kept empty

• EMAIL_SENDER_DOMAIN

asked if APP_ENV is 'production' or 'staging', but can be kept empty

3. Not asked on initial setup, but asked by 'source update' and 'source restore commit' commands:

• GIT_COMMIT_NAME
• GIT_COMMIT_EMAIL

4. Not asked at all because of non-empty default values already present

• BACKUPS
• GH_ASSET_MAX_SIZE
• MYSQL_DUMP
• DOC

Basically, the only variable you may want to change — is BACKUPS, to enable hourly backups, for example. In that case you can just do that —  with no need to recreate or restart the containers for a change (for this specific variable) to take effect.

See below the contents of .env.dist file with variables usage explanations:

Enable external access

As already mentioned, any Indi Engine AI app is built on a standard MySQL database that you fully own and control. Therefore, you may choose to make this database accessible from any external tool, framework, or front-end using regular MySQL credentials — whether that’s a public web application, a mobile client, a REST API service, or anything else.

To enable external connections to Indi Engine’s internal MySQL server, you will have to specify a port number in the MYSQL_EXPOSE_PORT variable during installation. By default, these connections require the MySQL server’s root password, so you must either define it explicitly using the MYSQL_ROOT_PASSWORD variable or leave it empty to have a strong password generated automatically. In both cases, the password will be stored in the .env file for further use.

Extend container setup

As an alternative to connecting external frameworks (e.g. Laravel, Django), mobile clients, or REST API services, you can integrate them directly into Indi Engine’s Docker Compose setup by defining additional services in the custom/docker-compose.yml file, which is automatically merged with the default configuration. This approach allows you to extend the default setup with any additional services you need and/or customize existing ones.

Sample app to explain features

To explain and clearly illustrate the hundreds of Indi Engine's features and concepts, it became obvious that some kind of a sample app needs to be introduced, which should be:

• enough simple for everyone to get a clue on what's going on under the hood, but at the same time
• enough complex to contain the relevant use cases for as many features and architecture concepts as possible to be applicable and demonstrable.

For such an app, starting from now, a lightweight version of a language school app will be used, because the subject area involved here is quite clear, as it consists of the things everyone knows: Students, Teachers, Lessons, Courses, Attendance, Payments etc. To install sample app, you can execute the following commands:

git clone https://github.com/indi-engine/sample

cd sample

source start

▶00:37

▶00:56

Users, roles and access

Indi Engine's access system consists of answers on two main questions:

WHO CAN DO WHERE AND WHAT?

This is similar to well-known ACL concept, however it does not follow that precisely, as there are several major differences:

Difference 1: Only one role per one user, so if some user has Admin-role, that user can't have Teacher-role or Student-role

Difference 2: Users having different roles can be stored in different database tables. This is defined by Entity of users-field in the Role-record properties, where you can choose which entity should be used as a storage for the credentials data of users having that role. For example, any teacher's credentials are stored in `email` and `password` columns in `teacher` table, but for each student - in the same-named columns in the `student` table in the database.

who - means a user having certain role, for example any user having Teacher-role

can do what - means certain action, for example Index, Details, Save, Delete

can do where - means the certain section within the data-views hierarchy, for example Teacher-user can do all of the above mentioned actions in Lessons-section, but can only do Index and Details actions in Students sections (i.e can't do Save and Delete there)

If we compare this to the ACL concept, this would mean rights=actions, and resources=sections, so you define a Section, and then you define which Actions would be available there and for which Roles

▶00:39

WHAT ABOUT THE OWNERSHIP?

At first let's clarify what does the ownership mean, and we'll do that - yes, using an example:  we have Teacher, Student and Lesson entities with the following fields in their structures:

1. Teacher (id, title, email, password, toggle, countryId)
2. Student (id, title, email, password, toggle, countryId)
3. Lesson (id, teacherId, studentId, date, time, duration, selfPrice, salePrice, profit)

Ownership means there should be a connection between user and owned record defined as a foreign-key field within the record's data structure, and this means there might be multiple owners for the same record. In this particular case each Lesson-record can have 2 owners: one is the Teacher and another one is the Student.

By default, Indi Engine does not apply any restrictions for non-owners, unless you want to explicitly define the behavior to be applied, and if yes - you may use For owners – only owned records-field which is definable:

On Section level having the following choices:

1. No
2. Yes, for all actions
3. Yes, for certain actions

On Action in the section level having the following choices:

4. No
5. Yes, for all owner roles
6. Yes, for certain owner roles

All of the above means that you can, for example, define the complete inaccessibility of the records in Lessons-section for Student-users who are NOT mentioned in studentId of those lessons i.e. Student-users will see only their own lessons, and at the same time you can define all lessons to be visible for any Teacher-users but writable only for the ones who are owners.

▶00:41

As you can see on the screencaptures above:

• Index and Details actions are accessible

• For Teacher-users - any Lesson-records
• For Student-users - only students’ own Lesson-records, because of:

• For owners - only owners records = Yes, for certain owner roles
• For which certain owner roles = Student

• Save and Delete actions are accessible:

• For Teacher-users - only teachers’ own Lesson-records
• For Student-users - only student’ own Lesson-records
• both because of:

• For owners - only owned record = Yes, for all user roles

It's also possible to define access restrictions for certain roles on certain data-columns. For example, you can configure Self price to be hidden for Student-users, Sale price to be hidden for Teacher-users, Profit to be hidden for both, but all visible for Admin-users. Read Grid columns ↴ Access roles and Adjusted fields ↴ Access roles for more details.

Quick UI editing

Quick UI editing means you can do some things either right where you currently are or via a quick jump straight to the right window where configuring is possible.

If you are not a Developer-user, then the only thing you can do is renaming the titles and tooltips for certain UI elements. For example, you can rename Native speaker-field to Is native speaker-field right there in the Details-window of any certain Teacher-record, or you can rename Teacher-entity to be, let’s say, Tutor-entity. Also, you can rename titles and tooltips for grid columns, titles for filters, and titles for actions having icons

BTW, if you complete your renaming for grid title/tooltip with Shift+Enter (instead of just Enter) - then this new title will be propagated on the field behind that grid column instead of on just that grid column itself - this is helpful when you have that column in more than one section, so you can rename once and all usages will be affected.

▶01:03

But, if you are Developer-user, then in addition to the above you can also do the following:

1. If you are in Details-window (for example with details of certain Teacher-record):

1. Jump to Details-window of the current entity (in our example it's Teacher-entity)
2. Jump to Details-window of an any field (for example Email-field)
3. Reorder fields using drag and drop
4. Jump to the Altered fields for your current section (in our example it's Teachers-section), so you can add some adjustments that will be applied only in the current section and, if needed, only for the roles you choose. For example, you can adjust Mode for Password-field to be Hidden for Student-users in teacher details. See Adjusted fields to see all the possible adjustments

▶00:55

2. If you are in Index-window (i.e. you see the grid of Teacher-records in Teachers-section):

1. Jump to Details-window of the current section (i.e. Teachers-section, so you can amend default sorting, enable records numbering, etc)
2. Jump to Details-window of a selected column (for example Youtube introduction video link-column, so you can amend column header style, navigation, values template, etc)
3. Jump to Index-window having all columns definitions for current section
4. Create new column right after selected column, respecting selected column's parent column and locked-state, if any
5. Delete selected column
6. Lock/unlock selected column (means same as freeze column at the left side in Excel)

▶01:09

In most cases there would be no need to enable UI editing for any roles other than Developer-role, but there might be scenarios when you would need that, for example if you translated UI titles from English to German, but you aren't enough good at German to check those auto-translations made via Google Cloud Translate API, so you asked some German native-speaking person to login as some Teacher-user, take a look and re-phrase some UI titles where needed.

How realtime works

Here is the list of tools that are involved:

1. MySQL is writing all the data-changes into binary logs, and this is enabled by default in MySQL since version 8
2. Zendesk Maxwell daemon is running as java-process within apache-container and is reading data-changes from MySQL binary logs and writing them into a RabbitMQ-exchange
3. Indi Engine

1. create a RabbitMQ-queue for data-changes to be streamed into there out of RabbitMQ-exchange
2. is reading data-changes from that RabbitMQ-queue in JSON format (format that Maxwell daemon use for writing)
3. is preparing changes' json-data to be compatible with Indi Engine's UI panels
4. is pushing prepared json-data into the RabbitMQ-queue(s) created on browser tab(s) opened by user(s)

4. RabbitMQ is reading that prepared json-data from those RabbitMQ-queues and is delivering that data to the corresponding browser tabs via WebSocket connections, maintained by RabbitMQ Web Stomp plugin

From the user perspective, 'realtime' means that any data changes made by no matter who and for whatever reason - are immediately reflected in the UI for that user. For example, if some Teacher-user has opened the Lessons-section (e.g Lesson-records are shown in the grid or calendar), but then some Student-user created a new Lesson-record - this new Lesson-record should immediately appear in the Lesson-records grid shown for Teacher-user. For sure, this should work not only when a new record is created, but when it's updated or deleted.

More examples:

• If some Teacher-user has NOT yet opened Lessons-section, it means any data-change event that happened for any Lesson-record should NOT be delivered to that Teacher-user.

• If Admin-user changed the value of Sale price-field for a certain Lesson-record, but Sale price-column is disabled for Teacher-users - then updated sale price should NOT be delivered to Teacher-user even despite that teacher might have already opened Lessons-section with that specific Lesson-record shown.

• If Admin-user changed value for Note-field for a certain Lesson-record having Status = Completed, but Teacher-user did apply a Status = Upcoming filter to the grid in the opened Lessons-section - then no delivery of updated value should happen as well.

To be able to handle all those (and many more) cases, Indi Engine know which users are currently logged in, how many sessions using which languages each user has, how many browser tabs each user did open within each session, what data-views (grids / forms / etc) are currently opened within each browser tab, what filtering, sorting and paging is currently applied for each data-view and which records and their data-fields are currently shown in each data-view.

All this makes it possible to check whether some data-change event should be reflected in some data-view(s), and if yes - calculate the exact way of how it should be reflected. For example, if our paging is that we're on page #3, but a record from any previous page was deleted by someone, it means the first record on our current page should disappear because now it's the last record on the previous page, and at the same time - first record on the next page should become the last record on our current page. So to make this work, Indi Engine calculates whether that was the previous, current or next page from where the record was deleted. The simplest is when a record was deleted from one of the next pages - when we simply decrement the Total counter shown in the right bottom corner of the grid.

INFO: Previously, MySQL binlog and Maxwell daemon were NOT involved, so the data-changes were captured by the Indi Engine on PHP-level rather than on MySQL-level, and this was NOT working as a separate background process, so if you simply updated the value of Note-field for some Lesson-record, you had to wait until Indi Engine prepare and deliver that change to all currently opened browser tabs including the one from where you pressed Save-button in lesson Details-window. This is working ok, but is not really scalable, and that is why the current binlog-based solution was implemented.

Foreign keys / ORM

Indi Engine allows to define some fields to be foreign key-fields, and this means that the background values in such fields - are IDs of records from some other tables (or from the same table, if the current entity is intended to represent a hierarchy).

When you create a new single-value foreign key field dealing with ordinary (i.e non-enumerated) values within some entity, Indi Engine creates a new CONSTRAINT for that entity's underlying database table, as this is natively supported by MySQL.

For example, if you create Teacher-field in Lesson-entity, this would mean any Lesson-record itself won't keep the full info about the teacher, but just an ID of a certain Teacher-record instead.

Foreign key fields definitions in MySQL are coming with the ON DELETE rule, which gives an answer on what should happen with the usages of the record we're trying to delete. For example, if we have some teacher, who had some lessons already, but at some point we try to delete that teacher from our database — then the question is: what should happen with those lessons? Here are the alternatives:

• CASCADE: Teacher-record is deleted, but the Lesson-records of that teacher - are preliminary deleted as well
• RESTRICT: Teacher-record is prevented from deletion, so if you still want to delete - you must delete lessons at first
• SET NULL: Teacher-record is deleted, but the Lesson-records of that teacher - are preliminary become orphaned by setting empty value into their Teacher-field

▶00:40

However, the life made it clear that the foreign keys support that MySQL has natively - is not always sufficient in certain use cases:

ENUMERATED VALUES

For example, we have Lesson-entity and we have Status-field there, with the following possible foreground values:

       Upcoming,        Completed,        Cancelled,        Absence. On the MySQL level, this field is represented by `lesson` table's `status`-column defined as ENUM('upcoming','completed','cancelled','absence') NOT NULL DEFAULT 'upcoming', but in the real-life those background-values by themselves are not sufficient, as you might need to apply different foreground values for different UI-languages and apply different styling  as shown above. To be able to handle that, Indi Engine is treating those background values as keys or IDs of records where foreground values and styles are stored, and Indi Engine has a special system Enumset-entity for that purpose

▶00:36

COMMA-SEPARATED VALUES

For example, we have Teacher-entity and we have Courses-field there, for it to be  possible to choose the courses that a certain teacher is able to teach, so we have Course-entity and 3 Course-records:

1. Casual English
2. Business English
3. Exam preparation

If for some teacher we choose both Business English and Exam preparation in Courses-field, this would mean the background value of `teacher`-table's `courseIds`-column for that teacher would be 2,3. So here we have foreign key field where multiple comma-separated IDs are stored.

▶00:35

ENUMERATED COMMA-SEPARATED VALUES

For example, we have Teacher-entity and we have Working weekdays-field there, shown as checkboxes or combobox options with the following possible foreground values: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday. On the MySQL level, this field is represented by `teacher` table's `wdays`-column that might be defined as SET('mo','tu','we','th','fr','sa','su') NOT NULL DEFAULT '', so if you check Monday, Tuesday and Wednesday checkboxes, it would mean the background-value is going to be 'mo,tu,we'.

▶00:36

For all of the above 3 cases Indi Engine respects the ON DELETE rule as well, despite it not being natively supported by MySQL.

For example:

• If we delete Course-record (e.g Exam preparation) - then the background value for Courses-field in the above mentioned Teacher-record will be changed from 2,3 to just 2
• If we delete Enumset-record (e.g. Tuesday) - then the background value for Working weekdays-field in the above mentioned Teacher-record will be changed from 'mo,tu,we' to just 'mo,we'

Localization

Basically, localization means that some strings should be auto-translated to the languages you need, and there is an integration with Google Cloud Translate API for that, but for this to work you have to obtain an API key from Google, and once done, the responsibility of Indi Engine is then to collect those strings in source language, get translations, and then append translations back into the same places where sources were collected from.

▶02:12

First thing here that you need to know is that Indi Engine has fractions, so that strings related to different fractions can be translated into different sets of languages, and there are two major fractions - System and Custom:

• System fraction is used to gather things that are specific to the Indi Engine itself
• Custom fraction is used to gather things that are specific to the custom app you're creating with Indi Engine

For example, Teacher-entity is an entity that belongs to a Custom fraction, as well as Lesson-entity and Student-entity. But Section-entity, Element-entity and Field-entity - all belong to System fraction and those are existing in every app built on Indi Engine.

Also, not only Entity-records can belong to a certain fraction, but Section-records and Role-records as well. Evenmore, some certain Action-records can belong to both fractions at the same time, for example Details-action, because it is used both in system and custom sections.

Another important thing about fractions is that fraction can be defined on record-level if its entity has a Fraction-field and this has the priority over what's defined for the entity that this record is of. For example, Indi Engine has a Role-entity, that is a data-structure and storage of all the Role-records that we may have, and this entity itself belongs to the System fraction. But, Role-records have Fraction-field, and Developer-role has Fraction=System, but all the others - Admin-role, Teacher-role and Student-role - have Fraction=Custom

Before you translate your app to some new language, you have to enable localization for the certain fields you need Indi Engine to collect the source strings from, and in most cases those will be Title-fields, which literally means the values of Title-field of the records from specific entities.

In Indi Engine, localization is already enabled (where needed) for the fields that belong to System fraction, so if you want to enable new language for System fraction, you can do that with no need of any preliminary steps. But for the Custom fraction, which gathers the things that are specific to the app you are creating - you have to decide by yourself which fields you need to be translated and enable localization for those fields.

For example, in our sample app you have Course-entity, and there are Title-field (single-line string) and Description-field (multi-line string), so each of 3 previously mentioned Course-records for sure have values in Title-field (Casual English, Business English, Exam preparation) and might have some values in their Description-field. You can do whatever step first: enable new language or enable localization for those fields, and vice versa, but you will get nothing translated until both steps are done:

Changes of background-values of Title-field during the recommended sequence of steps:

Changes of background-values of Title-field during the opposite sequence of steps

Why is the first sequence of steps recommended and the second one is not? Because the first sequence assumes that your app is already prepared for being translated, which means you had already enabled localization for all the fields where you thought it is needed, so you'll start getting translations right after you enable new languages, instead of trying to get a clue on why there are no translations after some new language was enabled and then realizing, that the reason is that you forgot to choose the fields.

There are two major kinds of fields that you can enable localization for. The first kind is string fields (single- and multi-line), which are mentioned above, and the second kind is foreign key fields having enumerated values. For example, Status-field in Lesson-entity:

Changes of background values of Title-field in each of Enumset-record corresponding to certain possible value of Status-field:

As you can see, the background values of the foreign key field itself - are not translated when you enable localization for that field, but instead, the values of Title-field of the corresponding Enumset-records are translated.

Another important aspect of localization is subfractions of Custom fraction:

1. Interface - are titles and tooltips used in Sections, Entities, Fields and others, including titles stored in Enumset-records
2. Constants - are titles that are defined as php-constants and stored in php-files, but this will be explained in SDK docs.
3. Data - are strings that are the data and not the UI, for example titles and description for each course, teachers and students names, etc

Normally, you don't need Data subfraction to be translated. The only use case ever popped up so far - is when demo versions were prepared for already existing apps, and it was good for potential clients to be able to see everything (Interface + Constants + Data) translated to the language selected on the login page. And yeah, after you translate everything you need for a certain new language - you have to enable that language to be selectable on the login page. Read more in the Languages chapter.

Ok, let's guess we already translated the Custom fraction’s Interface and Data subfractions to German-language.

What will happen if we add        Ongoing as a new possible value for Lesson-entity's Status-field, or if we add a new Financial English course? The answer is: those titles would be translated to German. For sure, if the user who added those new possible status or new course - is currently logged in using German language, then those titles would be treated as German, so they'll be used to translate to English.

What will happen if we change the value of some localized Field in an existing record? The answer is: translations won't be auto-updated unless you enable the Update translations for other languages-param for the field where you changed the value.

Other translations are not updated by default on change for one translation, because in most cases the localization is needed for System and/or Custom interface, and the real life usage is that at first you polish the existing/initial/source translations which mean you make them to look perfect, you try to use words and/or phrases that would exactly explain the meaning behind, with respect to the titles of surrounding UI elements, for example in case for multi-level column headings. And for sure, you don't want all those efforts to be just overwritten by auto-translation triggered when you'll be doing the same polishing but for another language.

However, there might be cases where auto-updating translations for other languages is useful, for example for Title-fields in Teacher-entity and Student-entity when full names are stored in those fields. Also, it can be relevant for Address-field in Student-entity if there would be such a field, which is not the case for our sample app though.

Keyboard shortcuts

Keyboard shortcuts are working only in Index-window with a grid (not always grid) and in Details-window with a form (always form):

• Same for grid and form

• Navigation to subsections inside the currently selected record(s) in grid or opened record in form

• ALT + 1..9 -  open (sequence of) Index for 1st..9th subsection-window(s)
• ALT + SHIFT + 1..9 - open (sequence of) Create new in 1st..9th subsection-window(s)

• ALT + N - open Create new-window
• ESC - close current window

• Grid only

• ALT + E - export grid as an Excel-spreadsheet
• Actions for currently selected record(s)

• ENTER or F4 - open (sequence of) Details-window(s)
• DELETE - do Delete-action
• ALT + T - do Toggle-action
• ALT + UP - do Move up-action
• ALT + DOWN - do Move down-action

• Selection

• Single records

• DOWN - make next record to be selected instead of currently selected record
• UP - make previous record to be selected instead of currently selected record

• Multiple records

• SHIFT + DOWN - make next record to be selected in addition to currently selected record
• SHIFT + UP - make previous record to be selected in addition to currently selected record
• SHIFT + PAGE DOWN - select all records from the current until the last at the current page
• SHIFT + PAGE UP - select all records from the current and until the first at the current page
• CTRL + A - select all records on the current page

• Navigation to other pages

• PAGE DOWN - if last record is selected then load the next page and make the last record selected
• PAGE UP - if first record is selected then load the previous page and make the first record selected

• Form only

• ALT + RIGHT - open Details-window for next record
• ALT + LEFT - open Details-window for previous record
• ALT + N - open Create new-window e.g for new record
• ALT + R - reload Details-window for current record
• ALT + S - do Save-action for current record
• ALT + A - toggle Autosave before goto-mode, so that Save-action will be done automatically for current record

• On attempt to goto next, previous or any sibling record
• On attempt to goto Create new-window i.e for new record
• On attempt to goto any subsection of current record
• On attempt to goto any subsection's Create new-window

This might be useful when you need to sequentially amend some values in multiple records, so you can do:

Amend or setup > goto any or new > amend or setup > goto any or new > etc,

instead of

Amend or setup > save > open any or new > amend or setup > save > open any or new > etc 

because the Details-window is closed when you press Save-action's button, so once saved but with no usage of Autosave before goto-mode you will have to select the next record in the grid and open Details-window again, and do so for each next record you need to amend

File uploads

Indi Engine stores all the uploaded files in custom/public/data/upload directory, which contains subdirectories for each entity having at least one file-upload field and having at least one record with a file really uploaded into that field. For example, if we have Photo-field in Teacher-entity, then the path to the uploaded file would be custom/public/data/upload/teacher/1_photo.jpg, where

• 1 - is the ID of that Teacher-record
• photo - is the Alias of Photo-field in Teacher-entity

If you configure resized copies to be created for images uploaded into that Photo-field, then additional files would appear there as custom/public/data/upload/teacher/1_photo,thumb.jpg and/or custom/public/data/upload/teacher/1_photo,large.jpg, where thumb and large - are background names that you can define for each of those resized copies, see Resized copies for more details.

Update and migrate

▶00:53

There is an Update-action in Entities-section, which is available for the Developer-users only, and once clicked, the update command will be executed consisting of the following steps:

1. App-specific (custom) source code update - Checks whether the most recent commit for your repo on github does not exist on your current Indi Engine instance, and if yes - it means your app-specific source code is outdated, so Indi Engine executes git pull and composer install commands

2. App-agnostic (system) source code update - Check whether the most recent commit for Indi Engine's system and/or client packages on github does not exist on your current instance, and if yes - it means some or both of those packages in your current instance are outdated, so Indi Engine executes:

1. composer update indi-engine/*
2. git add composer.lock
3. git commit -F .git/COMMIT_EDITMSG

INFO: there is a prepare-commit-msg hook already set on your app repo which prepares the commit message contents based on combined git logs of updated Indi Engine packages, so you can see the summarized overview of Indi Engine's crucial source code changes right in your app repo log just to see where you are

4. git push - Push to your app repo on GitHub, if you’ve already have it along with GH_TOKEN_CUSTOM_RW token

3. DevOps setup update - Checks whether any of your current DevOps setup files (everything except custom/ and .env paths) is outdated compared to https://github.com/indi-engine/newapp, and if yes - they will be updated, committed to your app's own repo with a "Updated DevOps-setup files from indi-engine/newapp"-message and pushed to GitHub. Then, Indi Engine will calculate the restart scenario for your instance if needed based on changed files, and write it to a temporary var/restart.plan file.

WARNING: do not change DevOps-files by yourself, as your changes will be overwritten on the next update.

4. App-agnostic (system) database migrate - Checks whether new system migrations are coming since the last time Indi Engine system package repo was updated, and if yes - those are executed in the order they are defined in vendor/indi-engine/system/library/Indi/Controller/Migrate.php

For example, there is a migration represented by noExcel4RoleIdsAction(), which adds Roles to disable Excel-export for-field into Section-entity, which is useful in cases like if you want to prevent Teacher-users from exporting all records from Students-section

5. App-specific (custom) database migrate - Checks whether new custom migrations are coming since the last time your Indi Engine app repo was updated, and if yes - they are executed in the order they are defined in application/controllers/admin/MigrateController.php

For example, there might be a migration that can add a new field into Student-entity, or can increase lesson price for all teachers by 10%, but for now let's assume there are no migrations, as it will be not in zero-code scope anymore, which is a separate topic to be explained in SDK docs.

Each of both above migration steps (app-agnostic and app-specific) may include localization migrations as well, if changes are detected in the following files both in app webroot dir custom/public/ and/or in custom/public/vendor/indi-engine/system/ directories:

• application/lang/admin/ui.php - here is the list of fields to enable localization for
• application/lang/admin/ui/en.php - here are the titles for English
• application/lang/admin/ui/ru.php - here are the titles for Russian

Before migrations start - your current database state is backed up locally into data/before/dump.sql.gz so that if migrations fail for whatever reason - you'll be able to investigate, fix and re-run the migrations with preliminary restoring the database state at the point before the problematic migration attempt - via just a click on Update-action again.

6. Instance refresh - once migrations succeeded, Indi Engine will check if there are var/restart.plan file, rename it to var/restart for it to be further picked by restart watcher process started (by Indi Engine) at the very first deploy and running on your host, so that your instance's images and/or containers will be refreshed, if needed based on changed files.

For example:

5. If any of compose/*/Dockerfile.base files were changed - then base images will be re-pulled, own images will be re-built and containers will be recreated
6. If any of compose/*/Dockerfile files were changed - then own images will be re-built, and containers will be recreated
7. If any of docker-compose.yml or .env.dist were changed - then containers will be recreated
8. If any of other files were changed (of course excluding custom/ and .env paths) - then containers will be restarted

CLI Reference

Indi Engine has a number of bash scripts that allow you to deploy, backup, restore and update your Indi Engine instance via command line (as well as to do some other things), and this is how Backup, Restore and Update actions are really work in Entities-section, so those actions are just the UI triggers for the inter-container API requests from php curl in apache-container to the Flask http server running in wrapper-container, which is, in its turn, executing the needed bash scripts, and having the root access to the cloned repo directory (i.e. myapp) shared as a bind volume with the docker host.

source start

This command is used to get your Indi Engine instance up and running, no matter if this will be a deployment from scratch (i.e. you've just cloned the repo) or it is an existing one which you've previously stopped. In the first case, the script will additionally ask you to define the values of at least 2 configuration variables which will be then written to the .env file.

source backup

This command allows you to create and upload on GitHub a full backup of your Indi Engine instance, or patch some of the backups already existing on GitHub with the database state or file uploads from your current instance. Here are the examples of command usage:

1. source backup

Create a new full custom backup, with rotation of existing custom ones, if any.

2. source backup yourtag

Create a new full custom backup under yourtag release tag, with no rotation.

If you run that command again, the existing backup under yourtag tag will be overwritten by the new one.

3. source backup dump

source backup uploads

Patch a backup already existing on GitHub with a database state or uploads from the current instance.

Before patching, the command will show you the list of already existing backups and ask to choose one.

4. source backup dump --recent

source backup uploads --recent

Same as previous, except that the list of choices won't be shown.

The most recent backup for the same APP_ENV (the one to be patched) will be detected automatically.

If not detected (i.e. does not exist yet), then the full backup will be created instead.

source restore

This command allows you to restore your Indi Engine app instance from a certain backup among already existing ones on GitHub, or patch your instance with database state or uploads from any of those backups. For the first scenario, this command also allows you to commit or cancel the restore, or restore from other backups, if needed.

Here are the examples of command usage:

1. source restore

Restore from a backup you choose in the list of ones available on GitHub.

2. source restore yourtag

Restore from a backup tagged with yourtag release tag

3. source restore dump

source restore uploads

Patch your instance with the database dump or uploads from a backup you choose in the list of ones available on GitHub.

4. source restore dump yourtag

source restore uploads yourtag

Patch your instance with the database dump or uploads from a backup tagged with yourtag release tag

source update

This command allows you to update your Indi Engine app instance, and it's previously explained in the Update and migrate chapter.

source restart

This command allows you to restart your Indi Engine app instance, and there are 4 restart scenarios supported. Below, those scenarios are ordered from the longest to the fastest one.

1. source restart 1

Re-pull the base images, re-build own images and recreate the containers.

This scenario is used when new changes in compose/*/Dockerfile.base files are detected after update

2. source restart 2 

Re-build own images and recreate the containers.

This scenario is used when new changes in compose/*/Dockerfile files are detected after update

3. source restore or source restore 3

Recreate the containers. This is the default restart scenario and is needed to make sure changes (if any) in the .env file take effect.

Also, this scenario is used when changes in .env.dist or docker-compose.yml files are detected after update

4. source restart 4 

Restart the containers. This is used when bash scripts or something else is updated, except paths mentioned above plus custom/ and .env paths

source cleanup

This command allows you to completely remove your Indi Engine app instance from your VPS host, including the source code directory from the VPS host filesystem, as well as docker containers, volumes, images and docker build cache, so you'll get the VPS host state as if you've never deployed Indi Engine there.

This is useful in cases when you are using a single VPS host for temporary deployments of different Indi Engine apps, so you can deploy one, do or check something, backup on GitHub if needed, and then completely wipe out this one and deploy another one instead.

CONFIGURATION

In this chapter we'll walk through all the possible locations (i.e. sections) where you can go as a Developer-user, and you'll get the clue on the purpose of all the possible properties (i.e. fields) available in each section, and for the distinction between them, sections are indicated by ▶ icon and their fields are indicated by ⛭ icon.

All the grids in this left menu group (i.e. Configuration), including grids for direct and deeper sections -  are designed in a way that in most cases there is no need to open Details-windows for records shown in those grids, because all the fields are editable either via grid cell-editors (for most fields) or via clickable color-boxes (for foreign-key fields having enumerated values styled with icons or color-boxes).

▶ Sections / data-views

Sections are the real time data-views that you communicate to the underlying data-structures through. Sections have lots of features designed to handle cases when there is lots of data that needs to be shown on the screen at the same time, and in most cases sections are organized into a hierarchy based on the foreign keys of their underlying data-structures. You can define a hierarchy consisting of multiple sections each connected to its dedicated data-structure or to the same data-structure but having different depth and/or position within the hierarchy, different filtering, sorting, access and appearance including different sets of view-columns available. When you use a certain Entity (i.e data-structure) in some Section, this data-structure becomes a data-source for that section.

<тут воткнуть скриншот дерева разделов>

⛭ Parent section

Parent section-field is a combobox where you can select the parent for the current section, and this defines the depth and position of the current section within the global sections hierarchy. For example, let's take a look at the following hierarchy which is in charge of navigation steps:

Database » Students » Bart Simpson » Payments

Here we have the Database-section which does neither have a parent nor data-source for itself, so it is a top/zero-level section which can only be used as a parent for 1st-level sections, and in our example it is used that way for Students-section, which is in its turn used as a parent for Payments-section, that is intended to be the place where Payment-records of a specific student are shown

Another examples of hierarchy and corresponding navigation steps:

• Database » Students » Bart Simpson » Payments » 2025-02-09 05:44:51 » Details
• Database » Payments
• Database » Payments » 2025-02-09 05:44:51 » Details
• Dictionaries » Courses » Casual English » Topics » Greetings & Small Talk
• Dictionaries » Countries » United Kingdom » Cities » London » Universities » Imperial College London » Details

Technically, the maximum possible depth of the hierarchy is not limited, but in most cases there would be no need for more than 4 or 5 levels of depth, including the top/zero-level. Also, keep in mind that only top/zero-level and 1st-level sections are shown in the Indi Engine's left menu - you can see that on the screenshot above.

⛭ Connector field

For sections that are at 2nd or deeper level within the hierarchy (e.g. Topics or Cities), the special SQL WHERE clause is auto-generated and applied by Indi Engine, so that the records shown in such sections are always limited to only the ones that belong to a previously selected parent record. For example, let's take a look at the already mentioned navigation steps over the hierarchy:

Database » Students » Bart Simpson » Payments

Those steps assume that you clicked on Database » Students in the left menu, waited until students grid loaded, clicked on the Bart Simpson row (to make it selected) in students grid, and then clicked on Payments subsection-button, so now you see the payments grid for that specific student. But under the hood, once you clicked Payments subsection-button, Indi Engine auto-generated and executed the following SQL query: SELECT * FROM `payment` WHERE `studentId` = X, to be able to show you the payments of that student, and X is the ID of the student you've selected in the students grid

This works out of the box as long as Student-field has Alias=studentId in your Payment-entity and Indi Engine rely on that, but if for some reason you need to use different Alias, for example student_id  then you have to explicitly specify such Student-field as a value of Parent section connector field-field for Payments-section, to tell Indi Engine to use that field as a connector.

⛭ Data-source

⛭ Entity

This field is a combobox where you can select the entity to be the data-source for the current section. For example, if you want to create a Lessons-section, you have to choose the Lesson-entity in this field. Keep in mind that you have to create such an entity beforehand in the Entities-section, but if you haven't yet - click on Create new-button right in the Entity-field's combobox.

⛭ For owners - only owned records

For owners - only owned records-field is a part of the record ownership control system in Indi Engine, and you can use it to define the restrictions to be applied for the users who might possibly be the owners for certain record(s) in the current section, but who are in fact not the owners of those record(s). Please see the detailed explanation of the purpose of this field in What about the ownership? paragraph in Users, roles and access chapter of current documentation.

⛭ Filter by plain SQL WHERE

This field is a single-line text field where you can specify SQL WHERE clause to be directly applied as a pre-condition for any actions over any records in the current section. This might be useful when you need to, for example, prevent Teacher-records having Toggle=Waiting or Toggle=Turned off from being available to Student-users in My teachers-section as you don't want such teachers to be shown to Student-users, and if so, you can achieve that by putting `toggle` = "y" or `toggle` NOT IN ('p', 'n') into that field for My teachers-section, assuming Toggle is a foreign key field in Teacher-entity having the following possible enumerated values:

⛭ Loading records

⛭ Page limit, loading mode

Page limit can be defined via Number of records per page-field which is 25 by default, and in most cases you won't need to change that.

Loading mode-field is a combobox-field where you can define whether records-data must be loaded via separate (i.e. additional) XHR-request, which is started only after the initial one responds with the meta-data sufficient to build the UI on the fly. There are 3 possible values for that field:

1. Auto - Indi Engine will use separate XHR-request if any of the following conditions is met:

1. Current section is at 1st-level of depth (e.g is accessible via left menu): Indi Engine always maximize the Index-action windows in such sections, so there is no attempt to calculate the width/height usage of the records-data, so no need to load that data within the initial XHR-request
2. Current section has more than 10 data-columns (i.e. records in Grid columns subsection) accessible to current user

2. Separate request. This might be useful for sections having many tens of data-columns, as the time consumed by the request itself to prepare both meta-data and records-data on server-side plus the time consumed by grid cell rendering, width usage and auto-sizing calculation on client-side might possibly cause a bad performance impression for the user who opened such a section.

3. In the same request. From the other hand side, loading records-data within the same (e.g initial) XHR-request might be more fancy for cases when section window width/height usage (calculated with respect to UI plus data) is enough compact for window to be initially auto-sized to exactly fit its contents (instead of being initially maximized), as otherwise the user experience will be that the window size is "jumping" with a delay, because delay would be needed to load the data via separate XHR-request and to recalculate the size usage once again but this time respecting the data. In other words, loading records-data within the same request is needed to have everything for correct auto-sizing calculation from the very beginning.

⛭ Default sorting

There are two fields in Section-entity are responsible for default sorting of records in a certain section:

1. Sort by - here you can select a field among the already existing ones within the Entity used as data-source by that section
2. Sort direction - Ascending or Descending

For example, you can make records in Students-section to be sorted by values of their Title-field ascending (i.e. alphabetically), and/or make records in Payments-section to be sorted by Datetime-field (or ID-column) descending (i.e. most recent to be at the top of the list). If you wonder why Datetime is mentioned as a field, but ID as a column, please see Entities / data-structures ⛭ Title, DB table paragraph.

⛭ Displaying records

⛭ Show ID column

This is a combobox-field where you can make the ID column to be visible in the grid for the current section, because it's hidden by default. Record IDs will also be shown in the gallery and calendar panels, if those panels are enabled for the current section. For example, you might want to show the ID column in the Students-section to be able to distinguish between users having the same full names.

⛭ Enable numbering

This is a combobox-field where you can enable records numbering for the current section, and if you do that - additional column will be prepended in the grid to show the number for each record, starting from 1 and ending with the total quantity of records in the current section. Record numbers will also be shown in the gallery and calendar panels, if those panels are enabled for the current section. For example, you might want to enable records numbering for Dictionaries » Courses » Some course » Topics-section

⛭ Enable coloring

The main thing about records colors is: how do we know about a specific color to be used for a specific record? It's clear that color should be somehow based on the data inside of specific record, but in all cases color can only be defined in (and then picked from) a field having Element = Color picker, so the only question is where is that field, and here are the alternatives supported by Indi Engine:

1. In the current record. For example, you have Dictionaries » Payment methods-section data-sourced by Payment method-entity having Title and Color fields so it's possible to define title and color for each possible payment method. So, if you need each record shown in that section to be colored as per defined in Color-field for that record, you have to set Row color ↴ Field = Color for that section

2. In the record referenced by foreign key

1. Example 1: you have Database » Payments-section, and you want records there to be colored according to payment methods, defined in Method-field which is a foreign key field pointing to Payment method-record. To achieve such a coloring, you must set the following details for that section:

1. Row color ↴ Field = Method
2. Row color ↴ Further field = Color

2. Example 2: you have Database » Lessons-section, and you want records there to be colored according to lesson statuses, defined as enumerated values for Status-field in Lesson-entity (e.g ___ Upcoming, ___ Ongoing, ___ Completed, ___ Cancelled,        Absence, remember?) and to achieve that, you must set the following details for that section:

1. Row color ↴ Field = Status
2. Row color ↴ Further field = Text color. (Text color - is a сolor picker field in Enumset-entity)

⛭ Grid panel

Grid panel is the mostly used type of rowset-panel to show the records list, and it's enabled and used as default one for all sections, unless you explicitly disable it using Grid ↴ Enable = No, and/or make another type of panel to be default for certain sections. All grid panels support multi-level column headings, cell-editors, sorting, grouping, excel-export and reset sorting to default.

⛭ Records grouping

Records grouping is implemented via Grid ↴ Group by-field for any Section-record, so if you want records in the grid to be grouped, you should specify the field to be used for grouping. For example, you might want to make Country-records in Countries-section to be grouped by Continent-field.

⛭ Export as an Excel spreadsheet

In Indi Engine there is by default a possibility to export any grid as an Excel spreadsheet, and almost all of the features that affect the look and feel of the grid - are supported, i.e. multi-level column headers, header icons, records colors, grouping and numbering, cell colors, icons and templates for cell values and tooltips, as well as the indication of breadcrumb trail, sorting, filtering, keyword involved and the total count of found records. The only things that are not supported are row expander and locked columns.

<тут воткнуть скриншот как выглядит эксельник, выбрать откуда сделать экспорт чтобы было по-наряднее>

However, you might want to disable that possibility, which is useful in cases when you, for example, don't want Teacher-users to be able to export all records from Students-section, and if so, you should add Teacher-role into Roles to disable Excel-export for-field in that section’s details.

⛭ Gallery panel

Gallery panel by itself is about showing thumbnails of image and/or non-image files that might have been uploaded into each record, so to enable this kind of panel for a specific section, you should define which File upload-field should be used for that, because there might be multiple file-upload fields existing within the single entity (i.e. entity used as a data-source for that section).

If the uploaded files are going to be images, then it's recommended to use resized copies auto-created for those images instead of original images to be shown as thumbnails, because original ones might have different aspect ratio each and can have several megabytes of file size each, so the thumbnails will look awkward relative to each other and might take longer time to load.

For example, if you want to enable gallery panel for Database » Teachers-section, then you should create Photo-field in Teacher-entity, and then you shout go to Configuration » Entities » Teacher » Fields in structure » Photo » Resized copies section and create new record there with the following details:

• Alias = thumb. This value will be part of resized copy filename on disk, i.e. data/upload/teachers/1_photo,thumb.jpg
• Size ↴ Width = 300
• Size ↴ Height = 200
• Size ↴ Set exactly = Both dimensions, crop if need

Now, the only remaining step is to go to Configuration » Sections » Teachers » Details and set the following details there:

• Display ↴ Default panel = Gallery. You can skip this if you don't want gallery to be default panel
• Gallery ↴ Enable = Yes
• Gallery ↴ Fileupload-field = Photo
• Gallery ↴ Resized copy = thumb

<тут воткнуть скриншот с галереей преподавателей, плюс как выглядит если нет картинки или файл не картинка>

As you can see on the above screenshot, not only photos are shown for each teacher there, but also

• Toggle - box at the top right of the image
• WhatsApp, Telegram and Viber - boxes (here those are icon-styled ones) under image
• Title, Email, Phone and Courses taught - text under image

This is an example of that you can enable any data-column to be shown and choose where exactly it should be shown in the gallery panel: Text under image, Box under image or Box at the right. See more details in Gallery paragraph in Grid columns chapter

⛭ Calendar panel

⛭ Fields kit types

If you want to enable calendar-panel for a certain section, it assumes the records there are going to be treated as events, and this requires the data-source entity of such a section to have the fields representing Date of event (at least)  and it's Time and/or Duration as well (at most). This info can be represented by various kits of fields called Calendar fields ↴ Kit types, and here are the ones pre-defined in Indi Engine:

On an attempt to enable the calendar panel for a certain section, you will be prompted to select kit type, fields list matching that kit type, and calendar panel types to be enabled, so this means you must already have those fields created in your data-source entity.

There are 3 types of calendar panels possible - Month, Week and Day calendars, but two latter ones are applicable only when your kit type has Duration measured in minutes, because the main idea of those types of calendar panels is that records in there are represented as blocks having heights reflecting their (possibly different) durations on the intraday timespace.

Keep in mind that Indi Engine so far does not auto exclude/disable:

1. Options in Fields list that do not match the selected Kit type, so if you select wrong fields it will cause errors.
2. Options in Types that do not match the selected Kit type, but it will not cause errors as this is additionally checked internally

Drag and drop is enabled in all types of calendars, so you can change Date of a certain record in month-calendar by dragging that record from one day to another within a month, and you can change Date and/or Time in Week and Day calendars by dragging that record within a week and/or day. Also, you can resize a record in Week and Day calendars to change the Duration of that record.

As you could see in the kits list table, for the first 5 kits only month-calendar is applicable, because those kit types either do not have Duration, or have but its measured in days rather than minutes so that is not applicable for Week and Day calendars as each record there would always be shown having 100% height of the Week and Day calendars intraday timespace.

If you are using kit type where Day calendar is applicable, and is enabled by you, then you can also enable grouping via Grid ↴ Group by-field, and in that case the records (events) in your Day calendar will be grouped by the field you've specified there. This might be useful in case when, for example, your app is designed to handle multiple offices (which is not the case for our sample app) each controlled by a user having Office admin-role and each having multiple rooms for lessons, and you want Lesson-records to be grouped by the rooms they're scheduled in, so that Day calendar will become something similar to kanban board where you'll be able to drag records for changing their rooms, if needed.

However, keep in mind that you will highly likely have to create a separate Lessons-section (having different/unique value of Alias-field, i.e. Alias = officeLessons) for this and enable such a grouping there, as it won't be useful for non-Office admin-users, because rooms of all offices will be shown to them as not filtered by specific office, and it won't be clear what office each room is at.

⛭ Event timeId

If you are using kit type having timeId, its assumed to be a Time-field (i.e. field having Title = Time) within your data-source entity (you can see it's mentioned on the prompt screenshot above) and is required to have the following details:

• Alias = timeId
• Foreign keys ↴ Store keys = Yes, single-value
• Foreign keys ↴ Which entity keys = Possible time
• Foreign keys ↴ ON DELETE = RESTRICT
• Display ↴ Element = Combo
• MySQL-column ↴ Type = INT(11)

As you can see, this field is required to be a single-value foreign key field of MySQL datatype INT, pointing to Possible time-entity, which belong to System fraction and contains Possible time-records for hh:mm values starting from 00:00 and ending at 23:45 with a 15 minutes step, and this is done that way to make event's time to be selectable from the list of values rather than typing that time manually when creating/editing the record (i.e. event), and this helps in overlap protection as Possible time-records available in the Time-field combobox dropdown can be made disabled when causing overlap.

⛭ Event duration

If you are using calendar fields kit type having dayQty or minuteQty for Duration, then your data-source entity is required to have Duration-field, which is in its turn required to have Alias = duration, Display ↴ Element = Number and MySQL-column ↴ Type = INT(11), because Indi Engine rely on that while validating your records (i.e. events) both on attempt to insert/update and on attempt to make draft changes (i.e. changes that are not saved so far) so that overlap protection inform you about the overlapping in advance

⛭ Overlap protection

Overlap protection is only applicable for calendars fields kit types containing duration, and those are:

1. DATE, dayQty
2. TIMESTAMP, minuteQty
3. DATE, TIME, minuteQty
4. DATE, timeId, minuteQty
5. DATE, hh:mm-hh:mm

To enable overlap protection, you have to choose one or more foreign-key fields in Calendar fields ↴ Prevent overlap for. For example, in our sample app, this make sense to set the following value for this field for Lesson-entity:

• Calendar fields ↴ Prevent overlap for = Teacher, Student

This means that Indi Engine won’t allow you to neither create new nor modify existing Lesson-records if this would lead to conflict/overlap for the involved teacher and/or student, and therefore Indi Engine will fade down the areas in the calendar to prevent you from dragging/resizing the record into those areas in case if this would lead to overlapping.

<тут воткнуть скриншот где показано как фэйдятся области в недельном календаре>

Also, overlap protection works not only in calendar-panel, but in the Details-window and Create new-window as well, so Indi Engine won't allow you to specify the details for a record if those details will result in overlapping with other record(s). Field timeId from calendar fields kit type "DATE, timeId, minuteQty" is assumed to be field having Element = Combo because in that case Indi Engine is able to disable some values (i.e. choices) there, so they will be unavailable for selection when leading to overlapping with other records.

<тут воткнуть скриншот как какое-то время задизаблено>

▶ Actions

Configuration » Sections » Some section » Actions-section is using Action in the section-entity as the data-source, and it's there to give you the ability to define what actions are available in a certain section and for which users, so it's a crucial part of the access system, previously described in this chapter.

It's worth to mention that Indi Engine also has Configuration » Actions-section which is using Action-entity as the data-source, and it is a list of all possible actions that can be used across the entire app, i.e. Index, Detail, Save, Delete, Export, and others, so technically, each Action in the section-record serves as an association between certain Section-record and certain Action-record. Sometimes it may be useful to turn on/off that association, so there is Toggle-field for that.

⛭ Access roles

Each Action in the section-record has Access ↴ Roles-field, which is a combobox where you can choose the user roles that this action should be accessible for, which means the corresponding action button will be shown in the master toolbar of rowset-panels (i.e. Grid, Gallery, Calendar panels) and row-panel (i.e. Form panel) in this section, and the request to the corresponding URI will not be rejected.

Keep in mind that the action button itself is just a way to represent the action in the UI, but under the hood XHR-request is started when the button is clicked. For example, when you open Students-section, select some student and press Delete-button - Indi Engine makes a request to /students/delete/id/XXX/, and the access check is done during processing of such a request.

Another important point - is about Index-action, as it serves as a permission to open rowset-panel of a given section, so if there is no such action in given section - this section won't be shown anywhere: neither in the left menu, nor among the nested section-buttons in the master toolbars, if this section is a sub-section for some other section.

For example, if you don't assign an Index-action for Students-section, that section won't even be shown in the left menu, so this means you won't be able to get the list of students. However, you'll still be able to do other actions, but in most cases you'll have to do that via javascript console rather than via Indi Engine interface, for example using Indi.load() method

> Indi.load('/students/form/id/xxx/');

⛭ For owners - only owned records

By default, record ownership is not taken into consideration by the access system, but you can change this behaviour independently for each specific Action in the section-record, by using two special fields, and first one is For owners – only owned records-field which has the following possible enumerated values:

1. No
2. Yes, for all owner roles
3. Yes, for certain owner roles

If the last value is selected then it's possible to define those 'certain owner' roles via For which certain owner roles-field, and yeah that's the second of those special fields. Please see this chapter as the whole ownership concept is explained there with examples.

⛭ Override batch-selection mode

Batch-selection mode is supported for only 7 of tens of actions on global level (i.e. Action-records), but is enabled by default only for 6 of those 7: Details, Move up, Move down, Toggle, Export and Copy, and the only action for which it's not by default enabled despite supported - is Delete-action, because it's a possibly destructive action which should be carefully used to prevent occasional unwanted deletions.

However, you can override that on section level if need, because each Action in the section-record have Override batch-selection mode-field which is a radio field with the following choices available:

1. No, use default batch-selection mode

This is the default choice and in most cases you won't need to change that, unless you have the cases similar to explained below

2. Yes, enable batch-selection for this section

This might be useful for Delete-action in some sections where you think default deletion of records one by one is annoying

3. Yes, disable batch-selection for this section

You might want this if you, let’s say, have Export-action in some section where you created your own implementation of that action in the source code, but this implementation either does not assume or does not have batch-selection support so far.

For example, this is the case for Copy-action, because both the action itself and batch-support for it is implemented only for Sections-section to make it possible to copy data-views definitions to the different positions within the hierarchy, but if you add this action to some other section - it won't work there at all until you code that.

4. Yes, enable, but process one record per request

This works as a sequence of synchronous (via async/await) XHR requests, where request for the next record within selection is started only after the request for the previous one got the response. This can be useful if you need action execution for an individual record (among selected ones) to be inside a request that is isolated from other records, for example when action execution takes significant time so that request timeout can happen on browser-side or server-side, so with using this approach you can split a single long request that process all selected records at once - into a sequence of shorter requests each processing a single record. In most cases you might need this only when some 3rd-party services are integrated, for example there was a use case where there was a special implementation of Confirm-action in Payments-section, so that it was possible to select multiple Payment-records and send info about each one to the government tax authorities system, but this goes out of zero-code docs scope.

Basically, in most cases you won't need to override batch-selection mode for any action, because if you make batch-selection to be enabled in some section for some action that Indi Engine does not support that out of the box - you will have to implement that support by coding on your own. Let's imagine we want to create custom implementation for Confirm-action we've added in Payments-section:

1. Go to Configuration » Sections-section
2. Find and make selected the record that represents Payments-section
3. Do Create PHP-controller file-action for the selected record by clicking the corresponding button in the master toolbar
4. Open application/controllers/admin/PaymentsController.php file in your IDE (i.e. PHPStorm or other)
5. Append the following code inside Admin_PaymentsController class defined in that file:

public function confirmAction() {

              // do something with the first or single selected row

           echo t()->row->id;

    // do something here for each selected row

    foreach (t()->rows as $row) {

        echo $row->id

    }

 }

However, this goes out of zero-code docs scope, so won't be much explained here.

⛭ South tabs display mode

South tabs are another type of UI containers where rowset-panels (i.e. grids, galleries, calendars) can be rendered into. For sure, windows are the primary container type, but still there might be the cases where south tabs can be used instead or in addition to windows. However, south tabs can only be enabled for Details-actions.

South tabs for Details-actions can be useful when your current section has subsections so you want their views (e.g rowset-panels) to be rendered in addition to row-panel - as tabs under that row-panel, but still within the same Details-window, so there is no need to open any of those subsections in separate windows because now there are tabs right here for each.

For example, in our sample app we have Database » Students » Some student » Payments-section and Database » Students » Some student » Lessons-section, so if you set South tabs display mode = Display for Details-action in Students-section and then open Database » Students » Some student » Details-window - this window will have Payments and Lessons tabs under the student details, and those tabs will show payments grid and lessons grid, respectively, or whatever rowset-panel types you enable for those subsections.

<тут воткнуть скриншот как это выглядит>

South tabs presence is controlled by South tabs display mode-field which is a combobox field with the following choices available:

1. Auto

South tabs will be displayed if there are less than 10 fields shown in Details-panel, because if so - this will mean Details-panel's height usage is not that much, i.e. there is still enough vertical space for south tab(s) to be added under that Details-panel with no vertical scroller needed. For example, if you have Dictionaries » Countries » United Kingdom » Cities-section and you opened Dictionaries » Countries » United Kingdom » Details-window, then you'll have Cities-tab displayed under that Country-record's Details-panel, assuming this panel has just 1 field: Title = United Kingdom.

2. Display 

South tabs will be displayed anyway, i.e. no matter how many fields are shown in the Details-panel. If there are too many fields - vertical scrollbar will appear then to handle that. This might be useful when you want to have as much as possible about a certain record within a single Details-window (it’s shown how this looks on the screenshot above).

3. Do not display

South tabs are disabled, so won't be displayed. This can be useful when you want to keep things simple and not to overcomplicate the UI in some specific sections

⛭ Rename

There is also Rename-field available, so you can set up a different foreground name (i.e. Title) for this action to be applied in that specific section only. This might be useful for cases when you want the action title to be more self-explaining than the original one. For example, if you've added Notify-action for Lessons-section, you may want to rename it to be Notify student instead.

▶ Grid columns

Configuration » Sections » Some section » Grid columns-section is using Grid column-entity as the data-source, and it's there to give you the ability to define the look and feel of the data shown in rowset-panels (Grids, Calleries, Calendars) of a certain section, i.e. you can select the exact fields among the ones existing in the data-source entity (and also the ones existing in the entities referenced by foreign keys, i.e. JOINed fields) to be shown per each type of rowset-panel you've enabled.

Technically, any Grid column-record by itself is an indication that data coming from a certain field is shown in the rowset-panel of a certain section. It's called Grid column instead of Data view column or View column or whatever else just because Grid-panel is the mostly used type of rowset-panel, compared to Gallery-panel and Calendar-panel.

⛭ Data-source field

In most cases, data source for a grid column can be defined by the Field-field, where you can choose the underlying field for a certain grid column. For example, in our sample app there is Database » Lessons-section with a grid of all lessons, and you may want values of Profit-field to be shown for each lesson as a column in that grid. Also, you may want to add Teacher and Student fields to be shown as columns in that grid as well, in addition to lesson Date, Time and Duration.

⛭ Further / JOINed field

It is also possible to add fields that do not directly belong to the current data-source entity, but are, however, reachable via foreign keys, and in that case you have to select that foreign key field in Data-source field-field and then select the final field in Further / JOINed field-field.

For example, you have a Student-entity which has a Phone-field, and you want students' phones to be also shown in the Lessons-section grid. This Phone-field does not belong to Lesson-entity, but is reachable via Student-field which is a foreign key field, so you can make students phones to be shown by adding new Grid column-record having the following details:

• Section = Lessons
• Data-source field = Student
• Further / JOINed field = Phone

For sure, you can add teachers' phones in the grid as well, and any other fields reachable via foreign keys.

Columns added into the grid using that way will appear with a little bit faded background (both for header cell and value cells) to visually indicate that they are from different data-source entities. Under the hood, native SQL JOIN feature is not used while fetching the data for those columns, because it's a well-known expensive operation to do this that way on big tables, so in Indi Engine the data for such columns is fetched afterwards - only for the foreign keys values available on the current page of results having 25 records by default, instead of doing that for all records in the table when using SQL JOIN. However, this makes such columns not sortable in the grid, but that's not a big price for performance improvement it gives. So, using 'JOINed' wording in the field title is just for making it clearer what this is for fetching data from a different database table than the one used as data-source for the current section.

<тут воткнуть скриншот как это выглядит в гриде Lessons>

⛭ Parent column

This field is used to make your grid to have multi-level column headings, and to achieve that you must select some other already existing grid column to be the parent for one you want to be the child. You can organise your headings into as many levels as you want, but in most cases you won't need more than 3 levels.

Any parent column is always acting as the group of its child columns, and it does not have its own data, so the only data that is shown in a group - is the data of child columns, except the childs having their own childs. At the same time, any grid column (incl. the one used as parent) requires a data-source field, and this means you have to create that field in your entity for that purpose, but such a field should not have its own data in the database, i.e. there will be a valid Field-record in your entity, but there will be no corresponding column in the structure of the underlying database table, and this can be achieved by setting up Display ↴ Element = Field group in such field details.

For example, let's imagine you have Students-section and you want to organise the multi-level column headings there as shown below:

Before doing that, you'll have to create the following fields in the Student-entity: Signup, Contact details, Attendance, Lessons, but all of those should have the following details (assuming other ones you do already have in that entity due to they are real data fields):

• Mode = Hidden
• Display ↴ Element = Field group

After this, you'll have to go to Configuration » Sections » Students » Grid columns-section and create the Grid column-records via Create new-button in the order assuming parent ones are created before child ones, so while creating child ones it will be possible to select the parent ones from the list of already existing ones in Parent column-field's combobox.

As an alternative and much quicker approach you can press Create new-button once,  select all 12 fields in Data-source field-field (yeah, it's possible because that field type is temporarily changed by Indi Engine from single-value to multi-value) and press Save-button once. As a result, you'll see that 12 records appeared in Configuration » Sections » Students » Grid columns-section, so the only remaining thing will be to organise them into a hierarchy using drag and drop, because it's supported there.

After this, you can goto Database » Students-section and check the column headings hierarchy you've organised, and you can amend it via drag'n dropping headings right there.

⛭ Show in

This is a group of fields that allows you to define the presence of a certain column's data in each kind of rowset-panel, separately. For example, if you have a Teachers-section, you can make all possible columns to be shown in the grid, but only Title, Email and Phone - in the gallery.

Keep in mind that the order in which data from different columns is shown - is the same as the order of records in Configuration » Sections » Some section » Grid columns-section i.e. it is shared across all kinds of rowset panels. For example, if Email comes after Title - it will be that way in both (grid and gallery) panels.

However, you can achieve another order if you create additional Grid column-record having the same data-source field, so that you can make the original one to be shown only in grid, and the additional one - shown only in gallery. For example, you can have those 4 Grid column-records where 1st and 3rd ones are using same data-source field, so that grid will have this order of columns: Title, Email, Phone, but the gallery will have another order: Email, Title, Phone:

1. Title - shown in grid only
2. Email - shown everywhere
3. Title - shown in calendar only
4. Phone - shown everywhere

This approach will not only give you the ability to achieve the different order for different rowset panels, but also different styling, rendering and other settings.

⛭ Grid

Each Grid column-record has Show in ↴ Grid-field where you can define the way of presence within the grid, and there are the following choices available:

1. Turned on

Data is shown in the visible column in the grid, and this is the most widely used and default choice.

2. Hidden

Data is shown in the grid column, but that column itself is hidden. However, you can make that column to be visible via any other column’s menu, but this would be a temporary visibility change and it won't be preserved on reload of Index-window where this grid is rendered. Hidden columns are useful in cases when you don't want those columns to be visible in the grid, but you still need data for those columns to be fetched on server-side and available on browser-side, for example when you rely on values from those columns in some other columns values/tooltips templates, or when you need those columns to be hidden by default but shown when some button is clicked.

3. Hidden, but shown in row expander

This is similar to the previous choice, except that the value from such a column is additionally shown in the row expander, which is enabled when at least one column is configured to be shown this way. This is useful in cases when you want the data to be still visible in the grid but not as a grid column because of too long text expected to be there for the grid to stay handy (or because of whatever reason).

For example, in our sample app there is Students-section with Personal details-column set up as a parent column for Birth date, Gender and Country columns, and you can make all of them to be visible in a row expander instead of visible as a column.

<тут воткнуть скриншот>

4. Turned off

When this choice is active, the column is completely unavailable at both browser-side and server-side, so there is nothing to make visible via other columns menu or rely on it in value/tooltip templates for other columns. This choice might be useful in cases when you don't need some column to be in the grid anymore, but you're not sure at the moment about whether you'll need it in future, so you decided to exclude it from the grid for now, instead of deleting it.

⛭ Calendar

This is represented by Show in ↴ Calendar-field and it's a combobox having only two choices - Turned off (default) and Turned on.

Current implementation of all kinds of calendar panels (Month, Week and Day) supports just a single way of showing values - all inside a record/event block in the calendar, so the only question here is which columns you need the data to be shown from. For example, if you enabled the calendar for Lessons-section, you may want data from Student, Teacher and Course columns to be shown for each record/event in the calendar.

Also, you can still use values and/or tooltips templates to achieve the needed contents.

⛭ Gallery

Each Grid column-record has also Show in ↴ Gallery-field where you can define the way of presence within the gallery, and there are the following choices available:

1. Turned off

By default, once you enable the gallery-panel for some section - images thumbnails will be shown there, but no data for any specific column is additionally shown for each thumbnail, so this is the default choice until you explicitly change it for the columns you need to be shown.

2. Text under image

This choice is best suitable for short text values up to ~100 characters, because horizontally visible space for values shown this way is limited to thumbnail width, so the overflowing text is clipped but is scrolled on mouse hover, but this is not really usable for longer texts as those will be scrolled too fast on hover so won’t be recognizable, and therefore it's better to use this choice for titles, emails, etc.

For icon-headed columns (which might be the case for emails, phones), it's better to use Box under image or Box at the right, see below.

3. Box under image

This choice is best suitable either for icon-headed columns or columns data-sourced by a single-value foreign key fields having enumerated values styled using icons or color-boxes:

• If you enable this choice for an icon-headed column, then a corresponding icon will appear under the thumbnail image and the column’s value will be shown as a tooltip for that icon on mouse hover.

• If you enable this choice for the column data-sourced by a foreign-key field of a kind mentioned above - the result will be the same except that the icons (or color boxes) will be different for different values.

For example, on our sample app there is Teachers-section with gallery-panel enabled, and a columns data-sourced by WhatsApp, Telegram and Viber fields each having 1 of 2 enumerated values styled by icons - and you can see whether a specific teacher has a specific messenger - under the image thumbnail, i.e.

4. Box at the right

This choice is an alternative for the previous one, except that the icons and/or color-boxes will be shown on a faded background at the right side of the thumbnail. Keep in mind that this looks good for color-boxes, but might not look good enough for icons as it depends on the individual icon’s canvas background color and opacity defined in the icon file itself.

For example, on our sample app there is Teachers-section with gallery-panel enabled, and a column data-sourced by Toggle-field having

 ___ Pending, ___ Turned on or ___ Turned off as values - and you can see the value per teacher at the right side within the teacher’s thumbnail.

In general, it's not recommended to use each of the above choices for more than 5 columns to prevent gallery visual overcomplication.

<тут воткнуть гифку где галерея переключается на грид>

⛭ Header

It's a group of fields that control the appearance of the column header. See below which appearance settings are supported.

⛭ Locked / Normal

This is represented by Header ↴ Group-field where the following choices are available:

1. Locked

This can be useful when all of the following conditions are in place:

1. Your grid is wider than your screen, so that horizontal scrollbar appears, but you don't want some columns at the left side to be scrolled out of viewport when you scroll the grid to the right side
2. You just want to visually divide the grid into left and right sides using tiny sexy vertical line

So, if you use this choice for some columns - those will be locked at the left side of the grid and won't be affected by horizontal scrolling, if any. When this choice is used for at least one column - the vertical line appears between locked and normal sides of the grid to help for visual distinction between the sides.

2. Normal

This is the default choice, because grids are in most cases not enough big to have locked columns from the very beginning of grid creation, and also because grids can consist of normal columns only, but can not consist of locked columns only which would be the case when using Locked as a default choice.

In general this works in the same way as in Excel, but it's called Freeze there.

⛭ Icon

This field is a combobox-field where you can choose some icon to be shown inside the column header cell instead of column title, so the column title itself will then appear in the tooltip shown on the icon mouse hover. If you do that, this column will have a compact fixed width of 30 pixels, and all the actual values in that column will be shown as the same icon, so the presence of an icon in a specific row would mean non-empty value for that column in that row, and the value itself can be shown on icon mouse hover in the value cells.

This is useful for cases when you want to reduce the usage of horizontal space required by some columns in the grid.

For example, in our sample app there is Teachers-section with Youtube introduction video link-column having a header cell styled with  icon, so the link itself is shown only on mouse hover on the same icon within a value cell, unless no value for that field is specified for a specific teacher.

<тут воткнуть гифку как мышь наводится на заголовок столбца, потом на ячейку где есть ссылка youtube>

Keep in mind that if you set up an icon-heading for a column having data-source field as enumerated values foreign key field - the column values will not be replaced with that icon, but instead - will be shown either as plain text (clipped by column 30px width and shown in full on value cell mouse hover), or as icon / color-box if set up for a specific enumerated value.

Currently, there are 150+ different icons available (see those in custom/public/vendor/indi-engine/client/resources/images/icons), but you can add your own ones by putting them into custom/public/i/admin/icons directory, which should be created by you as it does not initially exist. See here how to configure the list of directories to be scanned for icons.

<тут воткнуть скриншот на котором показан выпадающий список иконок в форме редактирования столбца>

You should be aware that in most cases you will have to preliminary edit the icon file using Adobe Photoshop or some other tool, because it's highly likely that the icon file that you've obtained somewhere will have the background color, aspect ratio or position within its own canvas that make it look quite imperfect when within the column header cell.

If the icon you want to use is in SVG-format, then you'll have to convert it to PNG-format, as otherwise you'll have to deep dive into how SVG format works to be able to get a clue on how to solve the imperfect things by direct changes in the SVG-code.  Also, keep in mind that bigger icons are scaled by the browser to fit the header cell dimensions while keeping the original aspect ratio, but are not scaled by Excel when the grid is exported as an Excel-spreadsheet.

Also, while trying to reach the perfect look within the header cell, it's recommended to use incremental naming of icon files for each attempt, i.e.  some-icon-1.png, some-icon-2.png, etc, as otherwise they will be cached by the browser so you'll be annoyed to often see the outdated version(s) of that icon unless you keep your browser's DeveloperTools panel opened and check the Disable cache checkbox.

Unfortunately, it is not possible to set up Font Awesome icons at the moment, but it is on the roadmap.

⛭ Rename

By default, columns headers titles are set up to be equal to their data-source fields titles, but for some columns you might want to use the alternative titles (with possibly keeping the initial ones in the tooltips), and that is why Header ↴ Rename-field is here.

Renaming can be useful for columns that are data-sourced from numeric fields, because values in such columns do not need too much horizontal space, so that shorter header title would make column horizontal space consumption (calculated as maximum among header width and values width) more efficient.

For example, in our sample app we have Students-section with a grid column data-sourced by Attendance ↴ Presences qty-field and showing quantity of attended lessons per student, but the column itself renamed to just PQ (i.e. abbreviation). In this case, that column’s original title auto-appears as a tooltip shown on column header mouse hover, and here is why.

Also, renaming columns can be useful when you're creating multi-level column headings out of a lesser/single-level headings. For example, if you have Students-section with the Date of first lesson-column and Date of last lesson-column, you can reorganize those columns by renaming them to First and Last, respectively, and then grouping them under Lesson dates-column, that should be specially created for that purpose.

⛭ Tooltip

By default, the column's header tooltip is empty and its data-source field’s tooltip is shown instead, but for some columns you might want to override that.

Column’s header tooltip by itself is used to clarify/explain the meaning, logic and/or purpose of that column, and in most cases there is no need to override the tooltip when it's set for the column's data-source field. At the same time, there are lots of cases when tooltip is needed to be shown for a column, but is not needed to be shown for its data-source field in the any given record's Details-window, and this is the most typical use case for Header ↴ Tooltip-field, as it allows to set up the column-level tooltip while keeping its field-level tooltip empty.

For example, you can take a look at the 2nd table shown in the previous chapter where multi-level column headings structure is represented: there are First and Last columns, and let's imagine you want to set up Date of first lesson and Date of last lesson as their tooltips, respectively. If so, you have the following ways to go:

1. You can set those tooltips for the corresponding data-source fields, but in that case the tooltips of those fields will be equal to their titles, which may annoy users who will open any Student-record's Details-window and will see those fields having tooltips duplicating titles.
2. You can re-phrase tooltips to be different than their fields titles, i.e. First lesson date and Last lesson date - but it will still make no sense, because the titles of those fields are already self-explaining enough, so there is no need for tooltips for those fields to be shown in any Student-record's Details-window, at all.
3. You can set those tooltips for the columns themselves rather than for columns' data-source fields, and it is much better because those tooltips won't be shown in any Student-record's Details-window, as there are fields having titles that are self-explaining enough.

Also, Indi Engine can automatically use data-source field's title as a column's tooltip, but for this to work all of the following conditions should be met:

1. Tooltip is empty both for the column itself and for its data-source field
2. Column is renamed, but the new title is shorter than 30% of original title length, measured in characters. For example, it will work that way if we rename Presences qty-column into PQ, as 2 / 13 = 0,153 = ~15%

For sure, you can also set up bigger texts for tooltips, but keep in mind that the maximum tooltip width is 400px, which means bigger texts will appear as multi-line tooltips, and it's recommended to not use more than 6 lines of text, which approximately equals to 450 characters.

⛭ Value

This is a group of fields where you can make values to be editable right within the grid cells (i.e. with no need to open Details-window for a specific record), and make those values and/or their tooltips to be optionally composed from themselves and/or from the values picked from other columns of the same record.

⛭ Editable cells

Indi Engine has two ways of how values can be edited straight within the grid cells:

1. First one is cycling-by-clicking and is only applicable for columns data-sourced by single-value foreign-key fields having enumerated values styled with icons or color-boxes, because each enumerated value by itself has a certain order of appearance among the others, so when you click on value's icon or color-box within the grid cell - this value is replaced with the next one among enumerated, if exists, or first one, so that you can cycle through all the possible values by clicking on each of them.

For example, you have a Courses-section grid with Toggle-column data-sourced by Toggle-field having ___ Turned on 

and ___ Turned off as enumerated values styled with color-boxes, and this means you can turn on/off any course in the grid  just by clicking on the color-box in this column. This can be useful if you rely on this on/off state somewhere else, for example in Teacher-entity's Courses-field - for grouping courses in the dropdown by their on/off state, or for filtering out the ones that are turned off.

        <тут воткнуть гифку из раздела Courses где тыкается toggle>

Cycling-by-clicking is just working in any column where it's applicable, so you don't need to explicitly enable that, unless you've previously explicitly disabled that.

2. Second one is cell-editor and it's applicable for columns data-sourced by all kinds of fields except Fields group and File-upload panel. When cell-editor is enabled for a column, it means a special editor component will be shown having size and position to visually cover the entire cell, but the component itself might be different for different columns - depending on the column data type. For example, combobox is used as a cell-editor component for columns data-sourced by foreign key fields, textfield - is for single-line text fields, numberfield - is for numeric fields and so on. When the cell-editor is enabled for a certain column - it's indicated by the blue color of that column's header title.

If you want to start editing a specific cell in a column having cell-editor enabled - you must do that by second click on that cell. This is a synthetic event introduced in Indi Engine especially for triggering the cell-editor components on cells, and this works in a way that assumes that the first click - is for adding a blue dotted border around the cell to indicate that the second click will activate the editor component there.

Second click event is used in Indi Engine for triggering the cell-editor component on a cell because other events are already in use:

1. Single click is already in use for selecting a specific record, i.e. when you click on a record - it becomes selected; if you then do CTRL+Click or SHIFT+Click - this may increase or reduce the number of selected records
2. Double click is already in use for opening Details-window of a record.

Despite there are two ways of cell editing - both are controlled via the single Value ↴ Cell-editor-field, which is a combobox with the following choices available:

1. Turned off

With this choice, cycling-by-clicking is still enabled for all columns where applicable, but at the same time, cell-editor makes sense only for certain columns that you explicitly choose rather than for all columns you have in the grid, and this is the reason why Turned off-choice is the default one. Also, this choice can be useful in cases when you want to force users to open Details-window of a certain record to edit some field for that record, i.e. you don't want that field to be changeable too easily, so you want to reduce the probability of accidental change.

1. Example 1: you have a Teachers-section with Email-column there, and you want teacher email to be editable only in the Teacher-record Details-window, as an accidental typo in the email will lead to that teacher not being able neither to log in nor to receive emails (if any) from Indi Engine app anymore.

2. Example 2: you have a Payments-section with Amount-column there, and, again, you don't want payment amount to be accidentally changed right within the grid, but only via Details-window instead

2. Turned on

You can use this choice when you think cell editing will be useful for a certain column.

For example, if you have Payments-section with Note-column there - you can enable cell editing for values in this column to be easily editable right within the grid. Or, if you have Teachers-section with Courses-column - you can enable cell editing here as well, so that it will be possible to change the courses list for a certain teacher via the combobox component shown in the cell.

3. Turned off, including enum-values cycling-by-clicking

This choice is only applicable for columns data-sourced by foreign-key fields having enumerated values styled with icons or color-boxes, and it is here for cases when you want to not only disable cell-editor for a column, but disable cycling-by-clicking there as well. This might be useful if your app logic needs some more field(s) to be changed in addition to the current one, i.e. you don't want this field to be solely changed, which is the case for any kind of cell editing, as only a certain single cell can be edited at a time.

For example, let's imagine you have Students-section with the following columns:

1. Social platform-column, data-sourced by Signup ↴ Social platform-field having Google and Facebook as enumerated values styled with those platforms icons
2. Social user ID-column, data-sourced by Signup ↴ Social user ID-field represented by a simple textfield where user ID for the selected social platform can be stored

So, in this scenario, it should not be possible to solely change social platform neither by cell-editor, nor by cycling-by-clicking (i.e. clicking on the social platforms icons in the grid column), as the ID should be changed as well to match newly selected social platform, but this is not possible neither via cell-editor nor via cycling-by-clicking, because both are intended to change just one certain single cell at a time.

Keep in mind that all of the above ways of cell editing are only possible when all of the below requirements are met:

1. Save-action must exist in the current section and must be accessible for the current user
2. Field, that is used as a data-source for the column - should not have Mode = Readonly or Mode = Hidden:

1. Neither in Data-source entity of the current section
2. Nor in Adjusted fields for the current section

⛭ Composable cells and tooltips

In Indi Engine it's possible to make cell values and/or their tooltips to be composed from themselves and/or from the values of others cells of the same record, and that is why each Grid column-record has Value ↴ Value template and Value ↴ Tooltip template fields, so that you can define there a templates to be used to render cell value and/or its tooltip.

Template itself is a single-line text string with the support of some basic syntax that allows to setup the following things:

1. ⛭ Columns and delimiters