Conference iosg::all-in-1_v30

    almost forgot  -  ALL-IN-1 2.4 no patches
    
    ann

    Ann,

    It sounds like the user is attempting to delete a document which is
    perceived to be in another user's file cabinet.  That is the type of
    situation which causes the error message you posted in .0.

    The normal V2 shared folder has the form of [profile_name]folder_name.
    Unless the profile_name is the same as the current user's profile name
    the user cannot write or delete documents in that folder.

    I don't believe there is a way to have other user's shared folders in
    one's file cabinet.  Was this user's profile name changed by a transfer
    user or other change?

    The actual file protections wouldn't have any effect since the files
    are not actually touched until the wastebasket is emptied.

    Have fun,
    don

	First of all, Ann, in V2.4 you technically don't delete a folder 
(despite the option name); you delete all documents *within* the folder.  But
that's important, because I have an idea that the user trying to delete the
folder is not the owner of the folder.

	In other words, if I create a shared folder called "[NICODEM]" and
nothing else, I have full access (including delete access) to it.  *You* can
consider it part of your "File Cabinet", for reading only.  But you can't delete
any documents from it (which is what the Delete Folder option does).  I can,
however, do a Delete Folder.

	So unless the person trying to delete the folder is the owner of the
account (i.e., Smith is trying to delete folder [SMITH]), then they'll get the
error you described.

	F

    so, the user(s) who add a shared folder to their file cabinet have to
    live with it till the owner of the folder deletes it (or documents
    there in)?  doesn't seem right.
    
    ann

    Ann,

    I just did some testing and confirmed what I said in my reply about not
    having other people's shared folders in their file cabinets.  Mainly, I
    am unable to add a folder of the form [USER]FOLDER in my file cabinet
    where USER is not my username.

    I can access documents in other users' file cabinets by SELecting these
    documents.  However, when I select another folder and then do an Index
    there is no reference to the other user's documents unless I
    specifically request this shared folder.

    Does the user in question actually have records in his/her/its DOCDB
    which are of this form and not his/her/its user name?

    If so, how did they get there?

    One way to remove them would be to user DCL to remove the records.

    Have fun,
    don

    ok, this what the user did and what i just did to test -
    
    EM
    SEL  entered [RMSPECS] on the folder line
    <CR>
    
    the folder [RMSPECS] is in the current item block, this is the one that
    cannot be gotten rid of. No [USER] was entered when SELecting the
    folder.  now, i've got this darn folder and can't get rid of it either!
    the original folder was created back in 1989, was Shared Folders around
    then?  
    
    i searched my DOCDB and no references to this folder or a Zmumble file
    for one of the entrys. 
    
    thanks - ann

    Ann,

    Are you saying that you cannot use SEL to select another folder, like
    READ after accessing [RMSPECS]?

    In order to deleted the shared folder you will need to be in the
    RMSPECS account.  ALL-IN-1 will not allow any other user to do anything
    but read shared folders unless the customer adds SFCP.

    This style of shared folder has existed since ALL-IN-1 V2.0.

    I hope that this makes the customer more happy,
    don

    Don -
    
    >>Are you saying that you cannot use SEL to select another folder, like
    >>READ after accessing [RMSPECS]?
    
    	NO! everything else works fine.  I just can't delete this folder
    	from my file cabinet.
    
    Well, after seeing the answer - delete it from RMSPECS account - i can
    at least tell the customer that.
    
    I know they'll come back with this question - if this folder is deleted
    from the RMSPECS account, then its deleted for good (until EW is run
    anyway) right?  There is NO WAY to delete it from a specific users
    cabinet - right?
    
    	ann

    Ann,

    I am not sure that I understand or that we are communicating
    effectively.  You say that you cannot 'delete' the folder but
    everything else works.  

    Can you create a new document in another folder?  This would 'delete'
    the shared folder would it not?

    The shared folder is not in the users' file cabinets.  The shared
    folder is only in the context block of the menu in question.  This
    entails setting some symbols and nothing else.

>    I know they'll come back with this question - if this folder is deleted
>    from the RMSPECS account, then its deleted for good (until EW is run
>    anyway) right?

    The folder will be deleted as soon as there are no documents in it.
    This has nothing to do with the EW option.  The EW deletes files from
    the wastebasket folder.  

>			There is NO WAY to delete it from a specific users
>    cabinet - right?

    Right.

    Good luck,
    don

    don -
    
    thanks for your patience with this feeble old mind.  once again you are
    correct sir!  now that its understood by me, i'll exxplain to the
    customer.  
    
    sorry for the confusion.  i had worked a bit with SFCP, but not with
    shared folders. so maybe there is where i got confused.
    
    	ann

	Ann (and all others who may confuse the basic capability of shared
folders with the optional SFCP package),

	That was the entire reason for SFCP -- because the basic shared folder
scheme built into ALL-IN-1 does not allow *any* other access than Read Access to
someone who is not the owner of the ALL-IN-1 account.  Therefore, HARRIS could
create a folder called [HARRIS], and could add, delete, refile, etc.  And *all*
other users can *read* ANYTHING in that folder.  (There is no access control,
such as SFCP provides, either; it's all or nothing.)  But no one else can edit,
delete, or do anything else to documents in that folder.

	Any attempt to do so (such as using the Delete Folder option from the
FC menu -- which is what I assume you're trying to use) will generate the
error message you saw, as I said in an earlier reply.

	F