Add 'count' operation type to security rules UI

[tonytlwu]

Summary

• Add "Count" checkbox to security rules interface in interface.html
• Add 'count' case in type description mapping in interface.js
• Add "count" to operation type enum in schema.json

Related

• Jira: DEV-859
• API PR: Fliplet/fliplet-api#7495

Test plan

• Open Fliplet Studio
• Navigate to App Data > Select a data source > Security tab
• Click "Add Rule" or edit existing rule
• Verify "Count" checkbox appears alongside Read, Write, Update, Delete
• Enable only "Count" permission and save
• Verify the rule displays "Count" in the operations column

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added a new "Count" access rule type with a checkbox in the interface so users can apply count-based access control.

• Behaviour Changes

  • When a Read-type rule is present, Count is automatically selected and disabled to reflect the dependency; the UI shows "Count" in rule listings and validation/persistence respects this implied relationship.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds a new "count" access rule type: UI checkbox, JS logic enforcing a Read→Count dependency (display, validation, and save handling), and schema enum update to accept "count" as a valid access rule type.

Changes

Cohort / File(s)	Summary
UI interface.html	Adds a new checkbox input with id chk-count and value "count" under the "Applies to" section.
Client logic js/interface.js	Enforces Read→Count dependency: checks/disables Count when select present, renders "Count" in rule descriptions, prevents saving count separately if select is present, and updates validation/save flows accordingly.
Schema schema.json	Expands accessRules.items.properties.type enum and title to include "count" alongside existing rule types.

Sequence Diagram(s)

sequenceDiagram
  participant User as User
  participant UI as Browser UI (interface.html)
  participant Logic as JS Controller (js/interface.js)
  participant Store as Persistence/Save

  User->>UI: Toggle "Count" checkbox
  UI->>Logic: Notify change (checkbox state)
  Logic->>UI: Enable/disable Count if "select" present
  User->>UI: Click Save
  UI->>Logic: Request validation & prepare payload
  Logic->>Logic: Enforce Read→Count dependency (auto-check/disable or omit count when select present)
  Logic->>Store: Save access rule payload (with adjusted types)
  Store-->>Logic: Acknowledge save
  Logic-->>UI: Confirm saved / update UI
  UI-->>User: Show result

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title clearly and concisely summarises the main change: adding a 'count' operation type to the security rules UI across three files (interface.html, interface.js, and schema.json).
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@js/interface.js`:
- Around line 2350-2352: The switch statement that maps access rule types to
human-readable labels (the case branches including 'select', 'insert', 'update',
'delete', and the new 'count') lacks inline documentation; add a concise comment
immediately above that switch (referencing the switch that assigns to the
variable description and the case 'count' branch) that lists the type→label
mappings: 'select' → 'Read', 'insert' → 'Write', 'update' → 'Update', 'delete' →
'Delete', 'count' → 'Count', and notes these are the valid rule types expected
by the code.

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@js/interface.js`:
- Around line 2044-2048: Add unit tests for the Read→Count dependency covering
configureAddRuleUI, updateSaveRuleValidation, and the save rule logic: set up a
test framework (Jest or Mocha) and write tests that (1) call configureAddRuleUI
with rule.type containing 'select' to assert '#chk-count' is checked and
disabled, (2) call configureAddRuleUI without 'select' to assert '#chk-count' is
enabled, (3) simulate toggling '#chk-select' and call updateSaveRuleValidation
to assert '#chk-count' becomes checked+disabled when '#chk-select' is checked
and enabled when unchecked, and (4) test the save routine (the function that
composes rule.type on save) to ensure when both 'select' and 'count' are checked
only 'select' is saved, and when only 'count' is checked 'count' is saved;
target tests at the UI-control IDs (`#chk-select`, `#chk-count`) and the functions
configureAddRuleUI and updateSaveRuleValidation (and the save handler)
referenced in the diff.
- Around line 2532-2543: The current logic that iterates
$typeCheckbox.filter(':checked').each and pushes values into rule.type can miss
filtering 'count' when 'select' appears later in DOM; instead first collect all
checked values into a temporary array (e.g., checkedTypes), then set rule.type =
checkedTypes.filter(...) to remove 'count' if 'select' is present (use
Array.prototype.indexOf or includes on checkedTypes to detect 'select'); update
the code around $typeCheckbox.filter(':checked').each and rule.type assignments
to use this two-step collect-then-filter approach.

♻️ Duplicate comments (1)

js/interface.js (1)

2353-2371: Add inline documentation for the access rule type mappings.

The switch statement mapping access rule types to human-readable labels lacks documentation. Add a brief comment above the switch documenting the valid type→label mappings: 'select' → 'Read', 'insert' → 'Write', 'update' → 'Update', 'delete' → 'Delete', 'count' → 'Count'.

As per coding guidelines, all code should be fully documented.

📝 Suggested documentation

         type: rule.type.map(function(type) {
           var description;

+          // Map access rule types to human-readable labels
+          // Valid types: select (Read), insert (Write), update (Update), delete (Delete), count (Count)
           switch (type) {
             case 'select':
               description = 'Read';

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Testing plan for Read→Count dependency logic.

Per coding guidelines, consider the following unit test scenarios for the new feature:

1. configureAddRuleUI: When rule.type includes 'select', verify #chk-count is checked and disabled.
2. configureAddRuleUI: When rule.type excludes 'select', verify #chk-count remains enabled.
3. updateSaveRuleValidation: When #chk-select is checked, verify #chk-count becomes checked and disabled.
4. updateSaveRuleValidation: When #chk-select is unchecked, verify #chk-count is enabled.
5. Save rule: When both 'select' and 'count' are checked, verify only 'select' is saved to rule.type.
6. Save rule: When only 'count' is checked (without 'select'), verify 'count' is saved.

Note: This project currently lacks a test framework. Establishing one (e.g., Jest or Mocha) would be a prerequisite.

Also applies to: 2138-2147, 2535-2542

🤖 Prompt for AI Agents

In `@js/interface.js` around lines 2044 - 2048, Add unit tests for the Read→Count
dependency covering configureAddRuleUI, updateSaveRuleValidation, and the save
rule logic: set up a test framework (Jest or Mocha) and write tests that (1)
call configureAddRuleUI with rule.type containing 'select' to assert
'#chk-count' is checked and disabled, (2) call configureAddRuleUI without
'select' to assert '#chk-count' is enabled, (3) simulate toggling '#chk-select'
and call updateSaveRuleValidation to assert '#chk-count' becomes
checked+disabled when '#chk-select' is checked and enabled when unchecked, and
(4) test the save routine (the function that composes rule.type on save) to
ensure when both 'select' and 'count' are checked only 'select' is saved, and
when only 'count' is checked 'count' is saved; target tests at the UI-control
IDs (`#chk-select`, `#chk-count`) and the functions configureAddRuleUI and
updateSaveRuleValidation (and the save handler) referenced in the diff.