• Phil,

    Phil,

    It would seem desperate times call for desperate measures, though. What else is one supposed to do if a customer requirement states that all connections to various resources (such as DocuWare) need to have timeouts built in for security? I don't think it is DocuWare's place to dictate what clients want to do in that regard. And at over 200 votes, the "user voice" is definitely saying this needs to be addressed, even with named licensing now being the case.

    Judging by Jason's posts here, I have no doubt he wouldn't be so "cavalier" unless there was no other option. Unless you prefer the final option to be to dump DocuWare for a tool that supports this client need -- that's always an alternative, I suppose.

     

    Thanks,

    Joe Kaufman

  • Jason,

    Jason,

    Nifty solution. I will be eager to see what support says about that sort of behind-the-scenes manipulation, and obviously such code may break between versions.

    I imagine DocuWare let the issue fall off the back burner when they changed to named licenses. Perhaps the main focus was on concurrency, not on basic workstation security. That's a shame, because I don't see the downside to offering an auto-logout capability. It doesn't seem like DocuWare would have to compromise on anything to keep that functionality available, even if it were off by default (or even hidden in a config file).

     

    Thanks,

    Joe Kaufman

  • Phil,

    Phil,

    Thanks! Yes, we are definitely set to 10 minutes in that config file.

     

    Thanks,

    Joe Kaufman

  • Oh, and 10 minutes is exactly

    Oh, and 10 minutes is exactly my experience. The extra two minutes is a built-in grace period for connection instances. Even if you issue an explicit "LogOff" while using the SDK, for example, the license expiration does not occur for an additional 120 seconds. Though, that may be the IIS 120 second time-out in play -- not sure.

     

    Thanks,

    Joe Kaufman

  • Phil,

    Phil,

    Thanks for this truly definitive answer! What is the config file, by chance? I am not thinking I would ever need to change that setting, but it would be nice to know.

    I also assume IIS needs to be bounced after changing the setting? I might play around with it just to confirm things act the way I think they should.

    Sorry to hear 6.12 is out of luck -- I fear we may need to stay "left behind" even longer after hearing the timeouts don't work in 6.12 the way they do in 6.11. I share the lament of womdering why this was changed. Control over timeouts seems like a reasonable control to have, at least for on-premise work.

     

    Thanks,

    Joe Kaufman

  • Phil,

    Phil,

    On this thread:

    https://www.docuware.com/forum/english-forums/docuware-help-technical-problems/session-timeout-and-logged-users

    another user states, "Since DocuWare has removed the functionality to set session timeouts..."

    That was posted on June 27, 2018, making it sound like a semi-recent development. When did DocuWare remove the ability to control timeouts, and are you sure 6.11 does not still have the capability?

    Thanks,
    JoeK

  • First I have heard

    Phil,

    That is the first I have heard that our installation behaves aberrantly! I have mentioned the way our licenses time out numerous times on several different threads, and no one ever said we were the exception to the rule. Our DocuWare is nothing special, vanilla installation on a virtialized Windows server with a SQL Server back-end.

    The fact that the expiration reduces exactly ten minutes in tells me this has to be something in the DocuWare system. We do not employ any sort of network or web proxy timeouts (we can't -- all of our systems are network-file based, written in Visual Foxpro), and in any case, the timeout occurs for both web client access and Platform Service access.

    I don't see how this can be on our end. You are saying not a single customer with on-premise 6.11 has licenses auto-timeout in this way?

    If our licenses did not timeout in this fashion our entire installation would be in substantial trouble because we only have 20 licenses, and forcing a logoff call when using the Platform SDK is not reliable because of the two-minute "grace" period. I don't think I am exaggerating when I say that if DocuWare did not behave the way it does for us that we might be shopping for a different document management solution. You've got me extremely uneasy that something could shift from under us and stop working the way it does, and overnight we could be in big trouble!

     

    Thanks,

    Joe Kaufman

  • Jason,

    Jason,

    If you are referring to me, a big difference might be that we are on 6.11, not 6.12. I am not sure why DocuWare cannot give you a definitive answer or support on this.

     

    Thanks,

    Joe Kaufman

  • Could it be as simple as not

    Could it be as simple as not having deletion rights on the source file cabinet? Or do these workflows use an admin account that has all security rights?

     

    Thanks,

    Joe Kaufman

  • Kim,

    Kim,

    What is the destination/version of DocuWare? On-prem or cloud?

    In on-prem 6.11, you can right click on any File Cabinet in the DW Admin desktop tool and select "Show fulltext status". This appears to show full-text status for everything, not just the cabinet you click on (that's my experience, anyway). That offers some indication of how full-text is doing.

    If you are in the cloud on 7.0, I don;t know if that admin capability still exists.

     

    Thanks,

    Joe Kaufman