Edit form

1. General information

• An edit form is a graphical interface used to work with a single database record. It is used either to create a new record in the database or to edit an existing one.
• Each edit form has exactly one associated database table that stores the user data entered in the form. Its actual name is defined by the form identifier. Identifiers of user-defined forms normally start with the “ng_” prefix; system forms do not use this prefix.
• The structure of a standard associated database table is created and subsequently maintained automatically from the edit form and control configuration. Manually maintained database structures, such as the In-Memory tables and database views described below, are exceptions.
• Each associated database table contains a set of system database columns that form the foundation of the application logic:
  • “id” – the primary key of the database record, with the data type “int NOT NULL” or “long NOT NULL” depending on the form configuration.
  • “system” – a system record flag. The value “True” indicates a record that cannot be deleted (for example, system user records in NET Genium).
  • “pid” – the identifier of the parent database record, used for hierarchical relationships.
  • “pform” – the identifier of the edit form in which the parent record is located.
  • “userid” – the identifier of the user who created the database record and is its owner.

1.1. Edit form controls

• An edit form consists of database controls and visual controls.
  • A database control is always associated with a single column in the underlying database table, into which values entered by the user are stored. To be meaningful, an edit form must contain at least one database control.
  • Visual controls do not have a database column of their own. They are used for presentation, navigation, or interaction and may run scripts or operations that create, modify, or delete other database records. These include headings, data grids, buttons, graphical separators, and other decorative elements.
  • Every edit form automatically contains the “ActionButtons” control, which provides three essential buttons: “Save”, “Delete”, and “Back”. A detailed description of this control is available in a separate guide Edit form – ActionButtons.
• Controls in an edit form are typically arranged vertically but may also be visually organized into multiple columns using control anchoring. Users can navigate between database controls using the “TAB” key to move forward and “SHIFT+TAB” to move backward.
• Edit form controls can be accessed via JavaScript to dynamically change their properties, behavior, or values. For database controls, it is possible to read and set values of text fields, drop-down lists, and similar elements, provided that the control identifier in the HTML object model is known.

1.2. Permissions to enter an edit form

• An edit form is usually opened through navigation elements located on view pages or within other edit forms. A user can also be redirected to it by a server function (“SCHEDULEFORM”) or an external function. The form can also be opened through the direct URL “Form.aspx?form=<form ID>&id=<record ID>”, so security must never rely on hiding the URL; display and editing remain subject to permissions, ownership, and record locking.
• To create a new database record, a user can open an edit form in several ways:
  • Using a button placed on a view page or another edit form that redirects the user to a specific edit form. This is configured in the properties of the “Button” control or in its script using the “SCHEDULEFORM” function.
  • Via a view table that displays data from the edit form. This option is enabled by allowing the “New record...” icon in the view table settings.
  • Through other visual controls such as calendars, multi-resource planners, timetables, Gantt charts, or tree structures, provided that creating new records is enabled in their configuration.
  • By direct navigation from a view page that is configured to redirect the user to a specific edit form.
• To edit an existing database record, a user can open an edit form:
  • By clicking the pencil icon in a view table.
  • Through visual controls that allow opening record details, such as clicking an item in a calendar, map, Gantt chart, or tree structure.
  • Using a button with a “SCHEDULEFORM” script that opens a specific database record.
  • Via a view page configured to always open the first record of a given edit form.

1.3. Permissions to display edit form content

• An edit form itself does not have an independent display permission. Its visibility is determined by the permissions of its internal controls.
• An edit form displays only the controls to which the currently logged-in user has access. If the anonymous user has access to no control, the login screen is displayed instead of the form; a logged-in user gets an empty form in such a case. If the “DenyLogin.txt” file exists in the “Config” directory, the login screen is displayed only for access from the IP address “127.0.0.1”; otherwise the anonymous user also gets an empty form. A detailed description of the file is provided in the separate guide NET Genium settings.
• Each control can define specific user groups or individual users who are allowed to see and use it. Other users will not see the control and cannot interact with it.
• A control without any configured permissions is visible only to users with administrator rights – permissions of the edit form or the application are not inherited.
• If a user creates a new database record without having permission to some database controls, the corresponding database columns will be stored with the value “null”.
• When an existing record is saved, values of database controls for which the user has no permission are not overwritten and remain unchanged.

1.4. Record ownership

• Each database table contains a “userid” column that stores the identifier of the user who created the database record and is considered its owner.
• By default, the owner of a new record is the signed-in user who saves the record in the edit form. JavaScript of the edit form can change the owner of a new record before it is saved – the “#owner#” variable returns a reference to the hidden field with the ID of the record owner. For an existing record, the owner is always read from the database and a change of this field has no effect.
• Database records that were imported or created by an external application may not have the “userid” value set. Such records are considered to have no owner.
• The owner of an unowned record becomes the user who first opens the record in an edit form and saves it.
• When opened, an unowned record is treated as a record of the currently logged-in user. If “Editing rights” is set to “Owner or co-owner of the record”, any user with access to the controls of the form can therefore edit and save such a record.
• Only saving the record in an edit form sets its owner. Bulk changes and bulk deletion in a view table treat an unowned record as someone else's record; editing a value directly in a view table cell behaves the same as in the edit form.
• The anonymous user has a single user account “Anonymous” in NET Genium, so a record created by an anonymous user is owned by this account and, from the ownership perspective, belongs to all anonymous visitors. For public forms, it is advisable to keep “Editing rights” set to “Co-owner of the record only” and to add the users who process the records to the co-owners.

1.5. Record co-ownership

