Ebben a cikkben
Az ügyféloldali közösségi média jóváhagyás akkor működik megbízhatóan, ha az ügyfél közvetlenül az adott posztot látja, tételenként dönthet az elfogadásról vagy a módosítási kérésről, és a döntés magához a tartalomhoz kötve marad. Az Uplonicban a jóváhagyási link külön ügyfélfiók és belépés nélkül biztosítja ezt a hozzáférést. Ez az útmutató egy publikálási időpont nélküli piszkozaton mutatja be az API-munkafolyamatot: a jóváhagyás feloldja a felülvizsgálati zárolást, miközben a tényleges közzététel a munkaterület irányítása alatt marad.
A tágabb munkaterület-struktúra kialakításához olvasd el a több ügyfél közösségi média fiókjainak kezeléséről szóló útmutatónkat. Az alábbi munkafolyamat az ezen a struktúrán belüli jóváhagyási átadást mutatja be.
Mire van szükség, és mit igazol ez a teszt?
A folyamathoz szükséged van egy olyan munkaterületre, amelyen engedélyezve van az ügyfél-jóváhagyási funkció, egy írási jogosultsággal rendelkező API-kulcsra, az API alap URL-jére, valamint egy, az adott munkaterülethez tartozó piszkozat posztra. A link létrehozásakor az API ellenőrzi a munkaterület ügyfél-jóváhagyási jogosultságát (entitlement). Az API-kulcsot mindig megbízható szerveren vagy védett kliensben tárold; az ügyfélnek kizárólag a jóváhagyási URL-t add át.
A 2026-10-18-án elvégzett fejlesztői ellenőrzésünk egy izolált munkaterületet használt a fejlesztői adatbázisban, és a valódi review-link, illetve public-review HTTP-végpontokat hívta meg. Teszteltük a link létrehozását, a felülvizsgálati csomag megnyitását, az indoklás nélküli módosítási kérés elutasítását, az időpont nélküli jóváhagyást, az ismételt döntésküldést, a linkek listázását és a visszavonást. Egy külön adatbázis-integrációs teszt vizsgálta az ütemezett tételeket, a módosítási kéréseket, a lejárt időpontokat és a munkaterületek közti izolációt. Böngészős kattintásokat, e-mail-kézbesítést és éles közösségi hálózati posztolást ez a teszt nem tartalmazott.
Jóváhagyási link létrehozása a piszkozathoz
Küldj egy POST /review-links kérést a munkaterület API-kulcsával az x-api-key fejlécben. Cseréld ki az alábbi POST_ID értéket a munkaterületen lévő piszkozat azonosítójára. Az alábbi JSON-struktúrát használtuk a HTTP-tesztünk során is:
{
"postIds": ["POST_ID"],
"title": "Review demo",
"locale": "en",
"expiresInDays": 14
}A 14 napos lejárat a 2026-10-18-án ellenőrzött tesztpéldánk beállítása; a saját folyamatodban válassz olyan lejárati időt, amely lefedi a megbeszélt visszajelzési ablakot. A kérésünk nem tartalmazott címzett e-mail-címet, így a rendszer e-mail küldése nélkül hozta létre a linket. A válasz visszaadta a link azonosítóját, a teljes URL-t, a lejárat idejét és a tételek számát. A megfelelő jogosultsággal nem rendelkező munkaterületet a végpont még a link létrehozása előtt elutasította.
Mentsd el a visszaadott URL-t közvetlenül a létrehozáskor. Az adatbázisban tárolt rekord kizárólag a token hash-értékét őrzi meg, így a linkek későbbi listázása nem tudja visszaállítani az eredeti nyilvános URL-t. A szokásos privát kommunikációs csatornádon oszd meg a linket a kijelölt bírálóval, mivel a lejáratig vagy visszavonásig bárki hozzáférhet a hozzárendelt tételekhez, aki birtokolja a címet.
Tételszintű döntés begyűjtése
A jóváhagyási oldal a visszaadott URL-ben szereplő tokent használja a GET /public/review/TOKEN végpont betöltéséhez. A válasz tartalmazza a linkhez rendelt tételeket és azok review item azonosítóit. A tesztünkben a válasz kizárólag az adott linkhez rendelt piszkozatot tette láthatóvá, és az ügyfélnek nincs szüksége a munkaterület API-kulcsára.
A nyilvános felületen az ügyfél jóváhagyást vagy módosítási kérést választhat. A döntés akkor válik rögzítetté, amikor a bíráló ténylegesen beküldi a választását; önmagában az opció kijelölése még nem zárja le az átadást. API-integráció esetén küldj egy POST /public/review/TOKEN/decisions kérést a kapott tételazonosítóval:
{
"decisions": [
{ "itemId": "REVIEW_ITEM_ID", "decision": "approved" }
]
}Ezt a kéréstörzset 2026-10-18-án HTTP-n keresztül teszteltük. A válasz minden beküldött tételhez külön eredményt ad vissza: ellenőrizd az egyes elemek ok mezőjét és kimenetelét (outcome). Az üres megjegyzéssel küldött módosítási kérésünket a rendszer validációs hibával utasította el, míg a szervizszintű integrációs teszt külön igazolta a szöveges indoklással ellátott módosítási kérést. Egy adott linken az első rögzített döntés végleges az adott tételre: az ismételt beküldés REVIEW_ALREADY_DECIDED kódot adott vissza.
A jóváhagyás ellenőrzése és a következő lépés kiválasztása
Az ütemezés nélküli piszkozatunk approved_only kimenetelt adott vissza: a felülvizsgálati állapota jóváhagyottra váltott, maga a poszt piszkozat maradt, és nem jött létre publikálási kérés. Ebben az útmutatóban ez a sikeres végállapot. Mielőtt beillesztenéd a posztot a közösségi média tartalomnaptárba, vizsgáld meg a poszt állapotát és a link tételszintű kimeneteleit.
Kimenetel (Outcome) | Jelentés | Teendő a munkaterületen |
|---|---|---|
approved_only | A jóváhagyási feltétel teljesült; az időpont nélküli poszthoz nem indult közzététel. | Válassz célcsatornát és publikálási időpontot, amikor a tartalom készen áll. |
scheduled | A jóváhagyási folyamat elfogadta a tárolt jövőbeli ütemezést a szerviztesztünkben. | Ellenőrizd a publikálási kérést, majd később a célplatform eredményét. |
needs_new_time | A tervezett publikálási időpont már elmúlt, mire az ügyfél döntött. | Állíts be új időpontot; az ügyféllink nem publikálja ki némán a lejárt tételt. |
returned | Az ügyfél módosítást kért, így a tétel továbbra is zárolva van a közzététel elől. | Olvasd el a visszajelzést, javítsd a tartalmat, és küldd be újra jóváhagyásra. |
A sikeres jóváhagyás a felülvizsgálati döntést igazolja. Annak megállapításához, hogy a poszt ténylegesen megjelent-e a célplatformon, a publikálási eredményt külön kell ellenőrizned. Ha a jóváhagyás után publikálási hiba lép fel, kövesd a kis csapatoknak szóló közösségi média automatizálási útmutatónk ellenőrzési lépéseit, és vizsgáld meg a sikertelen célcsatornát az újrapróbálkozás előtt.
Ha az átadás nem működik
Jelenség | Ellenőrzött teszteredmény | Következő lépés |
|---|---|---|
A link létrehozását elutasítja a csomag. | A HTTP-teszt elutasította a létrehozást a funkciójogosultság hiányában. | Ellenőrizd, hogy az ügyfél-jóváhagyás engedélyezve van-e a munkaterületen. |
A módosítási kérés nem küldhető el. | A HTTP-végpont nem üres megjegyzést ír elő. | Írd le a kért változtatást, majd küldd be újra a döntést. |
A bíráló nem tudja módosítani a korábbi döntését. | Az ismételt tételdöntés REVIEW_ALREADY_DECIDED hibát adott vissza. | Nézd meg a rögzített eredményt; az átdolgozott tartalomhoz indíts új jóváhagyási kört. |
A jóváhagyási link már nem nyílik meg. | A visszavont és lejárt linkeket az ellenőrzésünk elutasította. | Ellenőrizd a link állapotát, és állíts ki új linket, ha még szükség van a bírálatra. |
Egy link visszavonásához hívd meg a POST /review-links/LINK_ID/revoke végpontot a munkaterület API-kulcsával. A teszt során lefuttattuk ezt a hívást, és igazoltuk, hogy a nyilvános URL ezt követően már nem oldódott fel. A visszavonás megszünteti a linkhez való hozzáférést, de önmagában nem hagyja jóvá, nem mondja le és nem törli a mögöttes tartalmat.
Források és módszertan
Módszertan: saját implementáció-áttekintés és fejlesztői munkafolyamat-ellenőrzés 2026-10-18-án. A leírt működés a tesztelt Uplonic-implementációból származik; külső cikkeket vagy piaci statisztikákat nem használtunk.
- Uplonic reviewLinks és publicReview HTTP-útvonalak, clientReview és postReview szervizek: linklétrehozás, jogosultság-ellenőrzés, tételdöntések, lejárat és jóváhagyási kimenetelek; ellenőrizve: 2026-10-18.
- Uplonic fejlesztői HTTP-ellenőrzés: dedikált munkaterület, hitelesített linkkezelés és nyilvános döntések; ellenőrizve: 2026-10-18. E-mail-küldési, böngészős vagy élő platform-kézbesítési állítást nem tartalmaz.
- Uplonic client-review adatbázis-integráció: függő tételek zárolása, jövőbeli ütemezések, módosítási kérések, lejárt időpontok és munkaterület-izoláció; ellenőrizve: 2026-10-18.
