Hi, I had a closer look at the solution of using role memberships to store composite values. However, if I understand it correctly, Syncope does *not* allow a user to have more than one membership (with different attributes) to a given role. Thus one cannot store multiple composite values for a user using memberships to the same role.
So in the example, I would have to create multiple "TermsAndConditions_<XXX>"-Roles, one for each terms and conditions document, with the same membership schemas (e.g. date of acceptance). Is this correct or did I misunderstand the suggestion? Cheers, Guido > Gesendet: Montag, 13. Oktober 2014 um 16:17 Uhr > Von: "Guido Wimmel" <[email protected]> > An: [email protected] > Betreff: Re: storing composite values in Syncope > > Hi Francesco, > > thanks for the helpful suggestions. > > I was thinking of the possibility to use role memberships for this as well, > but not about the possibility to use multiple memberships to the same role. > I'll investigate further into this solution. > > Cheers, > Guido > > > Gesendet: Samstag, 11. Oktober 2014 um 07:44 Uhr > > Von: "Francesco Chicchiriccò" <[email protected]> > > An: [email protected] > > Betreff: Re: storing composite values in Syncope > > > > On 10/10/2014 14:06, Guido Wimmel wrote: > > > Hi, > > > > > > I understand that Syncope schemas only support simple types (String, > > > Enum, Boolean, Long, Double, Date) and byte arrays. > > > > > > Is there a best practice for storing composite values? > > > > > > We're thinking of managing acknowledgements of terms&conditions documents > > > in our idm instance (is this usually done?) - which could be a multivalue > > > attribute having a set of (reference to terms&conditions-document, date > > > of acceptance) as values. > > > > > > One way would be to use String types and serialize the values e.g. to > > > JSON, which would work if one doesn't need to support efficient searches > > > for values of the components of a composite value. > > > > HI Guido, > > "composite" values in Syncope is indeed a nice use case. > > > > Certainly, using String + JSON (de)serialization could work, but it > > would require some considerable customization. > > > > With Syncope 1.2.0 (SYNCOPE-131) the concept of "attribute template" is > > introduced for membership and roles, e.g. when you define a membership > > or role schema, such schema is not immediately available for all > > memberships and roles (as it used to be up to Syncope 1.1.X), instead, > > you will need to "enable" such schema for usage with a certain > > membership / role (e.g. you will need to create an attribute template > > those membership / role can instantiate). > > > > An idea could be to implement the "composite values" use case above by > > creating a TermsAndConditions role (with no attributes) and to define > > several memberhisp schemas for all the items you need to store in the > > composite value; finally, to enable such membership schemas only for the > > new TermsAndConditions role. > > > > WDYT? > > Regards. > > > > -- > > Francesco Chicchiriccò > > > > Tirasa - Open Source Excellence > > http://www.tirasa.net/ > > > > Involved at The Apache Software Foundation: > > member, Syncope PMC chair, Cocoon PMC, Olingo PMC > > http://people.apache.org/~ilgrosso/ > > > > > > >
