.. _UC42: Use Case 42 - Hide or Unhide an Object from Discovery ----------------------------------------------------- .. index:: Use Case 42, hide object, UC42 Revisions View document revision history_. Goal Alter discovery of an object through search, but do not alter ability to retrieve the object given its identifier. Summary A content owner or manager would like to prevent further discovery of an object though ensure that references to the object (using its identifier) remain valid. Or, if the object is already hidden from search, return it to a discoverable state. This is operation is called "Archive" in the DataONE service APIs. Actors - Client, a content manager or owner (must have *write* permission) - Coordinating Node - Member Node Preconditions - Client has authenticated to the desired level. - Object has been synchronized by the Coordinating Nodes - The object may be replicated to other Member Nodes Triggers - A user with write permission calls :func:`CNCore.archive` - A user with write permission calls :func:`CNCore.unarchive` Post Conditions - The *archive* property of :class:`Types.SystemMetadata` is altered - System metadata for all replicas of the object is updated - The search index operated by Coordinating Nodes is updated accordingly .. image:: images/42_uc.png *Figure 1.* Use case 42 diagram showing actors and components involved in this action. .. figure:: images/42_seq.png *Figure 2.* Sequence diagram for Use Case 42 illustrating the high level sequence of operations associated with altering discoverability of an object. .. @startuml images/42_uc.png actor "Owner" as client usecase "12. Authentication" as authen note top of authen Authentication may be provided by an external service end note actor "Coordinating Node" as CN actor "Member Node" as MN usecase "13. Authorization" as author usecase "42. Archive Object" as archive usecase "21. Notify subscribers" as subscribe client -- archive CN -- archive MN -- archive archive ..> author: <> archive ..> authen: <> archive ..> subscribe: <> @enduml .. @startuml images/42_seq.png participant "Client" as app_client << Application >> participant "Read API" as n_crud << Node >> participant "Authorization API" as n_authorize << Node >> participant "Object Store" as n_ostore << Node >> app_client -> n_crud: get(session, PID) n_crud -> n_authorize: isAuthorized(session, PID, READ) n_crud <- n_authorize: True, False, Err.NotFound alt NotFound app_client <- n_crud: Err.NotFound else False app_client <- n_crud: Err.NotAuthorized else True n_crud -> n_ostore: read(PID) n_crud <- n_ostore: bytes n_crud --> n_crud: log(PID, READ) app_client <- n_crud: bytes end @enduml **Notes** 1. For the GET operation, should isAuth() be performed only by CNs? Relying on the MN system metadata requires trusted implementation of the MN system and consistency of system metadata across all MNs (which will be the case, though with uncertain latency). Requiring all isAuth() operations to be performed by CNs will increase trust in the operation (assuming the operation is not spoofed by a MN) though will increase load on CNs. This should be specified in the Authorization use case. 2. Data sent to watchers might include: timestamp, object identifier, user id, IP of client. .. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/01_uc.txt