Storage of static information: lists, action records, sales, plans, timesheets. Price lists, payments, etc.
Storage of large volumes of data (millions of rows).
Features:
Each row in the cycle table is linked to the data of calculation tables related to this cycle.
Used for creating deal tables, periodic reports, timesheets, cyclic plans, etc.
Features:
Each row reflects a set of calculation tables containing individual data for each cycle.
Row unit of recalculation.
Calculation tables in cycles can have field versions — thus allowing evolutionary changes in logic within cycles.
Each cycle row contains information about who has access to view or edit the cycle.
Access to cycles is configured as:
In the user settings, it is possible to grant access to another user's cycles without changing the cycle creators. For example, to temporarily grant one manager access to another's projects.
Calculation tables within a cycle are automatically interconnected and recalculated automatically if data in the linked table is updated.
The cycle row is automatically recalculated after recalculating the tables within the cycle. This can lead to simultaneous access errors when changing multiple cycles.
A calculation table can be linked to only one cycle table. Changing this link is not recommended due to possible data loss and cycle malfunctions.
Transition inside the cycle is done by clicking the button in the cycle table row or by double-clicking the cycle row in a locked field.
You can transition inside the cycle from any Totum table using the linkToTable() action function and passing the id
of the cycle.
example: linkToTable(table: 'calcs_table'; cycle: #cycle_id; target: "self")
Calculations and display of information within cycles. Dynamic display of aggregated lists using the autofill function.
Can be connected inside cycles.
The comfortable maximum size of such tables depends on the server's computational power (as they are calculated entirely).
Recommended size is no more than 15,000 cells (consider that tables within cycles are linked unless specifically configured otherwise).
Features:
Table unit of recalculation.
Possible switching of the recalculation order of the row part (row-by-row/column-by-column).
Can be connected inside cycles.
Have footer and column footers.
Have a prefilter, but are still calculated entirely.
Within cycles, they have versions, as well as a parameter allowing to disable automatic recalculation when data in the source table changes.
Each time it is opened, a new version of this table is created. Thus, multiple users can work with it simultaneously — each with their own set of data.
Dynamic reports, intermediate action tables, configuration tables. Tables providing "drill-down" into data.
Temporary tables are used as modal windows using the linkToDataTable function!
Features:
Tabular unit of conversion.
Possible switching of the conversion order of the lowercase part (row-by-row/column-by-column).
Can be integrated within loops.
Have footer and column footers.
No pre-filter.
Have a unique identifier hash of the temporary table
, which allows accessing data within these tables as long as they exist.
Standard table lifetime after creation is 3 hours.
Can be called by the function linkToDataTable with data passed into the table template.
Can be displayed outside the authorization scheme using anonymous access. The function linkToAnonymTable is used to generate the link.
By default, tables within loops are interconnected.
If a table during the calculation of code takes data from another table in the loop, this information is saved in the loop at the moment the table is saved. The link will be broken as a result of the next recalculation, in which there was no reference from the code to the source table.
When any table in the loop is changed, an automatic recalculation is triggered for those tables for which it was marked as a source. Recalculations are triggered in a chain until the data in the table remains unchanged as a result of the next iteration.
The order of recalculations is cascading. Automatic recalculations are performed after action codes. If the recalculation of several dependent tables is triggered, their recalculation order is determined randomly.
Automatic recalculation can be disabled for a specific table in a specific loop through table versions in loops.
Calculated tables in loops can have multiple versions. Fields in versions are independent of similar fields in other versions of this table. A version can be created based on an existing version, but they are then modified independently of each other.
Each loop contains information about the versions of calculated tables used in it. This allows for incremental editing of logic in loops, as well as using different logic in different loops of the same cycle table.
When a loop is created, it is created with the versions of tables marked by default.
When duplicating a loop, it is duplicated with the versions of the loops preserved, but you can use code on duplication to switch to the necessary versions based on conditions.
Versions are managed through two system tables:
Versions of Calculated Tables — manages available versions, creation of new ones, and "default" settings.
Version of Tables in Loops — manages the use of versions in specific loops, as well as enabling/disabling automatic recalculation in loops.
For the cycle table, there is functionality that allows seamlessly displaying part of another table as a tab within the loop.
This is used to enhance the system's convenience for users, as well as if it is necessary to link a large number of items to the loop (e.g., 50K rows), which is impossible to do by placing these rows in the Calculated Table within the Loop.
Implemented through the function linkToTable.
It is necessary to create one or more Buttons in the Cycle Table, in the name
of which the prefix tab_
must be used.
The button's action code should call the function linkToTable.
= : linkToTable(table: 'table_for_link'; filter: 'fl_for_cycle_tab' = #id)
Binding to the pre-filter in the target table is used. If it is necessary for the pre-filters not to be displayed, they should be set to the Visible to Creator Only mode.
In the target table linked by tab
, it is preferable to prohibit adding if the binding pre-filter is not filled, as well as to use a hidden binding field that receives the value from the pre-filter when adding through the #
code.
The position of the tab
in the loop, as well as visibility for roles, is determined by the corresponding button parameters in the cycle table.
If you set an action code with the
on add
trigger for an action within the created cycle in the cycle table, this action will not be executed, as the action code in this case is executed before the tables in the cycle are created.
The displayed title of the table.
The name of the table by which it is identified in references from the code sections.
It must be unique within a single database schema.
Defines the table type. Possible options:
Simple — data storage.
Cycles — creation of cyclic sets of calculated tables with a similar structure but different content.
Calculated in tree/cycle — table type for performing calculations or dynamic data display.
Temporary — a table that exists for a limited time. It has a unique data set even when multiple users are working simultaneously.
Changing the table type after creation is impossible!
Internal category of the table to simplify its search in the Table List.
Determines in which section and place of the tree the table will be displayed.
For calculations in cycles, this field suggests selecting the table of cycles to which the table will relate.
The number by which the table is sorted in the tree and within the loop. Sorted in ascending order of the number.
It is assumed that table numbers will be greater than 1000, while folders, shortcuts, and links will be less than 1000.
Defines the rules for handling simultaneous access errors to the table.
Non-strict — allows changes even if another user has modified the data in the table after it was opened by the current user. In this mode, when another user changes the table, a notification with the name of the user who made the change is displayed in the upper right corner.
Non-strict without notification — similar to non-strict
, but without showing a warning.
Strict — changes to the table are not possible if there is a change that has not yet been loaded into the browser of the user making the change.
! No change tracking — no change tracking at all. For example, for large cycle tables where a large number of people work without overlapping. This reduces server load by eliminating repeated transaction execution.
! PRO No tracking with notifications — only in PRO, similar to ! No change tracking
, but with notifications that the table was changed by another user.
Auto-update: When a notification about a table change by another user is triggered, it automatically updates the data on the page. If the user has a field open for editing, a panel, or a window at that moment, automatic updating will not occur, and a standard notification about the change in the background will be shown.
PRO Auto-update — only in PRO, similar to Non-strict
+ Auto-update
! PRO No tracking with auto-update — only in PRO, similar to ! No change tracking
+ Auto-update
In a table WITHOUT CHANGE TRACKING, data in the header may be INVALID!
The header in tables "Without change tracking" is recommended to be used only if it contains buttons. If you just need to remove notifications about changes in the table for users, for example, for a cycle table — use "Non-strict without notification".
For all except No change tracking
, automatic restarting of actions and codes applies. Example:
1.1. — At the start, they both took the table change tracking code — updated
.
updated
again.2.1. — After ensuring there were no changes in updated
, it recorded the updated data in Table_1 and changed its updated
.
updated
.3.1. — The updated
check failed because action_1 changed it, so the transaction of action_2 is rolled back and it is restarted with data retrieval again.
A property of calculated tables in a loop/tree and temporary tables that changes the order of recalculating fields in the row part and footer.
Determines the value of which field will be displayed in the header of the panel when right-clicking in the field in the row section.
For cycle tables, it determines the cycle header in the tree when it is opened.
Defines the field by which the rows will be sorted when opened in the web interface.
Do not use fields of type Select and Select tree as sorting fields in tables with a string unit of recalculation! This will lead to their inoperability when filled with a large amount of data!
A parameter that changes the sorting order of fields to sorting by the field n
. The order of recalculating rows of the lowercase part changes — they start to be calculated in ascending order of n
.
How to sort is described here.
You can refer to n
through #n
or select.
When changing the order, n
fields are rearranged 1=1.
When adding between existing rows, the fractional part of
n
increases.If there is a table in the project where there is constant insertion between rows, you need to set up a cron job for periodic execution of the normalizeN function.
Roles that can change the order of rows when sorting by order field is enabled. If not specified, then everyone with edit access to the table can change the order.
A parameter that determines whether to recalculate in tables with a row recalculation unit the rows where n
is greater than the minimum n
of the rows involved in the reorder.
Available for n-sortable tables. Allows displaying a row after adding it in its sort order.
When this setting is enabled in the web interface, the rows will be sorted in reverse order. Larger values will be at the top, smaller ones at the bottom.
Not applicable when there is sorting by order field.
When this option is enabled, it is possible to add rows to the table via the web interface and through the API.
Adding rows to the table is not separated by WEB/API. This can be done through insert_roles.
Roles that will have the ability to add rows to the table. Roles can be used to separate the ability to add rows between WEB/API interfaces!
When this setting is enabled, rows can be deleted from the table via the web interface and API.
Row deletion in the table is not separated by WEB/API. This can be done through delete_roles.
There are 2 types of deletion:
Delete — in this mode, all row data is removed from the database.
Hide — in this mode, the row is not deleted but marked as isdel
. It is no longer displayed in the web interface. Fields that referenced the row display its value in a strikethrough format.
In the Hide
mode, similar to deletion, it is possible to restore the record. To do this, you need to switch the row part to recovery mode.
Modifying hidden data is not possible.
Functions like select when accessing
where
byid
in comparison=
will continue to retrieve data from the deleted row!Recovery != Addition — the trigger on addition does not activate when restoring a row!
Hide does not work for Cycle tables! Even if selected, rows will still be deleted!
Roles that will have the ability to delete rows in the table. Roles can be used to separate the ability to delete rows between WEB/API interfaces!
Roles that will have the ability to restore rows in the table when the deletion type is Hide.
When this option is enabled, row duplication is possible through the web interface. Not available in the API!
When duplicating cycles, a new cycle is created without executing action codes within calculation tables.
Roles that will have the ability to duplicate rows in the table. Row duplication is not possible in the API!
If this code is filled in, it will be executed instead of the standard duplication procedure with the variable $#ids
passed to it, containing the list of id
of the duplicated rows.
If as a result of executing this code, rows are added to the table where duplication was clicked — they will be marked with ✓
.
If this code is filled in, it will be executed as an action code after any change in the table (from the web interface, API, or internal change).
For example, you can block changes in the table if any of the monitored parameters prohibit it. The check will be conducted on the server side.
In the table action code, only sections
=:
anda1=: a2=: a..=:
are allowed. The table action code does not differentiate between triggers — it executes on any change in the table!
When this option is enabled, access to rows and their addition is possible in the form of a panel.
Changes to fields occur at the moment the panel is saved.
When pressing a button in the panel, the button's action code takes
#field_in_row
not from the panel, but from the table row.To get the modified value from the panel before it is saved in the Button code, you need to use the reference
#pnl.field
.
Roles that will have the ability to export the table to CSV.
Roles that will have the ability to upload a table from CSV.
Be careful, when uploading via CSV, conditional locks through formatting of cells, rows, and tables do not work!
A list of fields with indexes created in the database for this table.
Relevant for tables with a string unit of conversion.
Significantly speeds up selections and searches in large tables.
It is not recommended to create more than two indexes on one table.
There are several options for setting access to cycles:
Only your own cycles are visible.
Other people's cycles are visible without the ability to open them.
Other people's cycles are visible with the ability to view their contents.
All cycles are available for editing.
This setting is also combined with the users setting — access to other users' cycles
and supervisor
.
Handles conditional row formatting. The main function is setRowFormat.
It takes precedence over the table formatting section but is secondary to field formatting.
Handles conditional table formatting. The main function is setTableFormat.
It is applied first and takes precedence over all other formatting placements.
Table description. Supports html
.
For internal documentation visible only to the Creator, place the text within the <admin>...</admin>
tag.
If you pass the <hide>
tag before all the text, the panel with the text will automatically be shown in a collapsed state when the table is opened.
If a value other than 0
is set, when a row is deleted in the web interface, a countdown window in seconds will be displayed to the user.
The row will only be deleted if the user waits for the specified time.
Roles that have access to modify data in the table. They override read roles.
Roles that have access to view the table. If a role is specified in edit roles, it does not need to be assigned a read role, as it is overridden.
Roles that need to hide the table from the tree.
Used for temporary and settings tables.
Allows resetting the current field visibility settings for all users to the default
settings.
Used for remote updating of the user interface when the table is modified.
If a user's settings save date is earlier than the date specified in this field, they will be reset to the default value.
Contains field sets eyes.
Including for different versions of calculation tables in cycles.
Manual editing is possible.
Pagination is specified as number/number.
The left part of the fraction indicates the number of rows per page in the desktop version.
The right part of the fraction indicates the number of rows per page in the mobile version.
For desktops, it is recommended to have no more than 500 rows for frequently used tables. For the mobile version, no more than 50.
An empty value or 0/0
means that pagination is disabled.
You can specify the maximum number of items a user can request to display — they are specified using **
:
500/50**5000/500
# means that for desktop the maximum is 5000 and for mobile 500
# in any case, no more than 30000 because with a larger value, a PostgreSQL error on the maximum number of selectable items is possible
In the interface, it is located under the pre-filter and looks like this:
It is possible to specify that the row count should be done in reverse order —
500/50/desc
.Or specify that when opening the table, it should automatically go to the last page —
500/50/last
.
Only in PRO
Allows you to change the number of rows loaded on the page, in addition to those loaded to fill the screen.
Specified as a number
. Indicates the loading limit above and below the screen.
For example, if the screen can display 60 rows, and you specify 200, then:
if the screen is at the top of the table, a maximum of 260 rows will be loaded
if the screen is in the middle of the table, a maximum of 460 rows will be loaded
if the screen is at the end of the table, a maximum of 260 rows will be loaded
The more rows the browser processes, the greater the load on the client computer! If you want to extend the range of loaded rows, select the value of this parameter empirically, based on the computers you have for each table.
Only in PRO
A set of settings that allows you to display the table as cards or kanban columns.
👆 a parameter h_panels_max_count
has been added to the settings — the maximum number of panels after which the table will be forcibly switched to row display mode.
If the card height or row height is left empty, the height of the card and row will be automatic and adjust to the content.
Only in PRO
Width in pixels. If set, it rotates the table, turning rows into columns with the specified width.