Ah sorry by mistake i accidentally mark your reply as read, that is why I wonder why there is no reply yet about my question.
I was asking because if I plan to move to the newest version from 1.x, what kind of risk that I would face. Since the permissions has been grow so big at my current production. Thanks for answering shawn. On Thu, Aug 23, 2018, 22:42 Shawn McKinney <[email protected]> wrote: > > > On Aug 23, 2018, at 10:22 AM, Yudhi Karunia Surtan < > [email protected]> wrote: > > > > > > How about the compability with previous version? > > If it is not compatible, is there a way for migrate it? > > Thanks. > > Hello Yudhi, > > By compatibility, are you asking about the new functionality (generic > abac), i.e. what was just added? Or the old, from back a few years ago > (pasets) > > For the old, yes, it passes all existing tests. > > For the new - yes as well. Here’s we’ll add a new constraint validator. > > Here’s what we had last release: > temporal.validator.0:org.apache.directory.fortress.core.util.time.Date" > temporal.validator.1:org.apache.directory.fortress.core.util.time.LockDate" > temporal.validator.2:org.apache.directory.fortress.core.util.time.Timeout" > > temporal.validator.3:org.apache.directory.fortress.core.util.time.ClockTime" > temporal.validator.4:org.apache.directory.fortress.core.util.time.Day" > > temporal.validator.5:org.apache.directory.fortress.core.util.time.Discriminant” > > For next release we could deprecate #5, and add: > > temporal.validator.5:org.apache.directory.fortress.core.util.time.RoleConstraint” > > That way if you have time to move into the new data format. Which will > use these apis to load: > > RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint > roleConstraint ) > throws SecurityException; > void removeRoleConstraint( UserRole uRole, RoleConstraint > roleConstraint ) > throws SecurityException; > > Instead of property values. Are you using these? Thanks for brining this > up. > > —Shawn > >
