for now let’s keep it simple.  Follow the way it’s done in User which is 
probably the closest to your target and has prop support already in add/update.

Next we can add an interface for DAO’s that have need…

public interface Properator  (just kidding on name:)

  FortEntity add ( FortEntity, String name, String value) throws Property 
  FortEntity update ( FortEntity, String name, String value) throws Property 
  void delete ( FortEntity, String name) throws Property Exception;
  String get ( FortEntity, String name) throws Property Exception;
  List<FortEntity>search ( FortEntity, String name, String value) throws 
Property Exception;

not all apis need to be supported on every entity nor will they need to be 
exposed publically.

Will that work?  If so, let’s create a ticket and get this info in there.  We 
can do this work gradually as needed.  


> On Oct 13, 2016, at 9:13 AM, Chris Pike <> wrote:
> 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" <>
> To:
> 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 (
>        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

Reply via email to