we are using HP AL 12.2 with limited concurrent session. some of the users when working on multiple projects are initiating multiple sessions from same pc instead of navigating between projects and consuming multiple licenses which is a problem for other users who are trying to login.
I would like to check if there is a way to restrict users to have only 1 active session and also display a error/warning when they try to open a new session from same PC or other PC
From my understanding the login and session information is stored in site admin schema table and i dont think i can access this information from query builder of any project.
I read online that QC's in built function "CanLogin" under workflow can handle it, but how do i edit the workflow script to handle my situation
How are you determining that a user with multiple instances open on the same PC is consuming multiple licenses?
In v11.52 I tried opening 2 Internet Explorer windows on one PC and logging in to two different projects. I see both connections listed in Site Admin on the Site Connections tab, and both show a License In Use, which might make one thing I am consuming 2 licenses. But if I look at the Licenses tab, it says only 1 license is being used.
Multiple connections by the same user on one PC should consume only 1 license.
Have you explored the Assigning Licenses to Users functionality that is available in v12.20? I don't know if that will actually solve your problem, but you might want to look into it.
If you have read online that the CanLogin workflow can handle it, provide a reference to what you read. That reference should provide some hint as to how the workflow can be coded to handle this.
The only ways I can think of to handle this are:
1. Access the Site Admin API - but that would require have the Site Admin client registered on every system where QC might be used.
2. Execute a SQL query via workflow to examine the Site Admin database to see if the user is already consuming a license. But that would require that you enable the Command object in the UI for every user (see DISABLE_COMMAND_INTERFACE site parameter), and then potentially users could design their own queries and execute them using that object and make updates directly to the db. That would be very bad.
(Opinions and information contained in this post are wholly my own and do not reflect the opinions of my employer.)