xwikisas/application-ldapuserimport

LDAP User Import Application

• Project Lead: N/A
• Issue Tracker
• Development Practices
• Minimal XWiki version supported: XWiki 13.10
• License: LGPL 2.1

application-ldapuserimport's Issues

Use the LDAP user mapping to structure information displayed in the Import Users modal

It is possible to have different LDAP correspondents to the XWiki user properties. For example, the last_name (XWiki) can be mapped to sn, name, cn, etc (LDAP). Thus, the wiki administrator needs to configure this mapping (with fallback on the XWiki LDAP Authenticator default) and that mapping should be taken into account.

Add French translations

Users without UID should not be displayed

The LDAP UID attribute is used as username for user creation and having it empty will make the LDAP user invalid for import.
For example, if the UID configured in XWiki is sAMAccount but some LDAP user has no value in this field, the proposed user to import will look like xwiki:XWiki..

Add a configuration option to provide a custom LDAP filter

Current filter pattern: (&(objectClass=*)(|(cn=*a*)(givenName=*a*)(mail=*a*)(name=*a*)(sn=*a*))).

Confusing "Cancel" button is displayed in the ldap user import popup after a successful import

How to reproduce:

• go to a group page
• click edit
• click import users
• in the popup, fill in a search that will yield results
• in the results, check some box to import some users
• click the "Import" button
• import is done successfully

Actual result:

• the button on the bottom of the popup still says "Cancel" ("Annuler" in french) - what it actually does is to close the window

it's not clear what the "Cancel" button cancels at this point, does it cancel the import? (the import cannot be canceled anymore, it was done and the user was added to the group and only a group page history revert would "cancel" it). Because of this, a user may get confused as to whether they can click it or not.

Expected result:
The button's message should correspond to what the button will do: "Close". An alternative is that the button would not be displayed at all and if the user wants to close the popup because they're done with the import they would use the cross button on the top right corner of the popup.
This should be looked at in conjuction with the logical separation of forms here #29 (comment) - the dialog probably would need to have a "Close" button that is not part of any form, and this button would be the one that remains on the screen when the import form is not "active"...

Manual Import/update group function in group admin

Subtask of #37

1/ In the XWiki admin group list, next to each group display a button to "Import/update group" ("Importer/mettre à jour le groupe". When clicking on the button it should
1a/ create all missing users
1b/ sync the data of all already created users
1c/ add user to the group

A confirmation screen should display the number of users found before launching the sync:

" users have be found in the LDAP group and will be imported or updated"
" utilisateurs ont été trouvés dans le groupe LDAP et vont être importés ou mis à jour"
"Confirm"
"Confirmer"

An API already exists in the ldap tools to get all users corresponding to a group as configured in the LDAP group sync.
Make sure proper exception trapping will allow to continue the sync even if there is an error in the previous user imported/synced.

Importing should be protected by right but possible for a user with edit right on a group

It should be possible to configure a right for importing:

• Main wiki admin
• Local wiki admin
• Any user with edit right on the group

This can be by a configuration on the LDAP import.

• We need to verify that we can import as a normal user with edit right on a group with the proper configuration
• We need to verify we can restrict importing and that the button will not display if restricted

Import button is showing up, even if there is nothing to import

This happens:

• before searching.. Nothing is displayed but there is the Import button
• if there are no results
• after importing

Ideally there should be "Close" button instead, especially after importing

Add tooltips on the users list items from the Import User modal

The list of users to be imported displays the information in the Firstname LastName ([email protected]). In order to provide the full information for the configured fields, each user item should have a tooltip displayed on hover with extra details.

Display the OIDC configuration only if the OIDC extension is installed

Improve the layout of the Import User modal

Client-side time out occurs before server-side time out

Using an invalid host 5.135.240.218 the server side response is a timeout but the client-side time-out happens faster so the exception is not catch and thrown soon enough to get the error in UI.
At the same time, another invalid host 127.0.0.1s gives a faster response so the time-out can be reported in UI.
The case of 5.135.240.218 needs a deeper investigation.

Caused by: LDAPException: Unable to connect to server 5.135.240.218:6,389 (91) Connect Error
java.net.ConnectException: Connection timed out (Connection timed out)
	at com.novell.ldap.Connection.connect(Connection.java:476)
	at com.novell.ldap.Connection.connect(Connection.java:408)
	at com.novell.ldap.LDAPConnection.connect(LDAPConnection.java:2163)
	at org.xwiki.contrib.ldap.XWikiLDAPConnection.connect(XWikiLDAPConnection.java:245)
	at org.xwiki.contrib.ldap.XWikiLDAPConnection.open(XWikiLDAPConnection.java:212)
	... 216 more
Caused by: java.net.ConnectException: Connection timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:607)
	at java.net.Socket.connect(Socket.java:556)
	at java.net.Socket.<init>(Socket.java:452)
	at java.net.Socket.<init>(Socket.java:229)
	at com.novell.ldap.Connection.connect(Connection.java:457)
	... 220 more

