DEV Community: Explorer

Dynamic BeanShell Hash Invocation in Joget

Explorer — Sun, 26 Apr 2026 12:00:09 +0000

1. Why This Is Useful

When you need to call another BeanShell helper dynamically, hash invocation keeps your main script small and reusable.

This pattern builds a hash string at runtime, executes it with AppUtil.processHashVariable, and captures the output for reuse.

2. Where to Use in Joget

Workflow Tool scripts that need reusable helper logic.
Form/Post-processing scripts that call another BeanShell utility.
Notification-related scripts where output from another function is needed first.

3. Core Idea

Build the hash string with required parameters.
Execute it through AppUtil.processHashVariable(...).
Use returned value in logs, payloads, or downstream logic.

Example hash format used:

#beanshell.captureResponseNotification[process_id=YOUR_PROCESS_ID]#

4. Full Working Code

import org.joget.apps.app.service.AppUtil;
import org.joget.commons.util.LogUtil;
import org.joget.apps.app.model.AppDefinition;
import javax.servlet.http.HttpServletRequest;
import org.joget.workflow.model.WorkflowAssignment;
import org.joget.apps.app.dao.UserReplacementDao;
import org.joget.apps.app.model.UserReplacement;
import org.joget.directory.model.User;
import org.joget.directory.model.service.DirectoryManager;
import org.joget.workflow.model.WorkflowProcess;
import org.joget.workflow.model.service.WorkflowManager;
import org.joget.workflow.util.WorkflowUtil;
import java.util.HashSet;
import java.util.Collection;
import org.json.JSONObject;
import org.json.JSONArray;
import java.net.HttpURLConnection;
import java.net.URL;
import java.io.OutputStream;
import java.nio.charset.StandardCharsets;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import org.joget.apps.form.service.FileUtil;
import java.util.Base64;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import org.joget.apps.app.service.AppUtil;
import org.joget.commons.util.LogUtil;


/*
// c_code #variable.branch_code# and locale
public String getBranchName(String locale){
    String callHashToInsertResponse = 
    "#beanshell.getComplaintDetailsForEmail[c_code=" + "#variable.branch_code#" + "&locale="+ locale + "]#";

    // Evaluate hash
    String result = AppUtil.processHashVariable(callHashToInsertResponse, null, null, null);

    return result;
}
*/

String ProcessID = "testing the process id";

// build valid hash format
String callHashToInsertResponse = 
    "#beanshell.captureResponseNotification[process_id=" + ProcessID + "]#";

// Evaluate hash
String result = AppUtil.processHashVariable(callHashToInsertResponse, null, null, null);

LogUtil.info("Email Integration - API", "Evaluated Hash = " + result);

5. Quick Validation Checklist

Verify the target BeanShell function name is correct.
Confirm all required parameters are included in the hash.
Log output once to validate returned value.
Test with safe sample process IDs before production use.

6. Security and Publishing Note

Replace real process IDs, variable names, and function names with placeholders in public content.
Avoid exposing internal workflow naming conventions.

7. Final Note

This is a strong pattern for reusable Joget scripting: one script orchestrates, another script handles details, and hash invocation connects both.

Follow-up topic: Building a shared BeanShell utility library for multi-process reuse.

Convert Joget Signature Field to Image (Generic Dynamic Table, Field, and ID)

Explorer — Sun, 26 Apr 2026 11:55:35 +0000

1. Why This Is Useful

Joget signature fields store stroke data (JSON), but many use cases need a real image output.

This script converts signature JSON into a PNG image and returns it as a Base64 data URL.

The best part is that it uses dynamic table, field, and id parameters, so you can reuse the same code anywhere without rewriting logic.

Use this when you need to:

preview a signature directly in a form or report,
embed signature image in email/PDF templates,
avoid custom external conversion services.

2. Where to Use in Joget

Form Builder: BeanShell script in a formatter/element that needs image output.
Userview/Report: render returned data URL as image source.
Workflow tools: generate signature image before notifications or documents.

3. Required Input Parameters

Pass these parameters to the script:

table: form table name
field: signature field column
id: record ID

Because these are dynamic inputs, the same script can work across multiple forms and modules.

Example usage pattern:

#beanshell.generateSignature[table=your_table&field=your_signature_field&id=your_record_id]#

4. Full Working Code

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import javax.sql.DataSource;

import java.awt.BasicStroke;
import java.awt.Color;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import org.json.JSONArray;
import org.json.JSONObject;
import javax.imageio.ImageIO;
import java.net.URLDecoder;
import java.util.Base64;

import org.joget.apps.app.service.AppUtil;
import org.joget.commons.util.LogUtil;

// --------------------------------------------------
// Input parameters
// #beanshell.generateSignature[
//   table=app_fd_cpa_comp_question&
//   field=c_consumer_signature&
//   id=UUID
// ]#
// --------------------------------------------------


public String generateJSON(String table, String fieldName, String recordId){
    String callHashToInsertResponse = 
    "#form." + table + "."+ fieldName +"["+ recordId +"]?url#";

    // Evaluate hash
    String result = AppUtil.processHashVariable(callHashToInsertResponse, null, null, null);

    return result;
}



String tableName = table[0];
String fieldName = field[0];
String recordId  = id[0];

LogUtil.info(
    "generateSignature",
    "Params -> table=" + tableName + ", field=" + fieldName + ", id=" + recordId
);

LogUtil.info(
        "Image URL : ",
        generateJSON(tableName, fieldName, recordId)
    );


//Here defines the signature image size
int width = 200;
int height = 80;

try {
    String jsonstr = URLDecoder.decode(generateJSON(tableName, fieldName, recordId), "UTF-8");
    JSONArray jarr = new JSONArray(jsonstr);
    BufferedImage offscreenImage = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
    Graphics2D g2 = offscreenImage.createGraphics();
    g2.setColor(Color.white);
    g2.fillRect(0,0,width,height);
    g2.setPaint(Color.black);
    g2.setStroke(new BasicStroke(2));
    g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
    for (int i = 0; i < jarr.length(); i++) {
        JSONObject jobj = jarr.get(i);
        g2.drawLine(jobj.getInt("lx"), jobj.getInt("ly"), jobj.getInt("mx"), jobj.getInt("my"));
    }

    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ImageIO.setUseCache(false);
    ImageIO.write( offscreenImage, "png", baos );
    baos.flush();
    byte[] imageInByte = baos.toByteArray();
    baos.close();   
    String base64bytes = Base64.getEncoder().encodeToString(imageInByte);
    String src = "data:image/png;base64," + base64bytes;

    return src;
} catch (Exception e) { }

5. Quick Validation Checklist

Signature exists in selected record.
Script returns value starting with data:image/png;base64,.
Image renders correctly in form/userview/report.
Empty/invalid signature JSON is handled safely in your UI.

