Keenan Donegan

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.

*****I'm not referring to DW not accepting a value in a select list only field that does not match the case of the value on the select list.  I've seen other threads on this, but that is not my issue.******

I'm reffering to the in field search for a select list value being case sensitive.  We have a vendor list of 13k names.  Users may only know part of the name.  Let's say the vendor name is BROOKLYN HEIGHTS PAINT.  My user may type *brooklyn. For the past 6 years this would bring up the vendor mentioned, they would select that value (not what they typed to search for the value, they would select the value that is displayed from the select list). 

However, I recently set up a new select list where typing *brooklyn to search for BROOKLYN does not work. When I inquired with DW, I'm being told the select list search was always case sensitive, even though it has never been for us in our experience. 

Can someone clarify?  The select list type for both the working select lists which are not case sensitive and the new one that only has a case sensitive lookup, is external.  There is no difference in the config. 

In the image below I am showing it working and not working.  

Version 6.12

https://www.docuware.com/sites/default/files/forums-images/select-list.png