How to mass-update email addresses
Asked by hans-peter.geier:

I need to update all user records (accounts), to set a new email address.

Is there a tool (postgresql script?) available to perform the update, so I can save developping such a script myself?

Our Confluence and Jira instances are hooked up to LDAP AD (no crowd).

I'm not sure whether the email address would be automatically synchronized from LDAP once this is updated,

or do we need to update the local records?


Answers:
author: Bob Swift (personal)
body: In general, you can use the user actions from [Confluence Command Line Interface](https://studio.plugins.atlassian.com/wiki/display/CSOAP) and [JIRA Command Line Interface](https://studio.plugins.atlassian.com/wiki/display/JCLI) to deal with user information. But, in your case, don't you need to update this information in AD using AD tools and then have them flow to JIRA and Confluence?

comments: author: hans-peter.geier
body: yep, I'm unsure whether I have to do anything in Concluence and Jira. If the AD update will update Confluence databases via LDAP interface, it would be fine. Does it?


author: Bob Swift (personal)
body: Yes, it should. Only if someone is using Crowd delegated authentication and the user info is now duplicated in Crowd, then it would need to be managed separately. Even, if you are on a Confluence/JIRA release that uses Crowd under the covers, it handles the synchronization.


author: hans-peter.geier
body: The update through LDAP interface to the Confluence user database has worked fine. This is really good, because I figured that the CLI (version 2.4) of Confluence has no "updateUser" API call, in contrast to the Jira API. (weird, huh?)

In the meantime, I have also updated our Jira instance, this time using the updateUser call of the Jira CLI. It appears our Jira's LDAP I/F is configured to not update existing users' email address.


author: Bob Swift (personal)
body: The CLI just uses the Confluence search service, so expect the same results on GUI and CLI. Confluence search is based on source text indexing (Apache Lucene). It is not going to know that want .com to match with .net. Use both .com and .net to get both. I don't think there is any issue here other than the limitations of the search engine.


author: hans-peter.geier
body: hmm, more likely it is not the .com; it appears to me that I cannot search for anything in links after the colon, so I can find "http:" and "mailto:" but not what's behind these words.


author: hans-peter.geier
body: Hi Bob,

Besides the user records update, I also worked on mass-updating the pages' content. I faced a strange issue. When I attempt to search for something like "mycompany.com" , I do NOT find any pages holding that string. This is true for both, the CLI "getContentList --search" and in the GUI (e.g. Livesearch macro).

I did some experiments and figured that I can query for "mycompany.net" (.net is our intranet extension) without problem, so I suppose ".com" as part of the search string is causing the query engine to not find anything (????)

I think this is strange and hard to understand.

I got the idea that the cause could be because this string most frequent appears in a link, although this is also true for .net addresses. I did another attempt searching for "mailto:" which also occurs in the same links.

Funny, searching for "mailto:" did return the desired pages, at least most (?) of them.

Then I used the CLI actions "getPage" and "storePage --findReplace" to update the email addresses. This worked fine.

But, of course there are some email addresses contained in pages which are not part of a mailto: link, so I couldn't find them at all. I ended up downloading ALL pages to the file system and there apply Unix find/grep statements to identify the affected pages. Quite a heavy work-around for the issue that searching for \*.com does not work as expected.

I'm not sure, should I open an issue on this? Probably it's not caused by the CLI but somewhere deeper in the architecture, as the search macros in the GUI show the same effect. Maybe the issue is already known?

btw, we are on Confluence 3.5.13, using CLI 2.4.

regards,

hp


author: Joerg Bencke
body: Just check it with a testaccount ?