Where and how is the variable _USTN_WORKSETDGNWS defined?

Well, this is sort of embarrassing! But it's not 100% my fault!

First and foremost, it turns out that my inability to get the DGNWS file to work was due to a permissions setting in my target folder location. Once I realized that, I was finally able to get the DGNWS file to get created once a file was opened in the Workset. However, do you think an error message, like "Unable to create DGNWS file. You do not have sufficient permissions to complete that task." might have helped.

With that out of the way, allow me to rant a little:

There are a lot of variables in CONNECT that are potentially stupid! I know that sounds harsh, but hear me out.

There is a variable named _USTN_WORKSETDGNS which is defined as the "Search Path for design files". I don't know how others work, but in a large organization like a DOT, or on large projects, DGN files are spread all over the place in a project folder structure. Usually, by discipline but even within one discipline, many departments keep sheet files separated from drawing or model files. If there is a purpose for this "search path" that would justify defining it to all the possible DGN file locations, it would be nice to know what this actually does. 

Another variable is _USTN_WORKSETSTANDARDSDIRNAME which is defined as the "Base directory name for Standards of WorkSet. At the time of creating new WorkSet, this name is appended to the WorkSet root directory path". By default, it is defined as "Standards". Additionally, there is a variable _USTN_WORKSETSTANDARDS which appears to be the combination of the previous variable and the WorkSet root directory path, as the previous variable's definition explain. Well, on our project folder setup, I needed to redefine the _USTN_WORKSETSTANDARDSDIRNAME to match our folder names. After making that changes, I thought that _USTN_WORKSETSTANDARDS would naturally adjust to match this new definition. But no, it had no effect. I had to redefine _USTN_WORKSETSTANDARDS to use the WorkSet root directory path plus my definition of _USTN_WORKSETSTANDARDSDIRNAME to get it to work.

One last observation - this is a ProjectWise observation, but it might apply to a non-PW workspace: When you review a path variable in the configuration dialog box, if the Value displays back-slashes as the path separators, that is an indication that the path defined actually exists. If you see the Value is still using forward-slashes, it means that the folder specified is non-existent. For example, the previously mentioned _USTN_WORKSETDGNS variable displays using forward slashes since my DGN folder names is seldom DGN nor is it located right below the top level folder of the WorkSet.

I still have no idea how or where the default location for the DGNWS is defined, but in ProjectWise, I finally undefined it in my Predefined CSB's to get the full path definition to stick. However, even though its definition claims it to be a full path variable, it may work when defined as a name only value if the variable _USTN_WORKSETSDGNWSROOT is correctly defined to its folder path. 

Those are very good points and I agree with all of them.  Working outside PW, the DGNWS file and the functionality that can be associated with it would helpful, especially when using fields in title blocks and all that.

In the past, I configured our workspaces to a central location distant from the actual project CAD files.  This was done to have all our users resource standards from once central location (DUH!), prevent them from editing said standards and allow our IT folks to easily assign the necessary file access permissions.  Its been a disappointment that even at Release 16, the DGNWS file still can't reside "outside the standard "Configuration" folders.  At to your point, _USTN_WORKSETSDGNWSROOT is a variable that serves no purpose.

I filed an SR several months ago and it is indeed a defect (as they call it) Defect 1116741and its anticipated to be addressed in Release 17.  16 Releases too late.

here is another DGNWS woe:

https://communities.bentley.com/products/road___site_design/f/geopak-inroads-mx-openroads-forum/217047/managing-sheet-index-dgnws-for-different-companies-disciplines-on-the-same-project

Hi Charles,

A defect titled "WorkSet Template Custom Properties not copied to new WorkSet" was fixed in MicroStation Update 14 (10.14.00.109). The description of this matches your experiences.

Which application versions are you using?

I think the DGNWS file gets the needed properties, but if it is located other than with the workset it doesn't get read. He stated that if he moved the created DGNWS file under the worksets folder then he was able to see the added properties.

BUT... if I copy the DGNWS file to the Workset folder, all the fields are present and works "as it should"

or am I reading it wrong ?

Marc,

I'm using release 16.  I know I created the fields earlier this year probably with Release 15.  I filed the SR in April and notified of the defect.

Tim,

You nailed it.  The fields are available ONLY if the DGNWS file is in the same folder as the workset cfg file ( _USTN_WORKSETSROOT).  The fields ARE NOT available if the DGNWS file exists anywhere else even the defined DGNWS root folder (_USTN_WORKSETSDGNWSROOT)

Tim,

You nailed it.  The fields are available ONLY if the DGNWS file is in the same folder as the workset cfg file ( _USTN_WORKSETSROOT).  The fields ARE NOT available if the DGNWS file exists anywhere else even the defined DGNWS root folder (_USTN_WORKSETSDGNWSROOT)

I just tested adding a custom field in one of my configs where the DGNWS is with the project data, the field was not displayed in a new session. I will flag this with the team.

Thanks Marc.

So do you see our frustration?  Don't get me wrong, I love the new functionality and all, but it gets old when, someone who is the admin and wants to add these features when a) it works in one release, but not in another, b) only works in the "Bentley" controlled environment, c) all the above.

Yes completely.

Marc,

Is there a timeframe or specific build that we can expect this issue to get resolved?  Or has it already been resolved?

Thanks,

Chuck

Hi Charles, I've filed an SR about this one on your behalf.

For anyone concerned about this problem, the active defect is no 658928 "WorkSet custom properties vanish when DGNWS and CFG are in different locations". Please file an SR referencing this defect number and discussion.

I have updated it with further details to assist the developers.