Skip to main content

Security Workbench

The Security Workbench screen is the single editor for every JD Edwards security entry. One line per (Security Type, User / Role, Object). The same data the JDE P00950 Work With User / Role Security form maintains — but on one grid, with filters, sort and bulk edits.

Add, change or remove an entry directly on the row. The dialog adapts its fields to the security type: Object Name and Action flags for application security, Data Item for column security, From / Thru actions for action security, etc.

At a glance​

Nomajde · Security Maintenance · Security WorkbenchCATEGORYTYPEUSER / ROLEOBJECTDATA ITEMRUNVIEWADDCHGDELOBJECTS1FIN_BOOKKEEPERP0411—OBJECTS2FIN_BOOKKEEPERW0411AVLDGJ————ALIAS4PROC_BUYERP4310RPER——OTHERSAPROC_BUYERP4310PORLSE—————READING THE DOTSGreen = the action is granted · red = the action is denied · dash = the column does not apply to this security type.

Goal of the view​

For each security entry that exists in JDE:

  • Every security type in one place. Application security, action security, row security, column security, processing-option security, tab security — instead of separate forms in the JDE security workbench, every type sits on one grid filtered by Type.
  • The action flags side by side. Run, View, Add, Change, Delete — the per-row grant / deny indicators are visible without opening the row.
  • The dialog adapts. Only the fields that apply to the selected security type are shown — Object Name for application security, Data Item for column security, From / Thru action codes for action security. No clutter.

Columns​

ColumnSourceWhat it tells you
CategorySEC_TYPE — broad category.OBJECTS, ALIAS or OTHERS — groups the JDE security types into the three buckets the dialog uses to decide which fields to show.
TypeFSSETY — specific security type code.The JDE security type: 1 for application, 2 for column, 3 for processing option, 4 for row, 5 for tab, 6 / 7 / 9 for processing-option variants, A for action, S for solution explorer, etc.
User / RoleFSUSER — JDE identifier.The user or role the entry applies to.
ObjectFSOBNM — object name.The application, form or table the entry applies to.
Data ItemFSDTAI — data item alias.The data dictionary item (for column and action security).
From / ThruFSFRDV, FSTHDV — action / version range.The action code range (for action security).
Run / View / Add / Change / DeleteFSRUN, FSVWYN, FSA, FSCHNG, FSDLT — Y / N flags. Displayed as green / red dots.Per-action grant or deny. A dash means the action does not apply to the security type on that row.

Additional JDE flags carried on the row but hidden by default: install, OK, copy, update, attention markers, system code, owner display, function name, function number, exit ID, table ID, text ID, path — and the audit columns (program, job, date, time).

Edit dialog​

Click Add in the toolbar to register a new security entry, or double-click a row to edit. The dialog has one tab, three columns wide. The fields shown depend on the Type — the dialog hides the columns that do not apply.

FieldWhen it appears
CategoryAlways — sets the broad category (OBJECTS, ALIAS, OTHERS).
TypeAlways — the specific JDE security type. Mandatory.
User / RoleAlways. Mandatory. The lookup filters by the Category.
ObjectWhen Category is ALIAS, OBJECTS or OTHERS. Mandatory for most types.
Data ItemWhen Category is ALIAS or OTHERS and the type is column, action, row or similar.
From actionAction-security types — the start of the action range.
Thru actionWhen Type = 4 (row security on alias) — the end of the action range.
RunTypes that grant run (3, 6, 7, 9, A, B, M, S).
ViewTypes that grant view (2, 4, 5, 7, 8, 9, A, G, I, K, U).
Add / Change / DeleteAction-security types — turn the row into a grant or a deny.
OK / Copy / Update / AttentionObject-level action codes for specific JDE types.

The unique key is the full combination — JDE allows several rows for the same (User, Object) when the security type differs.

Bulk edit on the grid​

The security workbench is the screen where the security administrator spends most of their time — and most of the work is repetitive: copy an entry to ten more users, flip View from Y to N on every action row of an application, deny a sensitive form across a whole role family. Nomajde supports this directly on the grid.

Bulk edit — three patterns covered on the gridMULTI-SELECTSelect N rows, edit onceTick the rows that need the samechange, modify the column on onerow, the change applies to all.COPY TO USER / ROLEReplicate a row to several targetsRight-click an entry, pick thetarget list, the same row isinserted for each one.EXCEL UPLOADHundreds of rows in one importExport the grid, edit offline,re-upload — the SI's bundlebecomes live in one click.
PatternWhen to use it
Multi-selectTick the rows that need the same change (e.g. set View to N on five application-security entries for the same role), then edit the column on one of the ticked rows — the change is written to every selected row in a single save.
Copy to user / roleRight-click a row, pick Copy to user or Copy to role, choose the target list — the same security entry is inserted for every target. Use this to extend a single grant to a set of users without retyping.
Excel uploadExport the grid (filtered as needed), edit hundreds of rows offline, then re-import via the toolbar's upload action. The standard Add dialog handles single rows; the upload is meant for the bundles that ship with a new module.

Every bulk action follows the same row-level validation as the single-row edit — a missing required field or an invalid flag combination stops the save, and the operator sees which row failed.

Dynamic columns and filters​

The security workbench table holds 35+ columns, but only a subset applies to any single security type. The grid takes advantage of this by hiding the columns that do not apply to the rows currently visible.

When the filter isThe columns that surfaceThe columns that hide
Type = 1 (Application security)Object, Run, View, Add, Change, DeleteData Item, From / Thru action
Type = 2 (Column security)Object, Data Item, View, ChangeRun, Add, Delete, From / Thru
Type = 3 / 6 / 7 / 9 (Processing options)Object, Run, ViewAdd, Change, Delete, Data Item
Type = 4 (Row security)Object, Data Item, From / Thru, View, Add, Change, Delete(all action columns visible)
Type = A (Action security)Object, Data Item, From action, Add, ChangeView, Thru action

The same logic drives the edit dialog: when the type is 2 (column security), the dialog only shows the fields meaningful for column security; when the type is 1 (application security), it switches to the application columns. There is never a stale, unused field to ignore.

Column visibility can also be overridden manually from the Columns button on the toolbar — useful when an administrator wants a specific column visible across all types for an audit export.

Tips & best practices​

  • Filter on Type first — the screen carries every JDE security type, and the right filter (e.g. Type = 1 for application security) collapses both the rows and the visible columns to a focused view.
  • Multi-select before bulk edit. Hold Shift to select a range or Ctrl to pick individual rows, then edit any column — the change applies to every selected row.
  • Use Copy to user / role to extend a row to a list of targets. Faster than retyping, and the copies carry the standard audit columns automatically.
  • Excel upload for SI-delivered security bundles. The standard Add flow handles single rows; the upload is meant for the dozens of rows that ship with a new module.
  • A deny on All Actions with User = *PUBLIC plus targeted grants on roles is the standard JDE pattern. The grid makes it easy to read whether the deny is in place for every object.
  • After bulk changes, run Nomasx-1 → Applications → Rights to confirm the effective rights match the intent — the workbench shows what is configured, Rights shows what JDE will compute at sign-on.