Was told by support to post this as an idea even though its a defect and not an enhancement. I also don't see an idea category for configuration so I put it under user interface.
MS_CONFIGURATIONOPTS variable can be used to do any of the following
DisallowCreatingWorkSpace - Disables the Create WorkSpace option in the WorkSpace drop-down.
DisallowCreatingWorkSet - Disables the Create WorkSet option in the WorkSet drop-down.
DisallowSelectingWorkSpace - Disables the WorkSpace selection drop-down.
DisallowSelectingWorkSet - Disables the WorkSet selection drop-down.
But if you set this variable in a workspace it is not honored when you select the workspace in the workspace dropdown. Basically the variable setting that MicroStation CONNECTis using is from whatever the last workspace you loaded. Making it basically useless to be used at the workspace config level.
So if one workspace wants to disable creating a workset and another workspace wants to allow it. It DOES NOT matter which workspace is selected in the interface. The variable values are taken from the last workspace that was loaded.
So example scenario
WorkSpace A : set to DisallowCreatingWorkSet
WorkSpace B: set to allow creating workset
User loads Workspace A, closes and reopens, now in startup screen the user selects workspace B in the workspaces drop down. Now the user wants to create a new workset for this workspace B. But the userfind that the button to create a workset is disabled. even though the user selected workspace B and workspace B allowsfor creating worksets, Since WorkSpace A was the last loaded workspaceWorkSpace's A configuration is being used for the MS_CONFIGURATIONOPTS variable.
This is pretty clearly something that should not be submitted as an idea, Its a defect and not an enhancement because its nothonoring the configuration level the variable is beingset at.
I mean the worksets dropdown is being populated by the selected workspace but then the create workset button is not?? come on!! it shouldn't take me this much effort to try to get something fixed.
if you want to control this setting across all workspaces that's what the organization level is for.
Tim Hickman over 1 year ago
what is preventing the user from not using the interface to create the workset or workspace ?
In other words - you set the variable and the user goes around it by doing it manually - so setting this prevents nothing.
John Drsek over 1 year ago
yes someone could still make one manually but they would have to have some knowledge of how to do that and get the right configuration set up.
Bottom line is this create workset button is very limited. it cant even put the workset folder to a different location then the workset cfg. we have delivered our own create workset application with our workspace to make creating worksets simple and does several things to finish setting up a workset. I want to disable this button so users don't user it by mistake. but I don't want to disable it for another workspace a different workspace might have want to use it.
if someone can go around it or not is not the question here. Do you not agree that if the variable is set at the workspace level then it should only be applied when that workspace is selected? if so please upvote this. if not please explain to me why a configuration variable should not honor the level it was set at?
Tim Hickman over 1 year ago in reply to John Drsek
based off of what you are saying (that the create workset button is very limited) and you have created your own application. I would think that for consistancey you would want to use your application in all cases, and the create button should be disabled in all cases.
John Drsek over 1 year ago in reply to Tim Hickman
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.
Tim Hickman over 1 year ago in reply to John Drsek
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.
John Drsek over 1 year ago in reply to Tim Hickman
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.
Tim Hickman over 1 year ago in reply to John Drsek
this is all good information - thanks - it helps Bentley understand the different requirements and complexities of their configuraions.
John Drsek 10 months ago
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.