That sounds like exactly what we want. We would want to add properties and have
the ability to generically filter by them, but don't need the API to act on
them in any way.
I guess the question is what is the proper way to update the API to support
this, for example, to add to AdminRole
1. Add properties field into object
- private Props props = new Props();
2. Update DAO to insert / update / delete properties
3. Add additional method to allow filtering by properties?
- public List<AdminRole> findRoles(String searchVal, List<Props.Entry>
propFilters)
or more generic?
- List<FortEntity> searchEntity(List<Props.Entry> propFilters, Class
targetClazz)
or change pattern of searching to more of a query builder?
- AdminRoleQuery query =
AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
"value").addPropertyFilter("key2", "value")
- public List<AdminRole> runAdminRoleQuery(AdminRoleqQuery query)
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Thursday, October 13, 2016 8:46:04 AM
Subject: Re: Fortress Properties
> On Oct 12, 2016, at 9:27 PM, Chris Pike <[email protected]> wrote:
>
> I noticed that all of the fortress entities have the ftProperties object
> class in LDAP, which means that they can all contain many ftProps. Is that
> correct? Are the ftProps meant to be user defined defined properties? If so,
> does the API provide any mechanism to set or query by these properties?
The props aux obj class:
## AC2: Fortress Properties Auxiliary Object Class
objectclass ( ftAxId:2
NAME 'ftProperties'
DESC 'Fortress Properties AUX Object Class'
AUXILIARY
MAY (
ftProps
)
)
Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
But there is only code written on Config, PermObj and Users which allow some
level of adding and updating props. No APIs for search at the moment - except
for Config which of course is just an entity containing properties.
I would be in support of expanding the usage of properties as long as there
aren’t business rules associated with it. For example it would be fine to have
apis to perform generic searches on property names / values
List<FortEntity> searchEntity(propName, PropValue
I would also support adding code to implement the property capability on the
other entities, both those listed above and those not.
For me the general idea of a property is that we offer apis for CRUD but don’t
interpret the value of a property on behalf of the caller. That is the caller
pulls it back and it is up to it to decide what to do with it.
Shawn
