[Feature]: Rename ACLRule fields for clarity: `index` → `sequence`, `action` → `rule_type`

[pheus]

NetBox version

v4.4.1

Feature type

Change to existing model

Proposed functionality

Summary
Improve naming clarity by renaming:

• index → sequence
• action → rule_type (choices: permit, deny, remark)

Provide backward‑compatible aliases for one release cycle so existing API clients and integrations are not broken.

Data model & API

• Schema migration: rename database fields (index → sequence, action → rule_type).
• Serializers:
  • Prefer sequence and rule_type in request/response payloads.
  • Accept index and action as input aliases (mapped to the new names) for a deprecation window.
  • (Optional) Echo legacy names in responses behind a feature flag, or include deprecation warnings.
• Choices for rule_type: permit, deny, remark (no behavior change; matches current semantics).

UI/UX

• Update field labels in forms, tables, and filters to Sequence and Rule type.

Migration plan

1. Add the field renames with data migrations.
2. Update serializers, and forms to use the new names.
3. Document deprecation of index/action and plan removal after one release cycle.

Testing

• Backward‑compatibility tests: payloads using index/action are accepted and stored correctly.
• Display tests: new labels appear in UI; filters and ordering by sequence still work.

Use case

• Reduces ambiguity for users and contributors (e.g., “sequence” is the common industry term; “action” conflates with the concept of a “remark,” which isn’t an action).
• Makes future extensions (additional rule types) clearer.

External dependencies

• None

[patrickpreuss]

@pheus I agree, “sequence” seems like the correct term here.

From my perspective this currently models something very close to Cisco IOS access-lists. The rule_type field doesn’t really match how things work on Cisco (and similar) devices – there it’s still essentially just an action.

If the goal is to make this vendor-independent, I think the data model needs a bit more rework. For example, in *BSD pf this is defined differently, and on FortiGate the configuration is different again and there’s no remark/comment concept at all.

So at least from my point of view, the current ACL representation reflects Cisco’s feature set rather than a more generic firewall abstraction.

Yes, I’d like to see a more abstract interface that combines the concepts from the data flows plugin and the ACL plugin in a generic way — something that can define objects/rules for firewalls, Cisco services (e.g. SNMP, routing), routing prefix-lists, proxy servers, etc.

We need to be careful about how we approach this. For example, it might be useful to generate source object(s) from a query, e.g. “top prefixes assigned to Site A”. However, this could translate into multiple rules in a Cisco ACL-style representation, while on other platforms the resulting configuration might look quite different.

Cisco:

Ext Access List configuration commands:
<1-2147483647> Sequence Number
default Set a command to its defaults
deny Specify packets to reject
dynamic Specify a DYNAMIC list of PERMITs or DENYs
evaluate Evaluate an access list
permit Specify packets to forward
remark Access list entry comment

PF
pf-rule = action [ ( "in" | "out" ) ]
[ "log" [ "(" logopts ")"] ] [ "quick" ]
[ "on" ifspec ] [ route ] [ af ] [ protospec ]
hosts [ filteropt-list ]
Fortigate
FG (10) # set
action Permit or deny this IP address and netmask prefix.
prefix IPv4 prefix to define regular filter criteria, such as "any" or subnets.
wildcard Wildcard to define Cisco-style wildcard filter criteria.
exact-match Enable/disable exact match.

FG (10) # set action
permit Permit or allow this IP address and netmask prefix.
deny Deny this IP address and netmask prefix.