Pages and records
Decide which datasets a role may open and which rows belong in its scope.
An internal admin panel should let authorized people perform specific business operations. It should not expose every table, every column, and every possible edit simply because those things exist in the database.
PHPRunner can provide the application framework, while the important work is deciding which operations are legitimate and how each one should be controlled and recorded.
Treat an admin panel as a collection of approved business actions. Give each role only the records, fields, and commands it needs; validate important changes; require confirmation for high-impact operations; and record who changed what. Database access alone is not an authorization model.
“Edit customer row” is vague. “Suspend account,” “change billing contact,” and “approve credit limit” are understandable actions with different permissions and checks. Named actions make the interface safer because users can see the consequence before they make the change.
Decide which datasets a role may open and which rows belong in its scope.
Decide what may be viewed, edited, exported, approved, or deleted.
Reject changes that violate dependencies, status rules, or required evidence.
Record the user, time, action, and material before-and-after values.
Administrators sometimes need broader access for support or correction. Make that access explicit and rare. A separate role, extra confirmation, and a complete audit record are safer than quietly giving every administrator unrestricted editing rights.
PHPRunner builds authenticated lists and forms around an existing database and supports role-based, record-level, page, field, and action permissions. Custom buttons and events can turn sensitive edits into named operations with validation, confirmation, and audit logging.