Veröffentlicht Mon, 22 Nov 2021 19:29:36 GMT von Jon Weston File IT Solutions Sr Application Developer, 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.
Veröffentlicht Tue, 23 Nov 2021 14:46:54 GMT von 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.
Veröffentlicht Tue, 23 Nov 2021 16:58:41 GMT von Jon Weston File IT Solutions Sr Application Developer, 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).
Veröffentlicht Tue, 23 Nov 2021 19:27:02 GMT von Michael Ceresia Sales and Support Consultant

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

Veröffentlicht Tue, 23 Nov 2021 19:48:43 GMT von Jon Weston File IT Solutions Sr Application Developer, 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).
Veröffentlicht Tue, 23 Nov 2021 23:04:54 GMT von Jon Weston File IT Solutions Sr Application Developer, 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:

<Disabled>163423e5-a47d-40fa-ba39-cec4d291afca</Disabled>
<Order>2f7b055d-661e-442b-83ba-33d5289b540a</Order>

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 <Order> to <Disabled>, not an attribute value.

Veröffentlicht Wed, 24 Nov 2021 01:33:55 GMT von 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.
Veröffentlicht Wed, 24 Nov 2021 11:49:06 GMT von 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
Veröffentlicht Thu, 25 Nov 2021 22:35:01 GMT von Jon Weston File IT Solutions Sr Application Developer, 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

Sie müssen angemeldet sein um Beiträge in den Foren zu erstellen.