FPS is using the ftProps attribute to store data that isn't in the standard inetOrgPerson, eduPerson or PSUPerson schemas. We probably should have created a schema for some of it but it's working well so far. Note that these are all added to inetOrgPerson (or User via the Fortress library).
Steve “Object-oriented programming is an exceptionally bad idea which could only have originated in California.” – Edsger Dijkstra ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Thursday, October 13, 2016 10:32:57 AM Subject: Re: Fortress Properties 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 Exception; FortEntity update ( FortEntity, String name, String value) throws Property Exception; 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. Thanks, Shawn > On Oct 13, 2016, at 9:13 AM, Chris Pike <[email protected]> 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" <[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
