Details
-
New Feature
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Done
-
None
Description
When discussing Folio-377, we realized that our ModuleDescriptor is not quite right. The problem is that permissions (and later, permission sets) will need to belong to an interface the module supports, and also to the RoutingEntries that need them. Therefore RoutingEntries should be handled under the provided interfaces, not globally for the whole module.
We can still use global RoutingEntries for filter-like things like mod-authtoken, logging, and timing - things that don't provide a decided interface.
We also need to have a new section for the system interfaces the module provides. At the moment we have the tenant interface, and soon we will have one more, for catching when modules get enabled for tenants, in the first instance to make sure mod-permission can add the module's permissions (and sets) into its database. Later, we will have more stuff like that.
TestRail: Results
Attachments
Issue Links
- blocks
-
FOLIO-487 use ModuleDescriptors provided in the root directory of each module repo
-
- Closed
-
-
OKAPI-267 Define permission sets in ModuleDescriptor
-
- Closed
-
-
OKAPI-268 Permission loading interface in Okapi
-
- Closed
-
- relates to
-
CIRC-1 Adapt circulation module to use new Okapi path filtering
-
- Closed
-
-
CIRCSTORE-3 Adapt loan storage module to use new Okapi path filtering
-
- Closed
-
-
FOLIO-377 Permission model design
-
- Closed
-
-
METADATA-52 Adapt inventory and inventory storage module descriptors to use Okapi Path Filtering
-
- Closed
-