• In addition to a single owner, database records may have one or more co-owners.
• Co-owners can be individual users or entire user groups.
• Co-ownership is not defined per individual record but at the level of the database table, i.e., the edit form as a whole.
• Ownership or at least co-ownership is required to edit and save an existing database record; the exact behavior is controlled by the “Editing rights” setting.
• If a user is neither the owner nor a co-owner of a record, they are not allowed to modify it. A user with administrator rights is an exception.
• Co-ownership has no effect on the creation of new records. The owner of a newly created record is the user who saves it in the edit form, unless JavaScript of the form changes it (see “Record ownership”).

1.6. Permissions to display control values

• Visibility of database control values may be governed by record ownership or co-ownership.
• The permission to display a control value is configured directly in the properties of the control.
• A control can be configured in one of the following ways:
  • the value is visible to all users (default),
  • the value is visible only to the owner or co-owner of the record.
• In an edit form, a control whose value is visible only to the owner or co-owner is displayed to whoever may edit the record – a user with administrator rights, a co-owner, and the owner if “Editing rights” is set to “Owner or co-owner of the record”. Other users do not see the control and cannot view or enter its value.
• Such a control cannot be displayed as a view table column and is not exported from a view table. In view table details, in a tree, and in a kanban, its value is displayed to a user with administrator rights and to the owner and co-owner of the record, and for an unowned record to all users. A print template always prints the value.
• In the body of an email sent by the “Send email” script command, the value of such a control is displayed only if the user who ran the script has administrator rights or is the owner of the record, or if the record has no owner. If the script is run by a co-owner of the record, the value is not displayed; the recipients of the email play no role. For a record that is synchronized to another instance, the email is sent only after the record is transferred, and the decision is made by the user under whom the synchronization is being sent at that moment.
• If such a control is selected as the “Resource” column of a Kanban control, the cards are placed in the columns of the board according to its value regardless of this restriction, and if the resources of the board are entered manually and the list is empty, its values are displayed as the names of the board columns to all users of the board.
• The setting protects the display of the control, not the value used in the page code: a control identifier used in JavaScript or in the “HTML” control is replaced with the value from the database for a user who cannot see the control.

1.7. Permissions to save a record

• Permission to save a database record requires rights to at least one database control and ownership permission according to the “Editing rights” setting. An administrator may save the record outside this ownership limitation.
• Edit permission is configured directly in the properties of the edit form.
• An edit form can be configured in one of the following modes:
  • both the owner and co-owner are allowed to edit,
  • only the co-owner is allowed to edit (default setting).
• Scripts of buttons and events of the edit form write to the database regardless of the permissions of the user who ran them – who may perform the action is determined by the permissions of the button.

1.8. Permissions to delete a record

• Only an existing non-system record may be deleted, and only when the user is allowed to edit the form and has access to at least one database control in it.
• By default, the user must have permission for all database controls in the edit form.
• If the “Always allow deleting to the owner or co-owner of the record” option is enabled in the “ActionButtons” control, an authorized owner or co-owner may delete the record even without permission for some database controls.
• A record with the “system” flag cannot be deleted even when this option is enabled.
• If the user is not allowed to delete the record, the “Delete” button is inactive. For a new record that has not been saved yet, the “Delete” button is always inactive.
• Deleting a record deletes neither its nested records nor the files of its attachments.

1.9. Control identifiers

• A control identifier represents a reference to a database control in the HTML object model and simultaneously defines the name of the database column where the entered values are stored.
• The identifier is derived from the control name and starts with the prefix “ng_”. System controls do not use the “ng_” prefix.
• An identifier derived from the control name is shortened to at most 50 characters including the prefix, for the Firebird database version 3 and older to 31 characters. If the derived identifier is already used in the database table of the form, a number is appended to its end.
• The control identifier is available on the “Administration” tab in the control properties.
• Identifiers can be used:
  • in JavaScript executed in the web browser,
  • in server-side scripts,
  • in database conditions and joins,
  • in the “HTML” control,
  • in print templates.

1.10. Record locking

• Database records opened in an edit form can be locked so that only one user can edit them at a time.
• The user who opens a record first and is allowed to modify it automatically locks it.
• The lock is automatically renewed while the user is working in the edit form. It is released immediately when the user leaves through the “Back” button or a form redirect; if the browser tab is closed, the browser crashes, or the connection is lost, the lock expires after the configured period from its last renewal.
• The lock duration is configured in minutes in the edit form settings and is primarily relevant in case of technical issues such as browser tab closure or connection loss.
• Locked records are indicated in view tables by a lock icon showing who locked the record and until when the lock is valid.
• Locked records can still be opened by other users, but the edit form is displayed in read-only mode.
• A user with administrator rights does not respect the lock of another user – they can edit and save a locked record.
• The anonymous user does not lock records, but the lock of another user applies to them.
• The record is locked only if the user has rights to at least one control of the form and is allowed to modify the record. A user for whom the form opens as read-only (without the right to modify the record or to any database control, or with the record locked by another user) does not lock the record; a lock held by another user is reported to them, though. If the form is disabled only by the “OnAfterOpen” event script with the “DISABLEFORM” function, the record is locked in the same way as in a form that can be modified.
• The lock applies only in the edit form. Editing a value directly in a view table, bulk changes, data import, scripts, and the “form_Save” and “control_Save” functions write even to a record locked by another user.

1.11. History and change tracking

