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> 

or more generic?
  - List<FortEntity> searchEntity(List<Props.Entry> propFilters, Class 

or change pattern of searching to more of a query builder?
  - AdminRoleQuery query = 
"value").addPropertyFilter("key2", "value")
  - public List<AdminRole> runAdminRoleQuery(AdminRoleqQuery query)

----- Original Message -----
From: "Shawn McKinney" <>
Sent: Thursday, October 13, 2016 8:46:04 AM
Subject: Re: Fortress Properties

> On Oct 12, 2016, at 9:27 PM, Chris Pike <> 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'
    MAY (

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.


Reply via email to