6. Security and Publishing Note

Replace real table names, field IDs, and record IDs with placeholders in public posts.
Do not publish internal schema naming conventions if they reveal business context.

7. Final Note

This is a practical conversion pattern when your workflow needs image output from Joget signature strokes without adding external services.

Follow-up topic: Auto-attach generated signature images in Joget email notifications.

Trigger Previous Activity in Joget (Controlled Rollback Script)

Explorer — Sun, 26 Apr 2026 11:25:07 +0000

1. Why This Script Is Useful

Sometimes a running process reaches a wrong step because of data issues, user mistakes, or production fixes.

This script lets you rollback selected process instances by:

matching only specific running instances,
aborting from a known current activity,
resuming at a target activity,
restoring workflow variables when possible.

2. Where to Use in Joget

Workflow Builder context: execute as an admin/maintenance script.
Best use case: production correction for specific process instances.
Not a form validator: this operates on workflow engine state.

3. Critical Safety Rules Before Running

Run only with a strict target instance list.
Confirm appId, processDefId, and processVersion first.
Keep logs enabled and review summary counts after execution.
Take backup/snapshot before mass correction.

4. Configuration You Must Edit

Update only these values in the script:

appId
processDefId
processVersion
activityDefIdToAbort
activityDefIdToResume
targetProcessInstanceIds

5. Full Working Code (Unchanged)

import org.joget.workflow.model.service.WorkflowManager;
import org.joget.apps.app.service.AppUtil;
import org.joget.commons.util.LogUtil;
import org.joget.workflow.model.WorkflowActivity;
import org.joget.workflow.model.WorkflowProcess;
import org.joget.workflow.model.WorkflowVariable;

import java.util.Collection;
import java.util.Map;
import java.util.HashMap;

/*
=====================================================================
 PURPOSE
=====================================================================
 This script performs a controlled workflow rollback / jump in Joget.

 - Finds running workflow instances of ONE app + ONE process + ONE version
 - Checks if the instance is currently at a specific activity
 - Force-aborts that activity
 - Starts ANY activity you define (earlier, later, or never-run)
 - Restores workflow variables if the target activity ran before
 - Re-evaluates assignments after rollback

 IMPORTANT:
 - This affects ONLY workflow state, NOT form table data
 - Designed for admin / production-fix usage
=====================================================================
*/

/*
=====================================================================
 GET WORKFLOW MANAGER
=====================================================================
*/
WorkflowManager wm = (WorkflowManager) AppUtil
        .getApplicationContext()
        .getBean("workflowManager");

/*
=====================================================================
 HELPER METHOD:
 Get the latest (current) activity of a process instance
=====================================================================
*/
public WorkflowActivity getLatestActivity(String processInstanceId) {
    Collection activityList = wm.getActivityList(
        processInstanceId,
        0,
        1,
        "dateCreated",
        true
    );

    if (activityList != null && !activityList.isEmpty()) {
        return (WorkflowActivity) activityList.iterator().next();
    }
    return null;
}

/*
=====================================================================
 HELPER METHOD:
 Get the most recent execution of ANY specific activity definition
 (Used to restore workflow variables if activity ran before)
=====================================================================
*/
public WorkflowActivity getLastRecentSpecificActivity(
        String processInstanceId,
        String activityDefId
) {
    Collection activityList = wm.getActivityList(
        processInstanceId,
        null,
        null,
        "dateCreated",
        true
    );

    if (activityList != null && !activityList.isEmpty()) {
        for (Object obj : activityList) {
            WorkflowActivity act = (WorkflowActivity) obj;
            if (activityDefId.equals(act.getActivityDefId())) {
                return act; // Return the latest matching execution
            }
        }
    }
    return null;
}

/*
=====================================================================
 HELPER METHOD:
 Extract all workflow variables from an activity instance
=====================================================================
*/
public Map extractWorkflowVariables(String activityInstanceId) {
    Map vars = new HashMap();

    Collection varList = wm.getActivityVariableList(activityInstanceId);
    for (Object obj : varList) {
        WorkflowVariable var = (WorkflowVariable) obj;
        String value = (var.getVal() != null) ? var.getVal().toString() : "";
        vars.put(var.getId(), value);
    }
    return vars;
}

/*
=====================================================================
 CONFIGURATION SECTION (MODIFY ONLY THIS PART)
=====================================================================
*/
String appId = "your_app_id";
String processDefId = "your_process_def_id";
String processVersion = "your_process_version";

/* Activity where process MUST currently be */
String activityDefIdToAbort = "your_current_activity_def_id";

/* Activity where process will be resumed (ANY activity you want) */
String activityDefIdToResume = "your_target_activity_def_id";

/* Restrict rollback to specific process instances */
String[] targetProcessInstanceIds = {
    "your_process_instance_id"
};

/*
=====================================================================
 SAFETY METHOD:
 Check if current instance is in target list
=====================================================================
*/
boolean isTargetInstance(String processInstanceId, String[] targets) {
    for (int i = 0; i < targets.length; i++) {
        if (processInstanceId.equals(targets[i])) {
            return true;
        }
    }
    return false;
}

/*
=====================================================================
 MAIN EXECUTION LOGIC
=====================================================================
*/
int totalMatched = 0;
int successCount = 0;
int failureCount = 0;

/* Fetch all running workflow instances */
Collection runningProcesses = wm.getRunningProcessList(
    appId,
    processDefId,
    null,
    processVersion,
    null,
    null,
    null,
    null
);

for (Object obj : runningProcesses) {

    WorkflowProcess process = (WorkflowProcess) obj;
    String processInstanceId = process.getInstanceId();

    /* Get current activity */
    WorkflowActivity currentActivity = getLatestActivity(processInstanceId);

    /* Skip if not at expected activity */
    if (currentActivity == null ||
        !activityDefIdToAbort.equals(currentActivity.getActivityDefId())) {
        continue;
    }

    totalMatched++;
    LogUtil.info("Auto-Rollback", "Matched instance --> " + processInstanceId);

    /* Safety check: only allowed instances */
    if (!isTargetInstance(processInstanceId, targetProcessInstanceIds)) {
        LogUtil.info("Auto-Rollback", "Skipped (not in target list) --> " + processInstanceId);
        continue;
    }

    /*
    ===============================================================
     Attempt to restore workflow variables from previous execution
     of the resume activity (if it exists)
    ===============================================================
    */
    Map wfVars = new HashMap();
    WorkflowActivity lastRunOfResumeActivity =
        getLastRecentSpecificActivity(processInstanceId, activityDefIdToResume);

    if (lastRunOfResumeActivity != null) {
        wfVars = extractWorkflowVariables(lastRunOfResumeActivity.getId());
        LogUtil.info("Auto-Rollback",
            "Workflow variables restored from previous execution of --> "
            + activityDefIdToResume);
    } else {
        LogUtil.info("Auto-Rollback",
            "No previous execution found for --> "
            + activityDefIdToResume
            + ", starting fresh");
    }

    /*
    ===============================================================
     Force start the chosen activity
    ===============================================================
    */
    boolean started = wm.activityStart(
        processInstanceId,
        activityDefIdToResume,
        true
    );

    if (started) {

        WorkflowActivity resumedActivity =
            getLatestActivity(processInstanceId);

        /* Restore variables if available */
        if (!wfVars.isEmpty()) {
            wm.activityVariables(resumedActivity.getId(), wfVars);
        }

        /* Re-evaluate assignments */
        wm.reevaluateAssignmentsForActivity(resumedActivity.getId());

        successCount++;
        LogUtil.info("Auto-Rollback",
            "SUCCESS rollback --> " + processInstanceId
            + " resumed at --> " + activityDefIdToResume);

    } else {
        failureCount++;
        LogUtil.info("Auto-Rollback",
            "FAILED rollback --> " + processInstanceId);
    }
}

