Add route for uploading metadata in yaml

[anne17]

A user should be able to upload a resource of type "metadata". This should be a yaml file matching one of the formats specified in these templates. The uploaded file should be verified with a json schema (does not exist yet), either by the frontend or the backend.

If the user has superuser permissions (e.g. "write" in "Mink-App"), the yaml file should somehow be incorporated into our metadata API

Some more notes on this in Swedish:

Kunna ladda upp metadata-filer i Mink samt publicera på resurssidan

• för superusers (med plublicering) Förutsättningar:

  • användare måste ha write i Mink-App (om det är så vi vill definiera superuser-rättighet)
  • användare är kopplad till ett organisations-prefix (t.ex. sbsam-) (var lever den mappningen? Kan den bo i sbauth på något sätt?)

  Arbetsflöde:

  1. användare får välja ett resurs-ID, som automatiskt prefixas
  2. endpoint för create-metadata med vald resurs ID
     • BE kollar upp om ID:et är ledigt https://ws.spraakbanken.gu.se/ws/metadata/check-id-availability?id=some-id
     • datakatalog ska skapas på guit2, i separat mapp (ej blandat med korpusar)
  3. endpoint för uppladdning av yaml
     • validering av yaml
     • kopiera till datakatalog på guit2
  4. endpoint för installation/publicering av yaml
     • i.e. rsync till bark i mapp som heter samma sak som användarens prefix
  5. endpoint för hämtning av metadata (för att kunna visa i FE)

  problem: resursnamn ska synas i gränssnittet... var kommer det ifrån? Sparv-config? I så fall borde vi nog tänka om lite för att göra detta mindre Sparv-beroende ska man ändå ha ett job-item? Ja, förmodligen... måste tänkas igenom mer först!

• för alla användare (utan plublicering, ett enkelt sätt att få in lite metadata för korpusar som folk vill att vi ska slänga in?)

  • Det här har jag inte hunnit fundera på än :) inte helt säkert att det ska vara i Mink ens... kanske bättre som en separat grej?

[anne17]

Några saker som @arildm och jag kom fram till ang. metadata-arbetsflödet i Mink:

• Alla resurser får mink- IDn internt, registry:n har koll på "publicerings-ID" (obs: ändring av publicerings-ID är problematiskt! Det ska man antingen förbjuda, eller så ser man till att ta bort allt med det gamla publika ID:et från eventuella "installationer", dvs resurssidan mm)
• organisations-prefix for publika IDn, var ska dessa bo? Just nu i en dict ({user_id: org-prefix}) i Mink backenden (instance/config.yaml)
• Vilken "resource type" ska en "metadata-resurs" få i sbauth? Svar: "metadata"!
• sb-auth-routen för att lägga till en resurs (https://spraakbanken.gu.se/auth/resources/resource/) gör just nu att resursen blir en korpus. Det vill man kunna styra med någon parameter så att man kan skapa andra typer av resurser via API:et. Arild kollar kanske på det. Sedan behöver det implementeras i sb_auth/login.py i backenden.

[anne17]

Lite info till @arildm och @MartinHammarstedt i fall ni ska fortsätta med detta medan jag är borta.

Nu har jag implementerat några nya routes:

• create-metadata
• remove-metadata
• upload-metadata-yaml
• download-metadata-yaml

Dessa fungerar hyfsat. De är releasade och dokumenterade (https://ws.spraakbanken.gu.se/ws/mink/api-doc#tag/Manage-Metadata). Här är några saker till som jag har tänkt på men inte hunnit med:

• /list-corpora listar nu också metadata-filer... inte optimalt! Man kanske borde döpa om anropet till list-resources och sedan lista allt uppdelat efter olika resurstyper. Detta styrs av sb_auth/login.py
• /upload-metadata-yaml gör ingen kontroll av yaml-formatet! Bör kollas mot ett schema, av frontend eller backend?
• Det finns nya return_codes (relaterade till nya metadata-routes) som backenden kan spottar ur sig som inte Arild har fått (och som frontenden därmed inte kan översätta). Tidigare har jag bara greppat efter dessa med grep -r -P -o 'return_code=".+"' och sedan lagt in i https://docs.google.com/spreadsheets/d/12YOLXdArr17S2OsAmSIekY3Ys-G6L7mEW0S7t-n6-Qs/edit?usp=sharing
• input-parametern corpus_id borde ändras till resource_id i hela API:et (och i Postman). Detta måste dock ske koordinerat med frontenden för att inte Mink ska gå sönder.

[arildm]

Har kollat på detta och börjat anpassa frontenden nu!

En sak som jag tycker saknas är ett anrop för att se om användaren har tillåtelse att skapa metadataresurser. Dvs om den finns med i METADATA_ORG_PREFIXES. Så att vi inte visar den delen av gränssnittet för alla.

Kanske som en route typ /user-info? Jag tycker det känns troligt att det kommer tillkomma fler detaljer som rör användaren. Det finns ju redan en check om användaren har tillgång till admin-läget. Den checken görs både i frontend och backend just nu, men det vore kanske snyggare att det bara är backenden som gör det, som en del av /user-info då.

Ett svar från /user-info skulle alltså kunna se ut typ:

{
  "id": "httpsidp3.it.gu.seidpshibboleth-xmatargu.se",
  "org_prefix": "sbx",
  "app_grant": "ADMIN",
  // + status, return_code, message
}

[arildm]

~Jag kan skapa och ta bort metadataresurser. Däremot får jag bara fel från /upload-config. Jag skickar abotidning.yaml med PUT till upload-config?corpus_id=mink-u9uozrx2yz, och får:~

{
    "status": "error",
    "message": "Failed to upload config file for 'mink-u9uozrx2yz'",
    "info": "Failed to upload contents to 'mink-data/corpus/u/mink-u9uozrx2yz/config.yaml': bash: mink-data/corpus/u/mink-u9uozrx2yz/config.yaml: No such file or directory\n",
    "return_code": "failed_uploading_config"
}

Edit: Nevermind! I just confused /upload-config with /upload-metadata-yaml!