Author Topic: Multi-User Configuration Issue  (Read 3624 times)

0 Members and 1 Guest are viewing this topic.

Xander

  • Guest
Multi-User Configuration Issue
« on: April 16, 2012, 09:41:42 PM »
Problem:
The company I work and develop for has multiple offices. In my local branch, all our routines are stored and run locally, with the benefits of:
  • A local - per user configuration file.
  • Individual logging of times and routine usage.
  • If the server crashes, users can still work locally.
Downsides:
  • Routines and applications may differ between users (I resolved this with a simple auto update routine for my development).

Our other branch has all routines stored on a network and loaded as such.  This unfortunately destroys parts of my code dependant on the configuration for database establishment, user identification and session logging.


I'm not really looking at converting all my code to store the config separate from the application directory, and am looking at the following solution:

As my configuration is a typical INI style file:

Code: [Select]
[GENERAL]
BASEPATH=C:\GTLISP
PLOTPATH=X:\1.0-Drafting\2.0-Plot Configuration\3.0-GTLISP Plot Configurations
INITIALS=A.S.
DATEFORMAT=DD.MM.YY
ENABLE_TIMES=S
ENABLE_OVERLAY=T
[GENERAL_ARCHIVING]
FOLDER=Superseded\
DWGDETACH=x-sign-*
IMGDETACH=*
[STYLES]
FONT=iso3098b.shx
WIDTH_FACTOR=0.75
[STANDARDS]
TEXT_HEIGHT=30
[TEXT HEIGHTS]
18T=1.8
25T=2.5
35T=3.5
50T=5.0
70T=7.0
100T=10.0
25D=2.5
30D=3.0
35D=3.5
[PENS]
18=1
25=7
35=2
50=3
75=4
85=5
100=6
15S=254
25S=253
50S=252
75S=251
90S=250
[LAYERS]
LEADER_BLOCK=((0 . 'BLOCK') (2 . 'GT-ARR10') (70 . 2) (10 0.0 0.0 0.0))|((0 . 'LINE') (8 . '0') (10 0.0 0.0 0.0) (11 -1.73205 1.0 0.0))|((0 . 'LINE') (8 . '0') (10 0.0 0.0 0.0) (11 -1.0 0.0 0.0))|((0 . 'LINE') (8 . '0') (10 0.0 0.0 0.0) (11 -1.73205 -1.0 0.0))|((0 . 'ENDBLK'))
TEXT_COLOR=7
TEXT_LTYPE=CONTINUOUS
GRID_NAME=S-Grid
GRID_COLOR=8
GRID_LTYPE=CONTINUOUS
DIMENSION_NAME=S-Dims
DIMENSION_COLOR=7
DIMENSION_LTYPE=CONTINUOUS
[DATABASE]
SERVER=database
DATABASE=main
EMPLOYEEID=58
[LOGGING]
#AVAILABLE LEVELS: 0=OFF, 1=DEBUG, 2=INFO, 3=WARNING, 4=ERROR, 5=FATAL, 6=ALL
LEVEL=6

My proposed solution is to seralise hardware information into a new configuration section and store any required user information within.

To do this however, I need a method (without using DOSLib) of grabbing these hardware IDs.

Any direction would be greatly appriciated.

Xander

  • Guest
Re: Multi-User Configuration Issue
« Reply #1 on: April 17, 2012, 01:46:46 AM »
I did some digging and found that the WMScript.Network ActiveX object can provide some PC details and the Scripting.FileSystemObject can provide hard drive serials.

Combine these together with a md5 hash generation from here, and I have a unique enough ID to work with.

