Linchpin User Profiles - Documentation
Create a meaningful and up to date profile
See the documentation for your Release
Table of Contents
Further information
Migration panel
Every Confluence installation has a set of default profile fields: Phone, IM, Website, Position, Department, Location. If your Confluence installation was in use before you installed the Linchpin User Profiles App, those fields could already contain data.
LUP comes with a migration feature to transfer data from default Confluence profile fields to corresponding LUP fields. You can find the "Profile Migration" in the Confluence administration.
By default the corresponding LUP fields have the same names as their Confluence counterparts. You are free to edit their names, but like Confluence default profile fields, they can't be deleted.
Please note!
The migration process will copy all the information contained in the default Confluence profile fields to the corresponding LUP fields.
When a LUP field changes, the corresponding Confluence default profile field is automatically updated.
If you have entered data into the six aforementioned LUP fields before running the migration process, this data will be overwritten by the migration. That's why the migration is the first thing you should do after installing the app.
The hint will disappear after the migration runs the first time. From the migration page you can always run the migration again.
Import user data from your LDAP
Linchpin User Profiles will use the LDAP directories configured in Confluence to obtain the data for the user profiles. To update the LDAP data in the user profiles regularly a scheduled Confluence job ("Bulk profile update (LDAP sync)") will try to connect to the configured LDAP and update the user profiles.
You can configure the execution time of that job as desired or even manually start the import there.
Please note
Confluence supports different kinds of directory connections, they are described here: https://confluence.atlassian.com/crowd/adding-a-directory-18579549.html. Linchpin User Profiles does only support Delegated Authentication Directory and LDAP Directory Connector, so if you connect your user directory via one of the other types (e.g. JIRA) the synchronization will not be possible!
Write fields back to user directory (LDAP)
General idea: Usually an LDAP is the information central of a company. This is where user information is stored, and other systems can pull data like names or phone numbers from there. This means a lot of work for the IT crew who has to maintain this data and apply changes.
The Linchpin User Profiles app allows you to establish a self service for user data for selected fields: Users can change their phone numbers or correct spelling mistakes themselves within their intranet profile. These changes are written back to the LDAP, from where they are distributed to other systems.
Because the LDAP is such a crucial part of every IT infrastructure, there's a two step process to enable this feature.
First you need to enable and configure the feature itself in the Data Sources. Use the Save and test connection button to open an interactive test. This test panel allows you to check if Confluence has write access to the LDAP attribute of a specific Confluence User in your configured user directory.
Check multiple user directories
If you have configured multiple user directories for your Confluence, you need to test at least one user per directory to check the write access.
Check multiple attributes
To check the access for multiple attributes just repeat the test for each attribute.
To enable and configure this feature your Confluence user needs the role System Administrator. All Confluence Administrators are also System Administrators by default, but you can use the different admin roles to prevent unintended modifications by your non-technical administrators.
Configure fields in the Profile Editor
After this first step still no profile field will write back to your LDAP. You have to enable this for each field individually. Or in other words: By default, no field is written back to your user directory although you enabled the feature globally.
To enable the feature for a selected field, just open the editor for the profile field, configure a LDAP attribute and enable the option below ("Write data entered by the user into the corresponding LDAP attribute.").
Supported field types
At this point this feature is only supported for the field type Text input, Multiline text, Select and the profile picture.
Supported user directories
Supported user directories are OpenLDAP and Active Directory.
Troubleshooting
If the test fails, please check the following things.
- Connection to the user directory (network, credentials, permission)
- Check configured LDAP Schema (Base DN, Additional User DN) in the Confluence administration (User Directories). The DN to search users sometimes can be less specific the DN for modification. Look up the actual DNs with ldapsearch, if you are not sure.
- Does the Confluence User belong to a user directory? Local users (like admin) won't work for the test.
- Does the LDAP Attribute exist in the Schema of your user directory?
How are conflicting field values handled?
There is a slight possibility for conflicting field values.
Usually you'll have your users' data synchronized by the Scheduled Job "LUP: Bulk profile update (LDAP sync)".
As soon as someone starts to edit their own Confluence profile, the app quickly updates all the fields afresh, so changes that have been made since the last sync will be transferred to the profile. The user simply has to click on the save button to accept these changes.
On rare occasions there might be a conflict, if the user opens the edit dialog and then lets it sit open for a while. If during this time there are changes to the LDAP, by clicking on the save button the user will overwrite these.
Local file as XML data source
Use a local XML file on your confluence server as source for your profile data. Learn how to configure the CUP - XML import
The file has to be stored on the same server as your Confluence installation. Furthermore it must be accessible by the Confluence process.
Incremental LDAP Synchronization
Workaround for newly added profile fields
If you add new profile fields after you already activated the incremental sync, they won't be synchronized automatically. In this case simply clear the "Last LDAP sync date" field. This forces a full sync once, which will result in synchronizing all fields including the new ones.
Use an incremental LDAP synchronization of your user data to only import modified user data and benefit from a faster synchronization.
Go to Data Sources in the administration panel and select the LDAP tab.
Enable the incremental synchronization if you want to reduce time and server load. The next run of the LDAP sync will use the date defined in the field to "Last LDAP sync date" to synchronize only users who have been modified from that date up to now. Every time the sync job runs, it will set this date and time new. So usually you don't have to change anything here, except for two cases:
- you want to force a complete synchronization once: empty the field.
- you want to synchronize all users' data that has changed since a specific date: enter that date and time.
The plugin internally uses the timestamp format dd-MM-yyyy HH:mm:ss
So if you want to manually enter a date, you have to use this format, e.g. 23-05-2016 15:00:00.
Define the timestamp pattern of your LDAP resource
In order to make the synchronization work, the plugin needs the exact timestamp pattern your LDAP resource uses for storing the "last modified date" information. Please enter the pattern in the second input field.
Information for different timestamp patterns can be found here.
Examples:
yyyyMMddHHmmss.Z (known to work for a lot of AD installations)
yyyyMMddHHmmssZ (known to work for a lot of OpenLDAP installations)
Please make sure that all connected LDAP systems use the same timestamp pattern, otherwise no data will be synchronized.
Other Data sources
You can add an alternative LDAP and an XML import (p.e. from a SAP Export) to fill your users' profiles automatically.
Profile-Editor
See CUP - Profile-Editor for further information
Restricted categories
You can now restrict profile field categories to prevent users from seeing fields they don't need.
By choosing group restrictions, all profile fields within this category are only viewable / editable for users within the configured groups.
Users from other groups will not see these field in their profile. By default no groups are configured, so every user has the profile fields from this category.
This is not a security restriction, it is meant to reduce overhead for users! If a user has set a field, which is restricted later, the value can still be found in the search.
Theo Schröder ist in the "confluence-administrators" group, so he can see and edit all fields inside the "Admin only knowledge" category.
Kathrin Holmes is not in this group, therefore she can't see this field in her profile.
Help tooltips for profile fields
Help your users with useful information or examples for the data you expect them to put into certain fields. Users will see a question mark icon next to the field. Hovering with their mouse over it, they will see your help text as a tool tip. You can add a custom help text for each field, but it is not required to do so. Leave it empty, and there will be no question mark icon.
Please note that HTML tags are not allowed, only plain text. There is no restriction regarding the amount of text you enter as help text.
Known Issues
"Profile Updated" by Anonymous due to Confluence Synchronization
When Confluence synchronizes against any external user management, all of the newly created and updated users will be displayed under the "All Updates" section of "Recently Updated" macro in Confluence dashboard.
Considering the amount of users Confluence will create or update from the synchronization, it would be better to be excluded from "All Updates" section. Or at least, Confluence should provide the option to exclude these updates.
From Confluence 5.5 and later you can add the following argument in your JVM options to prevent updates to user information appearing in the dashboard https://jira.atlassian.com/browse/CONF-32081
Parentheses in filters are treated wrong
Since we have introduced complex filters for your custom landing pages, parentheses in filters are treated as logical characters. So your filter might be broken if you try to filter by attributes containing parentheses.
A workaround would be using the wildcard '?' instead of a parenthesis.
Problems with uploading profile pictures using Internet Explorer
Im some server configurations, a problem can occur when uploading profile pictures using the Internet Explorer. This problem leads to a page with the text "Loading...", and the user is unable to resize the picture. If this happens, the following snippet can be added to the Apache configuration, which should solve the issue (example for .png-files):
<LocationMatch ".*\.png$"> ForceType image/png Header set Content-Disposition inline Header set Content-Type image/png;charset=UTF-8 </LocationMatch>