Dostavam nejaky divny data pri nahravani obrazku. Vlastne nesedi nic co se tyce obrazku... Snad jsem zase nekde neco neprehlid. Nahrani samotne probehne, ale nedokazu ho potom embedovat (asi proto, ze se netvari jak obrazek...). Obrazek najdes kdyztak na alphe pod tim ID. Zkousel jsem to nekolikrat s ruznymi obrazky, pokazde to same...

{
  id: 2279999,
  file_type: discussion_attachment,
  id_specific: 1786,
  id_specific2: null,
  filename: image_picker_7D819726-9C03-415F-9698-CBC0B131E499-48037-000137CB5CEC3772.jpg.jpg,
  size: 269257,
  uploaded_at: 2021-03-18T22: 36: 44,
  mimetype: octet/stream,
  image_width: null,
  image_height: null,
  image_avg_color_hex: null,
  image_embed: false,
  image_embed_option: link,
  url: /files/000/022/2279999_2b66af0aa336a7deb497/original.bin,
  thumb_url: null
}

Tak pravda, mel jsem to tam blbe. Pardon :-/

Mozna ten my_rating mam blbe, overim.

LUCIEN: i tam to je, ne? Nahore v popisu parametru.

NYX: aargh, sorry, nechapu proc jsou ty enumy obcas v tom exploreru primo vypsany a obcas ne. Treba jako action u /api/discussion/{discussion_id}/rating/{id}/{action}. Budu si prochazet ty schemata vic pecliveji. Dik.

LUCIEN: Tj. tebe zajimaji ty mail_attachment a discussion_attachment

LUCIEN:

LUCIEN: file_type je v tom swaggeru jako enum, tj. tam mas komplet seznam hodnot.

id_specific - podle typu souboru - id diskuze, 0 pro N/A (posta)

Muzu se zeptat k cemu je parametr id_specific u endpointu PUT /api/file/upload a co je pripustne u parametru file_type?

NYX: Ve staré to tak bylo, tak jsem si nebyl jistý jak to je v nové. Pokud nedostanu data, pak asi víc nepotřebuju.

LUCIEN: discussion_common.discussion.ar_read jsou prava pro vsechnu
discussion_common.access_rights.ar_read je pravo pro konkretniho uzivatele
a majitel a navrhovany majitel ma vyjimku jeste

Asi by bylo lepsi nekam ulozit uz vyhodnoceny vysledek pro daneho uzivatele, co?

Premyslim, proc tohle resis pro pristup? Kdyz nemas pristup, nedostanes data, ne?

Jak prosim poznam zda ma uzivatel pristup do diskuze v endpointu ​/api​/discussion​/{discussionId}? Mam nejaky bordel v tech ar_XYZ permissions... Vsechno se mi to zda jako "admin rights"... Dik.

Tipuji, ze tak do pul hodky to bude hotove. Bohuzel se mi to dnes trochu protahlo :-/

https://alpha.nyx.cz/api/bookmarks/all mi ted vraci HTTP 502

NYX: Takze az to preklopis, tak alpha bude kopie www a nebude tam uz dochazet kazdy den k resetu DB? Jinymi slovy bude safe (aspon nejakou dobu) pouzivat jako endpoint alpha.nyx.cz?

LUCIEN: Novy nyx bude vracet na jakykoliv GET/POST request na api.php nejaky chybovy stav ve strukture, v jake to chodilo ve starem API. Takze by melo stacit aby novy nyx bezel dal na alpha.nyx.cz, na www.nyx.cz a zaroven i na hole nyx.cz domene, coz bude asi ta primarni lokace.

viz: https://alpha.nyx.cz/api.php

Ještě by mě zajímalo jak přesně chceš překlopit novou API místo staré. A/ Bylo by fajn v době překlopení mít v Appstoru už schválenou app s "Pending Dev Release". Jenže aby mohla být app schválená, musí odkazovat na API na Alphě. B/ Zároveň by bylo fajn u staré app zase zobrazovat hlášku, že je app deprecated. Tzn. ještě předtím udělat release, který tohle nějak ošetří.

Mno, takže jak na to? Co se stane se starou api? Pokud tam bude 301 redirect, tak na to konto můžu zobrazit hlášku o deprecated. Tzn. vyřeším bod B. TO je easy a můžu update zítra klidně poslat do Appstoru. Jak s A?