Code - Auto/Visual Lisp: [Select]
  1. ;;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;;
  2. ;|
  3. <function>GTHardware:GenerateID</function>
  4. <summary>Generates a unique ID based on PCName, Username and a fixed drive serial</summary>
  5.  
  6. <returns>System ID String</returns>
  7. |;
  8. ;;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;;
  9.  
  10. (DEFUN gthardware:generateid (/ filesystemobject drives n serial wscript pcname pcuser)
  11.   (SETQ serial 0
  12.                 pcname ""
  13.                 pcuser ""
  14.   )
  15.   (COND ((SETQ wscript (VLAX-CREATE-OBJECT "WScript.Network"))
  16.                  (SETQ pcname (VLAX-GET-PROPERTY wscript "ComputerName") ; Computer Name
  17.                            pcuser (VLAX-GET-PROPERTY wscript "UserName") ; UserName
  18.                  )
  19.  
  20.                  (VLAX-RELEASE-OBJECT wscript)
  21.  
  22.  
  23.                  ;; Obtain the first Hard drive serial number
  24.                  (COND ((SETQ filesystemobject (VLAX-CREATE-OBJECT "Scripting.FilesystemObject"))
  25.                                 ;; access the Drives collection
  26.                                 (SETQ drives (VLAX-GET-PROPERTY filesystemobject 'drives))
  27.  
  28.                                 ;; Check each drive for a fixed drive. When the first drive is found, exit.
  29.                                 (VL-CATCH-ALL-APPLY
  30.                                   '(LAMBDA ()
  31.                                          (VLAX-FOR n drives
  32.                                            ;;If there drive is a fixed drive, get the serial and exit
  33.                                            (IF (= (VLAX-GET-PROPERTY n 'drivetype) 2)
  34.                                                  (PROGN
  35.                                                    (SETQ serial (VLAX-GET-PROPERTY n 'serialnumber))
  36.                                                    (EXIT)
  37.                                                  )
  38.                                            )
  39.                                          )
  40.                                    )
  41.                                 )
  42.                                 ;; Release the vla objects
  43.                                 (VLAX-RELEASE-OBJECT drives)
  44.                                 (VLAX-RELEASE-OBJECT filesystemobject)
  45.                            )
  46.                  )
  47.                 )
  48.  
  49.   )
  50.   (STRCAT (ITOA serial) pcname pcuser)
  51. )
  52.  

Chris

  • Swamp Rat
  • Posts: 548
Re: Multi-User Configuration Issue
« Reply #2 on: April 17, 2012, 08:01:34 AM »
I'm not fully understanding what you are asking.  Perhaps a simpler method would be in order.
what about the possibility of standardizing your file locations.  for main files that are loaded on a network, have it run via a mapped drive.  use the "vl-file-directory-p" function to determine if the standard folder exists on the network.  I use this method for our multi office environment to load lisp routines on a custom basis, in a combination with the user's loginname.
Christopher T. Cowgill, P.E.
AEC Collection 2020 (C3D)
Win 10

Xander

  • Guest
Re: Multi-User Configuration Issue
« Reply #3 on: April 17, 2012, 08:39:34 AM »
Without a doubt there are many viable options, yet all parties must be willing to accept it. I unfortunately play the role of code monkey, with one of our other offices heavily fortified against change...They still use hand written invoices.

As such, I'm forced to have all AutoCAD related files: routines, hatch patterns, and so forth; for my applications within the same folder. It's hard to explain, and I'm not fully doing it justice.

The cause of all this is, logic forbid, one draftsmen updated their LISP files while others neglected it, providing varying outcomes in routines.

what about the possibility of standardizing your file locations.  for main files that are loaded on a network, have it run via a mapped drive.  use the "vl-file-directory-p" function to determine if the standard folder exists on the network.  I use this method for our multi office environment to load lisp routines on a custom basis, in a combination with the user's loginname.

Our network folders are mapped as such, but my office applications interact with a MySQL database storing block details and managing drawing revisions and time management/logging, each action requiring the employee ID for interaction.  And all routines are loaded regardless of usage (these routines were developed circa 1997) and unfortunately don't use dynamic loading, some commands even override AutoCAD defaults such as `bedit`.

As for main files...These don't exists. Everyone has everything.  If a toolset was provided to remedy a problem, such as the massive viewport scales list a while ago, it was push onto everyone else within the company involved with AutoCAD.

My main goal was to uniquely identify each user using the shared resource, while utilising a common configuration file, allowing a single resource to define the company standards and also include individual user settings (one of our offices have drafters with the same login name).  By creating a hash of each computer name, username and first (non-removale) drive serial, I've managed to get this to work. Accommodating all branches of our company.

It also prevented me from going through all my code looking for areas to refactor (I think I changed 6 lines total, created one variable and altered 5 string references).

I will admit that it's an odd solution, yet it's clean and scalable enough for our branch sizes while complying with multiple office standards.
 

BlackBox

  • King Gator
  • Posts: 3770
Re: Multi-User Configuration Issue
« Reply #4 on: April 17, 2012, 07:31:59 PM »
From the little I've read of your situation; please accept my condolences.  :lol:

We're fortunate to have a (relatively) standardized directory structure throughout the entire enterprise (at least to a point, it's a free-for-all after that! LoL)... which means all +11k employees internationally will have common drives mapped to their local servers.

We place enterprise support files in a network location which is read-only to all users (except a select few), and all user custom files on the user's personal network space. What this allows for, is any CAD user in the company can log into any PC, or laptop (like the one in the conference room), and immediately have all local, regional support files, and templates, as well as their own customizations, workspaces, etc..

I've been toying with alternatives for those of us who work via laptop instead of PC, as I frequently bring my laptop home to work on some sort of customization, testing, etc.. Right now, the winner is to incorporate Offline Files over the alternative of using Batch files to Subst local folders as drives.

I can appreciate the difficulty you're facing with those apposed to change, but it is incumbent upon you (or those to whom you report) to demonstrate, and convince those opposed of the inherent benefits, and seek the authority from management to implement efficiency initiatives.

Perhaps even getting the system approved by management so that is it policy (for some that's too much, others maybe not enough?)... Policies are not a bunch of happy fun rules everyone likes, rather they're the rule, so go be a professional and adhere. So long as they are reasonable, and have a system in place to improve, all *should* be well.

... I know, I know, much easier said than done.  :lmao:

Good luck, and cheers!
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Multi-User Configuration Issue
« Reply #5 on: April 18, 2012, 02:19:20 AM »
What about incorporating the User Name as the filename for the INI? Something like this:
Code: [Select]
(getenv "username")That way you can test if such file exists, if not use vl-file-copy to copy the default onto it, otherwise just open it as if it's the user's local version of the settings file.

This should work fine in either case (i.e. local copies or network share). With the network share, just make sure each user has a unique user name, or else (as you've stated) you might try using a PC name added onto the UN. The duplicate UNs is a very bad idea though, some file servers might think you've got a file open already and allow write access to it while your name-sake is working on it -  :ugly:
« Last Edit: April 18, 2012, 02:24:37 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Xander

  • Guest
Re: Multi-User Configuration Issue
« Reply #6 on: April 18, 2012, 04:45:50 AM »
What about incorporating the User Name as the filename for the INI? Something like this:
Code: [Select]
(getenv "username")That way you can test if such file exists, if not use vl-file-copy to copy the default onto it, otherwise just open it as if it's the user's local version of the settings file.

This should work fine in either case (i.e. local copies or network share). With the network share, just make sure each user has a unique user name, or else (as you've stated) you might try using a PC name added onto the UN. The duplicate UNs is a very bad idea though, some file servers might think you've got a file open already and allow write access to it while your name-sake is working on it -  :ugly:

Each system within the office is setup as a single user environment, with each user having an individual server login account.  The username variable wouldn't be sufficient as one of our branches have two users with the same login names, unique server credentials.

+11k employees
Wow. My solutions is not quite scalable that far. As a collective we have 10 Draftsmen at any time Max. 5 of which who are daily users.

We're fortunate to have a (relatively) standardized directory structure throughout the entire enterprise (at least to a point, it's a  after that!

Our server structures are identical, however the other offices have each user 'sharing' routines hosted on the server.  Before this was adequate as the routines needed no user identification, yet mine do and they cannot understand why they cannot operate as global user.  It was never like this in the past, each user managed their own customisations, until they discovered incompatible and out-of-date routines. 

We place enterprise support files in a network location which is read-only to all users (except a select few), and all user custom files on the user's personal network space.

I'm the only deviant in the company.  I'm also the only one who can read the syntax. Should see the hassle I have to go through when they get a bounced back email with the error being 'Blank Subject Field'.

I can appreciate the difficulty you're facing with those opposed to change, but it is incumbent upon you (or those to whom you report) to demonstrate, and convince those opposed of the inherent benefits, and seek the authority from management to implement efficiency initiatives.

I agree 100%.  I'm happy explaining the situations, pitfalls and escapes to the best of my ability and understanding, and if necessary research until complacent on the subject. 

You should have seen how reluctant the head draftsmen was when I was attempting to introduce a basic plot routine for PDFs.  He actually tallied the time it took for him to use the dialog for settings, then browse to the folder path and name the pdf, compared to a single 'GT_PDF' command.

My director loves all things technological and even provides me with features he would like to see benefit the company, yet alas we are outnumbered when it comes to employee ranks.

What I really need (I say that lightly, and only wish it to happen when I have time) is for the old routines with global variables and overriding methods to break.  Just enough for all draftsmen to lose a little productivity, but also implant the nagging feeling that it could be better if we listened and accepted change. 

BlackBox

  • King Gator
  • Posts: 3770
Re: Multi-User Configuration Issue
« Reply #7 on: April 18, 2012, 09:27:44 AM »
+11k employees
Wow. My solutions is not quite scalable that far. As a collective we have 10 Draftsmen at any time Max. 5 of which who are daily users.

Just to be clear, that's total number of employees across multiple countries & continents... CAD generally is only a portion of, and the number which I support even smaller (i.e., countries, markets, regions, etc.).

I certainly have never supported that many users! I'm good, but not that good!!  :lol:

My director loves all things technological and even provides me with features he would like to see benefit the company, yet alas we are outnumbered when it comes to employee ranks.

What I really need (I say that lightly, and only wish it to happen when I have time) is for the old routines with global variables and overriding methods to break.  Just enough for all draftsmen to lose a little productivity, but also implant the nagging feeling that it could be better if we listened and accepted change.

If available to you, rather than trying to convince the hold-outs to convert, find one or more users interested in improving their proficiency, and give them the tools they need to outperform the hold-outs. Numbers don't lie.  :kewl:
"How we think determines what we do, and what we do determines what we get."

Xander

  • Guest
Re: Multi-User Configuration Issue
« Reply #8 on: April 18, 2012, 07:46:49 PM »
If available to you, rather than trying to convince the hold-outs to convert, find one or more users interested in improving their proficiency, and give them the tools they need to outperform the hold-outs. Numbers don't lie.
It's interesting you should say that.

Our counterpart office had an issue last night (after hours) with the plotting of PDFs, rather the naming. The naming convention was correct for the system, it's just my code was leaving the revision blank.  The draftsmen was complaining a little because he had to open 40 PDFs and check the revisions and add them. Took him approximately 30 mins.  The interesting thing is one of the directors opposed to change overheard this, and took action.  This is what I have in my email this morning:

Quote
Other Branch Draftsmen Name Omitted,
You are not in a position to have issues with drawing production & i am not interested in this creating delays for issuing drawings.  If testing is to be done, do it on a another machine, small scale & build up, not across the whole system in one untested trial - this is dangerous. Get it taken off the system immediately so that in the morning we are functioning as per normal & get drawings for project completed tonight as advised to client.

Alex,
Remove this from our system.

Maybe my luck has turned?

BlackBox

  • King Gator
  • Posts: 3770
Re: Multi-User Configuration Issue
« Reply #9 on: April 19, 2012, 12:24:36 PM »
Well, I guess I am a bit confused... I'm not sure if what caused the problem.

IMHO - Only fully tested, and qualified initiatives should be implemented across the enterprise (no matter how small, or large). To do otherwise without quality assurance will encourage, if not outright justify, an unwillingness to adopt these initiatives, both by users, and by management.

For any initiative to be successful, it must be production ready. It is impossible to test for every single condition, so issues come up, but there needs to be a system by which an initiative can be taken on, and off-line to suite the situation.

If you do not already have a testing environment, ask that one be made available to you, to mitigate this sort of issue. If a computer resource cannot be made available to you for testing, and quality assurance, then be sure to incorporate a 'debug' profile in your setup, which is mapped to a copy of your entire support structure (network, and local) so that any changes that are made do not interfere with your production profile, and support structure.
"How we think determines what we do, and what we do determines what we get."

Xander

  • Guest
Re: Multi-User Configuration Issue
« Reply #10 on: April 19, 2012, 06:45:53 PM »
My little side post was in relation to another aspect of my application, separate from the main issue at hand, which was in the process of tweaking and I was interrupted 3 months ago with urgent work and forgot.

I presently do have a testing environment, as-well as my production machine if I think it's ready, then the other drafters in my office.

The version was pushed through at a request of their office, and pressure from my director to get a solution ASAP.

The main issue I was having with a multi-user configuration file has been resolved.