Add a configuration option to toggle between single_field and all_fields search

In the LDAP User Import administration section, there should be an option to specify if the LDAP filter will search in a single field, specified by the user, or if it should search in all the fields configured in LDAP USER FIELDS property.
If the option is enabled (search in a single field), then in the Import User pop-up modal a select will be displayed with all the options from LDAP USER FIELDS.

Scheduler job updating all groups from LDAP group sync

SubTask for #37

2/ If a property of ldap is set to 1, then a scheduler job should automatically run the sync for all groups in the LDAP group sync.
The scheduler job should run at 4:30 am in the morning by default.
Make sure proper exception trapping will allow to continue the sync even if there is an error in the previous group/user imported/synced.

The same result as in 1 is expected with users created, updated and added to the group

Implement page name formatter

The application configuration should provide a way to control the format of the user page name created on import.

Update group membership of XWiki users is dangerous

It is possible now to do the following:

• define a LDAP group mapping containing XWiki.XWikiAdminGroup=anyLDAPGroup
• perform group update on XWiki.XWikiAdminGroup
  The result is that the initial admin user, XWiki.Admin in this case, is removed from the administration group, loosing all the rights inherited. This is very dangerous for the wiki and can be fixed with superadmin.
  The LDAP Authenticator does not touch the XWiki users when performing group membership synchronization, so if an user does not have a valid DN, no synch is performed.

In order to address the particular case of being able to clean the XWiki users from the mapped groups, we can use the default behavior from LDAP Authenticator and don't synchronize, but if a configuration option from LDAP User Import is enabled then clean the XWiki users.

The XWiki admin is responsible for checking the mapping and making sure that the admin users are not broken by this feature.

LDAP Groups that are already associated should be better highlighted

Null displayed as first name of the user in the import feedback, even if the user is imported properly

Reproduced on version 1.0.3 of the ldap user import.

Upon import of a user, in the confirmation message, "null" is displayed as the first name of the user instead of their actual first name:

even if, in the created user profile, the first name of the user is properly filled in.

In the ldap configuration, the first name is mapped to the ldap field givenname .

Note: on a search of users, in the search results, this user is properly displayed with their first name.

Enter key in the search user input does not launch the search

How to reproduce:

• go on a group page
• click edit
• click import users
• in the displayed popup, fill in a search string
• hit the enter key
  

Expected result:

• the search should be launched by the enter key and the search results displayed

Actual result

• the "search" button neds to be actioned specifically: clicked with the mouse or navigated to with the tab key and actioned there

Add hints to the LDAP Users Import configuration from Administration

