directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pike <clp...@psu.edu>
Subject Re: Fortress Properties
Date Thu, 13 Oct 2016 14:13:47 GMT
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" <smckinney@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 <clp207@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

Mime
View raw message