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
