# Do Not Put Operation Attributes On Base CRUD Overrides

Warns that a permission or operation attribute on an overridden base CRUD method is silently ignored.

Follow these project instructions.
# Do Not Put Operation Attributes On Base CRUD Overrides

Warns that a permission or operation attribute on an overridden base CRUD method is silently ignored.

Version: `1.0.0`

The base service does not use the operation executor. It reimplements the pipeline inline, and that inline version reads attributes from the service type only. A method-level operation or audit attribute on an override of a base CRUD method is read by nothing, and a method-level permission attribute is not read by the base classes at all.

Nothing warns you. The attributes are declared as valid on methods, so it compiles cleanly, and at runtime the permission demanded is the one derived from the class attribute or the entity-and-action convention - not the one you wrote on the method.

To change what a base CRUD path demands or records, set the attribute on the service class, or pass the name through the execution options. To apply a different rule to one operation specifically, write it as a custom method and route that method through the executor.

Know too that the base path's audit record is thinner than the executor's: it is written only after success, and carries no duration and no failure information. If you need a failed attempt recorded, the base CRUD path will not give you one.

#### Constraints
- Do not assume a base CRUD write records a failed attempt - it records only successes.
- Never rely on a method-level operation, audit or permission attribute on a base CRUD override.

#### Verification
- Anything needing a failure record goes through a custom method and the executor
- No method-level operation or permission attribute sits on a base CRUD override
- The permission actually demanded was confirmed by a test, not read off an attribute