[
https://issues.apache.org/jira/browse/ISIS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber closed ISIS-2431.
----------------------------
Resolution: Fixed
Implemented without providing tests.
> SecMan support for ObjectType (canonical object names)
> ------------------------------------------------------
>
> Key: ISIS-2431
> URL: https://issues.apache.org/jira/browse/ISIS-2431
> Project: Isis
> Issue Type: Improvement
> Components: Isis Extensions
> Reporter: Andi Huber
> Assignee: Andi Huber
> Priority: Major
> Fix For: 2.0.0-M5
>
>
> So called Application Features are currently referenced by fully qualified
> class names, which breaks persistent authorization data as soon as
> Application Features are refactored to new class names.
> The idea is to collate the objectTypes and use the "dirname" part as the
> package. Normally this will be a single value, representing a name of the
> module (though I think there's no restriction; logical subpackages probably
> would work).
> For example, we could have "customer.Customer" and "customer.EmailAddress" as
> two object types. These would both be in the logical package (aka module) of
> "customer".
> Or we might have "customer.Customer" but also "customer.contact.EmailAddress"
> and "customer.contact.PhoneNumber" and "customer.contact.PostalAddress". In
> this case we would have the module "customer" and another inferred module
> "customer.contact".
> ASIDE: I could imagine there being some metamodel validation whereby the
> owning module (Spring `@Configuration`) could specify a module name, and then
> we check that all domain classes within that module declare an objectType
> that is equal or a submodule of that owning module. But that's probably
> another ticket, for another day.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