Hints containing explanation about the purpose of each field should be added. At this point, the Configurable feature (https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Application#HMakingyourapplicationconfigurablewithConfigurableClass) does not handle the hints that can be added in the XWiki class definition. However, there's a workaround implemented in https://jira.xwiki.org/browse/XWIKI-12035

Add the import functionality

Given a list of LDAP users, it should be possible to select one or many users to be imported in XWiki.
This should follow the LDAP configuration and should provide the same result provided by ldap authentication module (user mappting, groups mapping, uid, etc).

No feedback on the screen when the import is ongoing: import can be launched multiple times while it's ongoing

How to reproduce:

• go to a group page
• click edit
• click import users
• in the popup, fill in a search that will yield results
• in the results, check some box to import some users
• click the "Import" button
  

Expected result:

• There should be some feedback on the screen that the import has started and it's ongoing (that the Import button actually worked)

Actual result

• Nothing changes on the screen at this point, it's not clear whether the button worked or not, whether the import started or not.
• In addition, the Import button remains usable, and can be clicked as many times as one wants - it's very probable for this to happen as there is no feedback on the screen that the first click was actually taken into account but it also depends on how long the import takes (this may be related to various server settings but also to the speed of the internet connection on the client)
  • If the button is clicked multiple times, at some point (when the multiple imports finish), there are a couple of messages displayed in the popup, that replace eachother, some are saying success, some are saying error
  • In any case, at the end of all this (when popup is closed) the user appears multiple times in the group, but with the same username (which was blurred on this screenshot) - later edit: they're not all with the same username, see comment below:

Update parent version to 10.11

The display of the button to import a user in the context of a group is not consistent between the different places where it's displayed

When navigating to the page of the group, an "Import users" button is displayed under the users table, in both view and edit mode:

View:

Edit:

However, when editing a group from the administration of the wiki, from the groups table (by clicking on the edit button), the import button is displayed next to the inputs allowing to select an existing user from the wiki:

There are 2 aspects of the currently reported issue:

• the display should be coherent in both cases, for efficient user experience
• my preference goes for the display from the administration, it presents the import button as an alternative to searching for an existing user on the wiki, which is what this button is

Referral exception sometimes thrown upon search of users

For some searches (not clear which ones), the following exception is logged by the ldap user import:

[...] xwiki/bin/get/LDAPUserImport/LDAPUserImportService] WARN  i.DefaultLDAPUserImportManager - Failed to get results 
com.novell.ldap.LDAPReferralException: Referral
	at com.novell.ldap.LDAPSearchResults.next(LDAPSearchResults.java:253)
	at org.xwiki.contrib.ldap.PagedLDAPSearchResults.next(PagedLDAPSearchResults.java:182)
	at com.xwiki.ldapuserimport.internal.DefaultLDAPUserImportManager.getUsers(DefaultLDAPUserImportManager.java:247)
	at com.xwiki.ldapuserimport.internal.DefaultLDAPUserImportManager.getUsers(DefaultLDAPUserImportManager.java:154)
	at com.xwiki.ldapuserimport.script.LDAPUserImportScriptService.getUsers(LDAPUserImportScriptService.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
        [...]

The referral topic seems to be related to the ldap server returning, as a result, a reference to other ldap servers (on which searches would need to be performed), probably for some sort of "aggregation" or "proxy"-ing of ldap servers (i'm not at all familiar with the topic).

This seems to have been handled in the past as https://jira.xwiki.org/browse/XWIKI-2388 and https://jira.xwiki.org/browse/XWIKI-6070 .
I propose to do the following as part of the ticket:

• diagnose the consequences of this exception: what is the functional impact of this exception? Are there missing results in the search? Does this create a desynchronization between the accounts that can connect on the wiki using ldap authentication and the accounts that can be imported ?
• fix these consequences, if possible
• if there are no functional consequences, handle the exception better so that it still displays (as a warning) but doesn't pollute the logs.

After importing and closing the window, we should see the user(s) imported

After importing and closing the window, we end up on different screens depending on where we click on the import button. We need to make sure in each of these cases that we see the user(s) imported if they should be on these screens. In most cases it should be enough to reload the page.

More generally we should come back to where we were.

1/ If we open from a group edit in the admin section, we should come back to the edit group view and see the user imported in the livetablee
2/ If we open from group page in edit mode we should see the user imported

This is also related to #20 as the button placement is not always correct.

Prepare documentation explaining the install procedure

Explain how the application should be installed.
As far as I know:

/ Install LDAP Import API on Farm
2/ Install configuration on main wiki and on subwiki
3/ Install LDAP on main wiki

Change the text of the buttons to be smaller

Instead of Associate LDAP Group and Import/update group we should name the buttons Associate and Update together with the tooltip providing more details about the actions.

Allow the creation of OIDC compatible users

It should be possible to have OIDC configured as authenticator. The username of the new created user from LDAP should follow the pattern required by the OIDC configuration.
An OIDC object needs to be added in the user profile.
A configuration is needed to specify that the user should be OIDC compatible
For now, a default pattern in the code should be enough. No need to have it configurable at this point.

Improve the configuration source management

A better way than having a dedicated configuration source for this extension to get the main wiki XWikiProperties configuration, is to rely on the standard configuration source management while using the main wiki context. This will also provide some compatibility with other extensions (Active Directory) that have their own configuration source.

Improve the message when user is being imported

Currently we have:

xwiki:XWiki.aluca

We should have:

Anca Luca (aluca, [email protected] user profile has been created in [[xwiki:XWiki.aluca]]

Provide some feedback when users are not found for the current search

This should include a feedback message at UI level (No users were found for the searched value!) and some logging with more details about the filter used for the search.

Improve the error handling at UI level

Do not show LDAP import configuration in sub wiki

When clicking on "ldap import" in a subwiki, instead of displaying the configuration fields, show a link pointing to the main wiki ldap import config with a message "This module is configured in the main wiki"

Associate LDAP group button in group Admin

SubTask for #37

3/ (priority low) A button "Associate LDAP Group" should be displayed next to each group not listed in the LDAP group sync. When clicking on this button it should be possible to search for a group.

The search should search in the "cn" field for entries having on the objectClass listed in the configuration "xwiki.authentication.ldap.group_classes" in the LDAP config. See https://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/

When selecting the group, the UI should add the group to the LDAP Group sync configuration and reload the group list. When reloading the button "Import/update group" from 1/ should be displayed.

Imported users are added as LOCAL users in subwiki groups, instead of GLOBAL

Provide support for Active Directory integration

Some adjustments need to be done in order to use the Active Directory configuration source, if exists.

Wrong display of the message about the limit of results displayed in French language

This concerns the message displayed for #33 , when the language of the wiki is set to french:

The link to update the configuration is not displayed, {1} is displayed in the message and the apostrophes are missing.

Improve the error handling with user friendly messages in the UI

The ldapuserimport component cannot be initialized when installing it in multiple wikis instead of on farm

At this point, the API module can be installed either on only one wiki, either on farm. Individually installing it in more than one wiki will cause a cache initialization failure:

Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [com.xwiki.ldapuserimport.internal.DefaultLDAPUserImportManager] identified by type [interface com.xwiki.ldapuserimport.LDAPUserImportManager] and hint [default]
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:204)
	at org.xwiki.component.embed.EmbeddableComponentManager.getDependencyInstance(EmbeddableComponentManager.java:406)
	at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:355)
	at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:451)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:201)
	... 241 common frames omitted
