Lainaus Fabio Martelli <[email protected]>:
Il 04/12/2013 13:01, Timo-V Hatakka ha scritto:
Hi!
On 03/12/2013 13:38, Timo Hatakka wrote:
Hi!
how can you add a virtual read-only attribute to an user by GUI
or using your own code? Only way to include a virtual attribute
is to give some dummy initial value in the user interface and
this trick cannot be used if the attribute is read only. Seems to
be a problem even in 1.1.5.
There is no problem in providing values for read-only virtual
attributes via client code.
Via admin console, however, this is rather impossible: could you
fill an issue, please?
I will.
Also, is there some design mistake in PROPAGATION /
SYNCRONIZATION selection with virtual attributes? I would suppose
that SYNCRONIZATION will only read values from external resource
and PROPAGATION will write values to external resource, but is it
so?
No: PROPAGATION / SYNCHRONIZATION / BOTH refer to the *purpose* of
mapping entry, e.g. if Syncope will be using that mapping entry
only during propagation, only during synchronization or in both
cases.
A read-only virtual attribute (whose value comes from external
resource A) can be propagated to external resource B, for example.
I had(in 1.1.4) following test, which you can iterate:
add virtual attribute HR:title to the schema
add read mapping: resource HR / USER / UserVirtualSchema / HR:title
/ title / false / SYNCRONIZATION
add write mapping: resource LDAP / USER / UserVirtualSchema /
HR:title / title / false / PROPAGATION
add a virtual attribute for a user by giving a string "test" as a
dummy value and save
value "test" is propagated to ldap as supposed (because no other
values available here)
open user, virtual attributes are now "test" and the value coming from HR
I suppose that system should show only value coming from HR not the
previous value written to LDAP. I first supposed that cache is used
in a wrong way in this situation but even the application server
restart keeps the situation the same. And notice that I didn't run
any task.
Hi Timo,
mapping purposes are just for propagation or synchronization
operations: MappingPurpose.PROPAGATION doesn't mean that the
attribute is "write-only" but that it is just interested by a
propagation not by a synchronization.
Your configuration implies:
* HR:title will be synchronized by executing a sync task defined for HR;
* HR:title won't be synchronized by executing a sync task defined for LDAP;
* HR:title won't be propagated towards remote attribute title on HR resource;
* HR:title will be propagated towards remote attribute title on LDAP
resource.
Virtual attributes will be read always (SEARCH capability on the
connector is needed for).
This implies following:
Lets suppose that HR.title is "A", after HR syncronization is done, it
is copied to LDAP. Then title is changed in HR to value "B". Now
a) if we resync HR, the value in LDAP will be "B"
b) if we open and save user from admin interface, it will be ["A", "B"]
I think this lead to an inconsistent state, where the result depends
on the operations done. Or did I miss something?
Regards,
Timo
Best regards,
F.
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