• Each edit form has an automatically generated history database table named “<form identifier>_history”.
• The history table contains copies of the form's user-defined database columns and its own system columns:
  • “id” – history record ID,
  • “date” – date of the change,
  • “userid” – login name of the user who performed the change,
  • “action” – identifier of the change source, such as a script, button, or service; changes written by a data import into a view table, by synchronization or by a restore from history leave it empty; for changes that did not go through submitting the edit form, it holds the value:
    • “ngef.aspx” – a change made by an external function called from JavaScript,
    • “Save.aspx” – a change saved without submitting the edit form: by editing a value directly in the view table, by the “form_Save” and “control_Save” JavaScript functions, or from a matrix,
  • “changedid” – identifier of the affected record,
  • “pform” and “pid” – parent relationship of the affected record (part of the snapshot used to restore a deleted record),
  • “userid2” – owner of the affected record, stored separately from the change author in “userid” (used to restore a deleted record),
  • “created” – record creation flag (“x” = created via form, script, external function, MCP server or synchronization, “i” = via data import into a view table, including an update of an existing record imported by ID, “r” = restored from history),
  • “deleted” – record deletion flag (“x” = deleted, “r” = deletion reverted by restore).
• When a record is created, the values of user-defined columns are stored in history in the same way as in the main database table.
• When an existing record is updated, only changed user-defined columns are stored in the history row. Columns that were not changed by that particular update remain without a stored value in the history row (database value “null”).
• If a field value is changed to database NULL, NET Genium stores it in history using an internal placeholder value according to the column data type, so it can be distinguished from a column that was not changed at all.
• A data import into a view table is an exception: it stores in history all columns written to the record by the import, even if their value has not changed, and it does not distinguish database NULL by an internal placeholder value.
• When a record is deleted, the last values of user-defined columns are stored in history — this full snapshot enables later restoration of the deleted record.
• When history is displayed, some special stored values are shown as three dots “...” with a tooltip that determines their meaning: “Empty string” means changing a text field to a zero-length text string, “Database value NULL” means changing the field to database NULL, and “ID 0” for a ForeignKey control with the “Show value in the view table without the need to join” box checked and the tooltip “0” for the File and Image controls outside the row with the “created” flag set to “x” mean a stored zero value, i.e. no selected record, or no file or image, respectively. Three dots “...” by themselves therefore do not mean “unchanged”.
• When history logging is enabled, creating, updating, or deleting a database record generates a corresponding history entry. An update that does not change any value creates no history entry, except for a data import into a view table.
• Changes made by the “DELETEDATA” server function, by the “TRUNCATE TABLE” commands in the edit form settings, writes and deletions via the MCP server without history enabled and direct changes in the database are not written to history.
• Restoring a deleted record from history creates a new history entry with the “created” flag set to “r”, and the original deletion entry gets the “deleted” flag set to “r”. The restore is written to history even for an edit form with history logging disabled. If a record with the same ID exists in the database table, the restore is not performed.
• History logging is enabled by default and can be disabled in the edit form settings.

1.12. Database table synchronization

• Synchronization is used to maintain consistent copies of database tables across multiple NET Genium installations.
• Both one-way and two-way (multiple master) synchronization are supported.
• In two-way synchronization, changes are applied in the same order in which they were initiated on the source server.
• Synchronization is not available in NET Genium Online – the link to its settings is not displayed in the edit form menu.
• Changes are not forwarded: a change received from another installation is not sent anywhere else. If a record is to get from server A via server B to server C, server A has to be linked directly to server C as well.
• A change received by synchronization is written directly to the database table on the remote side: it does not run the save or delete scripts, validation, default values or recalculation of “AutoSum” controls of the remote edit form. Logic that has to run in both installations therefore has to be transferred as data.
• Changes wait in a queue shared by all forms and all linked servers and are sent strictly in the order in which they were made. If a change cannot be sent (unreachable server, missing form on the remote side, database error), the transfer of all further changes stops until the cause is removed or until the change is deleted from the queue. In the reports, only the first displayed row – without a search, the first row of the queue, i.e. the transfer of the oldest change to one link – can be deleted in the view of the “ssynchronization” system table, and the whole queue of one link in the “Edit forms (Synchronization)” report. The emails of a change are carried by the first row of its group in the queue, so deleting this row discards them as well – on its own or together with the whole queue of a link. The next attempt takes place after 2 minutes at the earliest.
• A column that does not exist in the remote edit form is skipped without a message when received; a value that cannot be converted to the data type of the remote column is skipped and written to the “Warnings” log of the receiving side. The transfer of the other columns and of the queue continues, so after changing the identifier of a control or deleting it on the remote side, the columns in the synchronization settings have to be adjusted.
• A record has the same ID in all synchronized installations. A new record therefore gets an ID agreed with all remote sides before it is sent, and is renumbered locally if necessary. Renumbering rewrites the ID of the record in its history, in pending emails and in the synchronization queue. It corrects the link of nested records (“pid”) only in the form itself, in forms opened from it by a button of the “Open an edit form” type and in forms whose records are displayed by a non-statistical view table of this form with the “Show only nested records” option checked; nested records of other forms remain linked to the original ID on the sending side. Foreign keys referring to the renumbered record are not corrected.
• An ID is negotiated only for a record that is new when it is saved. An existing record – for example a record created before the synchronization was set up, or a record that satisfies the synchronization condition only after this edit – is sent under its own ID and only with the columns changed by this save. On the remote side, these columns are written to the record with the same ID, even if it is a different record, and its link to the parent record (“pid”, “pform”) and, when users are synchronized, its owner are overwritten as well; if no record with this ID exists there, it is created with these columns only. All synchronized columns are sent by the “Synchronize” button or by one-time synchronization.
• Foreign keys, the link to the parent record (“pid”) and the record owner are transferred as numbers, so the referenced records must have the same ID in all installations. The record owner is transferred only if users (the “User” form) are synchronized to the same server as well; otherwise a record created by synchronization remains without an owner on the remote side and the owner of an existing record does not change. The parent form of nested records must be linked to the same server.
• The agreed ID is reserved on the remote sides by inserting an empty record (only with the link to the parent record), which is filled with data by the transfer. If the reservation fails on one of the remote sides or the local renumbering fails, the next attempt negotiates a new ID and the empty records inserted by the previous attempt remain on the remote sides; an empty record also remains if the change is deleted from the queue before it is transferred. Such records have to be removed manually.
• Attachment files are transferred together with the record and a new attachment is always created on the remote side. If the attachment file is missing on the sender's disk, the remote side keeps its original value.
• Emails sent by the “OnBeforeSave” and “OnAfterSave” scripts of a synchronized record are sent only after the record has been successfully transferred to all remote sides. If the record is deleted before its change is transferred, the emails of this change are not sent.
• Deleting a record is transferred to the remote side, but only the record itself is deleted — neither nested records nor attachment files. A new record deleted before it was sent is not transferred to the remote side at all.
• Changes made by a data import into a view table, by restoring a record from history, by the “DELETEDATA” server function, by the “TRUNCATE TABLE” commands and by writing or deleting via the MCP server without history enabled are not queued.
• In admin mode, the edit form of a saved synchronized record offers the “Synchronize” button. The button saves the record in the same way as the “Save” button, including the “OnBeforeSave” and “OnAfterSave” scripts, and queues all synchronized columns, not only the changed ones; the synchronization conditions of the record and of the columns still apply. The button is not displayed for a new record and in an edit form with the “Save” button hidden.