Caused by: java.lang.RuntimeException: Failed to load component for type [interface org.xwiki.configuration.ConfigurationSource] for hint [ldapuserimport]
	at com.xpn.xwiki.web.Utils.getComponent(Utils.java:754)
	at com.xpn.xwiki.web.Utils.getComponent(Utils.java:715)
	at com.xwiki.ldapuserimport.internal.DefaultLDAPUserImportManager.<init>(DefaultLDAPUserImportManager.java:100)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347)
	at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:451)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:201)
	... 245 common frames omitted
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [com.xwiki.ldapuserimport.internal.LDAPUserImportConfigurationSource] identified by type [interface org.xwiki.configuration.ConfigurationSource] and hint [ldapuserimport]
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:204)
	at org.xwiki.component.internal.multi.DelegateComponentManager.getInstance(DelegateComponentManager.java:83)
	at org.xwiki.component.internal.multi.DelegateComponentManager.getInstance(DelegateComponentManager.java:83)
	at org.xwiki.component.internal.multi.DelegateComponentManager.getInstance(DelegateComponentManager.java:83)
	at org.xwiki.component.internal.multi.DelegateComponentManager.getInstance(DelegateComponentManager.java:83)
	at org.xwiki.component.internal.multi.DelegateComponentManager.getInstance(DelegateComponentManager.java:83)
	at com.xpn.xwiki.web.Utils.getComponent(Utils.java:752)
	... 255 common frames omitted
