[
https://issues.apache.org/jira/browse/ISIS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood updated ISIS-2431:
--------------------------------------
Description:
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.
was: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.
> 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: Daniel Keir Haywood
> Priority: Major
> Fix For: 2.0.0-M6
>
>
> 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)