2. List of tabs in the edit form settings dialog

• General – Setting general properties
• Other – Primary key settings, locks, change tracking and javascript
• Help – Set up floating help text and group controls
• Editing rights – Rights settings
• Rights of child objects – Setting the rights of child controls
• Administration – Setting other properties

2.1. “General” tab

2.1.1. Name

• The name of the edit form ideally determines the name of one database record, expressed in a single number, which is stored in the database table associated with the form.
• The name of the edit form is displayed in the title of the web browser tab.

2.1.2. Dictionary

• The dictionary displays a list of application group names, applications, categories, view pages, edit forms, and controls used throughout the application.
• The dictionary search is used to suggest the correct name for the edit form and to maintain the consistency of the nomenclature throughout the application.

2.1.3. Options

• Tab General + Other
  • Checking this box determines whether the “Tab” and “Other” tab controls should also be created when creating a new edit form.
• Change tracking + Watcher
  • Checking this box determines whether change tracking controls should also be created when creating a new edit form:
    • “History” control
    • “Watcher” control
      • Created by
      • Created on
      • Modified by
      • Modified on

2.1.4. Enter the columns of your new table

• The “Enter the columns of your new table” field enables the creation of new controls in the edit form.
• Individual column names are entered line by line, separated by the Enter key, each line represents one column of the table.
• Empty lines are skipped. The column name is truncated to 50 characters and its first letter is converted to upper case; the specified data type does not count towards this length. At most 100 columns are created, further lines are not used.
• A data type may be specified after the column name, written after a colon immediately following the name; the space after the colon is optional. Instead of the English key, the name of the data type in the language of the user can also be written (for example “Whole number”); neither letter case nor diacritics matter:
  • string
    • Wizard button for quick selection of this type: Text string
    • Target control: TextBox
    • Data type: Text string
    • Width: 150 px
    • Maximum length: 100 characters
  • integer
    • Wizard button for quick selection of this type: Whole number
    • Target control: TextBox
    • Data type: Integer
    • Width: 150 px
    • Maximum length: 50 characters
    • Alignment: Left
  • long
    • Target control: TextBox
    • Data type: Big whole number
    • Maximum length: 50 characters
  • double
    • Wizard button for quick selection of this type: Decimal number
    • Target control: TextBox
    • Data type: Decimal number
    • Width: 150 px
    • Maximum length: 50 characters
    • Alignment: Left
  • currency
    • Target control: TextBox
    • Data type: Currency
    • Maximum length: 50 characters
  • date
    • Wizard button for quick selection of this type: Date
    • Target control: TextBox
    • Data type: Date
    • Width: 150 px
    • Maximum length: 50 characters
  • file
    • Wizard button for quick selection of this type: File
    • Target control: File
  • image
    • Wizard button for quick selection of this type: Image
    • Target control: Image
• Specifying a data type is optional; if no data type is provided, the default type is string.
• An unrecognized data type is not used: a text string is created and the colon with the text after it remains part of the column name.

2.1.5. Add new columns

• New columns can be added to an already created and saved edit form by checking the “Add new columns” option.

• The names of the new columns are entered into the “Enter new columns” field, with each line representing one column.

• The placement of inserted controls in the form is governed by whether a specific position is marked before editing the edit form, or before pressing the gear icon:
  • Without marking – inserting controls at the end of the edit form; if the last control of the form is the “Space” graphic separator, the controls are inserted before it
  • With marking of the location using a horizontal line – inserting controls at a predetermined position

2.2. “Other” tab

2.2.1. Primary key

• The primary key specifies the data type of the primary key – the database column “id”, which is part of every database table in NET Genium.
• The data type of the primary key can be changed from Integer to Long at any time.
• A reverse change from Long to Integer is performed only if all primary key values in the database table and in the history table fall within the range of the Integer data type; otherwise the primary key remains Long. A confirmation is requested before the change, because the data conversion may take a long time.
• Before changing the primary key to Long, it is important to ensure that external functions, services, or other applications that work with the database table function properly. These are mainly DataSaver or DataSaverSynchro objects that must be changed to DataSaver2 and DataSaverSynchro2.
• Records with an ID greater than 2,147,483,647 are not synchronized – their changes are not added to the synchronization queue.

