Multi-component Page
While CuneiForms and CuneiTables on each of their own can create functional pages for several purposes, most accounting and transaction records require both to be displayed and manipulated in a meaningful manner. And while it is possible for such pages to be perfectly functional by stringing stad-alone forms and tables together, the numbers of requests and database accesses are unnecessarily high.
In the CuneiFox framework, inter-related forms and tables can be linked together via the use of Document Context. Below are the key functions of Document Context:
- Control page-level permissions and operations.
- Perform a document-lock/unlock upon entering entering/exiting the page's edit mode.
- Consolidate populating request for all forms and tables on the page.
- String together page edit sequence.
Page Sequence
In CuneiFox, modifying a multi-component entry (usually a document) is done in pre-defined steps. This design is to make the process more predictable and, thus, minimize the complexity of data handling behind the scene. The most common pattern of a multi-component page behaves as follows:
- The page is opened first in read-mode. In this mode, modifications to any form fields and table data are disabled.
- To make any modification, the user must enter the edit-mode, where forms and tables are enabled on a step-by-step basis. Entering the edit-mode by clicking the page-level Add or Edit button first allows the user to modify elements in the first page sequence (highlighted yellow).
- The user can proceed to the next sequence by clicking the page-level Proceed button.
- The user can may exit back into the read-mode by:
- Clicking the page-level Cancel button at any step.
- Clicking the page-level Proceed button on the last editing step.
NOTE: Step 3 and 4 can be blocked until certain conditions are met via Document Context key proceed_lock_seq.
Page-level Permission
When dealing with a multi-component record, one cannot assume the permission bit of that record type dictate the actions actually allowed for each sub-component. For example, a user authorized to edit (page-level permission: 3) Accounting Journal is expected to be able to delete (table-level permission: 4) individual debit and credit records as well.
Therefore, it is perfectly acceptable to max out the element-level permissions of all tables and forms on the page (set to 4 or higher), as long as the page-level permission exists to control users' access to different operation. On the server-side, it is also recommended to recheck whether the operation requested from the client-side is allowed. (If the developer follows the common pattern, this check is taken care of via the function process_allowed_action.)
Beacon & Document Locking
CuneiFox's beacon & document locking system prevents multiple users from modifying the same document simultaneously. In essence, the document locking works as follows:
- Locking a document is done by updating the column
editting(the misspelling has become intentional, a relic of a past mistake) of the document's master entry (usually the document header) with the username. (See #Page Permission → Document Lock → Allowed Actions below.) - Unlock the document by updating the
edittingcolumn with a blank string (''). The document unlock happens when:- The user exits from the edit-mode on an existing document. (A newly created master entry counts as an existing document.)
- The document is unlocked temporarily when the browser tab is hidden while the user is in the edit-mode. The document is automatically re-locked when the tab returns to visibility.
Beacon Keys
For the beacon system to properly lock/unlock a document, it must know the document is in the company's database. Beacon keys help point the system to the correct target.
- Javascript-packed: These set of keys indicate the client-side state when the beacon is sent, and thus must be packaged along with the beacon via client-side Javascript. For pages using the usual patterm, these keys are automatically packaged and are accessible on the server-side via either
request.dataorrequest.form['bdata'].- token (str): The session token. This is used to determine whether the session's user can lock/unlock the document. (For example, a user cannot unlock a document that is locked by another user.)
- mode (str): The type of the beacon sent. This value can take either of the following:
'start': The user first enters the edit-mode. If the document already exists, CuneiFox will lock the document.'resume': The page resumes edit-mode after automatically exiting it as the user navigates to other tabs or apps. If the document exists, CuneiFox will lock the document.'done': The user exits the edit-mode via the page-level Proceed button while being in the final page sequence. CuneiFox unlocks the document.'cancel': The user exits the edit-mode via the page-level Cancel button. If the document exists, CuneiFox will unlock the document.
- cur_seq (int): The number representing the page sequence the user is in when the beacon fires (with the first sequence denoted by
0). This value is not utilized during the lock/unlock step, but can be highly necessary during the document's wrapup algorithms. - seq_count (int): The number of steps in the page sequence.
- cur_mainid (int): The ID of the document's main record (the document's header).
- time_diff (float): The difference between the server time and the session time in seconds. Because of the way CuneiFox stores its data, this value is necessary to pinpoint the database file in need.
- Database Pointer: The variables that points the program to the correct database file. This is usually hard-coded into each specific beacon-handling route or fed via request parameters for a shared route.
- bookcode (str): The name of the database file. In CuneiFox convention, this is usually a 3-lettered string.
- is_gl (str:
'yes'or'no'): Whether the target database is an Accounting Journal. (By CuneiFox convention, an accounting journal database name is prefixed withGL_for exampleGL_GL0.) - datatype (str:
'table','data', or'report'): The data type (location) of the database file.
- Other Keys: These keys are quite rare and are usually explicitly hard-coded in each specific Python route when needed.
- skip_lock (bool): Used exclusively by the Python function
process_doclockto make it return immediately without performing document locking/unlocking.
- skip_lock (bool): Used exclusively by the Python function
Beacon Routine Functions
The 2 groups of beacon keys discussed above can be converted into a dict form for ease of use via the Python function process_beacon_args.
process_beacon_args(internal_args, request)
| Parameters |
|
| Returns |
|
| Notes |
The function throws a 461 exception (Session-time Error) if the beacon value time_diff is invalid or does not agree with the session time. |
The process of locking/unlocking a document cna also be automated via another function process_doclock.
process_doclock(beacon_args, module_name, perm_name, headmodel=None, paired_gl=None)
| Parameters |
|
| Returns |
|
Page Permission → Document Lock → Allowed Actions
In a sense, the actions that a user can perform on a page are dictated by the user's permission. However, in the messy real world, permission bits are no the only factor at play here. In CuneiFox, allowed actions are determined as follows:
- When a user initiates a page-level action, CuneiFox first determines whether the user is authorized to do so (via a permission bit check). Then,
- For an edit operation, the program checks whether the document is locked by another user. If not, the document lock is applied under the current user's name.
- For a delete operation, the user is only allowed to proceed if the document is not locked by another user.
- For an add operation, the program automatically proceeds. The document lock is to be applied automatically once the document header is committed to database.
- When a user submits a CuneiForm (a stand-alone form, an in-line form, a CuneiTable's full-form), the recommended template has CuneiFox re-interpret the permission bit and the document lock state into allowed action dictionary via Python functions
check_doclockandprocess_allowed_action. The form submission is only processed if the operation is allowed.
check_doclock(datatype, bookcode, headmodel, form, field,
doc_perm_bit, head_id_col="id", paired_gl=None)
| Description | Based on the current lock-state of a particular document, returns the dict of actions the user is allowed to perform at a header level. |
| Parameters |
|
| Returns |
|
| Notes | The function throws a 491 exception (Frozen-data Error) or 492 exception (Posted-data Error) if the month's data is frozen or locked respectively. |
process_allowed_action(head_action_dic, is_head)
| Description | Interprets the head_action_dic (returned from check_doclock) and whether the current form is for the document header, returns a new allowed_action dict that is really applicable to the current form.
By CuneiFox standard, all actions is allowed for the sub-entries if the user holds the edit permission at the header level (including the temporary edit permission granted upon document addition.) |
| Parameters |
|
| Returns |
|
Define a Document Context
Document Context is a dict fed to the Flask render_template function. Most of the keys in the dict are handled (with default values assigned, if not given) by a separate Python function prep_mainseq. We shall begin with these so-called Main Sequence keys, then we will discuss a few additional keys.
Main Sequence Keys
Page Permission & Sequence Definition
- mainseq ([[CuneiForm/CuneiTable,],]: defaults to
[]): The list of page sequence specifications. Each member is a list of CuneiForms and/or CuneiTables belonging to that specific sequence. - mainseq_name ([[str,],]: defaults to
[]): Basically mainseq, but repacked with _id attributes (str) of each CuneiForm/CuneiTable in place of the object itself. (This value is automatically created can only used for ease of internal references.) - page_perm (int: defaults to
1): Page-level permission value.- 0: Not readable. (Usually users with this permission level should be prevented from reaching the page at all. DO NOT rely on this permission bit as a security measure,)
- 1: Read-only.
- 2: Add. (Allows 'add' type actions: add and copy.)
- 3: Add + Edit.
- 4: Add + Edit + Delete.
- ≥5: Add + Edit + Delete + Import.
- proceed_lock_seq ([[str,],]: defaults to
[]): List of document verification items that should prevent proceeding/canceling away from each sequence. - searchers [CuneiTable,]: defaults to
[]: List of search tables.
Basic Actions
- mainseq_add (str: defaults to
'plain'): Action type when the page-level Add button is clicked.'newmaster': The button triggers the addition of a new master entry. (This setting assumes the existence of a Master Form and certain Mass Populate setting.)- Any other string: The button triggers the function
this_page_add(event). This function must be custom written for each page that needs it.
- mainseq_del (str: defaults to
'plain'): Action type when the page-level Delete button is clicked.'delmaster': The button triggers the prompt for the deletion of the current master entry. (This setting assumes the existence of a Master Form and certain Mass Populate setting.)- Any other string: The button triggers the function
this_page_delete(event). This function must be custom written for each page that needs it.
- mainseq_proceed ([str,]: defaults to
[]): Each sequence's action type when the page-level Proceed button is clicked.'submit': Submit the first CuneiForm in the current page sequence. Note that this proceeding mode DOES NOT transmit a 'cancel' beacon. So, if the final sequence of the page has this proceed mode, the duty of unlocking the document falls on the submission route of the final form.'beacon': Beam a 'proceed' beacon to the server to signal a page sequence change. (For the final page sequence, a 'cancel' beacon is sent instead to signal checking out of the page's edit mode.)
- mainseq_search (str: defaults to
False): Field name of the Master Form used for page-level search. - mainseq_schprmpt (str: defaults to
'Document Number'): Prompt text for page-level search.
Request-based Actions
- mainseq_beacon (url_for_string: defaults to
False): Route for beacon transmission. - mainseq_print (url_for_string: defaults to
False): Route for print request. - mainseq_qr (url_for_string: defaults to
False): Route for Payment QR-code request. - mainseq_vouch (url_for_string: defaults to
False): Route to corresponding Accounting Journal record. (Usually directed throughcunei_gl.direct_to_vouch.) - mainseq_export (url_for_string: defaults to
False): Route to export request.
Form-based Actions
- mainseq_modaldel (CuneiForm: defaults to
False): If defined, right-clicking on the page-level Delete button triggers a CuneiModal containing this form. The standard Mass Deletion Form is pre-defined at cuneifox.base.main.forms.StdModalDelForm. - mainseq_copy (CuneiForm: defaults to
False): If defined, clicking on the page-level Copy button triggers a CuneiModal containing this form. The standard Document Copy Form is pre-defined at cuneifox.base.main.forms.StdCopyForm. - mainseq_attach (CuneiForm: defaults to
False): If defined, clicking on the page-level Attach button triggers a CuneiModal containing this form. The standard Document Attach Form is pre-defined at cuneifox.base.main.forms.StdAttachForm. - mainseq_modalprint (CuneiForm: defaults to
False): If defined, right-clicking on the page-level Print button triggers a CuneiModal containing this form. The standard Custom Printing Form is pre-defined at cuneifox.base.main.forms.StdModalPrintForm. - mainseq_upload (CuneiForm: defaults to
False): If defined, clicking on the page-level Import button triggers a CuneiModal containing this form. The standard Document Import Form is pre-defined at cuneifox.base.main.forms.StdImportForm.
# Example from Accounting Journal (w/ Input VAT) page
# MAIN SEQUENCE FORMS/TABLES
head_form = VoucherHeadForm.init_form(prefix="VoucherHeadForm",
gen_del="cunei_gl", sequence_bound=True,
populate_id=["id"], populate_suppress=["grab"],
post_route=url_for("<head_submit_route>"), ...)
vouch_tb = VouchBodyTable(prefix="VouchBodyTable", editable=True, perm_bit=4,
populate_route=url_for("<vouch_default_val_request_route>"),
populate_id=["master.id"], populate_suppress=["qsch", "free_grab"],
post_route=url_for("<vouch_submit_route>"), ...)
vouchsum_form = VoucherDetailSum.init_form(prefix="VoucherDetailSum", ...)
vat_tb = VouchVatTable(prefix="VouchVatTable", editable=True, perm_bit=4,
populate_route=url_for("<vat_default_val_request_route>"),
populate_id=["master.id", "#master.section_stid",
"#master.docdate", "#master.desc"],
populate_suppress=["qsch", "free_grab"],
post_route=url_for("<vat_submit_route>"), ...)
vatsum_form = VatDetailSum.init_form(prefix="VatDetailSum", ...)
wht_tb = VouchWhtTable(prefix="VouchWhtTable", editable=True, perm_bit=4,
populate_route=url_for("<wht_default_val_request_route>"),
populate_id=["master.id", "#master.section_stid",
"#master.docdate", "#master.desc"],
populate_suppress=["qsch", "free_grab"],
post_route=url_for("<wht_submit_route>"), ...)
whtsum_form = WhtDetailSum.init_form(prefix="WhtDetailSum", ...)
# SEARCH TABLES
# (Note that most search tables use unified 'Search Table with a Stand-alone Page'.
# See corresponding section under CuneiTable page for the template.)
section_tb = SectionTable(prefix="SectionTable", perm_bit=<user_perm_for_section>,
populate_route=url_for("cunei_gl.section", fetch="yes"),
post_route=url_for("cunei_gl.section"),
in_modal="Modal0", modal_head=lazy_gettext("Choose Section"), ...)
acccode_tb = AccCodeTable(prefix="AccCodeTable", perm_bit=<user_perm_for_acccode>,
populate_route=url_for("cunei_gl.acccode", fetch="yes"),
post_route=url_for("cunei_gl.acccode"),
in_modal="Modal1", modal_head=lazy_gettext("Choose Account Code"), ...)
...
# START CREATING DOCUMENT CONTEXT
mainseq = [[head_form],
[vouch_tb, vat_tb, wht_tb, vouchsum_form, vatsum_form, whtsum_form]]
attach_form = StdAttachForm.gen_attach_form(post_route=url_for("<attach_submit_route>"),
populate_route=url_for("<attach_fetch_route>"))
modalprint_form = StdModalPrintForm.gen_modalprint_form(post_route=url_for("<custom_prn_submit_route>"))
modaldel_form = StdModalDelForm.gen_modaldel_form(post_route=url_for("<mass_del_submit_route>"))
modalcopy_form = StdCopyForm.gen_copy_form(url_for("<copy_submit_route>"), ...),
modalimport_form = StdImportForm.gen_import_form(url_for("<import_route>"))
# USE 'pack_mainseq' TO FILL UNSPECIFIED KEYS WITH DEFAULT VALUES.
mainseq_args = pack_mainseq(mainseq=mainseq,
mainseq_add="newmaster",
mainseq_del="delmaster",
page_perm=<user_perm_for_the_page>,
mainseq_proceed=["submit", "beacon"],
proceed_lock_seq=[[], ["incomp"]],
mainseq_search="docno",
mainseq_print=url_for("<print_route>"),
mainseq_export=url_for("<export_route>"),
mainseq_beacon=url_for("<beacon_route>"),
mainseq_copy=modalcopy_form,
mainseq_attach=attach_form,
mainseq_modalprint=modalprint_form,
mainseq_modaldel=modaldel_form,
mainseq_upload=modalimport_form,
searchers=[section_tb, acccode_tb, ...])
Additional Document Context Keys
- btn_set (bool): Whether the page button sets should be rendered.
- doccount (bool): Whether the document counter elements should be rendered.
- docverify (dict): The specifications for the document verification blocks. Each key-value pair corresponds to a single block:
- The key is a string used for internal referencing.
- The value is a list ([str, str, str (optional)]):
- A short human-readable description of the verification. This value is the popover text when the mouse cursor hovers above the block.
- Pill text, a highly abbreviated shorthand string that appears on the block at all time.
- (Optional) The name of the function to run when the verification is not an all-out pass. Usually the function serves to highlight the elements where attention is needed.
# Example from Accounting Journal (w/ Input VAT) page
doc_context = {"btn_set": True,
"doccount": True,
"docverify": {"incomp": ["INCOMPLETE", "INCOMP", "blip_vouch_tab"],
"iwht": ["INPUT WITHHOLDING TAX", "IN-WHT", "blip_wht_tab"],
"owht": ["OUTPUT WITHHOLDING TAX", "WHT", "blip_wht_tab"],
"bvat": ["TAX INVOICE", "VAT", "blip_vat_tab"],
"editting": ["EDITTING", "EDIT"]},
**mainseq_args)
More render_template Arguments
Arguments discussed under this final sub-section are not parts of the Document Context, and are to be fed directly to the render_template function. However, they are commonly utilized in tandem with Document Context, so it is fit to list them here as well.
- mass_populate (list):