bulk update - users in delivery server repository

[Jo]

Hi,

I have been trying to update users data as bulk by getting the user
report and then by looping through each users.
But the update mode only updates the user in active session. Here is
the xml code I am using :

<dyn>

<rde-dm:user mode="report" tag="staff-search-results" item-tag="user"
resulttype="xml" buffersize="1" >
<rde-rd:user-filter>
<rde-rd:group>testusers</rde-rd:group>
</rde-rd:user-filter>
</rde-dm:user>

<rde-dm:attribute mode="write" source="request" attribute="userlogin"
value="[#xpath://search-results//user//@login#]" />

<rde-dm:attribute mode="read" source="request" attribute="userlogin"
tag="users" />

<rde-dm:user mode="load" user="[#context:id#]" >

<rde-dm:attribute mode="write" source="user"
attribute="test.telephoneNumber" op="set" value="020 7899
0000" />

<rde-dm:user mode="update" path="test" />

<rde-dm:attribute mode="flush" />

</rde-dm:user>

</rde-dm:attribute>

</dyn>

just trying to update only one value as test.

Can anybody help on this please ? I am not sure where I go wrong or is
this possible in delivery server ??

Thanks,
Jo

[Bagsy]

Hi Jo,

Just to check, although you are flushing the attribute forcing it to
the repository, are you viewing the before and after effects within
Delivery Server with a single user without logging off and on again.

For example, are you testing like this:

- logged in with admin user
- Check targeted user or users for status on attributes
- Run test script
- Check targeted users for status on attributes

It could be that the view of those users attributes are cached
relative to that admin session regardless of the flushing.

Therefore, to check this, try these additional steps:

- logged in with admin user
- Check targeted user or users for status on attributes
- Run test script
- *Logoff as admin user
- *Logon as admin user
- Check targeted users for status on attributes

This is a quick answer and I haven't read your post in detail so let
me know if this doesn't address your issue. It is certainly a gotcha
that has got me in the past.

Regards,

Dan

[Jo]

Hi Dan,

Thanks for your reply.

I tried that actually, but it doesn't work.
Could you be able to recollect how did you do that ?

Many Thanks,

Jo

[Bagsy]

Hi Jo,

In that case, it may be worth trying to set attributes in the default
"path" under rde-edit-user with attributes being set under rde-edit-
user.rde-attributes.telephoneNumber for example.

The alternative is that the attribute branch is required - i.e. set
attribute as test.rde-attributes.telephoneNumber.

Keep in mind those special branches that is detailed in your
documentation:

rde-fields
rde-groups
rde-roles
rde-attributes

The documentation can be seen under your Delivery Server install under
http:<server>/cps/docu/wsds-h-pdy/en/html/_manual.htm

Hope that helps,

Dan

[Jo]

Hi Dan,

Thanks.

I tried several different ways. It'll update only the user who is in
active session rather bring a user into session and update his/her
details!!
I don't think for-each loop is working. Doesn't seem to update the
user . There is only one user in the group "testusers" (if you look at
my code).

I am using DS9 HF9.

Regards,

Jo

[Bagsy]

True, you are not using the attribute DynaMent in for-each mode for
the loop by the looks of it (I should've looked more closely first of
all).

Therefore, you need to loop through your userlogin attribute as you've
set it and load user using user DynaMent in load mode (no nested
elements) and then do the attribute setting etc.

Break down the problem to one known user out of the loop first to
check the attribute setting and then build in the loop.

Regards,

Dan

[Jo]

Hi Dan,

Sorry, I accidentally deleted the for-each dynamnet when I pasted
here! Here is my updated code :

<dyn>

<rde-dm:user mode="report" tag="search-results" item-tag="user"

resulttype="xml" buffersize="1" >
<rde-rd:user-filter>
<rde-rd:group>testusers</rde-rd:group>
</rde-rd:user-filter>
</rde-dm:user>

<rde-dm:attribute mode="write" source="request" attribute="userlogin"
value="[#xpath://search-results//user//@login#]" />

<rde-dm:attribute mode="read" source="request" attribute="userlogin"
tag="users" />

<rde-dm:attribute mode="for-each" source="request"
attribute="userlogin" alias="id">

<rde-dm:user mode="load" user="[#context:id#]" >

<rde-dm:attribute mode="write" source="user" attribute="rde-edit-
user.rde-attributes.test.telephoneNumber" op="set" value="020 2828
3498" />

<rde-dm:user mode="update" path="test" />

<rde-dm:attribute mode="flush" />

</rde-dm:user>

</rde-dm:attribute>

</dyn>

Now the group has got 2 users and trying to update the telephoneNumber
field. I have logged in those users so they are in active session.
But the update doesn't happen :(

Thanks for helping me Dan,

Jo

[Tim D]

Jo,

I'd recommend getting one of the 2 things working first not trying to combine the loop and the update until you know you can update 1 user. I've provide something (untested) to try below. Hope its helpful but its been years since I wrote one of these.

<dyn>

<!-- start with a known user to simplify complexity of not confusing the loop with the update user -->
<rde-dm:attribute mode="write" source="request" attribute="userlogin" value="expert" />

<rde-dm:user mode="load" user="[#request:userlogin#]" />

<rde-dm:attribute mode="write" source="user" attribute="rde-edit-user.rde-attributes.test.telephoneNumber" op="set" value="020 28283498" />

<!-- visually validate the tree of attributes updated as expected - debug only -->
<rde-dm:user/>

<!--- you had test so it was trying to update the user making the HTTP calls test attribute. the paths not really needed from samples in the manual -->

<rde-dm:user mode="update" path="rde-edit-user.rde-attributes.test" />

<rde-dm:attribute mode="flush" />

<!-- not sure what you had this all wrapped in a user tag. User is called as an empty tag usually your code may have been ignored -->


</dyn>

[Jo]

Hi Tim,

Thank you for helping.

I tried with single user and it is updating. It doesn't work when I
try to update multiple users or as bulk.
To avoid the hassle to chase users to update their details, esp. phone
number, name etc. we thought it would be nice if an admin could do the
job , it's much easier!!

Thanks,
Jo