2.2.2. Record locking

• Database records opened in the edit form can be set so that only one user can edit them at a time.
• The user who opens the database record first and is allowed to modify it automatically locks the record. While working in the edit form, the lock is automatically extended. It is released immediately when the user leaves through the “Back” button or a form redirect; if the browser tab is closed, the browser crashes, or the connection is lost, the lock expires after the configured interval from its last extension.
• The lock belongs to the web browser window in which the record was opened. If the same user opens the record in another browser as well, the edit form is shown there read-only, just as it is to other users. If the user opens it in another window of the same browser, the form is blocked right after opening, just as when the lock is taken over as described below, and a message says so. In both cases the tooltip of the lock icon in the view table tells the user that the record is open elsewhere. A lock left behind by a closed window is released for the other windows of the same login, too, only after the configured time interval has elapsed.
• If another window or another user takes over the lock in the meantime, typically after the lock expired while the computer was asleep, the original window detects it at the next automatic lock extension, says so in a message and blocks any further editing of the record in it: it disables the buttons for saving and deleting the record as well as all buttons of the edit form controls, disables mass editing in the view tables of the form and turns off autosave. The “Back” button keeps working. The server checks the lock when the record is saved or deleted as well, so neither goes through from such a window even if the user attempts it before the window detects the takeover; a message about the locked record is shown instead.
• Record locking is defined in the edit form settings by specifying a time interval in minutes during which the lock should be active. The length of the time interval plays a role only in case of technical problems of the user, due to which the lock cannot be extended automatically during the entire time the user works with the database record in the edit form. Typical issues include opening a different web browser tab, closing the current tab with a cross, launching a different application on a mobile phone, or internet outages. Therefore, in case of technical problems, the lock will not be released automatically until a selected time interval has elapsed since the last automatic lock extension. The length of the time interval therefore determines the period for which the lock will be active even in the event of a connection failure between the client and the server.
• Restarting the web application releases all locks (with multiple instances over one database only the restart of the main instance; the other instances release them no sooner than 6 hours after the previous restart). Logging out a session by an administrator or a user account administrator releases the locks of that session immediately; a regular logout or session expiry does not release the locks – they expire only after the configured time interval has elapsed.
• Locked records have a lock icon in the view table instead of the pencil icon that is used to open the database record. The lock icon contains a tooltip with information about who locked the record and until when the lock is active. Even so, the database record can still be opened using the lock icon; other users can only read the edit form with the locked record without editing it.

2.2.3. Options

• Log opening records
  • Checking this box determines whether each opening of a database record in the edit form should be recorded in the change tracking history.
  • A history record is created on every opening of an existing record, even if the user does not save the record.
  • Opening is logged only if history logging of records is not disabled and the user has rights to at least one control of the edit form.
• Disable history of records
  • Checking this box determines whether database record history logging should be disabled.
  • Disabling the logging completely, or even temporarily, is recommended before bulk editing or deleting database records, where each change or deletion of a database record creates one record in the change tracking history.
  • Disabling the logging applies only to new changes; previously written history records are kept.
• Disable JavaScript
  • Checking this box determines whether to disable the generation of the content of “JavaScript” controls. In addition, the event code of “CheckBox” controls that calls the “chb_Display” function is not run when the form is opened, and the button for clearing the value of “TextBox” and “ForeignKey” controls is displayed as a button instead of an icon.
  • JavaScript in the events of controls and in the “Client” field of buttons is not disabled by this setting.
  • The JavaScript of the “ActionButtons” control buttons (“Save”, “Delete”, “Back”) is not disabled by this setting.
  • This option is used in situations where the edit form is looped by inappropriate javascript. In some cases, it is not even possible to open the edit form settings in the usual way, and it is necessary to use reports to do so. A detailed description of the reports is provided in the separate guide Reports.

2.3. “Help” tab

2.3.1. Width of floating help

• The width of the floating help determines the width of the help box for the edit form located in the upper right corner of the form. This box is displayed independently of the vertical scroll in the edit form.
• The floating box also includes the contents of all “RichText” and “HTML” controls with the “Floating help in the edit form” check box selected. This content is located behind the help of the edit form in the order that these controls have in the edit form.
• If the width is not filled, the default width of the floating box of 200 pixels is used.

2.3.2. Options

• Automatic grouping
  • If “Automatic grouping” is checked, a bulleted list of all help controls located on the same row will be automatically generated in the help column of each edit form control, with the option to click the bulleted list item and display the help text.
  • If “Automatic grouping” is not checked, the help for controls to the left of snap-on controls is not displayed.
  • Help grouping is used for controls that have the “Snap to previous control” check box selected.

2.3.3. Help

• Help is the text displayed in the upper right corner of the edit form inside the floating box.
• The floating box also includes the contents of all “RichText” and “HTML” controls with the “Floating help in the edit form” check box selected. This content is located behind the help of the edit form in the order that these controls have in the edit form.

2.3.4. Notes

• Notes are used to enter any text intended for the application administrator.
• Calls to server functions that control the behavior of the edit form are placed in the notes:
  • CENTER() – centers the edit form
  • DISABLEAUTOFILL() – prevents the web browser from filling in text fields automatically
  • DISABLEPAGETOOLS() – hides the icons in the upper right corner of the form
  • FULLAJAXMODE() – the form uses ajax requests instead of submitting the form
  • LABELSINSIDE() – controls display their label inside the control
  • LAYOUT(id) – uses a different layout for the form
  • LEFTALIGNMENT() – aligns the names of controls in the left column to the left
  • LOWRESOLUTION() – displays the form on a mobile device for a small screen; the small screen then stays turned on for the user until the end of the session
  • MARGINS(top, right, bottom, left) – sets the margins of the form
  • NOBACKGROUND() – controls do not use the colored background of the left column with names
  • WEBFORM() – controls use the reverse design of a web form without the colored background of the left column
