Assigning WSID after BRCONFIG.SYS

Information and discussion about setup, brconfig.sys, installers and other configuration related topics.

Moderators: Susan Smith, admin, Gabriel

Post Reply
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Assigning WSID after BRCONFIG.SYS

Post by Susan Smith »

Hi all,

Is there a way to assign a WSID to someone AFTER the BRCONFIG.SYS process is over? I see in the wiki that WSID is not supported with CONFIG.

I need to be able to assign a WSID to someone after they go through my password/login routine which assigns the login name. These users work at different physical workstations throughout the day, but need to have their permissions and other limitations follow them. I can't use the desktop shortcut to assign WSID and the login procedure (when I find out who they actually are) doesn't take place until AFTER BRCONFIG.SYS.

I am now using beginning to use login names to keep track of people, which IS assignable inside of BR, but I still have some legacy programs which control permissions by WSID and I need to maintain backwards compatibility until those can all be changed.

-- Susan
Larry TIetz

Post by Larry TIetz »

I track users by the following. The assignments are made after a login procedure.

let setenv("username",usid$)
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Thanks Larry. I'm doing something similar in my newer programs. My problem is the old programs that are already set up to use WSID$ to assign permissions for many different things. Ultimately, those programs will be modified to use the username instead, but for now, I was looking for a way to SET a WSID inside of a BR program so I could maintain backwards compatibility until I have a chance to change them all.

Previously, we were assigning WSID either in the desktop shortcut or in BRCONFIG.SYS. That became a problem because these users move around the office all day from workstation to workstation as they cover for people who are out on breaks, etc. So they need their permissions (and WSID) to travel with them.

I may be forced to change all of these programs now instead of later which puts me even more behind on this project. But if there's no way to change a WSID *after* BR has launched, then I may have no choice.

Thanks for your response.

-- Susan
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

The short answer to your question is NO. You cannot assign WSID's after BRCONFIG has been processed.

However, you can include the following statement in the configuration file:
@username WSID 25
We define each user's WSID in a file and INCLUDE the file in several config file variations. We also begin the file with "WSID 0" and check for WSID 0 in the startup program. If we find WSID 0 we display a message that the WSID has not been setup for this user and then we exit.

I have uploaded our WSID include file as an example.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Thanks Gordon. Your method is what I WAS using before the client changed their requirements. Now they say that users will be working at various workstations throughout the day without logging out (and back in) to Windows again. So because each person has specific permissions in BR, my programs have to distinguish between the Windows username and the BR username.

BR can handle most of this just fine since I can set loginname$ equal to the username they use when they sign in with my password/program.

Unfortunately, the "@username WSID 25" method will no longer work since I won't know who the REAL user is until AFTER they launch BR, get through the BRCONFIG.SYS process and enter their BR username and password. (These particular workstations are ONLY running my BR system and nothing else, so the Windows desktop does not need to change when the user changes.)

I will just have to retrofit these older programs NOW (rather than later as I had hoped) so that the WSID$ is no longer the control for the permissions and I will write the loginname$ to data file records instead of WSID$ so I will know who created the records. It's just a matter of finding the time. At least I know definitively that this is what I'm up against. Thank you for the clarification.

-- Susan
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

Okay, but one more trick ios available to you. You can use SUBSTITUTE statements to substitute one WSID for another. This can easily create a nightmare if it is not properly organized.

The best idea is to use the WSIDs file as described above and to allow additional logins to substitute back to the original. For example, let's say my WSID is normally 40. The WSIDs file says its 40 when my Windows ID is used. Now I login to the application as ACCOUNTING. I am assigned a WSID of 60 by the WSIDs file. Next I identify myself to your authentication routine as Gordon. Your authentication program simply checks my current WSID against the one specified in the WSIDs file and if it doesn't match it substitutes me back to my assigned WSID.

e.g. SUBSTITUTE 60 40

A word of caution though. This only works if your normal file naming conventions don't include two numeric digits in the range of normally assigned WSIDs.
[/list]
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Chris has had success setting WSID and other configuration statements dynamically by generating a wbconfig.sys file on the fly and launching a new copy of BR with it.

That may be a bit messy though.

If I were in your position, I'd write a library function called fnWSID$, which would check the login_name$ and return the legacy WSID$ for the person. Then all you have to do is search and replace "WSID$" with "fnWSID$" in your old programs to fix them.

Gabriel
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

A fairly simple solution is to create a new environment variable:
Let SETENV("Client_WSID",WSID$)
Of course instead of WSID$, you will figure out the # you want. Also remember
CONFIG SUBSTITUTE [WSID] [CLIENT_WSID]

Then go through every program and change WSID$ to ENV$("CLIENT_WSID")

Or even better, make a variable that is more appropriate like "USER_ID".

WSID is not a reliable variable to identify a user, as it is Workstation Specific.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Thank you everyone for your thoughtful responses to my dilemma. It's interesting that such a question as "can you set a WSID after launching BR?", whose answer is firmly NO, can result in such creative solutions!

I can see how all of these solutions will work. In my case, I think I will use Luis' solution as this would require the least amount of work to retrofit my old programs. But Gabe and Gordon...your suggestions would have worked as well in a different context:

Gabriel: Since some of my use of WSID is as "[WSID]" substitutions in filenames and such, I can't substitute a function for that type of usage. And unfortunately, I can't launch a custom BRCONFIG.SYS in a new session because these users are limited to one session.

Gordon: the SUBSTITUTION suggestion seems to be the complement to Gabriel's suggestion in that it WOULD successfully deal with embedded [WSID] in file names. But in places where I have 'if WSID$="12" then do something', I'm not sure that this would work. Or perhaps I'm just not understanding the SUBSTITUTION suggestion completely.

In any case, there are lots of options. I'll give Luis' a try this time since it is a pretty simple search/replace. Luis, your point about WSID being workstation-specific, is of course, my problem here. It was never a problem when everyone stuck to their own workstation. But as this is no longer the case, I need more flexibility. This will ULTIMATELY result in a complete separation between WSID and LOGINNAME$ in my code where loginname$ dictates program permissions and WSID dictates PHYSICAL limitations, such as hardware assignments. I imagine that sometimes there will be combination of the two. For example, one workstation may have a printer attached that is loaded with dedicated forms, but not all users sitting at that workstation would have permission to print to that printer). I can deal with those kinds of things in a myriad of other ways.

Thanks again, everybody.

-- Susan
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

http://www.ads.net/brules/download.html#top

Post by GomezL »

http://www.ads.net/brules/download.html#top

The downloads page has a nice program "Search3.wb", it lets you search all programs in a folder, and replace variables. It is case sensitive.

Of course you have source, so you can enhance it as appropriate.
Post Reply