auth-use-requires
Rule Details
Some annotations such as @requires or @readonly are convenience shortcuts for @restrict. In actions and services with unrestricted events, it is recommended to use @requires instead of @restrict.to, which this rule enforces.
Examples
✅ Correct example
In the following example, the CatalogService action addRating correctly uses @requires: 'Admin' to indicate granting of unrestricted events to the Admin role:
cds
using { sap.capire.bookshop as my } from '../db/schema';
service CatalogService {
@readonly entity ListOfBooks as projection on Books
excluding { descr };
@readonly entity Books as projection on my.Books { *,
author.name as author
} excluding { createdBy, modifiedBy }
actions {
@requires: 'Admin'
action addRating (stars: Integer);
}
}1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
❌ Incorrect example
In the following example, the CatalogService uses @restrict to assign unrestricted events (grant: *) to the Admin role (to: Admin). This could be written more clearly using @requires and so the rule reports a warning:
cds
using { sap.capire.bookshop as my } from '../db/schema';
service CatalogService {
@readonly entity ListOfBooks as projection on Books
excluding { descr };
@readonly entity Books as projection on my.Books { *,
author.name as author
} excluding { createdBy, modifiedBy }
actions {
@restrict: [{grant:'*', to: 'Admin'}]
// Use `@requires` instead of `@restrict.to` at action `addRating`.
action addRating (stars: Integer);
}
}1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Version
This rule was introduced in @sap/eslint-plugin-cds 2.4.1.