• Only the listed functions are evaluated from the notes when the form is opened; the rest of the notes, including other server functions, is not evaluated. A detailed description of server functions is provided in the separate guide Server functions.
• The text “DEBUGPICKER” in the notes turns on writing the progress of taking over values from the picker to the browser console. A detailed description of the picker is provided in the separate guide Picker.
• The definition of the database view is placed in the notes if the edit form is set to read data from the database view.

2.4. “Editing rights” tab

2.4.1. Co-owners of the records

• Record co-owners define a list of user groups and users who extend ownership of database records. In addition to the owner of the record, i.e. the user who created the database record, they extend ownership by other users who automatically become co-owners of all records in the database table.

2.4.2. Editing rights – options

• Owner or co-owner of the record – database records in the edit form can be edited by the owner or co-owner of the record.
• Co-owner of the record only – database records in the edit form can be edited only by the co-owner of the record.
• A user with administrator rights may edit the record regardless of the “Editing rights” setting.

2.5. “Rights of child objects” tab

• The list of rights on this tab is used only for a bulk change of the rights of the edit form controls. It applies only when the edit form is saved with one of the options below checked, and the list itself is not stored – the next time the edit form settings are opened, the list is empty.
• Which user groups and users see a control on the edit form and its values elsewhere in the application is determined by the rights set on the individual controls.
• The edit form has no separate display permission. It opens for a user who has permission to at least one of its controls; controls without permission are not displayed in the form.

2.5.1. Options

• Replace rights in all child objects - Checking this box determines whether the rights settings in all child controls should be overwritten to the user groups and users selected in the list on this tab when the edit form is saved.
• Add selected rights to all child objects - Checking this box determines whether all selected user groups and users should be added to all child controls when saving the edit form.
• Remove selected rights in all child objects - Checking this box determines whether all selected user groups and users should be removed from all child controls when saving the edit form.

2.6. “Administration” tab

2.6.1. Location

• Select the application in which the edit form is located.
• The drop-down list contains all applications.
• Edit forms located in the “Settings” system application may not be moved or deleted.

2.6.2. Identifier

• The identifier specifies the name of the database table in the database in which the user data filled in by the user in the edit form is stored.
• The identifier is derived from the name of the edit form. It starts with the prefix “ng_”, and also contains the alphanumeric characters used in the edit form name (system edit forms do not contain “ng_”). When changing the name of the edit form, the “Correct” button is available, which is used to correct the identifier and thus rename the database table in the database. For clarity and elimination of possible misunderstandings, it is recommended to keep the identifier in accordance with the name of the edit form. If external applications also access the database and, for example, read or write data to the database table of this edit form, it is necessary to schedule the change of the identifier until a suitable time.
• The “Correct all” button is available to automatically correct the identifiers of all database controls of the edit form.
• An identifier derived from the edit form name is shortened to at most 50 characters including the prefix, for the Firebird database version 3 and older to 19 characters. If the derived identifier is already used in the database, a number is appended to its end.
• When the identifier is changed, its occurrences in the SQL, SQLARRAY, COLORLEGEND and EXPORTDATA server functions are corrected automatically. Occurrences in HTML and JavaScript controls, in print templates and in external functions are not corrected and must be edited manually.
• Read/write data from the database table using a memory optimized table
• For SQL Server only
  • For the Firebird database, the box is not displayed. If the edit form takes over the checked box, for example by an application import, NET Genium ignores it for the Firebird database; service utilities such as SqlBackup, however, evaluate it for the Firebird database as well.
  • In-Memory tables are database tables located in the operational memory, which are suitable for frequent writing of data – especially for creating new records (INSERT) or updating existing ones (UPDATE).
  • In-Memory tables are not suitable for troubleshooting database query processing speed while reading data (SELECT). The solution to these problems is always to set the indexes correctly.
  • Checking this box determines whether a database table with the same identifier as the edit form should be used to read and write data, with only the word “_memory” at the end of the name.
  • In-Memory tables must be created manually. For this purpose, it is possible to use the command “CREATE ng_book_memory” from the drop-down list located below the check box. This command displays a database query to create a new In-Memory table with the same structure as the edit form, and attempts to create the database table immediately.
  • In-Memory tables do not allow additional changes to the database structure. It is necessary to delete the old table first, and then create a new one with an updated structure. For this purpose, it is possible to use the command “DROP ng_book_memory” from the drop-down list located below the check box. This command displays a database query to delete an In-Memory table, and attempts to delete the database table immediately.
  • Before deleting In-Memory tables, it is important to back up the data stored in these tables, and then restore that data. For this purpose, it is possible to use the command “EXPORT DATA FROM ng_book_memory TO 'Backup\ng_book_memory.xml'” from the drop-down list located below the check box, followed by “IMPORT DATA TO ng_book_memory FROM 'Backup\ng_book_memory.xml'” or “IMPORT DATA TO ng_book_memory FROM ng_book“.
