هذه مشكلة اتصال لا مشكلة تصريح. الوصول سليم؛ لكن المتجر لم يُجب في الوقت، أو لم يُجب أصلاً. | ما تراه | الرمز وراءه | ما يعنيه بدقة | |---|---|---| | «متجرك لم يُجب» | STORE_UNAVAILABLE | فشل الاتصال، أو أرجع المتجر خطأ 5xx | | «متجرك استغرق وقتاً طويلاً للإجابة» | TIMEOUT | أُرسل الطلب ولم تصل إجابة داخل الحد | ما يفعله المنتج دون أن تطلبه - ينتظر مدة محدودة. ثلاث ثوانٍ للاتصال، وثماني ثوانٍ للإجابة، وعشر ثوانٍ لكامل المحتوى. المتجر البطيء يكلّف انتهاء مهلة واحدة، لا صفحة معلّقة. - يعيد المحاولة مرة واحدة، وللقراءة فقط. الاتصال المنقطع أو خطأ 502 أو 503 أو 504 في قراءة يُجرَّب مرة أخرى. وانتهاء المهلة لا يُعاد، فلا يُزاد المتجر البطيء بطئاً بسببنا. وإجراء الطلب لا يُعاد أبداً، لأن إرسال استرداد مرتين أسوأ من الإبلاغ عن فشل واحد. - يعرض لك ما لديه بالفعل. إن استطاعت اللوحة تقديم سجل طلبات مخزّن فستفعل، مع بيان وقت آخر تحديث. اللوحة التي تقول «آخر تحديث قبل ٤٠ دقيقة» تقول الحقيقة بدل أن تتظاهر بأنها لحظية. - لا يغيّر حالة المتجر. المتجر الذي لا يمكن الوصول إليه يبقى active، لأن تعذّر الوصول مؤقتاً ليس مثل فقدان التصريح. ما تتحقق منه، بالترتيب 1. افتح المتجر بنفسك في المتصفح من اتصال إنترنت عادي. إن كان بطيئاً أو متوقفاً عندك فهو كذلك عندنا. 2. ووكومرس فقط: تأكد أن المتجر متاح من الإنترنت العام. المتجر خلف شبكة خاصة أو على عنوان محلي لا يمكن لشيء خارجه الوصول إليه، والمنتج يرفض المحاولة — راجع عنوان المتجر مرفوض. 3. تحقق من استضافتك: حدّ معدل أو قاعدة جدار حماية. الاستضافة التي تحجب حركة غير مألوفة ترفضنا باستمرار بينما يعمل المتصفح، وهذا النمط هو أكثر ما يشبه عيباً في المنتج وليس عيباً فيه. 4. تحقق إن كان بطيئاً تحت الحمل فقط. المتجر الذي يُجيب في اثنتي عشرة ثانية يعمل من وجهة نظره، وسينتهي وقته هنا في كل مرة. وهذا يحتاج إصلاح الاستضافة لا إصلاح الربط. عندما يزول لا شيء يلزم فعله. أول طلب ناجح يعيد تقديم بيانات حيّة، وتتوقف اللوحة عن قول إنها قديمة. ولا ذاكرة مؤقتة تُفرَّغ يدوياً.

حل المشكلات

متجرك يحتاج إلى إعادة ربط

