Occasionally, I get a “classic” support case and last week just that happened. A CORE™ user told me that he imported a data file and it appeared to work, but produced a conflict file. Then he couldn’t see the project. He imported again and again with the same result.
Not really all that classic, but definitely something that could be explained in detail!
There are basically two things happening here.
1.All imports carry with them the permissions restrictions from the source. The user accounts that had permissions in the source do not exist in the destination, so the permissions for these users were removed. This is what most of the conflicts were reporting.
2. The final line in the file is key to why the import appears to have failed. Remember I said that the users don’t exist, so the permissions for those users were removed? Well, the user account used to import the file didn’t have permission to view the data, so after the import, it appears to just disappear. It’s actually there, and that’s what the last line in the file indicates.
Let’s talk about how to overcome this. Because everyone’s environment is unique, it’s helpful to summarize the assumptions in this scenario.
Assumptions:
1.The data source is a local client installation of CORE that does not use a server.
2.In the local client, you have set up an account name.
3.That local client account is given permission to the project.
4.You have other user accounts on the server, probably ones that were created manually in the server.
Now, we can fix it the fast way, or the right way.
The fast way is just fine if you intend the data move to be a one-time thing, such as you started the data on your local machine and are importing it in to the server to work on it there from now on. If that’s the case, then:
1.Go back to the local data source.
2.Log in to the project as the user with permissions.
3.Click Tools > Administrative Tools.
4.Right-click on the project and select Manage > Set Project Permissions.
5.Give the “Administrator” account administrative permissions on the project.
6.Export to XML.
7.Log out.
8.Log in to the server on the “Administrator” account.
9.Import the XML from Step 6.
10.Go to Administrative Tools and set the permissions as desired.
The long way is the path you want if you plan to exchange the data between these two sources on a regular basis. This might be the case if you were exchanging the data file with a contractor, another office, or your customer. If so, then we need to declare one of the locations as the source for the user accounts and data.
1.Pick one of the locations as the source for the user accounts, this is most likely the server as you probably already have more accounts set up there.
2.Log in to that location and create user accounts for everyone that might need to access this data in any way.
3.Do everything in the “fast way” steps above to bring in the data and set the permissions as desired.
4.Export Users & Groups. (You’ll find this option in the Export dialog.)
5.Log out of CORE.
6.Go to the other location and log in.
7.Delete all user accounts in this location.
8.Import the Users & Groups file from Step 4.
9.You are now ready for data exchange.
The key here is in understanding how user accounts and permissions work. When you create a user account, a unique ID is created with it. Then, project permissions are linked to the unique ID, NOT the actual user name. So, if I created a BMaddox account on my local machine, then logged in to the CORE Server and created a BMaddox account, these two accounts would have different unique IDs. Therefore, permissions from local data would not work on server data, and vice versa.
To overcome this, the steps above have me set up accounts in a source, then export and import them into the other location. This export/import process preserves the unique IDs, thus preserving project permissions.
For more information on CORE Server administration, please reference my webinar on the topic in the MySupport area of our website.