• Read data from the database table using a view
  • Checking this box determines whether a database view with the same identifier as the edit form should be used to read the data, with only the word “_view” at the end of the name. It is not possible to write data to views, so it is recommended to hide the “Save” button in these edit forms. An error occurs when trying to save data to a view.
  • Views must be created manually. For this purpose, it is possible to use the command “CREATE ng_book_view” from the drop-down list located below the check box.
    • This command displays a database query to create a new view with the same structure as the edit form, and attempts to create the database view immediately.
    • The view created by this command has the same structure as the edit form, and therefore it is necessary to modify its definition (CREATE VIEW) additionally.
    • It is advisable to save the resulting definition in a note of the edit form, where NET Genium will search for it the next time the “CREATE ng_book_view” command is run, and run it in this wording.
  • Views do not allow additional changes to the database structure. It is necessary to delete the old view first, and then create a new one with an updated structure. For this purpose, it is possible to use the command “DROP ng_book_view” from the drop-down list located below the check box. This command displays a database query to delete the view, and attempts to delete the database view immediately.
• In NET Genium Online neither the “Read/write data from the database table using a memory optimized table” nor the “Read data from the database table using a view” field is displayed – In-Memory tables and database views are not available in the cloud.

2.6.3. Commands

• CREATE REPORT FROM ng_book – Creating a report on the length of strings stored in the edit form
• CREATE ng_book_memory – Create In-Memory table
• IMPORT DATA TO ng_book_memory FROM 'Backup\ng_book_memory.xml' – Import data into In-Memory table from XML file located in the “Backup” directory
• IMPORT DATA TO ng_book_memory FROM ng_book – Import data into the In-Memory table from the main database table of the edit form
• EXPORT DATA FROM ng_book_memory TO 'Backup\ng_book_memory.xml' – Export of data from the In-Memory table to an XML file located in the “Backup” directory
• DROP ng_book_memory – Delete In-Memory table
• CREATE ng_book_view – Creating a view
• DROP ng_book_view – Delete view
• TRUNCATE TABLE ng_book + ng_book_history – Delete all data in the database table, including history records, and set the primary key counter to an initial value of 1
• TRUNCATE TABLE ng_book_history – Delete all history records, and set the primary key counter to an initial value of 1
• RECREATE TABLE ng_book + ng_book_history – Data backup and re-creation of database tables, including subsequent data import
• The In-Memory table commands are offered only for the MSSQL database.
• In NET Genium Online the drop-down list of commands is not displayed – none of the commands listed above is available in the cloud.

2.6.4. Index 1

• Setting the index to the “pid” database column or the associated index to the “pform” database column along with the “pid” column.

2.6.5. Index 2

• Setting the index to any list of database columns of the edit form.
• In the text box located below the check box, it is possible to define the names (identifiers) of all columns that are to be in the federated index – they should be part of the index key.

2.6.6. Delete history older than

• Setting the number of months during which it is necessary to keep the history of database records of this edit form.
• If the number of months is not filled in, the default setting of 6 months is used.
• The setting itself does not delete history automatically – older history records are deleted only in one of the ways listed below.
• Two buttons are located to the right of the text box:
  • The “Delete history” button permanently deletes the entire history of the edit form regardless of the set number of months.
  • The “older than” button deletes history records older than the number of months entered in the text box (6 months if not entered).
• History records older than the time period set in this way can also be deleted once using:
  • Smaller icons for deleting record history from reports. A detailed description of the reports is given in a separate manual Reports.
  • “DELETEHISTORY” server functions.

2.6.7. C#/JavaScript

• Using the “C#/JavaScript” button, a text report will be displayed with an example in C# for saving the record to the database table associated with this edit form.
• The report includes a list of all database controls in the edit form.

2.6.8. Statistics

• The statistics display aggregated information on the use of the edit form across the entire application.
• Using the “Statistics” button, a detailed report of all places where the edit form is used or referenced is displayed, including the option to open the settings of such a place or control.
• Before each deletion of the edit form, it is recommended to thoroughly go through the statistics of the editing element, and to eliminate possible misunderstandings.
• Before each deletion of the edit form, the evaluation of the statistics starts automatically. If the edit form is used or referenced somewhere in the application, it is necessary to confirm the deletion of the edit form again.

2.6.9. Logging

• Using the “Logging” button displays a detailed report containing records of the edit-form activity. The report includes information on:
  • the date and time when the edit form was displayed,
  • the user who displayed the edit form,
  • the processing time of the edit form,
  • the start date and time of the processing,
  • the end date and time of the processing,
  • the size of the resulting HTML code generated for the edit form,
  • an indication of whether it was the first form load or a form refresh (postback).

• For logging to function correctly, logging must be enabled in the NET Genium settings on the “Other” tab, either as “To database” or “To database and disk”. A detailed description is provided in the separate guide NET Genium settings.
• The minimum display time for processing an edit form is set to 0 milliseconds by default, so all display records of edit forms are displayed, including those whose processing took 0 milliseconds. This minimum time can be increased or decreased by changing the “mintime” parameter in the report URL.
• The number of records is limited to 100 by default. This number can be manually increased or decreased by changing the “maxrows” parameter in the report URL.

2.6.10. History

• Using the “History” button, a detailed report with individual change tracking records is displayed.

2.7. “Save”, “Delete” and “Close” buttons

• “Save” button – Save changes to the edit form settings.
• “Delete” button – Permanently delete the edit form. The edit form is deleted with all its controls, their database queries and scripts, the database table and the history table. The files of attachments stored in the form are not deleted. A system edit form cannot be deleted.
• “Close” button – Close the edit form settings dialog without saving changes.

3. Sync settings

3.1. Server settings

3.1.1. Name

• The name of the remote server, resp. NET Genium.

3.1.2. URL

• Internet address of the remote NET Genium (SSL communication via the “https” protocol can be used).

3.1.3. Synchronization password

• Synchronization password set on the remote NET Genium in the NET Genium settings.

3.1.4. Intranet URL

