Ownership and ownership transfer

The owner role is a system role, i.e. computed by BSCW and not arbitrarily set by users. Every object has one or more owners, who share responsibility for the disk space used by the object owned – important when disk space control (‘quota system’) has been activated for your server.

Ownership and transfer of ownership in BSCW (and transfer of roles in general) is best ex­plained by taking a closer look at the entries in folder listings that act as links to BSCW ob­jects. An object is accessed via its entries where one object may have a multitude of entries. An example: If you click on an entry of an HTML document in one of your shared work­spaces, the document is shown to you. If another member of the same workspace clicks on her entry of the same document, she is also shown the document. So, both of you have (at least) read access to the HTML document by means of your entries in the shared workspace refer­ring to the same object.

If you cut, delete or paste an object you actually do not cut, delete or paste the object, but you move an entry referring to the object into your clipboard, into your trash or from your clip­board to some other container object. Moving objects in BSCW means moving the entries, not the objects themselves.

How are entries created? If you create an object, entries to this object are created for all mem­bers of the container object in which you create the object. Other actions also create additional entries of an object, e.g.,    Link    to Clipboard  creates an entry referring to the object in your clip­board, and inviting new members to a workspace creates entries to the workspace and its con­tents in the home folder of the newly invited members.

Entries come in two flavours with respect to ownership, membership and transfer of roles:

o  Entry transfers roles: This is typically the case when an object along with its entries is created in a folder. In this case, the object inherits the members and their roles (in­cluding the owner role) from the folder in which the object was created.

o  Entry sets roles: This is typically the case when a user A is invited to a folder in the role ‘xyz’. In this case, an entry in the home folder of user A is created that refers to the folder and sets role ‘xyz’ for user A. The owners of the folder remain unchanged, only user A joins in role ‘xyz’.

Given the necessary access rights – by default those of a manager – you may change the char­acter of entries with respect to transferring roles or setting roles. Invoke   Access    Assign Role  to display a form that either lets you only define specific role assignments for the mem­bers of the object (in this case, the object has only one entry, which has to be a role transfer­ring entry), or that lets you also specify for each entry of the object whether it is to transfer roles from the containing folder or whether it sets a specific role for the members of the con­taining folder. Depending on your choice, the entries become role transferring entries or role setting entries. There must at least be one entry left which transfers the owner role from the folder above (the owner role cannot be set!). The specific role assignments for the users listed override the role assignments derived from role transfer or role setting (see 4.2.3 Assignment of roles).

The two kinds of entries are not easily distinguished at the user interface. The  icon signal­ling that the respective object is contained in at least two folders with different groups is a good guideline: Entries with a  icon, where the owner differs from the owner of the con­taining folder, are good candidates for role setting entries, whereas entries with no  icon are good candidates for role transferring entries. To be sure about the character of an entry, you have to use   Access    Assign Role .

When entries are moved (cut, pasted, deleted), they do not change their character with respect to transferring or setting roles. When you move a role setting entry to your clipboard, it still remains a role setting entry, and you keep your role(s) that you had beforehand.

The members and their roles with respect to an object result as a sum of what is transferred or set by the individual entries referring to the object, eventually overridden by specific role as­signments via   Access    Assign Role . When an object is no longer referred to by an entry, i.e. when all entries have been destroyed, the object will eventually be removed from the sys­tem (see ‘Destroy’ below).

After the discussion of the general principles, let us now see how ownership and membership of an object is affected by cutting, pasting, deleting and destroying the entries referring to it.

o  Cut: Cutting an entry from a folder F moves the entry to your clipboard. If the entry transfers roles it will now transfer roles and members from your clipboard instead of from folder F. This will give you the role of owner and manager. If the entry sets roles your role will remain the same as in folder F. The other members of folder F, if any, will lose access to the object referred to by the entry via this entry. Membership and ownership based on other entries referring to the same object in other folders remain as is.

o  Paste: Pasting a role transferring entry from your clipboard to a folder G lets the entry now transfer members and roles from folder G instead of from your clipboard. Conse­quently, all members, managers and owners of G will also become members, manag­ers and owners of the object referred to by the entry. You will lose your owner/man­ager role if you are not also owner/manager of G. Pasting a role setting en­try from your clipboard to a folder G leaves you in your role that you had in your clip­board. Other members of folder G, if any, get access to the object referred to by the entry in the role that is set in the entry – eventually overridden by specific role as­signments of the object – with the exception of restricted or anonymous members of G, which be­come anonymous members of the object to ensure minimal access. Own­ership which is based on other role transferring entries remains as is.

o  Delete: works like cut, only entries are moved to your trash and not to your clipboard.

o  Undelete: works like paste, only entries are moved back to their original location.

o  Destroy: removes entries from your trash. If you destroy a role setting entry you lose ac­cess to the object referred to by the entry via this entry; if the entry was your only access to the object, you are removed as member of the object. If you destroy a role transferring entry – you are owner and manager of the object because you are owner and manager of your trash! – you lose your owner and manager role transferred via this entry; if the entry was your only access to the object, you are removed as member and owner of the object. The disk space used by the object is no longer accounted to your disk quota, if disk space control is activated for your BSCW server. A problem arises when the role transferring entry to be destroyed is the last such entry referring to the object, and there are other role setting entries left that still refer to this object. If the entry would be simply removed, the object would have no owner left; you would think you had destroyed your ‘own’ object while other members still have access. To avoid such a situation, the other role setting entries referring to the object are removed as well. Since the other members of the object lose access to the object, you are warned by BSCW before you destroy the last role transferring entry referring to an object that still has other members. If you go ahead, the object has no more entries re­ferring to it and will eventually be removed from the system.