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).
“Object-oriented programming is an exceptionally bad idea which could only have
originated in California.” – Edsger Dijkstra
----- Original Message -----
From: "Shawn McKinney" <smckin...@apache.org>
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
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
not all apis need to be supported on every entity nor will they need to be
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 <clp...@psu.edu> 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>
> 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" <smckin...@apache.org>
> To: email@example.com
> 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'
> 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.