Difference between revisions of "ESciDoc Transfer Ownership"
Jump to navigation
Jump to search
m (→Issues) |
|||
(5 intermediate revisions by one other user not shown) | |||
Line 17: | Line 17: | ||
==Approaches for Items/Containers== | ==Approaches for Items/Containers== | ||
===Modify created-by for all versions of the resource=== | ===Modify created-by for all versions of the resource (Discarded)=== | ||
*this has to be done by special core method | *this has to be done by special core method | ||
*the information on who had been previous owner is lost | *the information on who had been previous owner is lost | ||
Line 25: | Line 25: | ||
*simpler, smaller revision needed | *simpler, smaller revision needed | ||
===Modify created-by for last version of the resource only=== | ===Modify created-by for last version of the resource only (Discarded)=== | ||
*core service has to introduce created-by for versions as well | *core service has to introduce created-by for versions as well | ||
*in this case, created-by for resource will be equal to created-by for versions starting with the version in which the resource was at the time of ownership transfer | *in this case, created-by for resource will be equal to created-by for versions starting with the version in which the resource was at the time of ownership transfer | ||
Line 31: | Line 31: | ||
*complex, huge revision needed | *complex, huge revision needed | ||
===Use new property owned-by for all versions of the resource=== | ===Use new property owned-by for all versions of the resource (discarded)=== | ||
*if no owner is set, object is owned by creator | *if no owner is set, object is owned by creator | ||
*owner of an object is not stored in fedora, but in separate database-table (as lock-owner) | *owner of an object is not stored in fedora, but in separate database-table (as lock-owner) | ||
Line 37: | Line 37: | ||
*additional filters to filter objects for owner | *additional filters to filter objects for owner | ||
*possibility to create policies that are dependent on owner of an object | *possibility to create policies that are dependent on owner of an object | ||
===Rename property "created-by" to "owned-by" to have clear semantics === | |||
*the "created-by" property will be renamed to "owner" property (to have clear semantics) | |||
*each Item/Container resource version has already last-modified-by property (which actually gives information which user created that particular version of a resource ) | |||
*new "owned-by" value will be delivered in the presentation of all versions of the resource | |||
*XACML policies will be modified to reference "owned-by" instead of "created-by" property | |||
====Future use case: Deposit-on-behalf-on==== | |||
*would require separate service (e.g. SWORD Server API) and separate role (e.g. user A grants deposit-on-behalf rights to user B for som/all of his contexts) | |||
==Approaches for Contexts== | ==Approaches for Contexts== | ||
Line 48: | Line 56: | ||
==Issues== | ==Issues== | ||
[[Category:eSciDoc]] | [[Category:eSciDoc|Transfer Ownership]] |
Latest revision as of 09:42, 7 January 2011
Resources[edit]
- for Items
- for Containers
- for Contexts
Definitions[edit]
- Owner of a resource in eSciDoc is a user who has created the resource (the depositor of the resource) i.e. property: created-by
- Transferring of the ownership would mean that another user is from the moment of transferring owner of the resource
Current status[edit]
- Item/Container resources are versioned
- there is no distinction between created-by on resource level and created-by on version level
- only last-modified by on version level is kept for each version
- Context resource is not versioned
- there is only distinction between created-by
Approaches for Items/Containers[edit]
Modify created-by for all versions of the resource (Discarded)[edit]
- this has to be done by special core method
- the information on who had been previous owner is lost
- an entry in the version history shall be made with event-type (transfer ownership) and information on the old user
- new user becomes automatically "created-by" of the resource
- rights and privileges related to the owner automaticaly are transferred to the new owner
- simpler, smaller revision needed
Modify created-by for last version of the resource only (Discarded)[edit]
- core service has to introduce created-by for versions as well
- in this case, created-by for resource will be equal to created-by for versions starting with the version in which the resource was at the time of ownership transfer
- rights and privileges related to the owner are always checked by created-by on the resource level (not on the version)
- complex, huge revision needed
Use new property owned-by for all versions of the resource (discarded)[edit]
- if no owner is set, object is owned by creator
- owner of an object is not stored in fedora, but in separate database-table (as lock-owner)
- new core-methods to set and change an owner (for all versions!)
- additional filters to filter objects for owner
- possibility to create policies that are dependent on owner of an object
Rename property "created-by" to "owned-by" to have clear semantics[edit]
- the "created-by" property will be renamed to "owner" property (to have clear semantics)
- each Item/Container resource version has already last-modified-by property (which actually gives information which user created that particular version of a resource )
- new "owned-by" value will be delivered in the presentation of all versions of the resource
- XACML policies will be modified to reference "owned-by" instead of "created-by" property
Future use case: Deposit-on-behalf-on[edit]
- would require separate service (e.g. SWORD Server API) and separate role (e.g. user A grants deposit-on-behalf rights to user B for som/all of his contexts)
Approaches for Contexts[edit]
- Context related roles are:
- one possible approach is to do nothing, but assume that the user who needs to do something on the context has Context Modifier role
- another approach is to transfer the ownership to another user who has context administrator role
- note: Roles are extended on the referenced pages