Keenan D

Is this still the best solution to accomplish this? 

Is it accurate to say:

A user cannot edit index data through the use of an Index Value Profile alone.  In order to edit index data a user must have the right Allow new entries. This right is only available when a Custom Profile is used.  

My tests show that if a user has all rights under an Index Value Profile, they cannot edit index data. The error message refers to the right Allow new entries.  However, if I create a Custom Profile with no rights at all except for Allow new entries (for every field), that same user can then edit index data (edit then save) - when that user is added to both profile types.

 

Phil,

First, thanks for the quick and detailed response. That's why I asked the question before implementing this approach.  Now if we could just harness that energy for a non-solution into one for an actual solution perhaps we can be more productive. Session time out was removed and not mentioned in the changes from 6.11 to 6.12. I'd say that's pretty cavalier.  DW didn't shift to named licenses they still sell concurrent but with a major price increase. This would suggest to me that concurrent licenses shouldn't be losing features like session time out. In any case, it looks like I'll be looking for a solution via browser, such as building an extension that closes tabs on the DW URL due to inactivity, that is if I cannot use PowerShell to manipulate URL-specific browser inactivity.

 

Here's the "idea" for bringing back session time out from 2015 with 205 votes.

https://docuware.uservoice.com/forums/230570-client-english/suggestions/...    

I see that there has been a ticket open for this issue since 2015 and DW's response is officially we will add it to our collection of ideas.... That does not sound like it is being taken seriously.  In search of a solution I am taking a look at user sessions in the database. Ultimately, we will write something that identifies users based on inactivity, but in order to test it we used the simple syntax below and it worked as a way to boot users, by userid in this test scenerio.  I'm writing here to see if there would be any issue with this method as a workaround for the no session time out problem that will exist in 6.12 and beyond.

delete FROM [dwsystem].[dbo].[DWClientLicense]

where uid = <<specific user ID>>

Thank you both for assisting in gaining some clarity on this issue.  Are there any workarounds for this in 6.12 (perhaps through SQL) or is it available in 7 or is there a plan to add this session timeout feature back in the next version?  I'm confused as to why this would be removed.

You're giving me hope Joe.  I wish I knew how to replicate it! 

I'm not sure that I even want to know if the answer is that this feature was lost on the newer version. 

 

The behavior you outlined is what I would expect in any modern application where concurrent user licenses are sold, but it is not what we experience (on-premise 6.12).  Also, I have contacted DocuWare multiple times in regards to this issue and the response has always been simply that there is no automatic user inactivity based release of a license. Prior to posting this, I ran a test where I had a user log into DW on 1 tab, then open a second tab to a random website, then minimize the browser, then leave it unattended (on a remote server for to make sure there was no activity).  1 hour and 40 minutes later (and counting) that user is still occupying a license. This is consistent with previous tests.

I'm trying to figure out why our experiences would differ.

When using notifications, there is an option to send a link to task list.  My users are accustomed to working with the split screen view you see when you log directly into the web client.  The notification links open in a single screen view.  How can I get the notification links to open in a split screen view?

Your response was very helpful. Thank you. - I am using an SQL DB and after checking, case sesnitivity is enabled SQL_Latin1_General_CP1_CI_AS.  I suspect there isn't a search technique that can overcome this db setting, correct?  It looks like I'll be looking for a workaround of some kind. Glad to hear the lookup iteself isn't actually case sensitive. Thanks again.