Fuuz Setup Data Management Table Screen Standard
Specification for Creating a Setup Data Management (SDM) Table Screen in Fuuz
Introduction
This specification provides guidance for designing and implementing a "Table Screen" in Fuuz for managing setup data. Setup Data Management (SDM) focuses on administrative entities such as types, statuses, groups, and categories. These are typically restricted to administrators and are used by end users to configure master data elements or transactions within the system. The template is derived from a JSON configuration (version 0.0.1) built using Fuuz's Application Designer, which prioritizes a resizable filter panel, a streamlined top action bar for essential CRUD operations, and a data table with core and audit columns.
The objective is to maintain consistency across SDM screens for administrative efficiency, while permitting deviations based on implementation details like data simplicity, access controls, or integration needs. For instance, if a setup entity involves hierarchical categories, additional grouping or tree-view features may be incorporated.
Key principles:
- Administrative Focus: Restrict access to admins; emphasize simplicity for quick setup and reference.
- User-Friendly UI: Clean layout with optional filters on the left, admin actions at the top, and essential data in a central table.
- Consistency: Standardize audit columns (e.g., Created/Updated At/By) and basic actions across screens.
- Flexibility: Allow customization for entity-specific fields (e.g., adding a "Code" column for statuses).
- Performance: Leverage efficient queries with auto-loading enabled for small datasets typical in setup data. Note that these screens generally should have very limited number of records (under 50).
This spec assumes knowledge of Fuuz's Application Designer, including components like Containers, Forms, Tables, and Actions.
Overall Layout
The screen uses a flexible, responsive canvas-based design:
- Root Screen: Full-width and height, column-based flex layout. Background: "paper". No padding or margins for a minimalistic admin view.
- Main Container (Outer): Row-based flex (100% width, flexible height) splitting into:
- Left: Resizable Filter Panel (Default: 300px, max: 300px, min: 0px; right-handle resizable). Suitable for admin filtering; can be minimized.
- Right: Body Container (Flexible width, 100% height) with top action bar and data table. Subtle left border (0.5px solid #5b30df) for separation.
- Borders and Styling: Minimal shadows and borders. Light header backgrounds (#f0f0f0) for clarity.
This setup keeps the interface admin-oriented, with filters available but not dominant for straightforward setup management.
Components and Configuration
1. Filter Panel (Left Sidebar)
Purpose: Enables admins to filter setup data dynamically, though often minimal for these entities.
- Header Container: Fixed height (30px), light background (#f0f0f0) with shadow.
- Title: RichText "Filter Panel" (bold, 14px Roboto, color: rgb(44,130,201)).
- Search Action: IconButton (magnifying-glass, info color) invoking table search (`$components.Table1.fn.search()`). Title: "Search Using Filters Below".
- Form Component: Encapsulates filters. Application API, single-record (edges[0]), no auto-load, standard parameters for ID filtering.
- Filter Controls (Column-based flex, flexible height):
- Select Inputs (Up to 3): For categorical filters (e.g., "SampleSelectFilter"). Config: Filled variant, clearable, single-select, contains-search. Option limit: 5 (flexible). Data path: Define per entity (e.g., "parentCategory").
- Switch/Checkbox: For boolean flags (e.g., "Active"). Labeled, centered. Use checkboxes when True/False/Null are possible options (or you need a way to filter for All True + False); use Switch only for explicit True/False filtering.
- Styling: 4px padding per control, 100% width, auto height. No required validation.
Guidance: Keep filters concise for setup data. Use for quick lookups (e.g., by type or status). Enable full state tracking for admin sessions.
2. Top Action Bar (In Body Container)
Purpose: Supports basic admin operations like creation and bulk deletion.
- Container: Fixed height (30px), row-based flex, light background (#f0f0f0), shadow, bottom border optional.
- Standard Actions Container (Left-aligned, 100px width, space-between):
- Create Single: IconButton (plus, success color). Opens form dialog. Example fields: Required text (e.g., "Label"). Follows with mutation and table refresh. Title: "Create New Record".
- Delete Multiple: IconButton (trash-list, error color). Disabled if no rows selected. Confirms deletion (`"Delete " & $count(selectedRows) & " records?"`), mutates, refreshes table. Title: "Delete Selected Records".
- Custom Actions Container (Right-aligned, 250px width): Empty by default; add entity-specific actions (e.g., "Export Categories" as IconButton).
- Styling: Icons "regular" variant, icon size. Buttons: 40px width, 30px height.
Guidance: Limit to essentials for admin efficiency. Dynamically disable based on selections. For setup data, consider adding "Import" if bulk setup is common.
3. Data Table (Main Content)
Purpose: Presents setup records in a simple, non-groupable table for admin review and selection.
- Table Component: Flexible height, 100% width. Application API, data path: "edges", auto-load: true, single-select, default ascending sort on first column.
- Features: No grouping, charts, or tool panels. Status bar hidden. Row multi-select disabled; column dragging disabled.
- Columns (customize per entity using TableColumn):
- Placeholder Column: Empty label, text format, 40px width (for spacing or future use).
- Core Fields: E.g., "Name" (text, sortable), "Policy" (JSON, 320px, no wrap), "Description" (markdown, 320px, sortable) - examples provided.
- Actions Column: 40px width, menu format (ellipsis-v icon). Options:
- "Information" (circle-info, info color; displays description in confirmation).
- "Edit" (pencil, warning color; opens update form).
- "Delete" (trash, error color; confirms single deletion).
- Audit Columns (Mandatory for traceability):
- "Created At" (datetime, sortable, user timezone).
- "Created By User" (text, derived from firstName + lastName).
- "Updated At" (datetime, sortable, user timezone).
- "Updated By User" (text, derived from firstName + lastName).
- Query Config: Minimal fields (e.g., "id"). Selected data change indicator: "refresh".
Guidance: Adapt columns to setup entity (e.g., add "Code" for statuses). For small datasets, auto-load enhances usability. Disable advanced features to keep admin views lightweight.
Integration and Data Flow
- API Integration: Application API (GraphQL). Queries auto-load; mutations for CRUD with pre-transforms (e.g., wrap in "where" for deletes).
- Transformations: Use for dynamic messages (e.g., count selected rows) and payload prep.
- Event Handling: Actions refresh table post-mutation. No subscriptions by default.
- Access Controls: Enforce admin-only via policies; hide non-applicable features.
Best Practices and Deviations
- Consistency: Mandate audit columns and basic actions. Use filled inputs and light headers.
- Admin Experience: Add titles/tooltips for clarity. Ensure responsiveness for desktop admin use.
- Performance: Auto-load suits small setup datasets; paginate if entities grow.
- Security: Restrict to admins; validate mutations server-side.
- Deviations:
- For hierarchical data (e.g., categories), enable master-detail. Though, not typical for this type of screen.
- If no filters needed, set panel collapsed by default.
- Customize icons/colors per branding, but retain functionality.
- Test for admin workflows (e.g., bulk deletes) and error handling.
Implementation Steps in Fuuz Application Designer
1. Import the template JSON as a new screen.
2. Set table model to your setup entity (e.g., replace "AccessControlPolicy" with "StatusType").
3. Define filters/columns via props (e.g., dataPath, fields).
4. Preview actions and queries.
5. Deploy, apply admin permissions, and refine based on feedback.
This specification promotes efficient, secure management of setup data in Fuuz, aligning with administrative needs while supporting system configuration. Refer to Fuuz docs or the template for details.
Related Articles
Table
In the context of Fuuz screen design or a web page within the Fuuz platform, a "table" refers to a structured and organized grid-like layout component used to present and display data in a tabular format. Tables are a fundamental part of user ...Fuuz Master Data Management Table Screen Standard
Specification for Creating a Master Data Management (MDM) Table Screen in Fuuz Example - for Columns with no image data to keep consistent height Design Philosophy Master Data Management Principles Master Data screens in the Fuuz Application Designer ...Screen Designer Terminology
This is where we can provide a “dictionary” of common terminology a user might encounter while navigating the interface, reading our documentation, or discussing the designer. The goal is to provide a place they can go if they see or hear a phrase ...Table Column
In the context of Fuuz screen design or a web page within the Fuuz platform, a "table column" refers to a specific vertical section within a table that represents a distinct data attribute or field. Table columns are used to organize and display data ...Table Feature: Master/Detail View
Master/Detail View is a feature available for the table screen element. This functionality allows the user to drag in screen elements inside of a table to design the table’s detail view. Once the screen is rendered, each row in that table will have ...