/*
=====================================================================
 FINAL SUMMARY LOGS
=====================================================================
*/
LogUtil.info("Auto-Rollback", "TOTAL MATCHED --> " + totalMatched);
LogUtil.info("Auto-Rollback", "SUCCESS COUNT --> " + successCount);
LogUtil.info("Auto-Rollback", "FAILURE COUNT --> " + failureCount);

6. Quick Test Checklist

Test on one non-critical instance first.
Verify target instance is currently at activityDefIdToAbort.
Confirm resumed activity is activityDefIdToResume.
Check assignment list after reevaluateAssignmentsForActivity.
Review logs for matched/success/failure counts.

7. Security and Publishing Note

Replace real app IDs, process IDs, version numbers, and instance IDs with generic placeholders before publishing.
Do not expose internal process naming conventions in public posts.

8. Final Note

Use this script as a controlled recovery tool, not as a routine workflow path. With strict targeting and logging, it becomes a reliable production-fix pattern.

Follow-up topic: Bulk rollback strategy with dry-run mode and audit report output.

🧩 Ensure Approver Roles Stay Unique in Joget (BeanShell Validator)

Explorer — Sun, 26 Apr 2026 11:15:46 +0000

1. Why This Matters

If the same user is selected for multiple approval roles, approvals lose segregation and audits become weak.

This validator blocks duplicate user selections at form submission time.

2. Where to Use in Joget

Form Builder: add this as a Custom Validator on each approver-related field.
Suitable fields: dropdown, select box, or user picker fields storing usernames.
Not for Workflow Builder or API Builder: this is pre-submission form validation.

3. Configuration You Must Set

Update these field IDs to match your form:

reviewer
authorizer
approver

Attach the same validator script to each of these fields so each selected value is checked against the other roles.

4. Production-Ready Validator Code

import org.joget.apps.form.model.Element;
import org.joget.apps.form.model.Form;
import org.joget.apps.form.model.FormData;
import org.joget.apps.form.service.FormUtil;
import java.util.Arrays;

public boolean validate(Element element, FormData formData, String[] values) {
    try {
        String reviewerFieldName = "reviewer";
        String authorizerFieldName = "Authorizer";
        String approverFieldName = "Approver";

        Form form = FormUtil.findRootForm(element);

        Element reviewerElement = FormUtil.findElement(reviewerFieldName, form, formData);
        Element authorizerElement = FormUtil.findElement(authorizerFieldName, form, formData);
        Element approverElement = FormUtil.findElement(approverFieldName, form, formData);

        if (values != null && reviewerElement != null && authorizerElement != null && approverElement != null) {
            String[] reviewerValues = FormUtil.getElementPropertyValues(reviewerElement, formData);
            String[] authorizerValues = FormUtil.getElementPropertyValues(authorizerElement, formData);
            String[] approverValues = FormUtil.getElementPropertyValues(approverElement, formData);

            String elementId = FormUtil.getElementParameterName(element);
            String selectedValue = values[0];

            if (selectedValue == null || selectedValue.trim().isEmpty()) {
                formData.addFormError(elementId, "Approver cannot be blank");
                return false;
            }

            if (selectedValue.equals(reviewerValues[0])
                    || Arrays.asList(authorizerValues).contains(selectedValue)
                    || selectedValue.equals(approverValues[0])) {
                formData.addFormError(elementId, "Approver must be unique");
                return false;
            }
        } else {
            return false;
        }

        return true;
    } catch (Exception e) {
        return false;
    }
}

return validate(element, formData, values);

5. Quick Validation Checklist

Select the same user in two roles: form must fail with duplicate error.
Select different users across roles: form must submit.
Leave a required role empty: form must show empty-field error.

6. Security and Publishing Note

Keep sample field IDs generic when sharing publicly.
Do not publish real usernames, emails, internal group names, or environment-specific IDs.

7. Final Note

This validator is small but high impact: it enforces role separation before workflow execution and prevents approval design mistakes early.

Follow-up topic: Dynamic multi-level approver uniqueness (including grid or multi-select fields).

🧭 Get Line Manager Until CEO in Joget Using BeanShell

Explorer — Sun, 26 Apr 2026 11:05:15 +0000

1. Overview

✅ This Joget snippet helps you decide who the next approver should be based on whether a request is escalated or not.

✅ If the item is not escalated, the script takes the requester’s higher-level manager and stores it as the next line manager.

✅ If the item is already escalated, the script keeps moving up the hierarchy by using the previously stored manager value.

✅ In real workflows, this is useful when approval paths depend on organizational levels instead of a fixed list of users.

2. How It Works

⚙️ The script reads a form field that tells Joget whether the record is escalated.

⚙️ If the value is not Yes, it fetches the manager information from the requestor and saves two workflow variables:

⚙️ LineManager for the next approver email.

⚙️ CurrentLineManager for the username of the current hierarchy level.

⚙️ If the value is Yes, the script reuses the previously stored CurrentLineManager and moves one step higher.

⚙️ The idea is simple: keep pushing the workflow to the right person without hardcoding the approval chain in every step.

3. Full Code

import org.joget.commons.util.LogUtil;
import org.joget.workflow.model.service.WorkflowManager;

