Change state dialog uncheck all as standard option

[Tom_de_Graaff]

When you open the Change state dialog, all files are selected (checked). If you re-use standard parts a lot, you always have to de-select (uncheck) all files and then select the ones you need to change state.

Therefore I would like to have an option in the settings menu to choose if I want them all checked or unchecked when starting this function. It will save me time. 

Additional benefit is the reduced chance to make an unwanted revision on released parts. When you go from a released state to work in progress and accidentally you have to many files selected, they all get an unwanted revision update.

[ihayesjr]

@Tom_de_Graaff 

I moved the Idea post to the discussion forum because this is already a standard right-click option in Vault 2023.

[ihayesjr]

Also, if your "Standard Parts" are in library folders, you can always exclude them in the settings options.

[Tom_de_Graaff]

Hi Irvin, when this dialog opens, it always selects all files, I want it to select no files by default setting.

I know the option to deselect them all, I want to reduce the number of clicks by adding "open dialog with all files unchecked" to the settings menu. Something like in the picture.

And we use Library folders, that works great. We still re-use from other projects or standard products (normal folders in our vault) or even when a sub-assembly already has been released, this option also adds speed to the change state process.

So I think this Idea needs to go back to the Idea forum.

[ihayesjr]

Correct me if I am wrong but you are reducing the number of clicks by two.

• Click one: Right click
• Click two: Uncheck all

[Gabriel_Watson]

2 clicks or 1000 mistakes from missing those. The hidden cost of non-compliance is often unaccounted for. It all depends on how often this is needed and how hard it is to train/verify it when missed.

I agree it is not a significant change, but if we respect his pains, this may be the difference between a process that many will follow seamlessly, to every day having revised files that someone took out of the Release state without knowing. Those could cause hours of issues and calls from downstream users perhaps unable to see the unlocked files, for example.

[ihayesjr]

However, you could say the same think in reverse. Nothing is selected by default and now something has the potential to be missed causes more than two clicks.

Sometimes it is also about choosing the worse of two evils.

[Tom_de_Graaff]

In my team we have all kinds of engineers, and even the most experienced ones make mistakes sometimes.

95% of the time we uncheck all files and select the ones we need to change state. So for us, a default setting to have them unchecked works for 19 out of 20 cases. 

Reduced chance of unwanted revisions is also a big advantage. 

[Gabriel_Watson]

@ihayesjr I agree. Though in this case, it seems like the cost of missing releases is much lower because the operation can be repeated instead of using "roll back lifecycle state change" on all other files (sometimes in multiple folders).

I even agree this is too much of an edge case to ever gather enough attention and votes here. However, censoring ideas without a workaround, or before asking the poster, can sometimes upset a customer further. They might feel unheard after properly organizing a flaming pain into the form of a polite suggestion.

[ihayesjr]

@Gabriel_Watson 

The idea post was not "censored". If it were, then it would have been deleted. 

My response was to have a conversation about it to make sure we get an understanding of the problem we are trying to solve. 

I try to respond to idea posts as quickly as possible, to have the conversations early so that the submitter can see that they are being heard. However, we don't guarantee that any idea post will be implemented.

[Gabriel_Watson]

Censoring is also a synonym for suppression, not necessarily deletion.
I thought this forum also had comments to discuss the ideas posted. Most ideas back on the Inventor forum are also never implemented but generate good conversation within, and the audience/exposure is different than the regular forum. I guess it would make sense to bring down a post from here onto the regular forums if the post was unclear so the intent was to reformulate it and re-post, and Editing was not allowed anymore (I think it locks out after a few minutes from posting here).

[ihayesjr]

@Gabriel_Watson 

You are commenting on this post. No comments were removed.

[Gabriel_Watson]

yes, that is my point. why not discuss it here? One-on-one with Devs/Prod management could be done on support tickets, but this is just as good of a public forum, with more eyes looking to support/vote valid ideas than just asking questions. Perhaps an invalid or unattainable idea could be archived, or the customer would be asked if moving to discussion (or even beta) would be best before moderation.
But I do not know the rules, this is just my assumption as a customer. I am here to learn what is what.