المتجر في هذه الحالة توقف عن العمل تماماً: سجل الطلبات لا يُحمَّل في المحادثة، والسلات المتروكة تتوقف عن الوصول، وإجراءات الطلبات غير متاحة. والمنتج لا يعيد المحاولة في الخلفية، لأن إعادة المحاولة بوصول رفضه المتجر لن تفيد. المدير وحده يصلحها، وبإجراء واحد: الإعدادات ← التجارة ← المتجر ← إعادة الربط. ما يقوله لك المنتج | ما تراه | الرمز وراءه | |---|---| | «هذا المتجر يحتاج إلى إعادة ربط» في الإعدادات ← التجارة | حالة المتجر needs_reauth | | «لم نتمكن من الوصول إلى متجرك» في لوحة المحادثة | AUTH_INVALID | الحالة دائمة: كُتبت لحظة رفض المتجر للوصول، وتبقى حتى يعيد أحد ربطه. وليست تخميناً من طلب فاشل واحد. لماذا يحدث السبب يختلف بحسب المنصة، ويستحق المعرفة لأن اثنين منها قد يحدثان دون خطأ من أحد. - ووكومرس — حُذف مفتاح الواجهة البرمجية، أو تغيّرت صلاحياته، في ووردبريس ← ووكومرس ← الإعدادات ← متقدّم ← REST API. وهذا هو السبب المتعمَّد عادةً: أحدهم رتّب المفاتيح. - سلة — أُزيل التطبيق أو انقضى تصريحه في لوحة سلة. إعادة تثبيت التطبيق تعيد ربط المتجر وحدها، ولا تحتاج إلى إنشاء رمز ربط جديد إلا إذا كان المتجر قد اختفى من القائمة أيضاً. - زد — انتهى التصريح أو أُزيل التطبيق. وزد تُجيب أحياناً على تصريح مرفوض بإعادة توجيه إلى صفحة الدخول بدل رفض صريح، والمنتج يقرأ ذلك على أنه تصريح مرفوض، وهي القراءة الصحيحة. - شوبيفاي — أُزيل التطبيق من لوحة المتجر، أو سُحب الوصول الممنوح له. ما يُحفَظ وما يُحذَف إعادة الربط لا تبدأ بك من الصفر، وفصل المتجر لا يحذف تاريخك: - يُحذَف وصول المتجر عند انتقاله إلى هذه الحالة، وكذلك بياناته المخزّنة مؤقتاً، ولهذا تَفرُغ اللوحات بدل أن تعرض شيئاً قديماً؛ - تبقى المحادثات وجهات الاتصال وسجل إجراءات الطلبات. فهي سجلات لينوميا نفسها، لا سجلات المتجر؛ - المتجر الذي تفصله يحفظ صفّه، فإعادة ربط المتجر نفسه لاحقاً تستخدمه مرة أخرى بدل أن يُحسَب على حد خطتك مرتين. إذا لم تصمد إعادة الربط إذا رجع المتجر إلى هذه الحالة بعد دقائق من إعادة الربط، فالوصول الذي منحتَه ليس الوصول الذي يحتاجه المنتج — اتصل ثم رُفض في أول طلب حقيقي. وهذه مشكلة صلاحيات لا مشكلة تصريح: راجع مفاتيح متجرك لا تستطيع ذلك.

حل المشكلات

عنوان المتجر مرفوض

هذا يُرفض قبل أن يخرج أي طلب من لينوميا، أو بمجرد أن يُجيب المتجر بإعادة توجيه. وينطبق على ووكومرس، وهي المنصة الوحيدة التي تكتب فيها عنواناً — أما سلة وزد وشوبيفاي فتقدّم عناوينها بنفسها. | ما تراه | لماذا | |---|---| | «هذا العنوان ليس متجراً نستطيع الوصول إليه» | المستضيف يُحَل إلى عنوان خاص أو محلي أو عنوان بيانات وصفية | | «هذا العنوان غير صالح» | العنوان ليس رابط https صالحاً | | «هذا المتجر أعاد توجيهنا إلى مكان آخر» | أجاب المتجر بحالة 3xx | قاعدة العنوان الخاص متعمَّدة، وهي تحميك كل طلب إلى متجر يَحُلّ المستضيف أولاً، ويرفض العناوين الخاصة والمحلية وعناوين البيانات الوصفية، ثم يثبّت الاتصال على العنوان الذي تحقّق منه — فلا يستطيع شيء أن يُجيب على التحقق بعنوان عام ثم يخدم الطلب من مكان داخلي. ولهذا يُرفض http://localhost وhttp://192.168.x.x وhttp://10.x.x.x والمستضيف المنتهي بـ .local كلها. المتجر على جهازك أو شبكة مكتبك لا يمكن ربطه: فهو غير متاح من الإنترنت، والعنوان الذي يُحَل إلى مكان داخلي هو بالضبط شكل الطلب الذي وُجدت هذه القاعدة لرفضه. استخدم عنوان المتجر العام الحقيقي، العنوان الذي يكتبه العميل. إعادة التوجيه لا تُتبَع أبداً إن كان متجرك يُجيب على https://shop.example.com بإعادة توجيه إلى https://www.shop.example.com، فإعادة التوجيه تُرفض بدل أن تُتبَع، وسترى رسالة إعادة التوجيه. أدخل العنوان الذي يخدم منه المتجر فعلاً — الذي تنتهي إليه بعد إعادة التوجيه — وتزول المشكلة. وعدم اتباع إعادة التوجيه متعمَّد: إعادة توجيه متبوعة تعني أن الطلب التالي يذهب إلى مستضيف لم يتحقق منه أحد. ما تُدخله - المخطط: https. المتجر على http لا يمكن ربطه إلا إذا أدرج مدير هذا التركيب مستضيفه صريحاً كمتجر تطوير؛ - المستضيف الذي يخدم منه المتجر، بعد أي إعادة توجيه؛ - بلا مسار: ليس /wp-json ولا /wp-admin ولا صفحة في النهاية. المنتج يضيف مسار الواجهة البرمجية بنفسه. إذا كان العنوان صحيحاً ومع ذلك يُرفض فالمشكلة ليست في العنوان. المتجر الذي يُجيب على العنوان الذي أدخلتَه لكنه يرفض الطلب هو مشكلة اتصال أو صلاحيات — راجع لينوميا لا تستطيع الوصول إلى متجرك ومفاتيح متجرك لا تستطيع ذلك.

