CS

Edit form - ActionButtons

Home / Documentation / Administrator guide / Edit form /

Edit form - ActionButtons

CS

1. General information

1.1. Description of the control

Each edit form automatically contains an “ActionButtons” control, which consists of three basic buttons needed to work with the form – “Save”, “Delete” and “Back”.

2. List of tabs in the control settings dialog

  • General – Setting general properties
  • Save – Save button settings
  • Delete – “Delete” button settings
  • Back – “Back” button settings
  • Below the script of each event (“OnAfterOpen”, “OnBeforeSave”, “OnAfterSave”, “OnBeforeOpen”, “OnBeforeDelete”, “OnAfterDelete”) there is a “Deny script” check box. Checking it turns off running the script, whether the event is triggered in the edit form or otherwise (for example by a multiple change in the view table); the script stays saved.

2.1. “General” tab

2.1.1. Options

  • Hide “Save” button
    • Checking this box determines whether the “Save” button should be hidden in the edit form.
    • Hiding the button does not protect the record against changes – the record can still be saved with the “Save and new” and “Save and continue editing” buttons, with a “Button” control of the “Open a view page” or “Script” type with step “1. Save the record” or “3. Save the record” checked, with a “Button” control of the “Open an edit form” type with step “1. Save the record” checked, and with a “Button” control whose script saves the record (with step “3. Save the record” or the “SCHEDULESAVE” function). The forced saving of a button of the “Print to template” and “Open an edit form” types without a script saves the record as well; it is skipped only in a read-only form, as described in the separate guide Edit form – Button. Who may edit the record is determined by the “Editing rights” of the edit form.
  • Hide “Delete” button
    • Checking this box determines whether the “Delete” button should be hidden in the edit form.
    • Unlike the “Save” button, hiding it disables deleting the record in the edit form on the server side as well, and bulk deletion of records in the view table then remains available to administrators only. Deleting a record with a script command is not disabled by it.
  • Hide “Back” button
    • Checking this box determines whether the “Back” button should be hidden in the edit form.
  • Show “Save and continue editing” button
    • Checking this box determines whether the “Save and continue editing” button should be displayed in the edit form.
  • Show “Save and new” button
    • Checking this box determines whether the “Save and new” button should be displayed in the edit form.
    • The button text can be set to custom. The custom text may contain variables (the value of a form control written as #ng_...:value#) and server functions, which are evaluated when the form is displayed; if the result is empty, the button is not displayed. Hiding the button is not a security measure – the rights to the record are always checked when it is saved.

2.1.2. OnAfterOpen

  • A script that is executed when the record is opened in an edit form.
  • The script runs only when the edit form is loaded. It does not run again after the form is submitted – for example after pressing a button or after an unsuccessful save. The script runs again when the form is loaded again by a redirect, i.e. after saving with the “Save and continue editing” button or after navigation by the “SCHEDULEFORM” function to the same record.
  • In user mode, the script does not run if no control of the form is displayed to the user (for example if the user has rights to none of them). In such a case, the default values of the controls are not filled in on opening either.
  • Database changes made by this script are committed as soon as it finishes, in a separate database transaction.
  • An error of the script does not prevent the form from opening: the edit form opens with an error message and the database changes of the script that the script has not committed with the “COMMIT()” function yet are rolled back. The values that the script assigned to the controls before the error stay in the form. For a saved record, the columns that the script scheduled for saving with the “SCHEDULESAVE” function with a parameter before the error are still written to the database, with the values assigned before the error.
  • The “SCHEDULESAVE()” server function without a parameter in this script saves the record as soon as it is opened, using the whole save process including validation and the “OnBeforeSave” and “OnAfterSave” scripts. A new record is created this way. The record is saved even in a read-only form, with the values stored in the database and with the values set by the script; the saving is refused only for a record locked by another user, with a message about the locked record.
  • Navigation scheduled in this script (SCHEDULEBACK, SCHEDULEFORM, SCHEDULEVIEWPAGE, SCHEDULEURL, SCHEDULEPORTLETS and others) and the “HIDEFORM” function are performed only in user mode. The “SCHEDULEFORM” function to the record that is currently open is ignored, and the “SCHEDULEMAILMESSAGE” function has no effect in this script.

2.2. “Save” tab

2.2.1. JavaScript

  • A function call (or another javascript expression) without a semicolon at the end, for example “beforeSave()”, which is evaluated when the “Save” button is pressed. The result is used as a condition, so the function is written including the parentheses – the function name alone without parentheses does not call the function. The “#ng_...#” identifiers in the expression are replaced in the same way as in other JavaScript of the edit form.
  • The expression may have at most 50 characters. Longer logic has to be placed in a function in the “JavaScript” control of the edit form, and only its call is entered in the field.
  • If the return value of the function is “true”, the server script “OnBeforeSave” is executed.
  • If the return value of the function is false – “false”, but also “0”, “null”, an empty string or “undefined”, which a function without the “return” command returns –, the server script “OnBeforeSave” will not be executed and the record will not be saved.
  • The expression is also evaluated before the record is saved with the “Save and new”, “Save and continue editing” and “Synchronize” buttons, before an automatic saving of the record (for example when a nested record is created or opened from a view table of the form), and after pressing a “Button” control of the “Open an edit form” or “Print to template” type; for the “Open a view page” and “Script” types only with step “1. Save the record” or “3. Save the record” checked. For a “Button” control, the expression is evaluated after the code from the “Client” field, and only if that code does not return a value with the “return” command earlier.

2.2.2. OnBeforeSave

  • A script that is executed before the record is saved to the database.
  • Control validation is completed before this script starts. A required field therefore cannot be filled in only by this script – validation evaluates it as empty.
  • The “OnBeforeSave” script and the record save run in one database transaction. A script error prevents the record from being saved and also rolls back database changes made by this script that the script has not committed with the “COMMIT()” function yet. A detailed description of the changes that a script error does not roll back is provided in the separate guide Script designer.
  • “SKIPSAVE()” behaves differently from an error: it skips only the record save, commits database changes made by the script, and then runs “OnAfterSave”.
  • If the “OnBeforeSave” script is run other than by saving the edit form – for example by a multiple change or a change of a value directly in the view table, in the details panel of a view table, on a card of the Kanban control or in the details of the Tree control, by an import from Excel, or by the “OBSOAS” server function – “SKIPSAVE()” does not perform the changes written by the script commands (“Save value to the database”, “New record”, “Delete record” and other writing commands). Only those of them that the script committed with the “COMMIT()” function are performed. Unlike in the case of an error, the script transaction is still committed: writes made by external functions through the passed “cmd” object remain and emails queued by the “Send email” command are sent.
  • In a multiple change of a value from the view table, a script error on an individual record does not interrupt processing – the record is not changed and processing continues with the next record. When processing finishes, the user is shown the text of the first error and the number of records on which the script failed.
  • Navigation scheduled in this script (SCHEDULEBACK, SCHEDULEFORM, SCHEDULEVIEWPAGE, SCHEDULEURL, SCHEDULEPORTLETS and others) is performed only after the record has been saved, and only with the “Save”, “Save and new”, “Save and continue editing” or “Synchronize” button. The “OnAfterSave” script takes it over and may change it. If the record is saved in another way – by a step of a “Button” or by the “form_Save” function – or if the script is run other than by saving the edit form, the navigation is not performed; with a “Button”, the redirect is decided by its own script.

2.2.3. OnAfterSave

  • A script that is executed after the record is saved to the database.
  • It starts only after the transaction containing the “OnBeforeSave” script and the record save has been committed successfully.
  • The “OnAfterSave” script runs in a new database transaction. An error rolls back database changes made by this script that the script has not committed with the “COMMIT()” function yet, but it does not restore the already saved record to its previous state.
  • Assigning a value to a control of the current record (the “Assign value” command) is not saved to the database in this script, because the record has already been saved. The value of the current record has to be written with the “Save value to the database” command.
  • Navigation scheduled in this script is performed only after saving with the “Save”, “Save and new”, “Save and continue editing” or “Synchronize” button, the same as the navigation taken over from the “OnBeforeSave” script.

2.2.4. OnBeforeOpen

  • A script that is executed before a new record is opened in the edit form.
  • The “OnBeforeOpen” script is executed after pressing the “Save and new” button in the edit form.
  • The script runs over the record that has just been saved – the “#id#” variable and the values of the controls belong to the saved record, not to the new one.
  • Assigning a value to a control is not saved, not even with the “SCHEDULESAVE” server function; only the recalculated values of the “AutoSum” controls are written to the saved record.
  • Values for the new record can be passed by the “SCHEDULEDEFAULTVALUE” and “SCHEDULEDEFAULTVALUES” server functions. The parent record of the new record (the “pid” and “pform” identifiers) cannot be set by them in this script – the new record takes over the parent record of the record that has just been saved.
  • If the script ends with an error, the new record is not opened.
  • Navigation scheduled in this script (SCHEDULEFORM, SCHEDULEURL and others) is not performed.
  • If the “OnBeforeSave” or “OnAfterSave” script of the saved record schedules navigation, this navigation is performed after pressing the “Save and new” button; the “OnBeforeOpen” script then does not run and the new record is not opened.

2.3. “Delete” tab

2.3.1. JavaScript

  • A function call (or another javascript expression) without a semicolon at the end, for example “beforeDelete()”, which is evaluated when the “Delete” button is pressed. The function name alone without parentheses does not call the function.
  • The expression may have at most 250 characters. Longer logic has to be placed in a function in the “JavaScript” control of the edit form, and only its call is entered in the field.
  • If the return value of the function is “true”, the server script “OnBeforeDelete” is executed.
  • If the return value of the function is false – “false”, but also “0”, “null”, an empty string or “undefined”, which a function without the “return” command returns –, the server script “OnBeforeDelete” will not be executed and the record will not be deleted.
  • If the function is filled in, it replaces the default confirmation of deleting the record – the default confirmation is then not displayed.

2.3.2. Options

  • Always allow deleting to the owner or co-owner of the record
    • Checking this box determines whether the record owner or co-owner should be allowed to delete the record, regardless of the existence of other controls on the form to which the record owner or co-owner does not have the right.

2.3.3. OnBeforeDelete

  • A script that is executed before deleting a record from the database.
  • The “OnBeforeDelete” script and the record deletion run in one database transaction. A script error prevents the record from being deleted and also rolls back database changes made by this script that the script has not committed with the “COMMIT()” function yet. A detailed description of the changes that a script error does not roll back is provided in the separate guide Script designer.
  • “SKIPDELETE()” behaves differently from an error: it skips the record deletion and then runs “OnAfterDelete”. The changes written by the script commands (“Save value to the database”, “New record”, “Delete record” and other writing commands) are not performed; only those of them that the script committed with the “COMMIT()” function are performed. The script transaction is still committed, so writes made by external functions through the passed “cmd” object remain.
  • In a multiple deletion of records from the view table, a script error on an individual record does not interrupt processing – the record is not deleted and processing continues with the next record. When processing finishes, the user is shown the text of the first error and the number of records on which the script failed.
  • Navigation scheduled in this script (SCHEDULEBACK, SCHEDULEFORM, SCHEDULEVIEWPAGE, SCHEDULEURL, SCHEDULEPORTLETS and others) is performed only after the record has been deleted. The “OnAfterDelete” script takes it over and may change it. When records are deleted in bulk from the view table, the navigation is not performed. If the record has been deleted, the “SCHEDULEFORM” function creates a new record as a nested record of the parent record of the deleted record (unless another parent record is set by the “SCHEDULEDEFAULTVALUE” function or the “back” parameter has the value “true”), and the deleted record is not used as the return target either; the “SCHEDULEMAILMESSAGE” function does not refer to the deleted record.

2.3.4. OnAfterDelete

  • A script that is executed after deleting a record from the database.
  • It starts only after the transaction containing the “OnBeforeDelete” script and the record deletion has been committed successfully.
  • The “OnAfterDelete” script runs in a new database transaction. An error rolls back database changes made by this script that the script has not committed with the “COMMIT()” function yet, but it does not restore the already deleted record.
  • Navigation scheduled in this script is performed after the record has been deleted, the same as the navigation taken over from the “OnBeforeDelete” script; when records are deleted in bulk from the view table, it is not performed. If the record has been deleted, the same as in the “OnBeforeDelete” script applies to the “SCHEDULEFORM” and “SCHEDULEMAILMESSAGE” functions.
  • If the script ends with an error in the edit form, the navigation scheduled before the error is performed anyway, the same as the scripts scheduled before the error by the “SCHEDULESCRIPT” function. When records are deleted in bulk from the view table, the scheduled scripts are not performed after an error.

2.4. “Back” tab

2.4.1. JavaScript

  • A function call (or another javascript expression) without a semicolon at the end, for example “beforeBack()”, which is evaluated when the “Back” button is pressed. The function name alone without parentheses does not call the function.
  • The expression may have at most 50 characters. Longer logic has to be placed in a function in the “JavaScript” control of the edit form, and only its call is entered in the field.
  • If the return value of the function is “true”, the user is redirected back to the place from which the edit form with the currently open record was called. If the form contains unsaved changes, the expression is evaluated before the question about leaving the form; once the question is confirmed, it is not evaluated again.
  • If the return value of the function is false – “false”, but also “0”, “null”, an empty string or “undefined”, which a function without the “return” command returns –, the user will not be redirected back.

2.5. “Save” and “Close” buttons

  • “Save” button – Saves changes to the control settings.
  • “Close” button – Closes the control settings dialog without saving changes.

3. Examples

3.1. Javascript functions

  • attachEvent2(window, 'load', function() { var o = el('btSave'); if (o != null) o.style.display = 'none'; });
  • attachEvent2(window, 'load', function() { var o = el('btDelete'); if (o != null) o.style.display = 'none'; });
  • attachEvent2(window, 'load', function() { var o = el('btBack'); if (o != null) o.style.display = 'none'; });