Where FaceKom test records (“tesztjegyzőkönyv” / “Tesztelési jegyzőkönyv”) live in YouTrack, and a read-only REST recipe to find + download any YouTrack attachment. All facts verified live against https://youtrack.techteamer.com on 2026-06-26. Short-circuits future “find a tesztjegyzőkönyv / find a YouTrack attachment” tasks.

For Agents

  • Test records are PDF/DOCX attachments on per-client release/bug tickets, NOT standalone tickets. Look on the ASS<CLIENT> release issue or the BUG<CLIENT> release ticket.
  • To find one: full-text search YouTrack for tesztjegyzőkönyv (Hungarian works), scoped by project: or client text, requesting the attachments(name,mimeType,created,url) field, then GET the attachment’s (relative) url with the Bearer header.
  • Auth + base URL + token file are identical to youtrack-ready-for-release-nusz-query: base https://youtrack.techteamer.com, Bearer token read from ~/.config/facekom/youtrack.token (never on argv).
  • GET / read-only only. Do not mutate tickets.

Where test records live (convention)

The FaceKom “tesztjegyzőkönyv” is a branded PDF (sometimes DOCX) attached to a release/bug ticket — it is not its own issue type. To locate one:

  1. Identify the client’s YouTrack suffix (see client-registry — suffix ≠ repo name).
  2. Open the relevant ASS<CLIENT> “Release” issue or the BUG<CLIENT> release ticket for that version.
  3. The test record is an attachment on that issue (or occasionally on a comment).

Standard document structure

The unified FaceKom-branded “Tesztjegyzőkönyv” has these sections:

#SectionContents
1CélPurpose / scope of the test
2Tesztelési háttérSystem + version, executor (tester), date
3Teszttípusonkénti összegzésTable: végrehajtott / sikeres / sikertelen / blokkolt counts per test type
4TesztesetekIndividual test cases
5Tesztelési jegyzőkönyv + EvidenciákThe log itself + evidence (screenshots)
6(Szöveges) értékelésAccept / reject narrative verdict
7Hibás működésDefects found
8MellékletekAttachments

Template source-of-truth tickets

The unified format is defined by two FKITDEV tickets:

  • FKITDEV-8329 — Egységes TJK formátum (unified test-record format)
  • FKITDEV-8330 — Release/Install jegy template

Use these if you need the canonical template rather than a client’s filled-in instance.

InstaCash: historically no test record — first one generated 2026-06-26

InstaCash had no TJK in YouTrack — and none is attached yet

Historically InstaCash did not follow the TJK-per-release pattern — no release or eSign tesztjegyzőkönyv was ever attached in YouTrack. As of 2026-06-26 the first InstaCash eSign TJK exists: generated for eSign 1.3.0.11 (5 test cases) by dogfooding fk-tjk, rendered locally to ~/Downloads/tesztjegyzokonyv_instacash_1.3.0.11.docx. It is not yet attached to YouTrack (the /fk-tjk flow does not auto-write), so a YouTrack search still finds no attached InstaCash TJK today — but the pattern is now established.

InstaCash YouTrack suffix is ICASH → projects ASSICASH / BUGICASH / CRICASH / SLAICASH.

TicketWhatAttachments
ASSICASH-65FaceKom 1.9.11.50 releasebuild .log files only
ASSICASH-92eSign 1.3.0.11 releasebuild .log files only
ASSICASH-66 / -62 / -67 / -93 (TESZT) / -96 (PROD)install ticketsscreenshots only

The only instacash-side “teszt jegyzőkönyv” PDFs are OLD compliance / disaster-recovery docs, not release tests:

  • BUGICASH-460 — BCP teszt jegyzőkönyv (dated 2023-06, uploaded 2024-09)
  • ISSFK-338 — SaaS DR teszt (2021)

eSign-tied test records: only Raiffeisen

The only test protocol tied to an eSign update is Raiffeisen’s:

  • BUGRAFIPI-512 — “eSign 1.3.0.22 release” → attachment FaceKom - Raiffeisen esign - Tesztjegyzőkönyv - 22 Facekom Release v1.1.2.pdf (2024-10-24). Shows 2/2 dev test cases passed, executed by Nagy Balázs on 2024-10-16; components vuer_css / vuer_oss / esign_queue.
  • BUGRAFIPI-516 (sibling) → ...esign bizalmi szolgáltatás DR recovery - Tesztjegyzőkönyv.pdf (2024-10).

The recent Raiffeisen "Tesztelési jegyzőkönyv" PDFs are NOT eSign

The most recent Tesztelési jegyzőkönyv PDFs (2026) are Raiffeisen FaceKom / VUER OSS+CSS releases, not eSign-specific:

  • ASSRAFIPI-117 — release 1.9.11.94
  • ASSRAFIPI-113 — release 1.9.11.93
  • ASSRAFIPI-102 — release 1.9.11.92

If asked for the eSign test record, use BUGRAFIPI-512/516, not these.

BUGRAFIPI-514 (FaceKom 1.9.11.61) carries both .pdf and .docx variants of its test record — a handy example of the DOCX format if you need it.

REST recipe (read-only)

Use python urllib rather than curl | … pipelines: it sidesteps pipe mangling and keeps the token out of argv.

  • Base URL: https://youtrack.techteamer.com
  • Token file: ~/.config/facekom/youtrack.token (mode 600 — read into a variable, never echo or pass on the command line)
  • Header: Authorization: Bearer <token>
  • All timestamps (created, updated) are epoch milliseconds.

Search for a test record

import json, urllib.parse, urllib.request, pathlib
 
BASE = "https://youtrack.techteamer.com"
TOKEN = pathlib.Path("~/.config/facekom/youtrack.token").expanduser().read_text().strip()
 
def yt_get(path, params=None):
    url = BASE + path + ("?" + urllib.parse.urlencode(params) if params else "")
    req = urllib.request.Request(
        url, headers={"Authorization": f"Bearer {TOKEN}", "Accept": "application/json"})
    with urllib.request.urlopen(req) as r:
        return json.load(r)
 
# Hungarian full-text works; scope with `project:` or client text (e.g. "Instacash")
issues = yt_get("/api/issues", {
    "query": "tesztjegyzőkönyv project: ASSRAFIPI",
    "fields": "idReadable,summary,project(shortName),created,updated,"
              "attachments(name,mimeType,created,url),"
              "comments(text,attachments(name,mimeType,url))",
    "$top": 200,
})
  • Full-text Hungarian queries work directly (e.g. query=tesztjegyzőkönyv).
  • Scope with project: ASSICASH (etc.) or plain text like Instacash.
  • Attachments live on the issue (attachments(...)) and sometimes on comments (comments(attachments(...))) — request both.

Add a links selector to walk related issues (e.g. release → install tickets):

links(direction,linkType(name),issues(idReadable,summary))

Download an attachment

The attachment object’s url is relative (e.g. /api/files/…?sign=…). Prepend BASE and GET it with the same Bearer header; write the raw bytes.

def yt_download(attachment_url, dest):
    req = urllib.request.Request(
        BASE + attachment_url, headers={"Authorization": f"Bearer {TOKEN}"})
    with urllib.request.urlopen(req) as r:
        pathlib.Path(dest).write_bytes(r.read())
 
# for issue in issues["issues"]:
#     for a in issue["attachments"]:
#         yt_download(a["url"], f"/tmp/{issue['idReadable']}__{a['name']}")

Attachment URLs are signed / expiring

The ?sign=… query param is a time-limited signature — re-fetch the issue to get a fresh url rather than caching the link. (Same caveat noted in release-automation-design for comment-attachment extraction.)