حل المشكلات

إجراء طلب لم يُطبَّق

إجراء الطلب — إلغاء طلب، أو تغيير حالته، أو إصدار استرداد — هو الشيء الوحيد الذي تكتبه لينوميا في متجرك. وكل سلوكه ينبع من قاعدة واحدة: الكتابة لا تُرسَل مرتين أبداً. فاسترداد مكرر أسوأ من فشل تراه. كل نتيجة وما تفعله | ما تراه | الرمز | ما حدث فعلاً | ما تفعله | |---|---|---|---| | «تغيّر الطلب وأنت تنظر إليه» | ORDER_CHANGED | غيّر شخص آخر الطلب بين تحميل اللوحة وإرسال الإجراء | أعد فتح الطلب وحاول على حالته الحالية | | «لم يُطبَّق ذلك» | NOT_APPLIED | قَبِل المتجر الطلب والطلب لم يتغيّر بالدليل | آمن أن تحاول مرة أخرى | | «متجرك رفض الاسترداد» | REFUND_DECLINED | رفضت بوابة الدفع، لا المتجر | استرِد من لوحة المتجر نفسها حيث يظهر سبب البوابة | | «متجرك رفض ذلك» | PROVIDER_REJECTED | رفض المتجر الإجراء نفسه | راجع الطلب في لوحة المتجر؛ يكون عادةً في حالة لا تسمح به | | «هذا الإجراء يعمل بالفعل» | ACTION_IN_PROGRESS | الإجراء نفسه جارٍ | انتظر؛ لا تبدأ ثانياً | | «هذا المبلغ غير صالح» | INVALID_AMOUNT | المبلغ خارج ما يسمح به الطلب | راجع إجمالي الطلب وما استُرد منه | | «لا نعرف إن طُبِّق ذلك» | نتيجة غير معروفة | أُرسل الطلب وفُقدت الإجابة | اقرأ بقية هذه الصفحة | | «إجراءات الطلبات معطّلة» | ACTIONS_DISABLED | المفتاح معطّل لهذا المتجر | المدير يشغّله في الإعدادات ← التجارة | | «هذا الإجراء غير متاح لهذا المتجر» | ACTION_UNAVAILABLE | المنصة لا تدعمه | لا شيء؛ هذه قدرة لا خطأ | «لا نعرف» إجابة صادقة لا عيب إن وصل الطلب إلى متجرك وفُقدت الإجابة — انتهت المهلة بعد الإرسال، أو انقطع الاتصال — فلينوميا لا تستطيع فعلاً أن تعرف إن طُبِّق الإجراء. ولن تخمّن، ولن ترسل الإجراء مرة أخرى لتعرف. وما تفعله بدلاً من ذلك: 1. تقرأ الطلب من جديد، بعد قليل، وتحكم بما يقوله المتجر الآن فقط. فإن كان الطلب في الحالة التي طلبها الإجراء فقد نجح. وإن كان بالدليل في حالته الأصلية فقد فشل وإعادته آمنة. 2. وإن لم تحسم إعادة القراءة الأمر، يبقى الإجراء مسجّلاً كغير معروف، وتقول اللوحة ذلك. 3. ولا تعيد الإرسال أبداً. الإجراء الذي قد يكون طُبِّق لا يرسله المنتج ثانية بأي حال. وإن بقي إجراء على «غير معروف» فافتح الطلب في لوحة متجرك. فهذه هي الإجابة الموثوقة، وتأخذ ثوانٍ. لماذا الإجراءات بقرار لا بتسهيل - معطّلة لكل متجر حتى يشغّلها مدير؛ - تحتاج بيانات تستطيع الكتابة — راجع مفاتيح متجرك لا تستطيع ذلك؛ - تُفحَص مقابل الطلب كما رآه الموظف، وهذا ما ينتج ORDER_CHANGED بدل مفاجأة؛ - وكل إجراء يُسجَّل بمن نفّذه وبما أجاب به المتجر. وهذه أربع فرص لرفض إجراء، وكل رفض جملة لا صمت.

