Erratic behavior with bulk import using 1.1.5 in multisite

I am running the ADI plugin on my company intranet and the bulk import process was not working on either my production or test servers, but it was working on my development server. With this in mind, I was essentially trying to break the bulk import function on my development server to see if I could diagnose why it wasn’t working on my test or production servers.

After some trial and error, I was able to break my working instance of the ADI bulk import function on my development server. The good thing, in this case, is I was able to document how I broke it in hopes that I might get some helpful info on why it broke and (maybe) how to fix it.

Before I get into what I did to break it, I’ll provide some detail about how we’re using the network. This is a company intranet, so all of the sites in the network represent either a business unit of the company or some specific program content, etc. In the main, root site, I manually run the bulk import of all company employees every couple of days to ensure that user profiles are updated and new employees are added, etc. This bulk import at the root level adds users to both the main site users list and to the network users list. Most everyone in the company is assigned a subscriber role on the main root site. Once they are authenticated, they then have access to view the entire network of sites as a visitor, even though they are only technically imported to the main root site user list. Unfortunately, with a couple of recent updates to some other plugins, it has now become necessary to actually import every user into every site with a specific role.

At the subsite level, where I’ve been having the bulk import trouble, I used a test AD security group containing three users who are a subset of the already imported users for the entire network. On a test subsite, I added the necessary ADI plugin settings under authorization (“Role equivalent settings”) and also added the AD test security group to the groups to be imported. I ran the bulk import and it worked as expected. Three users were added to the subsite users list with the correct role.

After the test users were added, I manually removed them from the subsite users list by checking the box next to each name and selecting “Remove user” from the bulk apply function. The screen refreshed, the notice appeared at the top that the selected users were removed and they no longer appeared in the user list. A second time, I ran the bulk import with the same test group and the results were successful, just like the first import. So far, so good.

Before I ran the bulk import a third time, I cleared out the “Additional attributes” under the User Meta tab, while “Overwrite with empty values” and “Show Attributes” were already unchecked and left so. When I re-ran the bulk import for the test group, the import didn’t technically fail, but the bulk import process reported back that no users were added and three users were updated. This was strange, since these three users had been manually removed from the site and how could they be updated if they didn’t exist? Refreshing the subsite user list, none of the three users in the test group were added to the site with the assigned role. I ran the bulk import again (fourth time), same results. It’s as if the bulk import function was still seeing the users as being in the subsite and “updating” them instead of adding them.

I added the “Additional attributes” back under the User Meta tab and tried the bulk import a fifth time. The import process still didn’t work and behaved the same as described above. Next, I unchecked “Append account suffix to new created usernames” under the User tab. (I’ll note that it is necessary to have this setting checked at the root site when importing new users for our intranet accounts to work correctly.) I re-ran the bulk import a sixth time with my test group and the three users were added back to the site, as expected, just like the first and second time I ran the import. And even though “Append account suffix…” was unchecked, the users added to the subsite were the correct users from the Network user list, not three duplicated users without an account suffix.

So, with all of that, can anyone point me to an answer as to why the plugin is behaving like this? It seems that, somehow, the process of manually removing users from a site and then modifying some part of the import causes future imports to stop working until some other random configuration is changed in the plugin, at which point the import process starts to work again.

The reason why this is important is because, once all the necessary AD security group users have been imported to each network site with their assigned roles, eventually there will be employees who will move from one role to another within the company; for example, from a regular employee to a supervisor or manager. When that happens, it will be necessary to remove the user from a site and then use the bulk import process to add them back to the site with the correct new role.

I have found that If I simply change the role of an existing user on a subsite, their new role is downgraded back to their original role each time the bulk import is run. This is why just manually changing the role isn’t a solution and it is necessary to remove the user from the site and then add them back with the bulk import function.

https://www.ads-software.com/plugins/active-directory-integration/