public void getLineManager() {
    WorkflowManager workflowManager = (WorkflowManager) pluginManager.getBean("workflowManager");

    // Replace these placeholders with your own form and user hash variables.
    String escalatedValue = "#form.your_form.escalated#";

    LogUtil.info("Line Manager Blog", "Escalated value: " + escalatedValue);

    if (!"Yes".equalsIgnoreCase(escalatedValue)) {
        String managerEmail = "#user.{variable.requestor}.manager.email#";
        String managerUsername = "#user.{variable.requestor}.manager.username#";

        LogUtil.info("Line Manager Blog", "Initial manager email: " + managerEmail);

        workflowManager.activityVariable(workflowAssignment.getActivityId(), "LineManager", managerEmail);
        workflowManager.activityVariable(workflowAssignment.getActivityId(), "CurrentLineManager", managerUsername);
    } else {
        String currentManager = "#variable.CurrentLineManager#";
        String nextManagerEmail = "#user.{variable.CurrentLineManager}.email#";

        LogUtil.info("Line Manager Blog", "Current manager: " + currentManager);

        workflowManager.activityVariable(workflowAssignment.getActivityId(), "LineManager", nextManagerEmail);
    }
}

getLineManager();

4. Example Use Cases

✅ Multi-level approval chains where each escalation step goes to the next manager.

✅ HR or compliance flows where the approver depends on who submitted the form.

✅ Internal request routing where the next reviewer changes after each escalation.

✅ Cases where you want a simple and traceable approval path without building a separate routing table.

5. Customization Tips

💡 Replace #form.your_form.escalated# with your real Joget form field.

💡 If your hierarchy uses department heads, team leads, or role-based routing, adjust the hash variables to match your directory structure.

💡 If you want to go up more than one level, you can chain the logic and keep updating CurrentLineManager.

💡 Keep the workflow variable names short and consistent so they are easy to reuse in later scripts.

6. Key Benefits

✅ Less hardcoding in the workflow design.

✅ Easier escalation handling for approval chains.

✅ Cleaner maintenance when the organization structure changes.

✅ Better reuse across similar Joget processes.

7. Security Note

⚠️ Do not publish real usernames, email domains, or internal hierarchy field names if they reveal your organization structure.

⚠️ If your project uses sensitive directory mappings, replace them with generic placeholders before sharing the article.

⚠️ Keep the logic public, but keep the real deployment values private.

8. Final Thoughts

✅ This pattern is small, but it solves a common workflow problem very cleanly.

✅ Once you have a reliable way to move from requestor to manager to higher manager, many approval flows become much easier to maintain.

✅ The main thing to remember is to keep the hierarchy logic generic enough to reuse, but specific enough to remain readable.

💡 Follow-up topic suggestion: Dynamic Manager Escalation in Joget With Conditional Workflow Variables

🎨 Dynamic Dashboard Colors: Mapping Pie Chart Slices to Workflow Status in Joget

Explorer — Sun, 16 Nov 2025 11:24:01 +0000

1. Overview

Dashboards are only effective when they communicate information clearly. When using Joget's Report Builder (which uses ECharts) to create a Status Pie Chart, the default colors are meaningless. We need Green for "Authorized," Red for "Rejected," and Yellow for "Pending."

This client-side JavaScript solution, placed in a Custom HTML element on your Userview page, allows you to hijack the chart after it loads and programmatically apply meaningful colors based on the data label (the workflow status).

2. How It Works

This script performs two main actions: Color Customization and Interactive Filtering.

Action 1: Applying Status Colors 🌈

Chart Initialization: The script waits for the page to load, then targets the specific ECharts instance using its unique HTML ID (e.g., echarts_XYZ).
Data Grab: It pulls the raw data (series[0].data) from the chart.
Color Loop: It loops through every slice. For each slice, it checks the slice's name (the status, like "Authorized") and manually injects a custom itemStyle property with a specific Hex color.
Redraw: Finally, it uses aChart.setOption(option) to force ECharts to redraw the chart with the new color mappings.

Action 2: Interactive Filtering 🖱️

The second part of the script uses the ECharts built-in on('click', ...) event listener to turn each pie slice into a functional link, routing users to specific, pre-filtered Userview dashboards.

3. Full Code

Paste this code into a Custom HTML element (placed after the Report Grid element) in your Joget Userview.

Security Note: The unique ECharts ID (echarts_CHART_ID_HERE) and the Userview paths have been made generic. You must replace these placeholders with your actual values.

<script>
    $(document).ready(function () {
        // IMPORTANT: Replace 'echarts_CHART_ID_HERE' with the actual ID of your chart element.
        var aChart = echarts.init(document.getElementById('echarts_CHART_ID_HERE'));
        var option = aChart.getOption();

        var pieData = aChart.getOption().series[0].data;

        // --- DYNAMIC COLOR MAPPING LOGIC ---
        for (var i = 0; i < pieData.length; i++) {
            var status = pieData[i].name;

            // Set color based on status (Use Hex codes for consistency)
            if (status === 'Approval Pending') {
                option.series[0].data[i].itemStyle = { color: '#FFDD7D' }; // Yellow/Amber
            } else if (status === 'Authorized') {
                option.series[0].data[i].itemStyle = { color: '#9AC4A1' }; // Green
            } else if (status === 'Draft') {
                option.series[0].data[i].itemStyle = { color: '#EEA94E' }; // Orange
            } else if (status === 'Escalated') {
                option.series[0].data[i].itemStyle = { color: 'red' }; // Red Flag
            } else if (status === 'Rejected' || status === 'Request Rejected') {
                option.series[0].data[i].itemStyle = { color: '#DC143C' }; // Crimson (Strong Red)
            } else {
                // Default color for any unexpected or unmapped values
                option.series[0].data[i].itemStyle = { color: 'gray' };
            }
        }

        // Apply the new colors to the chart
        aChart.setOption(option);

        // --- INTERACTIVE CLICK LOGIC ---
        aChart.on('click', function (params) {

            // IMPORTANT: Replace the generic Userview links with your actual paths.

            if (params.name == 'Approval Pending') {
                window.open(`/jw/web/userview/app_name/v/_/pending_dashboard`, "_blank");
            } else if (params.name == 'Authorized') {
                window.open(`/jw/web/userview/app_name/v/_/authorized_dashboard`, "_blank");
            } else if (params.name == 'Rejected') {
                window.open(`/jw/web/userview/app_name/v/_/rejected_dashboard`, "_blank");
            } else if (params.name == 'Escalated') {
                window.open(`/jw/web/userview/app_name/v/_/escalated_dashboard`, "_blank");
            }
            // Generic fall-through: For all other statuses, open the main list filtered by the clicked status name
            else {
                // The hash variable used here (d-6985709-fn_Status) is a Report Grid filter hash.
                window.open(`/jw/web/userview/app_name/v/_/all_document_list?d-GRID_HASH-fn_Status=${params.name}`);
            }
        });
    });
</script>

4. Example Use Cases

✅ Compliance Dashboards: Instantly highlight records that are "Expired" (Red) or "Compliant" (Green).
✅ Service Desk: Show tickets based on priority: "High" (Red), "Medium" (Orange), "Low" (Blue).
✅ Financial Approvals: Use strong, clear colors to represent the stage of the approval process: "Submitted" (Yellow), "Finance Approved" (Light Green), "CEO Approved" (Dark Green).

5. Customization Tips