حل المشكلات

مفاتيح متجرك لا تستطيع ذلك

المتجر قد يكون مربوطاً ومتاحاً ويعمل — ومع ذلك يرفض شيئاً. فقراءة الطلبات وتغييرها صلاحيتان مختلفتان في كل منصة، ولينوميا لا ترفع الوصول الذي منحتَه بصمت أبداً: المدير يمنحه بقرار أو يبقى كما هو. | ما تراه | الرمز وراءه | |---|---| | «متجرك رفض ذلك» | PERMISSION_DENIED | | «هذه المفاتيح لا تستطيع تغيير الطلبات» | WRITE_ACCESS_DENIED | | «هذا المتجر غير معتمد لبيانات العملاء» | PROTECTED_DATA_NOT_APPROVED | | إجراءات الطلبات معطّلة، مع سبب | read_only_key أو missing_scope | القراءة والكتابة منحتان مختلفتان - ووكومرس — يُنشأ مفتاح الواجهة البرمجية بصلاحية قراءة أو قراءة وكتابة. ومفتاح القراءة مناسب تماماً إن أردت سجل الطلبات في المحادثات فقط. أما إجراءات الطلبات فتحتاج قراءة وكتابة، والمنتج لا يتظاهر بغير ذلك: يسجّل read_only_key أول مرة تُرفض فيها كتابة، ويعرض ذلك سبباً لعدم توفر الإجراء. ولتغييره أنشئ مفتاحاً جديداً بقراءة وكتابة في ووردبريس ← ووكومرس ← الإعدادات ← متقدّم ← REST API واستبدل المفاتيح في الإعدادات ← التجارة. فصلاحيات مفتاح قائم لا تُرفع في مكانها. - شوبيفاي — تحتاج إجراءات الطلبات نطاق write_orders. وبدونه يسجّل المنتج missing_scope ويبلّغ أن الإجراء غير متاح بدل أن يحاوله. وإعادة ربط المتجر تطلب النطاقات من جديد. - زد — الشكل نفسه: المتجر الذي لا يشمل تصريحه إدارة الطلبات يسجّل missing_scope. - سلة — تطبيق لينوميا للقراءة فقط بحكم التصميم. وإجراءات الطلبات غير معروضة لسلة أصلاً، وهذه قدرة في التكامل لا مشكلة في متجرك. بيانات عملاء شوبيفاي المحمية تشترط شوبيفاي اعتماد التطبيق قبل أن يقرأ أسماء العملاء وبُرُدهم وأرقامهم. وحتى يتم ذلك الاعتماد يُربط متجر شوبيفاي ويعمل في كل شيء إلا تفاصيل العملاء، والمنتج يبلّغ أنه غير معتمد لا أنه فشل — لأنه ليس فشلاً، وليس شيئاً تصلحه من متجرك. ولإجراءات الطلبات مفتاح خاص بها أيضاً بمعزل عن المفاتيح، إجراءات الطلبات معطّلة افتراضياً لكل متجر. الإعدادات ← التجارة ← المتجر ← شغّل إجراءات الطلبات. وتشغيلها يحتاج بيانات تستطيع الكتابة أصلاً، ولهذا يرفض المفتاح بالسبب نفسه أعلاه إن كانت المفاتيح للقراءة فقط: فموافقة لا تفعل شيئاً بصمت أسوأ من رفض صريح. ما ليست هذه المشكلة إن كان المتجر لا يقرأ شيئاً على الإطلاق فالمشكلة ليست هذه — راجع متجرك يحتاج إلى إعادة ربط (الوصول ذهب) أو لينوميا لا تستطيع الوصول إلى متجرك (المتجر لم يُجب).

مساحة العمل والفريق

التوثيق والدعم