Caused by: org.xwiki.component.phase.InitializationException: Failed to initialize cache
	at org.xwiki.configuration.internal.AbstractDocumentConfigurationSource.initialize(AbstractDocumentConfigurationSource.java:135)
	at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)
	at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:365)
	at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:451)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:201)
	... 261 common frames omitted
Caused by: org.xwiki.cache.CacheException: Cache with name [configuration.ldapuserimport.wiki] already exist
	at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:152)
	at org.xwiki.cache.internal.DefaultCacheManager.createNewCache(DefaultCacheManager.java:112)
	at org.xwiki.cache.internal.DefaultCacheManager.createNewCache(DefaultCacheManager.java:85)
	at org.xwiki.configuration.internal.AbstractDocumentConfigurationSource.initialize(AbstractDocumentConfigurationSource.java:133)

Store the issuer from the OIDC configuration

If OIDC application is installed and enabled in the context of the LDAP User Import, store the issuer value along with the subject value in the OIDC profile object.

Don't display the import users button on the group page in view mode

This issue is a continuation of #20 .

Currently, the import users button is displayed, on a group page, in both view mode and edit mode.

My vision is the following:

The functionality provided by this module is an alternative to adding an existing user in the group.
Most of the times, the administrator adding users in the group will want to add an existing user, if they exist, and only when the user does not already exist import them from LDAP. The usecase when the administrator knows a user doesn't exist yet is quite rare, I would say, and it's still possible with the alternative. Thus, the "import" button should be presented systematically as an alternative to the add user button. Since there is no add user button in the group view mode, there should be no import user button either.
In addition, the import user button in view mode could be confusing as it may make the administrator believe that that is the only way in which people can be added to the group (and make them miss the "edit" button for the group).

Users are imported with name "Sys Auth"

It seems on mindef staging that all users are imported as "Sys Auth" although the LDAP mapping seems ok.

Import users in the current Group when using the Importer from a Group page

