[ORD 2020 R3] Organization vs Organization Civil CFG priority?

I struggled with this as well

Your Workspace config can specify which Civil Organization is loaded. 

So I've set this up in such a way (so far) that the delivered client standards are under Organization-Civil, but when they user picks which workspace they are in, it loads the correct Organization standard. 

For Workspace level, my plan is to use it as an too append or add on configuration files that are not from the client, but apply for use.

I don't know if this is correct.   But it seems to work for the 3 sets configs we have now. 

The screen shot below shows the order of the loading of the configuration files.

The red arrow shows the 'Organization' standards cfg file being processed (45). These get loaded first.

The orange arrow is the WorkSpace cfg file (UK Projects) (47) - the first thing that this file does is then load the 'Organization-Civil' standards (UK Standards in this case - 48) - green arrow..

Finally, the WorkSet cfg file is loaded (purple arrow - 49) - 'Demo 109.cfg' in this example.

Hey Mark Marnell How do you pull up the File history dialog?

Shawn Cooke - I use the Bentley Configuration Explorer application. The screen shot shows the application's file history dialog.

https://www.bentley.com/en/products/product-line/modeling-and-visualization-software/bentley-configuration-explorer

We want to keep configurations in one location on our server, however project files (DGNs, templates, etc.) will be stored in an entirely different part of our network. A lot of client configs appear to default to the Bentley default of storing project files in the worksets in the same location as the rest of the configurations. But they all have their own tweaks to that and their own variables defined to cover it, so parsing all the variables is a challenge.

From the looks of this, I am either going to have to lock A LOT of variables at the Organization level, or I am going to have to redefine a lot of things in the workset CFG.

I am open to any suggestions.

Configuration explorer looks like a great tool, however I am running into "critical errors" with these client workspaces even without the network issue. Each one has some %elif exists that refuses to solve or move on (and it's different in each CFG). That's not helping.

We want to keep configurations in one location on our server, however project files (DGNs, templates, etc.) will be stored in an entirely different part of our network. A lot of client configs appear to default to the Bentley default of storing project files in the worksets in the same location as the rest of the configurations. But they all have their own tweaks to that and their own variables defined to cover it, so parsing all the variables is a challenge.

From the looks of this, I am either going to have to lock A LOT of variables at the Organization level, or I am going to have to redefine a lot of things in the workset CFG.

I am open to any suggestions.

Configuration explorer looks like a great tool, however I am running into "critical errors" with these client workspaces even without the network issue. Each one has some %elif exists that refuses to solve or move on (and it's different in each CFG). That's not helping.

MaryB - make sure the %if statements do not have spaces in them.

For example, this statement
%if exists $(_USTN_WORKSPACESTANDARDS)Template Library/$(CIVIL_WORKSPACE_TEMPLATE_LIBRARY_NAME)

becomes

TEMPLATE_LIB = Template Library/
%if exists $(_USTN_WORKSPACESTANDARDS)$(TEMPLATE_LIB)$(CIVIL_WORKSPACE_TEMPLATE_LIBRARY_NAME)

due to the space in 'Template Library/'.

It is possible to have the configuration in one location, the WorkSpaces in another, and the WorkSets in yet another.

I just went through this exercise, except I only have one Organization-Civil to contend with.

I setup our Workspace like this:

Where the Workspace is SHA ORD and the actual Worksets are individual Project folders which are Work Areas in ProjectWise. The highlighted Worksets folder is where the CFG files are stored that are named to match the Project folder names.

This process used the "Video: How-To Deploy a Dynamic ProjectWise Managed WorkSpace" process and the "Video: How to Configure Projects (or WorkSets) outside of the Managed WorkSpace in ProjectWise" process to implement the Project folder outside of the configuration folder structure. 

In order to edit my workspace files in a workspace/workset, the top Workspace folder and the SHA ORD had to be setup as Work Areas. The subfolders under MDOT SHA 2021: _ProjectWide\CAD Resources\dgn\ is part of our standard Project structure and is where I am attempting to store my DGNWS file(s). I only mention attempting because in my test workspace, using a newer ProjectWise than our production ProjectWise, that worked just fine. But on our Production server, I can't get the DGNWS files to work. According to everything in the videos, once setup, when you open a file for the first time in a workspace/workset that does not have a DGNWS file, one will be created. But it is not creating the file and any attempt to fake it is resulting in the file only being opened in a no workspace/no workset mode.

It did take some trial and error to get it operational on our test server. I have a new post asking for ideas on my my DGNWS files are not being created automatically. And these seems to be no way to manually create one. UPDATE: The folder I was using for the DGNWS files was not setup for read-write by anyone. No error message appears to explain that fact, but now I know why and how we need to implement things moving forward.

I believe this approach will work on network shares, just use CFG files instead of CSB’s.