هذا التوثيق يخصّ لينوميا تشات. فالمنصّة هي من يكتبه ويبقيه محدّثاً وينشره لكل مساحات العمل دفعةً واحدة، بالعربية والإنجليزية. وحسابك يقرأه ولا يكتبه. وهذا مقصود. فمجموعة توثيق واحدة تعني إجابة واحدة لكل سؤال، الإجابة نفسها للجميع، تُحدَّث يوم يتغيّر المنتج. مساحة عملك لا تنشر مركز مساعدة لا تمنح لينوميا تشات مساحة العمل مركز مساعدة عاماً تكتبه بنفسها. فلا يوجد قسم «مركز المساعدة» في القائمة الجانبية، ولا مركز تُنشئه، ولا تصنيفات ولا مقالات خاصة بك، ولا موقع عام على نطاقك. والأمر نفسه عبر الواجهة البرمجية: نقاط النهاية الخاصة بالمراكز والتصنيفات والمقالات ترفض طلب مساحة العمل. وإن كانت مساحة عملك قد نشرت مركزاً قبل هذا التغيير، فلم يُحذف شيء مما لك، والصفحات التي يملك عملاؤك روابطها ما زالت متاحة. ما لم يعد بإمكانك فعله هو تعديلها أو الإضافة إليها أو إزالتها من هنا. اطلب ذلك ممن يدير التثبيت لديك إن احتجت إلى تغيير صفحة أو إزالتها. ما تفعله بدلاً من ذلك | إن أردت | افعل هذا | |---|---| | الإجابة عن السؤال نفسه مراراً | اكتب ردّاً جاهزاً وأدرجه بضغطة واحدة | | إعطاء العميل شيئاً يقرؤه | اربط صفحةً على موقعك أنت، أو الصق الإجابة | | إخبار فريقك بطريقة عملكم | استخدم ماكرو للخطوات، وويكي داخلياً خاصاً بكم للشرح | | أتمتة الإجابة بالكامل | ابنِ قاعدة أتمتة أو تدفّقاً | والردّ الجاهز هو أقرب شيء إلى مقالة مركز المساعدة في العمل اليومي: يُكتب مرة واحدة، ويُبحث عنه من صندوق الرد بكتابة /، ويحمل متغيّرات تملأ اسم العميل ورقم طلبه تلقائياً. أين تجد المساعدة | | أين | |---|---| | التوثيق | الصفحات التي تقرؤها. المساعدة والدعم ← التوثيق في القائمة الجانبية، أو /docs | | سجل الإصدارات | ما تغيّر في كل إصدار، على /changelog | | الدعم | المساعدة والدعم ← اتصل بالدعم في القائمة الجانبية | وكلاهما يُفتح في تبويب جديد، ويضبط عناوينهما من يدير التثبيت لديك، فالتثبيت الذاتي يشير إلى عناوينه هو. ملاحظة عن الأدوار لم يعد الدور المخصّص يعرض صلاحية إدارة قاعدة المعرفة، إذ لا توجد قاعدة معرفة لمساحة العمل تُدار. والدور الذي أُنشئ قبل هذا التغيير يحتفظ بالصلاحية في سجلّه، وهي لا تمنح شيئاً الآن — يمكنك تركها أو تعديل الدور لإزالتها، وفي الحالتين لا يتغيّر شيء مما يستطيع ذلك الشخص فعله. انظر الأدوار والصلاحيات. ذات صلة - الردود الجاهزة - الماكرو - الأدوار والصلاحيات إن لم ينجح الأمر رابط التوثيق أو اتصل بالدعم غير ظاهر. لم يضبط التثبيت عنواناً له. اسأل من يدير التثبيت لديك. أريد تعديل مقالة نشرتها مساحة عملي سابقاً. لا تستطيع ذلك من هنا. الصفحة نفسها ما زالت متاحة لعملائك، لكن التعديل والإضافة والإزالة صارت من عمل مدير التثبيت.

Guides for setting up and running Lynomia Chat.

تصفح حسب الموضوع

البداية

المحادثات

جهات الاتصال

الجماهير والحملات

واتساب

أخطاء واتساب

الأتمتة والروبوتات

المتجر

مساحة العمل والفريق

التكاملات

الإدارة

حل المشكلات

المقالات الشائعة

لينوميا لا تستطيع الوصول إلى متجرك

متجرك يحتاج إلى إعادة ربط

عنوان المتجر مرفوض

إجراء طلب لم يُطبَّق

مفاتيح متجرك لا تستطيع ذلك

التوثيق والدعم