When the Import is triggered from a given group (group page or edit group modal - see #5), the user should be also added as member in the current group.

Add the Import User button in all the needed locations

The User Import button should be available in multiple locations:

1. In any group page -> under the members livetable
   

2. In the edit group modal (used for adding new members) -> next to Add button
   

3. In the Users section from the administration -> next to Create User button, for the main wiki
   

4. In the Users section from the administration -> next to Add and Invite buttons, for subwikis
   

Automate Group Sync

The Goal is to implement a Automated Group Sync.

For all groups that are listed in the group synchronization, then:

1/ In the XWiki admin group list, next to each group display a button to "Import/update group" ("Importer/mettre à jour le groupe". When clicking on the button it should
1a/ create all missing users
1b/ sync the data of all already created users
1c/ add the user to the group

A confirmation screen should display the number of users found before launching the sync:

" users have be found in the LDAP group and will be imported or updated"
" utilisateurs ont été trouvés dans le groupe LDAP et vont être importés ou mis à jour"
"Confirm"
"Confirmer"

An API already exists in the ldap tools to get all users corresponding to a group as configured in the LDAP group sync.
Make sure proper exception trapping will allow to continue the sync even if there is an error in the previous user imported/synced.

2/ If a property of ldap is set to 1, then a scheduler job should automatically run the sync for all groups in the LDAP group sync.
The scheduler job should run at 4:30 am in the morning by default.
Make sure proper exception trapping will allow to continue the sync even if there is an error in the previous group/user imported/synced.

The same result as in 1 is expected with users created, updated and added to the group

3/ (priority low) A button "Associate LDAP Group" should be displayed next to each group not listed in the LDAP group sync. When clicking on this button it should be possible to search for a group.

The search should search in the "cn" field for entries having on the objectClass listed in the configuration "xwiki.authentication.ldap.group_classes" in the LDAP config. See https://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/

When selecting the group, the UI should add the group to the LDAP Group sync configuration and reload the group list. When reloading the button "Import/update group" from 1/ should be displayed.

Null key for a Map not allowed in JSON

There is a particular case, when the uid field is part of the fields mapping, that causes

Failed to serialize object to JSON 
com.fasterxml.jackson.databind.JsonMappingException: Null key for a Map not allowed in JSON (use a converting
NullKeySerializer?) (through reference chain: java.util.LinkedHashMap["users"]->java.util.HashMap["null"])

on https://github.com/xwikisas/application-ldapuserimport/blob/main/application-ldapuserimport-api/src/main/java/com/xwiki/ldapuserimport/internal/DefaultLDAPUserImportManager.java#L289.
For example, if the uid is sn and the mapping contains last_name=sn.
This can happen when the uid is sn because there is a default mapping (first_name=givenName,last_name=sn,email=mail) that improves the usability of the application (it can work without configuring the mapping on UI) and it can also happen when the administrator explicitly configures the mapping to contain it.

What is needed here is a better way of building the users Map.

Display a message when the number of results of the search is limited by the 20 (21) users limit

This issue concerns the display of the search results when a search is performed in order to find users to import.
The number of results is capped at 21 (not really clear why 21, probably an off-by-one counting error when limiting).

The current behaviour is the following:

• open the import dialog
• search for users (in order to reproduce, a very generic search using a single letter (a or e) does the job)
• 21 results, both imported and not imported are displayed on the screen
  • these results are ordered alphabetically - but this ordering turns out to be done after the capping to 21, so they're not the first 21 results in alphabetical order, they are the first 21 results in random order (whatever order provided by the LDAP server), ordered afterwards.
  • this ordering is important, as it contributes significantly to the confusion (see below)
• there is no indication on the screen that the 21 results are not all the results but only the "first" 21, so it's very hard for the user performing the import (admin) to understand why a user that they're expecting in the results is not "found" (it actually may be found but just not displayed because not in the first 21).
  • on large LDAP servers with many accounts it's probably more probable for this cap to be reached for a "normal" search, not only for a too generic search.

Expected result:
One easy palliation of this issue is to just provide feedback on the screen when the cap is reached, encouraging the importer to refine their search by adding details.
Note: the wording used when providing this cap needs to be very carefully chosen to avoid misleading the importer into believing that the 21 displayed results are the first 21 alphabetical results, as this is not true. Maybe we could drop the sorting alltogether if we don't find a coherent way to present this to users.

More advanced handling of the capping situation (but complex, I would say, and that would need new tickets) may include:

• giving priority to the accounts not yet imported when capping
  • in the current situation, accounts that are already imported may be displayed in the 21 results on the screen while accounts that are not imported yet may be left out, requiring a second more precise search. This is rather useless for the importer, they are searching for users in order to import them, so the fact that accounts for which no action is possible (the already imported users) have priority over account for which actions are possible (and probably desired).
• allowing the admin to configure the cap in the ldap user import configuration - this would be an easy solution to allow the admin to temporarily raise the limit in order to be able to find an account on LDAP, if there is no refinement possible for the search string.
• implementing a real pagination to allow access to all accounts.

Group action buttons are not loaded every time

There may be some cases, depending on how fast livetable is loaded, when the Update and Associate buttons are not loaded.
Also, when one of these 2 actions are performed, the livetable needs to be refreshed and the buttons should be still there, which is not the case, currently.

Exclude the subwiki User Invite form from being updated by JavaScript

In the group page (edit mode) and edit group modal, a layout transformation is process through JavaScript. Having the same CSS selector, the User Invite form from subwiki was also processed when it was not needed.