Posted Mon, 22 Nov 2021 19:29:36 GMT by Jon Weston File IT Solutions Sr Application Developer and RIM specialist
Is there a way of hiding a store dialog for all users as if they'd gone into 'Profile & Settings' -> Store dialogs and hidden it themselves?  This is for an on-premise system so I have no problem with making this update with a SQL statement to their underlying db.

I want to do this because I'm setting up a new form that will require its own store dialog and I don't want the users to be able to use this store dialog independently of the form.  Yes, they could just go into 'Profile & Settings' and unhide it themselves but we don't see that as being much of a problem.
Posted Tue, 23 Nov 2021 14:46:54 GMT by Michael Ceresia Sales and Support Consultant
Hi Jon,

Simply do not give any other Roles/Users access to that store dialog box. Just give it access to the user publishing the Form to use.
Posted Tue, 23 Nov 2021 16:58:41 GMT by Jon Weston File IT Solutions Sr Application Developer and RIM specialist
Hi Michael, thanks for the reply.  I have to give this store dialog to all the users because they'll all have access to the form.  I can't make the form a Public form, and therefore only use a single user account and therefore not have to give the store dialog to everyone, because the form also captures who is submitting it and that's tied to the logged-in user so if I make it a Public form and have it use an Admin account then it always thinks an Admin person is submitting it (not good).
Posted Tue, 23 Nov 2021 19:27:02 GMT by Michael Ceresia Sales and Support Consultant

Ahhh. Thanks for clarification. That is an interesting Conundrum...

Posted Tue, 23 Nov 2021 19:48:43 GMT by Jon Weston File IT Solutions Sr Application Developer and RIM specialist
I'll dig into the SQL tables today and see if I can figure out where it stores the user settings for whether or not they've hidden each store dialog - I have to think that it's just a true/false field but I'm just hoping that it's not storing it in the db as xml (which I know DW does for various other things).
Posted Tue, 23 Nov 2021 23:04:54 GMT by Jon Weston File IT Solutions Sr Application Developer and RIM specialist

Darn, I was right - it stores it in an xml field called 'settings' in the DWUserSettings table.  Even worse, the relevant setting looks like this:

163423e5-a47d-40fa-ba39-cec4d291afca
2f7b055d-661e-442b-83ba-33d5289b540a

where the top line is one that is hidden and the bottom line is one that isn't (the string in the middle is the GUID of the store dialog).  I've only tangled with xml fields in SQL once and that was to only to read them (for a SSRS report) so this is looking to be way above my head, especially since it looks like it's the actual attribute name that would need to be changed from to , not an attribute value.

Posted Wed, 24 Nov 2021 01:33:55 GMT by Marcin Kratiuk
You can change this value - but please note that the end user can go to her/his profile and enable it - so the value change back. If you accept this risk then it is OK.
Posted Wed, 24 Nov 2021 11:49:06 GMT by Fabian Kall - left 01.22
I have come across this problem when I wanted users to be able to use a store dialogue vie DocuWare Printer but not have them accessible or at least visible in the Web Client. 
We help ourselves by giving the store dialogues a suffix like "...do not use" in the name and communicate this to the user. 

It might be worth to open a uservoice idea to at least hide the store dialogue for all users via the configuration without removing rights
Posted Thu, 25 Nov 2021 22:35:01 GMT by Jon Weston File IT Solutions Sr Application Developer and RIM specialist

good ideas, thanks for the feedback guys.

Marcin, that's good to know, thanks.  I'm feeling that if that's the only risk (eg. it wouldn't break any of those sinister-looking CheckSums) then I'm quite happy to live with it.  And in a system with only 30 users it wouldn't be that onerous for me to manually go through and update those xml settings myself.

Fabian, great idea.  I've used that once before but I found that it still felt a little less than elegant having it there in the user interface (though in times when I've done user-training sessions I've had them all go into their settings and hide that dialog and we found that it's been a great practical learning example, so there's that).

So what I'll probably do is combine both ideas - append '...DO NOT USE' to the end of the dialog name as well as going in and hiding myself.

DW forums ftw

You must be signed in to post in this forum.