💡 Using Lookup Objects: For cleaner code, consider replacing the long if/else if chain with a simple JavaScript lookup object (or map). This is easier to update when new statuses are added.
💡 Userview Pathing: The click logic uses window.open(...) to direct users. Ensure you replace app_name and the specific Userview categories (_) with your application's actual URLs.
💡 ECharts ID Safety: If you modify and save your Report Grid element, Joget sometimes changes the unique ECharts ID. If your colors disappear, this is the first place to check!

6. Key Benefits

🚀 Enhanced Clarity: Makes dashboards instantly readable by associating colors with conventional meanings (red=bad, green=good).
🚀 Improved UX: Turns a static visualization into an interactive filter, drastically reducing the clicks needed for users to drill down into data.
🚀 Maintainability: All coloring rules are contained in one simple, client-side script, separate from the core reporting configuration.

7. Security Note

🔒 Userview Security: The click logic exposes Userview URLs. Ensure that the target dashboard pages (/pending_dashboard, /rejected_dashboard, etc.) are protected with appropriate Userview Permission settings so unauthorized users cannot access the underlying data lists directly.

8. Final Thoughts

By using client-side scripting to customize the ECharts object, you transform a generic Joget dashboard into a highly intuitive and interactive data visualization tool. This simple technique is fundamental for professional-grade reporting in Joget.

💾 Custom Approval History in Joget: Direct SQL Insertion via BeanShell Tool

Explorer — Sun, 16 Nov 2025 11:19:31 +0000

1. Overview

While Joget's Form Binders and built-in audit trails handle standard data storage, complex enterprise applications often require specialized auditing and history tracking. This is particularly true when you need a dedicated, sequentially numbered Approval History table that links to multiple main processes for easy reporting.

This post details an advanced, expert technique using a Java/BeanShell Process Tool to perform a direct SQL INSERT into a custom database table (app_fd_approval_history). This method grants granular control over the primary key (id) sequence and allows you to log specific metadata (user, status, date) mid-workflow, decoupled from the main form's binder.

2. How It Works

The script operates as a robust, transactional database logger configured as a workflow tool.

