CONTACTS 

SUBJECTS
SDS, New User setup ideas
User interface, front end, 047024
Executive Services, 910121
Privacy, Security; LAN
Concepts & Plans, Executive Services
User ID Management

1008 -    ..
1009 - Summary/Objective
1010 -
101001 - Changed the way Executive Services and Executive SDS work, so there is
101002 - greater range of access, mainly through the chronological diary and
101003 - subject reports, including the subject index.
101004 -
101005 - This goes to product definition, and SDS concepts for the data base.
101006 -
101007 -
101008 -  ..
1011 -
1012 -
1013 - Analysis
1014 -
101401 - Looks like when Executive Services is used now, the original User ID
101402 - is not being retained for doing Diaries and Reports, after we close
101403 - down the Executive session for another User ID.
101404 -
101405 -      On 921023 I considered this type of issue. ref SDS 18 0979
101406 -
101407 -      It appears that the "original" user ID is set in globals 275 -
101408 -      279.
101409 -
101410 -      Counter 149 1249 establishes a record is opened for executive
101411 -      services.  Maybe we can rig ESC to recognize this flag, and set
101412 -      the primary User ID back to Original when the secondary User
101413 -      Schedule is purged.
101414 -
101415 -      Actually, there is a conflict in the concept.  If you are an
101416 -      executive you need access to the Diaries on a chronological basis
101417 -      of the people working for you.  On the other hand, we would
101418 -      ordinarily permit access only to diaries on a subject basis,
101419 -      since if someone knows a subject, then they are entitled to look
101420 -      at the record on that stuff.  Possibly that is the distinction
101421 -      between Corporate and Executive services.  The latter permits
101422 -      opening anyone's record and making that the current User ID.
101423 -
101424 -
101425 -       ..
101426 -      User ID Control
101427 -      Executive - General Flag
101428 -
101429 -      If this entire thing is an Executive session, right from the
101430 -      beginning, i.e. the User has "Executive SDS," then that person
101431 -      should be able to get diaries on every record, unless one is
101432 -      blocked.  It should use local counters, instead of Primary.  Only
101433 -      Corporate User's should also be held to original User ID for
101434 -      chronological diaries, so they can only access information based
101435 -      on subject, and those subjects are limited to their own User ID,
101436 -      so they can only access subjects they have in common with others.
101437 -
101438 -           Decided to try creating this capability by using gbl 257 17
101439 -           set in 04702.  I can manually change it for other Users, so
101440 -           their access is more limited.
101441 -
101442 -           I need to make a matrix that maps the options and settings
101443 -           that support them.
101444 -
101445 -
101446 -
101447 -
101448 - Suppressing Disclosure of Private Records Based on User ID
101449 -
101450 - I also want to create a way to set a flag so users cannot access other
101451 - User's diaries, even if they know the User ID.  So Users will have
101452 - confidence they can prevent access, if they wish.  One way to do this
101453 - with Executive Services separate User ID that is not included in the
101454 - SDS Group Manager.
101455 -
101456 -       Methods & Procedures
101457 -
101458 -       I think we can put "S" in column 44 on line 1, for "suppress".
101459 -       This is a fixed position that makes it visually obvious to the
101460 -       User when a record is suppressed, so that when it is not set,
101461 -       the User knows the record will be public.  When records are
101462 -       archived, the "S" will be entered in the pointer files in a
101463 -       column that will exclude the record.
101464 -
101465 -       Will make it possible for a program to NOT support this feature,
101466 -       by not relying on the visible flag, which anyone could enter
101467 -       manually.  Will create a menu function to enter the "S" and set
101468 -       a flag for "save" to keep the "S", so if the flag is not set
101469 -       then "save" removes the "S" entered in column 43.  If a record
101470 -       has "S" in column 43, and the User ID does not match the
101471 -       original User ID in col 285 - 289, then the record cannot be
101472 -       opened.  Where such records are listed in the Reference field,
101473 -       the program would return a message the record does not exist, if
101474 -       a non-authorized person tries to open it.
101475 -
101476 -
101477 -
1015 -
1016 -
1017 - 000005
1018 -
101801 - Line 2070 - pfesc macro, added call to macro 233, which is in 000001
101802 - that does the ESC code.  Added conditional to call macro 932 in
101803 - 000005, to move original User ID to Primary User ID.  Note this
101804 - change was eliminated in the next step.
101805 -
101806 -
101807 - Line 20 - getgbl 1 257, is called to see if it is an Executive
101808 - session, in which case we call macro 853 to move current globals to
101809 - Primary, so diary is always predicated on current User ID for
101810 - Executive SDS.  This should accomplish the purpose of the change at
101811 - line 2070, and so I removed that change.
101812 -
101813 -
101814 -
101815 -
1019 -
1020 -
1021 - 000001
1022 -
102201 - Line 870 - entry 233, this is the "Quit" command for the mouse.  I
102202 - added a conditional for Schedule, 47 50, to call macro 932 in 000005,
102203 - to move original User ID from 275 - 279 into Primary User ID, globals
102204 - 295.
102205 -
102206 -     This does not seem like a good solution for an Executive.  They
102207 -     should be able to get diary reports based on the local User ID,
102208 -     rather than Primary, so there is unrestricted access to the work
102209 -     of his staff.
102210 -
102211 -     I added other code this afternoon to accomplish this objective,
102212 -     as set out below with respect to macro file 04702 setgbl 157 17,
102213 -     and so will disconnect this "quit" command code and the new macro
102214 -     857.
102215 -
102216 -
102217 -
1023 -
1024 -
1025 - 000008
1026 -
102601 - Line 890 - entry 1303, made entry to move current User to Primary when
102602 - we open a contact record from an SDS record, and the Executive SDS
102603 - flag is set, glogal 257 = 17, so if we do a report from a contact
102604 - record, it will be on the current User, as explained for "Diary" in
102605 - 000005 line 20, see above.  Put it here where we know, 47 = 2.
102606 -
102607 -
102608 -
1027 -
1028 -
1029 - 0440110
1030 -
103001 - Line 30 - getgbl 1 257, made entry to move current User to Primary,
103002 - as explained for Diary in 000005 line 20, see above.  Put it here
103003 - where we know, 47 = 2.
103004 -
103005 -
103006 -
103007 -
1031 -
1032 -
1033 - 047041
1034 -
103401 - Line 75 - getgbl 1 257, made entry to move current User to Primary,
103402 - as explained for Diary in 000005 line 20, see above.  Put it here
103403 - where we know, 47 = 2.
103404 -
103405 -
103406 -
1035 -
1036 -
1037 - 03501
1038 -
103801 - Line 145 - getgbl 1 257, made entry to move current User to Primary,
103802 - as explained for Diary in 000005 line 20, see above.  Put it here
103803 - where we know, 47 = 2.
103804 -
103805 -     Added conditional so macro 853 is only called, if the current User
103806 -     ID in counters 285 - 289 is not blank.  This can occur
103807 -     occassionally, after trying to open an SDS record listed in the
103808 -     Reference field for which the User ID field is blank for some
103809 -     reason.
103810 -
103811 -
103812 - Line 235 -label bH_3502x, disconnected macro 856, so access to SI is
103813 - predicated on primary User ID, which in turn is controlled by the
103814 - session type in global 257 set in 04702.
103815 -
103816 -     The original theory was that the subjects of an individual provide
103817 -     some autonomy and privacy.  For Executives will give them this
103818 -     access to provide support.  We will create a method so user's can
103819 -     set a flag to avoid access to a record.
103820 -
103821 -
103822 -
103823 -
1039 -
1040 -
1041 - 03502
1042 -
104201 - Line 10 - getgbl 1 257, made entry to move current User to Primary,
104202 - as explained for Diary in 000005 line 20, see above.  Put it here
104203 - where we know, 47 = 2.
104204 -
104205 -     Added conditional so macro 853 is only called, if the current User
104206 -     ID in counters 285 - 289 is not blank.  This can occur
104207 -     occassionally, after trying to open an SDS record listed in the
104208 -     Reference field for which the User ID field is blank for some
104209 -     reason.
104210 -
104211 -          [Thinking about this further on 940318, I will eliminate the
104212 -          condition, and instead return an error message, if the
104213 -          routine that opens SDS records, encounters a blank User ID
104214 -          field, per analysis at ref SDS 19 line 197.]
104215 -
104216 -  ..
104217 -
104218 - Line 300 -label noLvl, 40 lines below, change macro 856, which places
104219 - original User ID in Primary User ID counters, so macro 921, brings
104220 - Primary global User ID to current User ID values in 285 - 289, which
104221 - is then loaded by macro 841, similar to macro file 03501 at 235.
104222 -
104223 -
104224 -
104225 -
1043 -
1044 -
1045 - 04702
1046 -
104601 - Line 50 - added setgbl 256 17 to identify the session as the Executive
104602 - program.  I want to try this as a flag to control macro 96 in
104603 - Executive sessions getting complete chronologies based on the local
104604 - User ID, rather than limiting the User to only the original User ID
104605 - or the Primary ID, as seems to be the case now.
104606 -
104607 -
104608 -
104609 -
104610 -
104611 -
1047 -