راهنمای آناما
دسته‌ها

ساخت App، ثبت نسخه و ارسال برای بازبینی

مشخصات پیش‌نویس را وارد کنید، manifest و مجوزها را کنترل کنید، نسخهٔ تغییرناپذیر بسازید و نتیجهٔ بازبینی را دنبال کنید.

ساخت پیش‌نویس افزونه

در /panel/apps/developer پورتال توسعه‌دهنده برای ثبت مشخصات افزونه، افزودن نسخه و فرستادن آن برای بازبینی است. این صفحه محیط انتشار نهایی یا ویرایش بازارچه نیست؛ ثبت پیش‌نویس و ارسال برای بررسی تضمین نمی‌کند افزونه تأیید یا عمومی شود.

در فرم «ساخت App» این اطلاعات را وارد کنید:

  1. slug: شناسهٔ کوتاه و یکتای افزونه را با حروف لاتین و خط تیره بنویسید، مثلاً loyalty-plus. این شناسه در پیوندها و مسیر داخلی افزونه به کار می‌رود؛ بعد از انتخاب، نامی پایدار برگزینید.
  2. نام App: عنوانی بگذارید که کاربر در بازارچه می‌بیند.
  3. خلاصهٔ دقیق: یک توضیح روشن از مسئله‌ای که افزونه حل می‌کند و کاری که انجام می‌دهد بنویسید. ادعای دسترسی یا عملکردی که در نسخه وجود ندارد نکنید.
  4. دسته: نزدیک‌ترین موضوع را انتخاب کنید؛ گزینه‌ها شامل سایر، بازاریابی، تحلیل، Commerce، ERP و پشتیبانی‌اند.
  5. «ساخت Draft» را بزنید. اگر خطا آمد، slug، نام و خلاصه را بررسی کنید و پیام را در همین صفحه بخوانید.

پیش از ساخت، مشخص کنید افزونه در کدام بخش نمایش داده می‌شود، چه داده‌ای می‌خواند یا تغییر می‌دهد، چه سرویس بیرونی دارد و چه مجوزی واقعاً نیاز است. در بازارچه، این موارد در Trust Card و فهرست مجوزها بررسی می‌شوند؛ توضیح بازاریابی را با اثر واقعی افزونه هماهنگ نگه دارید.

افزودن نسخه و manifest

پس از ساخت، افزونه در بخش «Appهای من» با شناسه، وضعیت و نسخه‌های موجود دیده می‌شود. «نسخهٔ جدید» را بزنید تا ویرایشگر نسخه باز شود. شمارهٔ نسخه را در فیلد جداگانه و manifest را در ویرایشگر JSON وارد کنید. ابزار هنگام ثبت، JSON را تجزیه می‌کند و مقدار فیلد نسخه را با شماره‌ای که در بالای ویرایشگر نوشته‌اید جایگزین می‌کند؛ بنابراین شمارهٔ ثبت‌شده باید با manifest و بستهٔ واقعی افزونه سازگار باشد.

نمونهٔ آغازین صفحه، نسخهٔ 1.0.0 با runtime اعلانی، مجوز studio.render و یک افزونهٔ نمونه از نقطهٔ توسعهٔ Studio را بار می‌کند. این فقط اسکلت نمونه است؛ پیش از ثبت، کلید افزونه، محل افزودن، عنوان نمایشی، رابط، schema تنظیمات و مجوزهای لازم را با محصول واقعی خود جایگزین کنید. در manifest:

  • schema_version نسخهٔ ساختار manifest است.
  • version نسخهٔ افزونه است و هنگام ثبت با فیلد نسخه هماهنگ می‌شود.
  • runtime نوع اجرای افزونه را مشخص می‌کند؛ نمونهٔ صفحه declarative است.
  • permissions.required دسترسی‌های ضروری و permissions.optional دسترسی‌های اختیاری را فهرست می‌کند.
  • extensions نقطه‌ای را که افزونه به آن اضافه می‌شود و محتوای نمایشی یا منطق اعلانی را تعریف می‌کند.
  • settings_schema و configuration ساختار تنظیم‌های افزونه و نصب آن را توصیف می‌کنند.
  • required_capabilities قابلیت‌های پایه‌ای مورد نیاز را مشخص می‌کند.

نمونهٔ بالا را بدون بازبینی کپی نکنید. مجوزهای بیشتر از نیاز کاربر را در معرض خطر می‌گذارند و نقطهٔ توسعهٔ نامناسب ممکن است افزونه را در جای اشتباه نمایش دهد. JSON باید معتبر باشد؛ ویرگول اضافه، نقل‌قول نادرست یا ساختار ناقص باعث خطا می‌شود. «اعتبارسنجی و ثبت نسخه» را بزنید. در صورت خطا، پیام صفحه را بخوانید، JSON را اصلاح کنید و دوباره ثبت کنید.

نسخه‌ها بعد از ثبت به شکل فهرست نسخه و وضعیت نمایش داده می‌شوند. هر نسخه را یک انتشار تغییرناپذیر در نظر بگیرید: تغییر بعدی را در نسخهٔ تازه ثبت کنید و شماره‌گذاری را مطابق سیاست انتشار پروژه جلو ببرید، نه اینکه نسخه‌ای را بی‌ردپا جایگزین کنید.

ارسال برای بازبینی

دکمهٔ «ارسال Review» برای افزونه‌ای فعال می‌شود که دست‌کم یک نسخه داشته باشد. پیش از ارسال، یک بار دیگر نام، خلاصه، slug، manifest، مجوزها، نقطه‌های توسعه، رفتار تنظیم‌ها و نسخه را بررسی کنید. سپس درخواست بازبینی را ثبت کنید و نتیجه را از وضعیت همان افزونه بخوانید. اگر پیام بازبینی در review_notes آمده، هر نکته را در نسخهٔ بعدی اصلاح کنید و پس از ثبت نسخهٔ جدید دوباره برای بررسی بفرستید.

وجود نسخه و ارسال موفق صرفاً درخواست بازبینی را ثبت می‌کند؛ تأیید نهایی، نشان تأییدشده یا انتشار عمومی ممکن است پس از بررسی مستقل انجام شود. وضعیت و یادداشت بازبینی را مبنا بگیرید و نتیجه را از قبل قطعی اعلام نکنید.

خطا و دسترسی

اگر فهرست افزونه‌های شما بارگیری نشد، پیام خطا را نگه دارید و دوباره صفحه را باز کنید. اگر ساخت نسخه خطا می‌دهد، JSON معتبر، شمارهٔ نسخه و ساختار manifest را بررسی کنید. اگر «ارسال Review» غیرفعال است، افزونه باید دست‌کم یک نسخه داشته باشد. اگر ارسال رد یا نیازمند اصلاح شد، دلیل ثبت‌شده را دنبال کنید و در صورت نیاز از مسیر پشتیبانی توسعه‌دهندگان سؤال کنید.

برای پیگیری، slug یا شناسهٔ عمومی، شمارهٔ نسخه، وضعیت و متن یادداشت بازبینی را بفرستید؛ کلید خصوصی، رمز امضای انتشار یا اطلاعات محرمانهٔ کاربر را در manifest، خلاصهٔ افزونه یا تصویر پشتیبانی قرار ندهید.

این راهنما مفید بود؟بازخورد شما به بهترشدن راهنما کمک می‌کند.
ارسال بازخورد