From today's email on swh-devel:

morane:

Goal: we want to provide a public, centralized and human-readable view
to all the deposits that were made, to check for their status and
error_message, without credentials to view the page.

zack:

So, before commenting on a specific solution, I'd like to better
understand what are the use cases, because they are not clear to me. Can
you give me a list of scenarios in which specific actors[*] need to
access information that are currently not easily accessible (or not
accessible at all)?

For the scenarios I will identify the actors:
*SWH-liaison* that is in charge of relations with the deposit clients (today it is me)
*client-liaison* that is in charge of deposit functionality on the client side (moderators for HAL)
*user* person depositing the content on the client's platform
*client-dev* that is in charge on SWORD implementation at the client side

Scenarios:

1. a *client liaison* at HAL has only access to the deposit before validation, when it is validated everything else is automatic and the success/failure of the transfer is not visible to this actor, but the *user* usually approaches this actor for information. For example: the status of the deposit on SWH is not visible in a deposit on HAL. With a public view of deposits, the *client liaison* can check the status of the deposit and provide information to the *user* about it.

2. With the public view, the *team liaison* can check the deposit status and have a quick way to answer the *user* or the *client liaison* without connecting to the deposit DB.

3. With the public view, even a *user* can check the status of his deposit using the external-id he was given by HAL.

4. With the public view, a *client dev* can view multiple deposits at the same time and have an easy human access to the information, when an error was notified.

This type of view should be also developed by the client for all the deposits they have made, to provide some overview (with HAL, the goal is to do so, but it won't be soon).
SWORD protocol is a machine to machine way to communicate and transfer data, without a monitor view, we need to do some technical manipulation to get the information,
which isn't very comfortable and the view is very easy to implement.

After a discussion with Zack:
We need to separate the internal and external use cases.
For the external use cases we separate "Write" with its technology and "Read" to be easily accessed and user-friendly.

• "Write" deposit : review url schema to follow the 'with what tool' pattern
  • /sword/2/
  • /sword/3/ : if we implement the SWORD v3 specs
  • /truc/42/ : for any other technology/version we implement

• "Read" deposit : an easy access REST+ JSON entry point without authentication:
  • /api/1/
    • /deposit/status/
    • GET /deposit/status/<deposit_id>
    • POST /deposit/status/ : for a batch of deposit_id

For the internal use case, we need an private admin view to monitor more than just the deposits..
This is why this task will change to only cover "Read" deposit.
Two other tasks will emerge regarding the rest...

After the deposit workshop and the last errors we had with HAL, I believe this entry point has to be without any deposit_id or external_id.

I think we should review this decision, which was made for privacy reasons (not to have all deposits publicly visible), but this view contained very little private information (all the deposits that don't have errors are available in the web-app with the deposit-id and reception date)

Maybe only showing the last deposits (even only 10) and their status to start debugging with an easy access entry point that can be viewed by moderators from the sending platform (not computer programmers) without the deposit-id which might not be visible on the the client interface (the case with HAL).