Conference iosg::all-in-1_v30

    Dealing with VMS accounts that have 2 or more A1 accounts is not one of
    the Group Services best points. The reason groups were put into V3 was
    to support shared filing, for the obvious reason that you don't want to
    go around re-sharing everything because a user joins or leaves a group
    of users. Shared filing is based on VMS ACLs, and groups work by having
    an associated identifier which can added to the ACL.
    
    This means that if 2 accounts share a VMS account then sharing with 1
    of these accounts automatically shares with the other. Without
    inventing our own special security scheme there's no way round this.
    
    Given that, we have the problem that the user enters an ALL-IN-1 name
    that we have to translate into a a VMS account name that is stored on
    an ACL or, in the case of groups, that will receive the identifier. So
    when re-displaying the information we have now "forgotten" which
    ALL-IN-1 account was originally named and so just pick the first that
    matches.
    
    We have tried to add UI code to help in these situations, but they do
    not completely help otherwise you wouldn't have had to write your note.
    
    For sharing purposes the UI works better if there is one-to-one
    correspondence between ALL-IN-1 and VMS account name, but we haven't
    helped ourselves by making the Manager account a shared account.
    Fortunately sharing with the Manager is not a real-lifer since the
    manager is likely to have access to everything anyway. But it is the
    first account anyone playing with the system is likely to share with.
    
    FWIW
    
    Stuart

    Stuart,
    
    I believe that the CSC had spotted and maybe already reported this one
    as a QAR and yes your explanation of why it happens makes sense however
    I guess I have one simple question that kind of follows on from the
    base note.
    
    In the case where the sharing account is the ALLIN1 account (might be
    called something else) could not the excellent Group Services code
    (creep, creep) force the one entry to be the MANAGER account (I know
    this might be called something else) as an exception since it is the
    MANAGER and not IVP account that you actually want to be included.
    
    Of course on systems that came from v2.2 and earlier and didn't do all
    the v2.3 post-install tasks the named account in v3.0 will be the
    infamous BOOT account
    
    Regards,
    
    Andrew.D.Wicks
    
                         

    Yes I think that's a good idea, and the same applies to the ACL$ data
    set as well.
    
    Cheers
    
    Stuart

I know several of you will be screaming NO not another one by now but how about 
a way of marking one of the set of ALL-IN-1 accounts sharing the same VMS 
account as the primary one (this is where the profile field comes in) and always
displaying this account.

Of course you would have to make sure that if one account was maked as primary
all the others sharing the same VMS account were unmarked (like the default
flag on proxy accounts).

This would then allow MANAGER to be marked as primary by default but allows
customer to change it if they want and set up dummy profile entries to give
generic ALL-IN-1 names to groups of accounts that share the same VMS account.

e.g. A group of ALL-IN-1 users SALESPERSON1, SALESPERSON2, SALESPERSON3 all 
use the SALES VMS account. A dummy ALL-IN-1 user called SALES could be created
that was marked as primary and so would appear when looking at access to
drawers.

This would put the traditional ALL-IN-1 flexability back into this small part
of the world.

Terry

P.S. Either this is a stupid idea and I don't realise it yet or I am doing
exceptionally well for a Friday afternoon ;^}

    Re .2
    
    Of course the ALLIN1 (sic) VMS account isn't always called that, so
    we'd have to do a relatively expensive test by seeing if the MANAGER's
    profile record had the same VMS account in it.
    
    Re .4
    
    Presumably we'd look for the flag, and if there wasn't one, it would
    just default to the old alphabetical order, and if multiple flags were
    set we'd just use the first one.
    .
    .
    .
    .
    Of course it's traditional for us to *always* change the size of the
    PROFILE with each version, and I know how disappointed everyone would
    be if we didn't, so this would be a good start for the PFR :-)
    
    Graham