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:

1. The page is opened first in read-mode. In this mode, modifications to any form fields and table data are disabled.
2. 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).
3. The user can proceed to the next sequence by clicking the page-level Proceed button.
4. 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.

Example page in read-mode and edit-mode.

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:

1. 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.)
2. Unlock the document by updating the editting column 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.data or request.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 with GL_ for example GL_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_doclock to make it return immediately without performing document locking/unlocking.

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	internal_args (dict or None): Provides beacon keys-values in cases of beacon-like internal operations. When this value is not None, the beacon aruguments are only read from this argument. request (Flask request): The client-side request. If no internal_args is not given, this function automatically extracts beacon keys-values from request parameters and request.data (or request.form['bdata']).
Returns	beacon_args (dict): Beacon keys-values repacked in the easily accessible dict form.
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

beacon_args (dict): Beacon keys-values as a dict. Usually this dict is what returned from process_beacon_args module_name (str): The code of the CuneiFox module that the current operation belongs to. This argument is used along side perm_name to navigate for the user's permission bit. perm_name (str): The permission bit name related to the current operation. headmodel (CuneiModel): The model of the document's master record (usually the document header). If this argument is not given, the document locking/unlocking is skipped. paired_gl (list): The specification for the accounting journal database corresponding to the current operation. The member's of the list are: glname: The account journal name in the form of 'GL_<code>' (for example, GL_PAY, GL_REC). gl_headmodel: The CuneiModel for the journal header. paired_col_doc (optional, defaults to 'docno'): The reference column in headmodel. paired_col_gl (optional, defaults to 'docno'): The reference column in gl_headmodel. lock_fld (optional, defaults to 'lock'): The journal lock column in gl_headmodel.

Returns

None if the locking/unlocking is skipped. 403 if the user does not have the valid permission to initiate the document lock. beacon_args: If the locking/unlocking is successful, the function spits back the beacon_args as given.

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:

1. 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.
2. 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_doclock and process_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	datatype (str: 'table', 'data', or 'report'): The data type (location) of the database file. bookcode (str): The name of the database file. In CuneiFox convention, this is usually a 3-lettered string: 'XXX' for general data, 'GL_XXX' for accounting journal data. headmodel (CuneiModel): The model of the document's master record (usually the document header). form (CuneiForm): The form currently being submitted. field (str): The name of the form field where the document ID can be retrieved. (Usually this corresponds to the IntegerField id for the header form, or the ForeignKeyField doc for detail/supplementary forms.) doc_perm_bit (int): The user's page-level permission bit for this operation. head_id_col (str): The column name for the document ID in headmodel. paired_gl (list): (See details under #process_doclock.)
Returns	403 if the user's permission is lower than 2. head_action_dic: A dict in the format {'add':True, 'edit':False, 'del':False}. Each of the 3 Boolean values in the dict indicates whether its corresponding action is allowed at the header level.
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	head_action_dic (dict): Allowed actions at the header level. is_head (bool): Whether the currently submitted form corresponds with the document's master entry.
Returns	409 if the no actions are allowed. At this stage, this is mostly caused by another user's lock on the document. allowed_action: A dict in the format {'add':True, 'edit':True, 'del':True}. Each of the 3 Boolean values in the dict indicates whether its corresponding action is allowed.

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 through cunei_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)]):
    1. A short human-readable description of the verification. This value is the popover text when the mouse cursor hovers above the block.
    2. Pill text, a highly abbreviated shorthand string that appears on the block at all time.
    3. (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)

Example of a Document Page: (1) Document Counter, (2) Document Verification, (3)~(4) Page Button Sets

Mass Populate Route

See more discussion on Mass Populate under Page.

The mass populate route is not defined as a part of the Document Context and is fed directly to the render_template function. Although its use is not limited to multi-component pages, it has enough exclusivity to warrant some discussion here.

The render_template argument mass_populate is a list with 2 members:

1. main_populate_route (url_for route): The route (along with any request parameters) to which the combined populating request should be POSTed.
2. trigger_list ([str,]): The IDs of the DOM elements whose changes should trigger a POSTing of a mass populate request.

Most document pages within CuneiFox system have their mass_populate set as:

mass_populate = [
                    "<mass_populate_route>",
                    ["master.id", "window.pagenav"]
                ]