Fix the MS_CONFIGURATIONOPTS variable to work within the correct configuration level

this is not fixed in update 14. it still takes the variable setting from the last loaded workspace rather then when a workspace is selected.

this is all good information - thanks - it helps Bentley understand the different requirements and complexities of their configuraions. 

Tim,

We tried to use the delivered functionality first, we always try that first.

We originally did make use of the create workset from template option. we released the workspace and had an installer to help set it up. since the workset template is within the workspace (that's the easier way to deliver it). and you could only select a template if that template is at the location of the worksets. so the user has to know to copy the delivered template from within the workspace over to where ever they store the worksets. and then they also need to know if we ever change anything in the template the changes also need copied over. so we had a sync tool to help mange that.

but within Ohio we have two state plain zones. so the workset seed files that go into a workset have these GCS predefined. but there is no logic that can be added to creating a workset from a template. so there is no way to make sure the workset gets the correct seed files to ensure the GCS are correct.

So we wrote a little vba that after you create the workset you then have to open a dgn file and run a vba to finish setting up the workset correctly. note there are some other things the vba does but in general the problem was we need some logic during the creation process.

so we showed our users this is how you can use out of the box tools to create a workset. and we used that for a while 

Well then comes ProjectWise. there is no way to create a workset inside ProjectWise. this was something that was missing in the ProjectWise integration (in my opinion). there should have been something added to create a workset when you select create workarea. but anyways this was another problem.

then almost all of out consultants said they need the ability to put workset folders in different locations. which the configuration can handle the workset folder in a different location then the workset cfg file. but the create workset button can not handle this.

So at this point we give the out of the box a fair try but came to the realization it just didn't have the needed functionality.

SO we made our own workset creation app. this way creating a workset would not be a 2 step process and we could make it work inside and outside of ProjectWise. (Side note our workspace works inside and outside of ProjectWise so we only have to manage one copy of it). Also we no longer had to worry about if the template in the worksets location was up to date as we no longer need to copy it there.

our custom application make it super easy for our consultants so they don't have to get into the weeds with configuration. they can run the app and it handles the configuration and whole creation process in one step. that was a brief summary there was more going on, but I highlighted the main reasons.

So now that we made this change I don't want our users to create the workset using the out of the box way because they way is no longer being supported.

You say the variable does not work with configuration levels. are there any other variables that don't work with configuration levels? is this documented anywhere? how is a user suppose to know which random variables Bentley decided to not support configuration levels with? Do you see where I'm coming from that this is a defect. even if it was designed to work this way, it was designed against your own rules of configuration making it a defect, which means I really shouldn't have to submit an idea to get this addressed. I know this variable was added after the fact but it seems like it was just implemented poorly and needs to be fixed. My understanding was the ideas are for enhancements to see what could be added, not to see if a defect should be fixed or not.

I understand the concept of levels. The variable does not work with them. Call it what you want - it was not designed to work the way you intend it to.

This is why you have posted here (for the enhancement/change).

Don't get me wrong - I do agree that the variable is short sided and it should work at these multiple levels, but at the same time if you want your users to create consistent worksets - then what is wrong with them using the "template" option ?

If you have a workset that already exists in a manner that you like, why not use that as a template when the workset is created ? This way the DOT supplied workset could be used, or your custom one that your app creates could be used (and the app would really not be needed) . Just suggesting a workflow in the meantime.

Tim your not understanding what I'm saying. we release a workspace. a workset goes with a given workspace. so the application to create a workset would be limited to just the workspace we release. So no I would not want to  disable it in all cases. Again why would I want to effect how other workspaces work from within a given workspace. Another workspace could be from maybe different Department of transportation and maybe they are utilizing the create workset button.

Maybe you didn't read my whole comment if you did you would have seen the part where I said "but I don't want to disable it for another workspace a different workspace might have want to use it"

if I wanted to control this setting across all workspaces then I would set it at the organization level. that's what its there for.

The whole point of having workspaces is so you can select the one you want. SO naturally if a user selects a given workspace then I want the workspaces settings to be applied.

its like your missing the concept of configuration levels. what your suggesting is achieved by what configuration level you define it at, but this is what the defect is, its not honoring the configuration level.