إنشاء تذكرة
من CLI، شغّل:source على cli. يضيف --diagnostics اسم الملف التنفيذي ونسخة
CLI ونظام التشغيل والمعمارية فقط. شغّل logbrew support --help لعرض كل الخيارات.
لا يرسل CLI مفتاح إعادة محاولة عند إنشاء التذكرة. إذا لم تكن النتيجة مؤكدة، فشغّل
logbrew support list --json قبل أن تشغّل الأمر مرة أخرى. وإلا فقد تنشئ تذكرة ثانية.
من الـ API، أرسل POST /api/support/tickets مع source وcategory
وtitle وdescription. لتكون إعادة المحاولة آمنة، أنشئ مفتاح إعادة محاولة مرة
واحدة للبلاغ، وأرسله في الترويسة Idempotency-Key. يستخدم هذا المثال قيمًا
اصطناعية:
Idempotency-Key اختيارية. ومن دونها، قد ينشئ الطلب المكرر تذكرة أخرى.
الحقول الاختيارية هي project_id وenvironment وruntime وframework
وsdk_package وsdk_version وrelease وtrace_id وevent_id
وdiagnostics. احذف project_id عندما لا تخص المشكلة مشروعًا معيّنًا. ويجب أن
يحدد project_id مشروعًا نشطًا في حسابك.
يُرجع الطلب الناجح HTTP
200:
sup_. استخدم next إرشادًا للشخص، وnext_action للتحكم
في البرنامج.
لحذف مشروع، استخدم إعدادات المشروع أو logbrew projects delete. لا تطلب حذف مشروع
في تذكرة دعم.
كتابة بلاغ مفيد
- أبلغ عن مشكلة واحدة في كل تذكرة.
- اختر أقرب
category. لا تستخدمotherإلا عندما لا تناسب أي فئة. - اذكر في
titleعَرَضًا واحدًا وواجهة واحدة. - اكتب
descriptionفي صورة خطوات، ثم النتيجة المتوقعة والنتيجة الملاحَظة. - أضف معرّفات المشروع أو الإصدار أو التتبّع أو الحدث فقط عندما تحدد العطل نفسه.
diagnostics التالية:
diagnostics كائن JSON بحجم يصل إلى 16 KB بعد الحجب. يستبدل LogBrew القيمة
بـ [redacted] عندما يدل مفتاحها على بيانات اعتماد أو جلسة أو عنوان بريد
إلكتروني. ويستبدل أيضًا النص الذي يشبه بيانات اعتماد أو عنوان URL أو مسارًا محليًا.
ويقصّر LogBrew كذلك النصوص الطويلة، ويحدّ من التداخل والمفاتيح وعناصر القوائم. لا
تعتمد على هذا الحجب. أزل البيانات الخاصة قبل أن ترسل الطلب.
متابعة التذكرة
تقبل القائمة
project_id وstatus وsource وcategory وrelease
وlimit. القيمة الافتراضية لـ limit هي 100، والحد الأقصى 500. لترقيم الصفحات
بالمؤشر، أرسل pagination=cursor. في الصفحات التالية، كرر عوامل التصفية نفسها،
وأرسل cursor_time وcursor_id من next_cursor. معرّف المؤشر هو معرّف تذكرة يبدأ
بـ sup_. توقف عندما تكون قيمة next_cursor هي null. يستخدم CLI الخيارات
--project و--status و--source و--category و--release و--limit
و--pagination و--cursor-time و--cursor-id.
قيم الحالة هي open وrouted وin_progress وwaiting_on_user
وresolved وclosed. يمكنك ضبط open أو closed فقط. طلب الإغلاق أو إعادة
الفتح المكرر ينجح دون أن يغيّر شيئًا، لذلك يمكنك إعادة الطلب نفسه تمامًا. اتبع
الحالة المُرجَعة وnext_action:
إضافة السياق المطلوب
ردّ عندما تطلب التذكرة سياقًا. تكون حالة هذه التذكرةwaiting_on_user، وقيمة next_action.code هي provide_context.
context وdiagnostics الاختياري. يجب أن يحتوي نص
context على 1 إلى 4,000 حرف. لا تضع بيانات اعتماد أو عناوين URL أو أسماء مضيفين
أو مسارات محلية في context. يرفض الـ API هذا النص مع 422. أرسل مفتاح إعادة
محاولة في الترويسة Idempotency-Key، فمسار السياق يتطلب هذه الترويسة. يتكون
المفتاح من 1 إلى 128 حرف ASCII مرئيًا، بلا مسافات. استخدم مفتاحًا جديدًا لكل رد،
ولا تُعِد استخدام المفتاح إلا لإعادة محاولة الرد نفسه.
يقبل الـ API السياق ما دامت التذكرة open أو routed أو in_progress أو
waiting_on_user. ويقبل ردًا واحدًا لكل حالة من حالات التذكرة. بعد الرد، انتظر
تغيّر الحالة قبل أن ترسل مزيدًا من السياق. الرد على تذكرة حالتها
waiting_on_user يضبط حالتها على open. اقرأ status المُرجَعة بدلًا من افتراض
هذا التغيير.
يُرجع الرد الناجح ticket_id وcontext_id وstatus وcreated_at
وnext وnext_action. يبدأ context_id بـ ctx_. اقرأ التذكرة مرة أخرى قبل
أن تجيب عن أي طلب لاحق.
يُرجع GET /api/support/tickets/{ticket_id}/context أحدث 20 إدخال سياق، من الأقدم
إلى الأحدث. لكل إدخال context_id وcontext
وdiagnostics وcreated_at. هذه القائمة بلا مؤشر.
الرد على تذكرة حالتها resolved أو closed يُرجع 422 مع
code: "validation_failed". لا تُعِد فتح التذكرة إلا إذا أراد المستخدم متابعة طلب
الدعم هذا. لا يمنح next_action الوكيل إذنًا بتغيير حالة الحساب.
التعافي من الأخطاء
تحتوي استجابات الأخطاء على
error وcode وnext وnext_action. راجع
أخطاء API.