• Intranet address of the remote NET Genium, to whose records users will be routed from e-mail messages sent by the script.

3.1.5. Language

• The language in which links will be created in e-mail messages, directing users to NET Genium entries.

3.1.6. Options

• Ignore SSL errors
  • Checking this box determines whether errors in SSL certificates will be ignored when communicating with remote NET Genium via the “https” protocol.
• Proxy Server
  • Checking this box determines whether a Proxy Server will be used to communicate with the remote NET Genium.
• Proxy URL
  • Proxy Server Address.
• Login name
  • Login name for communication with the Proxy Server.
• Password
  • Password for communication with the Proxy Server.

3.2. Sync settings

3.2.1. Server

• The name of the server with which the data from the database table of the currently open edit form will be synchronized.

3.2.2. Edit form

• Edit form in the remote NET Genium, with which the data from the database table of the currently open edit form will be synchronized.
• Changing the edit form deletes the changes waiting in the queue to be sent through this link; the emails carried by these changes are discarded as well.

3.2.3. Condition for synchronization

• A condition that limits the scope of synchronized data to a specific set only.
• The condition is evaluated on every save of a record, including editing a value in a view table, mass changes and one-time synchronization. A condition on a script variable is considered satisfied outside a script (for example when editing a value in a view table).
• The condition does not apply to deleting a record. A record that stops satisfying the condition remains on the remote side. The deletion is therefore sent by ID even for a record that was never transferred to the remote side (it did not satisfy the condition or was created before the synchronization was set up), and on the remote side it deletes the record with the same ID, even if it is a different record.

3.2.4. Columns

• The column settings determine which column (left) of the remote edit form will be synchronized, and which column (right) in the currently open edit form.
• Each column can contain a condition only when the value of the column will be synchronized.

3.3. One-time synchronization of all data

• One-time synchronization sends all records of the database table with all synchronized columns under their IDs; it overwrites a record with the same ID on the remote side and does not delete records on the remote side that do not exist on the source.
• A maximum limit of 10,000 records is set for one-time synchronization. If it is exceeded, nothing is sent. The limit can be increased using the “MaxSyncCount.txt” configuration file. A detailed description of configuration files is provided in the separate guide NET Genium settings.

4. Edit form behaviour

4.1. Opening a record

• When a new record is opened, default values are filled in the controls. For an existing record, only the default values of controls with the “Fill in the default value every time the edit form opens up” option and the values of “AutoSum” controls are filled in.
• A required drop-down list and a required foreign key without a value get the first item of their offer when opened, even for an existing record.
• After opening, the “OnAfterOpen” script runs. Values the script saves with the SCHEDULESAVE server function and the recalculated values of “AutoSum” controls are written to the database already when the record is opened, without the user saving it.
• Opening a deleted or non-existent record redirects the user to a page informing about the deleted record, provided the user has access to some control of the form. A user without access to the controls gets the form displayed in the same way as for an existing record.

4.2. Saving a record

• Saving a record proceeds in this order: *# validation of controls, including hidden controls and read-only controls, *# filling in the default values with the “Fill in the default value before each saving of the record to the database” option, *# the “OnBeforeSave” script, *# saving the record to the database, *# the “OnAfterSave” script, *# sending the e-mails scheduled in the scripts and the redirect scheduled in the “OnAfterSave” script.
• Only controls whose value has changed since the form was opened are saved to the database. If another user has meanwhile changed the same control, the value from the form overwrites it; only record locking protects against concurrent edits.
• The “Save” button saves the record and returns the user back. The “Save and new” button saves the record, runs the “OnBeforeOpen” script and opens a new record with the same link to the parent record. The “Save and continue editing” button saves the record and opens it again with the scroll position and the selected tab preserved.
• An error in the “OnBeforeSave” script does not save the record and the user stays in the form with the filled-in values. An error in the “OnAfterSave” script is displayed only after the redirect; the record remains saved.

4.3. Read-only form

• The edit form is displayed as read-only if the user is not allowed to edit the record (see “Editing rights”), if the record is locked by another user, or if the form contains no database control the user has access to.
• The values of controls sent from a read-only form are not used. Unless the reason is a lock of another user, buttons with a script that save the record work with the values stored in the database and with the values set by the script itself.
• If the record is locked by another user, a message about the locked record is shown after the form is opened, the buttons of the controls as well as mass editing in the view tables of the form are disabled, and the server rejects saving and deleting the record, including saving by the script of a button, with a message about the locked record.
• The “form_Save”, “control_Save” and “controls_Save” JavaScript functions do not save the record in a read-only form.

4.4. “Back” button

• The “Back” button as well as saving the record return the user to where the edit form was opened from, in this order: *# to the parent edit form with the scroll position and the selected tab preserved, if the record was opened from another edit form, *# to the picker, if the record was opened from it, *# to the main page with portlets, if the record was opened from a portlet, *# to the view page from which the record was opened, *# in admin mode to a new record of the same edit form, *# otherwise to the main page.

4.5. Errors, external functions and limits

• On every request to the edit form, the NETGenium.OpenForm external function runs, except when a deleted or non-existent record is opened. Its error ends the loading of the whole form. A detailed description is provided in the separate guide External functions.
• A script whose processing takes 60 seconds or longer is recorded in the “Scripts60sec” log.
• In the NET Genium Online cloud variant, the processing time of a single script is limited to 10 seconds; when exceeded, the script is interrupted with an error.

4.6. Copying an edit form

• A copy of an edit form is created by the copy icon in the navigation area in admin mode. The structure of the form, its controls, scripts, database queries, rights and co-owners are copied. Neither data nor synchronization settings are copied.
• A system edit form cannot be copied.