⚙️ Database Connection: It securely retrieves the Joget application's main database connection via the setupDataSource Spring bean using AppUtil.getApplicationContext().getBean("setupDataSource").
⚙️ Manual ID Generation: It executes SELECT MAX(CAST(id AS SIGNED)) to find the highest existing sequential ID. Crucially, it casts the id (often stored as a string in Joget forms) to a signed integer to ensure correct numerical ordering, and then calculates the nextId.
⚙️ Dynamic Data Capture: It utilizes Joget Hash Variables (e.g., #form.new_request.createdByName#) to dynamically capture real-time form data, user information, and timestamps directly from the workflow instance before preparing the data for insertion.
⚙️ Execution & Cleanup: It uses a PreparedStatement to safely execute the INSERT query. The finally block is critical, ensuring the database connection is closed (conn.close()) even if an exception occurs, preventing connection leaks.

3. Full Code

This code is configured as a BeanShell within a Joget workflow, typically placed immediately after a submission or approval step where the status transition occurs.

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.sql.DataSource;
import org.joget.apps.app.service.AppUtil;
import org.joget.commons.util.LogUtil;

public void insertNewData() {
    Connection conn = null;
    try {
        LogUtil.info("ApprovalHistoryTool", "Starting Approval History Creation Tool");

        // 1. Get the primary application data source
        DataSource ds = (DataSource) AppUtil.getApplicationContext().getBean("setupDataSource");
        conn = ds.getConnection();

        // 2. Determine the next sequential ID manually
        String maxIdQuery = "SELECT MAX(CAST(id AS SIGNED)) FROM app_fd_approval_history";
        PreparedStatement maxIdStmt = conn.prepareStatement(maxIdQuery);
        ResultSet resultSet = maxIdStmt.executeQuery();

        int nextId = 1; 
        if (resultSet.next()) {
            nextId = resultSet.getInt(1) + 1;
            LogUtil.info("ApprovalHistoryTool", "Next ID to be inserted: " + nextId);
        }
        maxIdStmt.close();

        // 3. Prepare the INSERT statement
        String insertQuery = "INSERT INTO app_fd_approval_history" +
                "(id, c_name, c_status, c_date, c_remark, c_request_for, c_parent_id)" +
                "VALUES (?, ?, ?, ?, ?, ?, ?)";

        // 4. Capture dynamic data using Joget Hash Variables
        // IMPORTANT: Replace the placeholder values (#form.new_request...) with your actual form IDs.
        String name = "";
        String status = "";
        String date = "";

        // Conditional logic based on a form field value (Request Type)
        if ("New".equals("#form.new_request.request_type#")) {
            name = "#form.new_request.createdByName#";
            status = "Request Submitted";
            date = "#form.new_request.dateCreated#";
        } else if ("Update".equals("#form.new_request.request_type#")) {
            name = "#form.new_request.modifiedByName#";
            status = "Update Request";
            date = "#form.new_request.dateModified#";
        }

        String remark = "#form.new_request.reason#";
        String requestFor = ""; 
        String foreignKey = "#form.new_request.id#"; // Links to the main form record

        PreparedStatement insertStmt = conn.prepareStatement(insertQuery);

        // Set values using the PreparedStatement (prevents SQL injection)
        insertStmt.setInt(1, nextId);
        insertStmt.setString(2, name);
        insertStmt.setString(3, status);
        insertStmt.setString(4, date);
        insertStmt.setString(5, remark);
        insertStmt.setString(6, requestFor);
        insertStmt.setString(7, foreignKey);
        LogUtil.info("ApprovalHistoryTool", "Linking history to parent ID: " + foreignKey);

        // 5. Execute and close
        insertStmt.executeUpdate();
        insertStmt.close();

        LogUtil.info("ApprovalHistoryTool", "Data inserted successfully in Approval History Table.");
    } catch (Exception e) {
        LogUtil.error("ApprovalHistoryTool", "Error inserting data: " + e.getMessage(), e);
    } finally {
        // 6. Ensure connection is always closed
        try {
            if (conn != null && !conn.isClosed()) {
                conn.close();
            }
        } catch (SQLException e) {
            LogUtil.error("ApprovalHistoryTool", "Error closing connection: " + e.getMessage(), e);
        }
    }
}

insertNewData();

4. Example Use Cases

✅ Complete Audit Trail: Creating a persistent, uneditable log of every approval, rejection, and modification action for compliance or security auditing.
✅ Custom Reporting: Facilitating streamlined reporting on approval cycle times, user actions, and status changes using a normalized, dedicated history table structure.
✅ Sequential Primary Keys: Implementing simple, strictly sequential, numeric ids for history records, which are far easier for end-users and reports to reference than default UUIDs.

5. Customization Tips

💡 Hash Variable Validation: Always verify that your Joget Hash Variables are correctly returning the required values (e.g., using LogUtil.info()) before trusting them in a database insertion.
💡 Error Logging: Expand the catch block to include logic that notifies an administrator (e.g., sends an email) if the database insertion fails, rather than just logging the error.
💡 Time Zone Control: Dates retrieved via Hash Variables may require explicit formatting. Use Java's SimpleDateFormat inside the script to format the date string before insertion, ensuring consistency across different geographic locations.

6. Key Benefits

🚀 Granular Control: Provides developers with complete control over SQL execution, allowing for custom data structures and transactional integrity.
🚀 Decoupled Logging: Separates the audit trail from the main form data, making both the main table and the history table cleaner and more performant.
🚀 Security & Consistency: Use of PreparedStatement protects against basic SQL injection and guarantees the field values are treated as data, not code.

7. Security Note

🔒 SQL Injection Prevention: The use of PreparedStatement with placeholder ? marks is the most critical security feature in this script. It prevents external data (even malicious data from a form field) from altering the structure of the SQL command.
🔒 Resource Leaks: The meticulous implementation of the finally block to close the Connection is non-negotiable. Failing to close connections will lead to resource exhaustion and potential database failure under load.

8. Final Thoughts

Mastering direct database interaction via BeanShell Tools gives you expert-level control over your Joget application's data layer. This technique is indispensable for building robust, compliance-ready solutions that require custom, sequential auditing and complex data relationships.

🚨 Resuming Stuck Joget Workflow Tools with API

Explorer — Sun, 16 Nov 2025 10:45:20 +0000

1. Overview

A critical issue in production environments is a workflow process halting when the Joget server unexpectedly goes down. While user activities are often easy to "Complete" manually via the Process Monitor, processes stuck specifically on a Tool Plugin (like an Email Tool or integration script) often resist normal completion attempts. The "Complete" button in the Process Monitor UI has no effect because a Tool is a server-side action, not a user-driven workflow task.

This post reveals the expert method, recommended by the Joget support team, to reliably force-resume or restart a stuck tool using the built-in JSON Monitoring API.

2. How It Works

When a tool element is stuck, the workflow engine typically believes the tool is still running or failed to complete its transaction. The solution is to issue a direct command to the workflow engine using the API endpoint specifically designed to manage activity states:

API Endpoint: The /monitoring/activity/start endpoint is used to push the activity back into the "ready" or "running" state, effectively forcing a re-execution of the tool's logic.
Authentication: The API requires administrative credentials (Basic Authentication or URL parameters) to ensure only authorized users can manipulate the workflow state.
Parameters: You must provide the specific Process Instance ID and the Activity Definition ID (the unique ID of the tool element in the workflow designer) to target the exact stuck step.

3. Full API Command

The API call uses the POST method and the /monitoring/activity/start/ endpoint.

POST /jw/web/json/monitoring/activity/start/(*:processId)/(*:activityDefId)

Example Request (Using URL Authentication)

http://localhost:8080/jw/web/json/monitoring/activity/start/24002_sampleApp_requestForm_approver_process/email_on_received?j_username=admin&j_password=admin

Parameter	Description	Example Value
Method	Must be used to change state.	`POST`
`processId`	The specific instance ID of the stalled workflow.	`24002_sampleApp_requestForm_approver_process`
`activityDefId`	The unique ID of the stuck Tool Plugin.	`email_on_received`
`j_username`/`j_password`	Admin credentials for authorization.	`admin`/`admin`

4. Example Use Cases

✅ Integration Failure Recovery: A process is stuck on an API Tool Plugin because the external service was temporarily unavailable during a server interruption. Restarting the tool allows the integration to run again.
✅ Notification Retries: An Email Tool failed to send due to a mail server timeout. The API call forces the email tool to re-execute and notify users correctly.
✅ Data Sync Issues: A Script Tool responsible for data synchronization failed mid-execution and left the process in an ambiguous state. The API forces the engine to resolve the tool's status and advance the flow.

5. Customization Tips

💡 Postman Environment: Create an environment variable in Postman for your base Joget URL (e.g., http://localhost:8080/jw) and your admin credentials to quickly execute these recovery calls without re-typing.
💡 Basic Auth: For better security, use the Basic Auth tab in Postman or similar tools instead of passing credentials in the URL parameters, especially in non-local environments.
💡 Logging: Before using this method, always consult the Joget server logs (wflow.log, catalina.out, etc.) to understand why the tool failed initially. Addressing the root cause is crucial to prevent recurrence.

6. Key Benefits

🚀 Immediate Process Continuity: Quickly recovers stalled business processes without requiring manual data intervention or lengthy server restarts.
🚀 High Data Integrity: By utilizing the official Monitoring API, you maintain the integrity of the workflow state within the Joget engine.
🚀 Targeted Fix: Allows administrators to precisely fix specific process instances without affecting other running processes.

7. Security Note

🔒 API Exposure: This API grants the power to manipulate live workflow states. Never expose this endpoint publicly. Ensure that any system making calls to this API uses strong administrative credentials and operates exclusively within a secure network environment.

8. Final Thoughts

Understanding how to directly interface with the Joget workflow engine via the Monitoring JSON API is a critical skill for any advanced Joget administrator. It provides the necessary surgical precision to handle edge cases like stuck Tool Plugins, ensuring your production workflows remain resilient and functional even after unexpected interruptions.

🛠️ Dynamic Joget Form Generation Using BeanShell Scripting

Explorer — Sun, 16 Nov 2025 10:02:36 +0000

1. Overview

While Joget's Form Builder is excellent for visual design, there are advanced scenarios where you need to generate form definitions programmatically. This is typically done when a form's structure is dynamic or based on an external metadata source (e.g., a database table, a configuration list, or another Joget list).

This blog post analyzes a powerful BeanShell/Groovy script designed to run within Joget's server-side tools. It reads form field definitions from a FormRowSet (or similar data source) and constructs a complete Joget Form Definition JSON, finally saving it to the App Definition.

2. How It Works

The script operates by constructing the complete JSON object that defines a Joget Form, adhering strictly to the internal schema used by the platform.

⚙️ Data Source: The script assumes field metadata (ID, Label, Class Name) is available in the rows variable (a FormRowSet).
⚙️ Field Construction: It iterates over the rows. For each entry, it creates a string representation of a JSON object for a single form element, ensuring the className (field type) and properties (ID and Label) are correctly inserted.
⚙️ JSON Aggregation: All individual field JSONs are placed into a JSONArray (fields). This array is then inserted as the content of the Form's main Column element.
⚙️ Form Saving: Finally, the fully assembled JSON is wrapped in a FormDefinition object. The script uses the AppService bean to call createFormDefinition, making the new form instantly available in the App Designer.

3. Full Code

This code is typically executed within a Process Tool using the BeanShell/Groovy language or in a Form/Datalist Binder script where the rows variable is populated.

import java.util.Collection;
import org.joget.apps.app.model.AppDefinition;
import org.joget.apps.app.model.FormDefinition;
import org.joget.apps.app.service.AppService;
import org.joget.apps.app.service.AppUtil;
import org.joget.apps.form.model.FormRow;
import org.joget.apps.form.model.FormRowSet;
import org.joget.commons.util.LogUtil;
import org.json.JSONArray;
import org.json.JSONObject;

// Get form metadata from request or script tool properties
String formDefId      = formData.getRequestParameter("form_def_id");
String formName       = formData.getRequestParameter("form_name");
String formTableName  = formData.getRequestParameter("form_table_name");

// Example: Assume 'rows' is a FormRowSet containing field configurations
// FormRowSet rows = ... 

try {
    JSONArray fields = new JSONArray();

    // Loop through the source data (e.g., field definitions)
    for (FormRow row : rows) {
        String fieldId = row.getProperty("field_id");
        String fieldLabel = row.getProperty("field_label");
        // Must be a valid Joget Form Element class name (e.g., org.joget.apps.form.lib.TextField)
        String className = row.getProperty("field_type");

        JSONObject formElement;

        // Build the JSON structure for a single form element
        formElement = new JSONObject("{\n" +
                                        "    \"className\" : \"" + className + "\",\n" +
                                        "    \"properties\": {\n" +
                                        "        \"controlField\": \"\",\n" +
                                        "        \"id\": \"" + fieldId + "\",\n" +
                                        "        \"label\": \"" + fieldLabel + "\",\n" +
                                        "        \"permissionHidden\": \"\",\n" +
                                        "        \"readonly\": \"\",\n" +
                                        "        \"readonlyLabel\": \"\",\n  " +
                                        "        \"size\": \"\",\n" +
                                        "        \"validator\": {\n" +
                                        "            \"className\": \"\",\n" +
                                        "            \"properties\": {}\n" +
                                        "        },\n" +
                                        "        \"value\": \"\",\n" +
                                        "        \"workflowVariable\": \"\"\n" +
                                        "    }\n" +
                                        "}");

        fields.put(formElement);
    }

    // Embed all generated fields into the main Form structure
    JSONObject form = new JSONObject("{\n" +
    "    \"className\": \"org.joget.apps.form.model.Form\",\n" +
    "    \"elements\": [{\n" +
    "        \"className\": \"org.joget.apps.form.model.Section\",\n" +
    "        \"elements\": [{\n" +
    "            \"className\": \"org.joget.apps.form.model.Column\",\n" +
    "            \"elements\":" + fields.toString() + ",\n" +
    "            \"properties\": {\"width\": \"100%\"}\n" +
    "        }],\n" +
    "        \"properties\": {\n" +
    "            \"id\": \"section1\",\n" +
    "            \"label\": \"Dynamic Fields Section\"\n" +
    "        }\n" +
    "    }],\n" +
    "    \"properties\": {\n" +
    "        \"description\": \"Dynamically generated form.\",\n" +
    "        \"id\": \"" + formDefId + "\",\n" +
    "        \"loadBinder\": {\n" +
    "            \"className\": \"org.joget.apps.form.lib.WorkflowFormBinder\",\n" +
    "            \"properties\": {}\n" +
    "        },\n" +
    "        \"name\": \"" + formName + "\",\n" +
    "        \"noPermissionMessage\": \"\",\n" +
    "        \"permission\": {\n" +
    "            \"className\": \"\",\n" +
    "            \"properties\": {}\n" +
    "        },\n" +
    "        \"postProcessor\": null,\n" +
    "        \"postProcessorRunOn\": \"create\",\n" +
    "        \"storeBinder\": {\n" +
    "            \"className\": \"org.joget.apps.form.lib.WorkflowFormBinder\",\n" +
    "            \"properties\": {}\n" +
    "        },\n" +
    "        \"tableName\": \"" + formTableName + "\"\n" +
    "    }\n" +
    "}");

    // Save the new Form Definition to the current App
    FormDefinition formDefinition = new FormDefinition();
    formDefinition.setJson(form.toString());
    formDefinition.setId(formDefId);
    formDefinition.setName(formName);
    formDefinition.setTableName(formTableName);

    AppService appService = (AppService) AppUtil.getApplicationContext().getBean("appService");
    AppDefinition appDef = AppUtil.getCurrentAppDefinition();
    Collection errors = appService.createFormDefinition(appDef, formDefinition);

    // Optional: Log errors if form creation failed
    if (errors != null && !errors.isEmpty()) {
        LogUtil.warn("FormCreator", "Errors encountered while creating form: " + errors.toString());
    }
} catch (Exception ex) {
    LogUtil.error("FormCreator", ex, "Cannot Create Form");
}

4. Example Use Cases

✅ Dynamic Survey Generation: Create different forms instantly based on survey questions stored in a master configuration list.
✅ Automated Integrations: Automatically generate forms that mirror the structure of an external API or third-party database table, minimizing manual development work.
✅ User-Defined Forms: Allow specific power-users to define the fields they need in a secondary Joget list, then use this script to generate the final functional form.

5. Customization Tips

💡 Field Type Mapping: Use a map structure in your BeanShell script to translate simple data types (e.g., "TEXT") from your source rows into the necessary full Java Class Names (e.g., "org.joget.apps.form.lib.TextField").
💡 Adding Complex Properties: For field types like Select Boxes, dynamically add the options or optionsBinder properties to the formElement JSON to ensure the new field is fully functional upon creation.
💡 Metadata Refresh: If you use this script to update a form, use appService.updateFormDefinition instead of createFormDefinition.

6. Key Benefits

🚀 Metadata-Driven Design: Decouples form structure from application code, making forms easier to manage and update.
🚀 Consistency: Ensures all generated forms follow a consistent structure (e.g., using the same default binders and field properties).
🚀 Extensibility: Enables the creation of complex applications where form fields are determined by business rules or configuration, not just static design.

7. Security Note

🔒 Access Control: Since this script can alter the core application definition, it must be carefully permissioned. It is best used in a workflow process tool that runs under the secure system user account or is triggered only by application administrators. Avoid exposing this logic directly in front-end form validation or client-side scripts.

8. Final Thoughts

Leveraging BeanShell to dynamically manipulate Joget's JSON configurations is the pinnacle of advanced Joget development. It unlocks the ability to build flexible, configuration-driven solutions that are resilient to changes in business requirements.

Mastering BeanShell Hash Variables in Joget: The Most Basic & Practical Guide

Explorer — Sun, 16 Nov 2025 07:49:01 +0000

1.Create an App Variable

2.call it

Points to Note Down:

It only Return String.
You can pass Dynamic Values to it.

How To Pass dynamic values to Beanshell hash.

Call it by passing the dynamic value.

🌍 Auto-Load Multilingual Dropdown Labels in Joget Using Platform Locale

Explorer — Tue, 11 Nov 2025 06:17:11 +0000

🧩 Overview

When building multilingual Joget apps, it’s important for dropdowns (Select Boxes) to automatically display values in the user’s active language — whether that’s English, Arabic, or any other supported locale.

In this guide, you’ll learn how to configure a Joget Select Box to automatically load the localized label based on the platform’s current language setting.

This approach ensures that users see the same data, but with labels translated according to their locale — all without extra scripting.

⚙️ How It Works

💡 The solution uses:

A SQL query as the Select Box’s options source.
Joget’s variable #platform.currentLanguage# to detect the logged-in user’s interface language.
A CASE statement in SQL to conditionally choose between Arabic and English column names.

Whenever the user changes the platform locale (via User Profile or /web/userview language toggle), the dropdown automatically displays the correct labels.

💻 Full Code

Use the following SQL query in your Select Box’s “Options Binder → JDBC Binder → SQL Query”:

SELECT 
    c_code AS value, 
    CASE '#platform.currentLanguage#'
        WHEN 'ar' THEN c_name_ar
        ELSE c_name_en
    END AS label
FROM app_fd_governate_mst
ORDER BY label

✅ Explanation:

c_code → The stored value in Joget (e.g., 001, 002, etc.)
c_name_en → English name of the location
c_name_ar → Arabic name of the location
#platform.currentLanguage# → Joget’s built-in variable that returns "ar", "en", or another locale code depending on the user’s active language

🧠 Example Use Cases

🌍 Government or Region Dropdowns — show English or Arabic names dynamically.
🏢 Branch Selector — display localized branch names based on user locale.
🏫 School / University Lists — handle multilingual labels seamlessly.
📦 Product Category Selector — automatically adjust category names to the interface language.

🛠️ Customization Tips

💡 Add more languages:
You can extend the CASE statement to support multiple locales:

CASE '#platform.currentLanguage#'
    WHEN 'ar' THEN c_name_ar
    WHEN 'fr' THEN c_name_fr
    ELSE c_name_en
END

⚙️ Default language fallback:
ELSE c_name_en ensures that English labels appear when no match is found.

🗂️ Table naming convention:
Keep your table name generic — e.g., app_fd_location_mst — to avoid exposing project-specific data.

🌟 Key Benefits

✅ Fully automatic localization — no extra scripting or filters required.
⚙️ Simple SQL-only setup — works directly in Select Box configuration.
💬 Consistent user experience — respects platform locale settings.
📱 Multilingual scalability — add new columns and locales easily.

🔒 Security Note

⚠️ Always ensure that:

The SQL query only reads from safe, authorized tables.
No sensitive information is exposed via the label column.
Use parameterized queries if dynamic filtering is added later.

🗑️ Add Delete Button and Add Row Feature in Joget Spreadsheet using JS

Explorer — Tue, 11 Nov 2025 05:44:52 +0000

🧩 Overview

In Joget, the Spreadsheet form element (powered by Handsontable) is perfect for managing tabular data inside forms.
However, it doesn’t natively provide built-in row-level delete buttons or a convenient add row feature.

In this guide, we’ll learn how to:
✅ Add a delete button to each row in a Joget Spreadsheet.
✅ Create a separate “Add Row” button that dynamically inserts new rows.
✅ Keep the entire implementation simple, secure, and fully functional.

⚙️ How It Works

💡 The approach uses a custom column renderer and a jQuery button event:

The custom renderer injects a Delete button in a column cell.
The button calls hot.alter("remove_row", row) to delete that row.
A separate Add Row button triggers hot.alter("insert_row_below") to insert a new row at the bottom.
Both actions are performed dynamically without reloading the form.

🧠 Important:

Set the spreadsheet column format type to Custom.
Paste the renderer script directly in the custom field configuration.
Avoid adding any extra comments inside the renderer function (to prevent Joget parser issues).

💻 Full Code

<!-- 🔹 Place this inside your Spreadsheet column (Format Type: Custom) -->
{ { 
  renderer: function (instance, td, row, col, prop, value, cellProperties) { 
    td.innerHTML = "<button type='button' class='eaction'>#i18n.ocs_delete_btn#</button>"; 
    td.style.textAlign = "center"; 
    $(document).ready(function () { 
      let hot = FormUtil.getField("appointments_spreadSheet").data("hot"); 
      let btn = td.querySelector(".eaction"); 
      btn.onclick = function (e) { 
        e.preventDefault(); 
        e.stopPropagation(); 
        hot.alter("remove_row", row); 
      }; 
    }); 
  } 
} }

// 🔹 Add this script in a Custom HTML element below your Spreadsheet

$("#addRowBtn").on("click", function(e) {
    e.preventDefault();
    let hot = FormUtil.getField("appointments_spreadSheet").data("hot");
    console.log({hot: hot});
    if (!hot) {
        console.error("Handsontable not initialized");
        return;
    }

    try {
        let lastRow = hot.countRows();
        hot.alter("insert_row_below", lastRow);
    } catch (err) {
        console.error("Failed to add row", err);
    }
});

<!-- 🔹 Add Row Button -->
<button id="addRowBtn" class="btn btn-primary">
  ➕ Add Row
</button>

🧠 Example Use Cases

✅ Employee Shift Planner – Quickly add or remove shift rows.
✅ Project Task Tracker – Manage task entries dynamically.
✅ Material Request Form – Add/remove item rows on demand.
✅ Appointment List – Delete canceled appointments instantly.

🛠️ Customization Tips

💡 To change the delete button label:
Replace

#i18n.ocs_delete_btn#

with plain text (e.g., "Delete" or "Remove").

⚙️ To use a custom Spreadsheet ID:
Update this line:

FormUtil.getField("appointments_spreadSheet")

to match your spreadsheet’s field ID.

🎨 To style buttons:
Apply CSS in a Custom HTML element:

<style>
  .eaction {
    background-color: #e74c3c;
    color: #fff;
    border: none;
    padding: 5px 10px;
    border-radius: 6px;
  }
  #addRowBtn {
    margin-top: 10px;
  }
</style>

🌟 Key Benefits

✅ User-friendly: Adds clear visual controls to manage rows.
⚙️ Lightweight: Uses only jQuery and built-in Joget APIs.
🚀 Instant updates: No form reload needed.
🧩 Reusable: Works in any spreadsheet-based form.
🔧 Customizable: Easily adjust button text, color, or logic.

🔒 Security Note

⚠️ Ensure that delete actions are contextually safe —

Only use this feature for client-side data entry (not for record deletion in the database).
If connected to backend records, validate all deletion logic on the server side before applying changes.