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" <smckin...@apache.org> To: fortress@directory.apache.org Sent: Thursday, October 13, 2016 8:46:04 AM Subject: Re: Fortress Properties > On Oct 12, 2016, at 9:27 PM, Chris Pike <clp...@psu.edu> 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