لقد كنا نستخدم روابط الدعوة لمساعدة المستخدمين على الانتقال بين المنصات والانخراط في المناقشات؛ ومع ذلك، فإن المطالبة الجديدة التي بدأت تظهر مع آخر تحديث للمنصة تسبب التأخير والارتباك.
المستخدمون الذين يستخدمون رابط دعوة يعيد توجيههم إلى منشور موضوعي لا يمكنهم استخدام الرابط مرة واحدة فقط، وهي مشكلة رئيسية إذا كنا نتوقع منهم استخدام الرابط في كل مرة يرغبون فيها في زيارة المنشور الموضوعي. من المهم أن نتمكن من إعادة توجيه المستخدمين باستخدام نفس رابط الدعوة عدة مرات يرغب المستخدم في إعادة زيارة الموضوع، ووجود هذه الميزة محظورة بواسطة المطالبة الجديدة يسبب مشكلة.
ظهرت مشاكل تقنية أخرى أيضًا. أولاً وقبل كل شيء، يستغرق الأمر خمس ثوانٍ على الأقل حتى يستجيب “قبول الدعوة” للنقر، ثم يستغرق الأمر بعض الوقت لإعادة توجيه المستخدم إلى الموضوع. ثانيًا، مع هذه الإضافة الجديدة، يستغرق الأمر وقتًا أطول لتحميل المطالبة أولاً. ثالثًا، حتى لو كنت قد نقرت على رابط الدعوة من قبل وقبلت الدعوة، فسيستمر في مطالبتك في كل مرة تنقر فيها على الرابط!
لتكرار هذه المشكلة، قم بإنشاء رابط دعوة يعيد توجيه المستخدمين إلى منشور موضوعي و/أو يضيفهم إلى مجموعة. انقر على رابط إعادة التوجيه أثناء تسجيل الدخول إلى حساب المنصة.
من فضلك، هل هناك طريقة لتعطيل هذه المطالبة من الإعدادات؟ هذا أمر عاجل ومهم لأن هذا سيؤثر على تجربة المستخدم.
قد لا يلاحظ الآخرون الذين يعتمدون على روابط الدعوة ولكنهم غير مدركين لهذا التغيير الجديد لأن هذا التغيير لم يتم الإعلان عنه، شكرًا!
أود أن أضيف أن هناك خطأ هنا أيضًا وفي حالة الاستخدام الخاصة بنا، لا نحتاج إلى المطالبة في المقام الأول، فهل سيكون من الممكن إزالته؟ أو إعطاء خيار في إعدادات المسؤول لتعطيله؟
الخطأ هو أنه إذا نقرت على “قبول الدعوة” للمرة الثانية، فستظل الصفحة ثابتة ولن تعرض أي رسالة. هذا غير مفيد على الإطلاق. إنه يمنع المستخدم من استخدام السياق السابق لإعادة توجيهه إلى الموضوع مرة أخرى. هذه مشكلة كبيرة. إذا وضعت رابط دعوة في مستند وتوقعت أن القارئ قد يستخدم نفس الرابط مرارًا وتكرارًا لإعادة توجيهه إلى الموضوع، فلن يعمل رابط الدعوة بعد الآن.
نحن نستخدم روابط الدعوة لأن المشارك يحتاج إلى إضافته إلى فئة خاصة أولاً ليكون قادرًا على قراءة الموضوع. إذا احتاج المستخدم إلى العثور على الموضوع مرة أخرى، فيجب أن يكون قادرًا على استخدام نفس رابط الدعوة. في هذه الحالة، يجب أن يقبل الدعوة تلقائيًا إذا كان المستخدم مسجلاً الدخول لأن الدعوة مخصصة لهذا المستخدم وكما عملت بشكل جيد سابقًا، يجب أن تعيد توجيه المستخدم إلى المنشور المقصود في الموضوع.
لقد عملت روابط الدعوة بشكل مثالي من قبل. آمل أن تتمكن من إلقاء نظرة أخرى على هذا وإعطاء المسؤول خيار تعطيل هذه المطالبة/رسالة زر “قبول الدعوة”. شكرا لك!
لا يمكنني إعادة إنتاج تأخير الخمس ثوانٍ هذا. تم اختباره هنا على ميتا باستخدام دعوات متعددة، سواء بإضافة إلى مجموعة أو بدونها. إذا رأيت هذا التأخير في كل مرة، هل يمكنك تجربته في المرة القادمة مع فتح أدوات المطور في علامة التبويب console ومعرفة ما إذا كانت هناك أي أخطاء مبلغ عنها هناك؟
يمكنني إعادة إنتاج هذا، يبدو أن هناك تراجعًا هنا، وسنقوم بإصلاح هذا قريبًا.
لا يمكنني رؤية أي أخطاء في وحدة تحكم Firefox، ولكن عندما أحاول في Chrome، أحصل أحيانًا على هذه الأخطاء.
includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234
discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940
SyntaxError: Unexpected token '<', "<html>
<h"... is not valid JSON
at Function.parse [as parseJSON] (<anonymous>)
at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
من فضلك، رسالة المطالبة ليست مفيدة في حالة الاستخدام الخاصة بنا، هل هناك طريقة للمسؤول لإنشاء روابط دعوة دون هذا النوع من المطالبات؟
تُستخدم روابط الدعوة في دورة تدريبية حيث تتم دعوة المشاركين للانضمام إلى منتديات المناقشة. كل ما نريده من رابط الدعوة هو إضافة المستخدم إلى مجموعة وإعادة توجيهه إلى موضوع في فئة خاصة (دون الحاجة إلى النقر على “قبول الدعوة” في كل مرة يستخدمون فيها رابطًا)، وبعد النقرة الأولى يُتوقع أن يتمكن المستخدمون من العودة إلى الموضوع باستخدام نفس رابط الدعوة. لقد كان هذا يعمل بسلاسة وبشكل مثالي حتى تم فرض رسالة المطالبة بين عشية وضحاها.
لقد شرحت كيف نستخدم روابط الدعوة في موضوع آخر
@tobiaseigen@dan@JammyDodger ، من فضلكم ساعدوني في هذا. يجب أن نتمكن من التخلص من رسالة المطالبة في حالة الاستخدام الخاصة بنا.
مرحباً @gassim، لقد ناقشنا هذا داخليًا. عذرًا، ولكن سلوك قبول نفس الدعوة عدة مرات لنفس المستخدم للعمل كإشارة مرجعية غير متوقع، وسنقوم بإصلاح هذا لإخفاء زر “قبول الدعوة” إذا كان المستخدم المسجل قد قبل الدعوة بالفعل. بدلاً من ذلك، سنعرض رسالة تخبر المستخدم بأنه قد استلم بالفعل رابط الدعوة.
كان القبول التلقائي للدعوة عند فتح الصفحة مشكلة أمنية، ولهذا السبب قمنا بالتغيير لوجود صفحة “قبول الدعوة” الفاصلة بدلاً من ذلك.
إذا كان من الضروري للمستخدم العودة إلى نفس الموضوع، نقترح عليه وضع إشارة مرجعية له. أو، إذا كان لديك بعض المستندات الداخلية التي تضع فيها رابط الدعوة، أضف رابطًا إلى الموضوع في نفس المكان للراحة.
مرحباً @martin، شكراً لك وفريق discourse على الاهتمام. نحن نناقش حلولاً بديلة في الوقت الحالي.
نعم، من فضلك وسيسعدنا معرفة متى تم إصلاح هذه المشكلة.
مفهوم… كنت آمل أن يُمنح المسؤولون خيارًا عند إنشاء رابط الدعوة لاختيار ما إذا كانت الرسالة التنبيهية تُستخدم أم لا (ربما مع تحذير بشأن ما يمكن أن يحدث إذا لم يستخدموا الرسالة التنبيهية). نحن ندرك أنه بدون الرسالة التنبيهية، يمكن لأي شخص الوصول إلى المجموعة/الفئة الخاصة ولكن في حالة استخدامنا، لا يمثل ذلك مشكلة لأنها ليست مجموعات/فئات “سرية”، إنها خاصة للحفاظ عليها منفصلة كمساحات مخصصة لمناقشة مواضيع الدورة التدريبية بالطبع.
ليس من السهل مطالبة المشاركين في الدورة التدريبية بوضع علامة مرجعية على الموضوع، ولكن الاقتراح الأخير يبدو خيارنا الوحيد الآن والإجراء الفوري الذي يمكننا اتخاذه لإصلاح المشكلة.
أوه، هذا قيد مثير للاهتمام. لذا لديك Discourse به 1000 غرفة يمكن لأي شخص الوصول إليها ولكنك تريد أن يكون لأعضاء الدورة التدريبية ارتباط قوي بالغرفة المحددة.
بعض الأسئلة:
ما هي القيمة في عدم استخدام الأمان هنا؟ هل latest مجرد كمية هائلة من الضوضاء للمستخدم العادي؟ لدينا أيضًا إعداد “بشكل افتراضي يتم كتم جميع الفئات من latest” قد يكون مثيرًا للاهتمام.
هل يمكن لشريط الشريط الجانبي تخفيف الألم قليلاً؟ إذا كانت لديك الفئة في الشريط الجانبي الخاص بك، فعلى الأقل يتم الإشارة إليها. ربما يجب أن يسمح الدعوة أيضًا بالإضافة إلى الشريط الجانبي؟ لست متأكدًا؟
هل سيساعد توضيح الأمور بشكل أفضل في موضوع الترحيب؟ للعثور على منزلك، يرجى وضع إشارة مرجعية على ما يلي وإضافته إلى الشريط الجانبي، إليك الخطوات
أعتقد أن علينا جميعًا قبول قيود بعضنا البعض على المدى القصير.
نظرًا لأنه يبدو أن @gassim كان لديه نظام معمول به وكان يعمل بشكل جيد بالنسبة لهم، أعتقد أن تقديم بعض الإرشادات هنا التي تظل قريبة قدر الإمكان من ذلك هو الأفضل على الأرجح. استمر في استخدام المجموعات لتقييد الوصول إلى فئات معينة والحد من الضوضاء من أماكن أخرى.
نحن مهتمون بتنظيف بعض الجوانب غير المصقولة في نظام الدعوات لدينا لجعله أكثر قابلية للصيانة والفهم، وأتوقع أن نواجه مشكلات كهذه على طول الطريق أثناء قيامنا بذلك. في هذه الحالة، نصر على عدم الاعتماد على روابط الدعوة كروابط مواضيع قابلة لإعادة الاستخدام.
بعد قراءة الموضوع السابق، أعتقد أن ما قد يكون منطقيًا هو القيام بشيء مثل ما يلي:
استبدل روابط الدعوة لكل دورة بروابط مباشرة إلى الموضوع.
بالقرب من هذه الروابط، قم بتضمين رابط دعوة عام. “ليس لديك حساب بعد؟ انقر هنا لإنشاء حساب والانضمام إلى المجموعة”
اجعل رابط الدعوة يوجه إلى موضوع أكثر عمومية ويعلم المستخدم بالعودة إلى دورته والانضمام إلى الموضوع الخاص بالدورة من هناك.
الغرف التي يتم الاحتفاظ بها خاصة هي للمشاركين في الدورة. بشكل أساسي ، نريد أن تكون هذه الغرف مساحة مخصصة دون التأثير على بقية نشاط المنتدى (الأحدث ، الأعلى … إلخ). إن وجود منتديات مناقشة الدورة في فئات خاصة ليس بسبب أنها “سرية” ولكن لأن أولئك الذين يختارون التسجيل في الدورة فقط يحتاجون إلى رؤية الموضوعات والمناقشات بينما يمكن للآخرين الذين لا يفعلون ذلك الاستمرار في استخدام بقية الموقع كالمعتاد.
شكرا على الاقتراح! لم أجرب الشريط الجانبي بعد ، ولكن إليك كتابة مجانية حول سبب عدم ترقيتي للشريط الجانبي بعد:
تعرض الصفحة الرئيسية بالفعل عمودين: الفئات في عمود ، والأحدث في عمود آخر ؛ وجود الشريط الجانبي يبدو تكرارًا في الصفحة الرئيسية (لا توجد طريقة لإبقائه مغلقًا في الصفحة الرئيسية؟)
يبدو الشريط الجانبي أنه يعطي اهتمامًا أكثر من اللازم للرسائل الخاصة ولا نشجع استخدام الرسائل الخاصة كثيرًا.
على عكس الاعتقاد بأن هذا سيخفف الألم ، سيبدو الشريط الجانبي بمثابة إلهاء للمشاركين في الدورة الذين ينضمون إلى الفئة الخاصة لأننا لا نريد أن تظهر الفئات الأخرى أثناء مشاركتهم. (لا يوجد خيار لتعطيل الشريط الجانبي في بعض الفئات؟)
إذا كان هناك خيار للمسؤول لتخصيص الشريط الجانبي لكل “مجموعة” بحيث يرى المشاركون في المجموعة أ أشياء ذات صلة بالمجموعة أ بينما ترى المجموعة ب أشياء ذات صلة بالمجموعة ب ، فسيساعد ذلك في تخفيف الألم. السبب في ذلك هو أننا لا نتوقع من جميع المستخدمين التعامل مع الموقع كما لو كان حساب بريدهم الإلكتروني وقضاء الوقت في تعلم تخصيصه ؛ من ناحية أخرى ، نحتاج إلى الترحيب بهم حيث سيشعرون بالراحة بالفعل ويستفيدون مباشرة من التجربة دون الحاجة إلى قضاء الوقت في تعلم التخصيص … إلخ. لذا إذا كان بإمكاننا تخصيصه مسبقًا لكل مجموعة ثم لديهم خيار تغييره ، فسيكون ذلك رائعًا (بالإضافة إلى خيار عدم عرضه في الصفحة الرئيسية - افتراضيًا يجب إخفاؤه في الصفحة الرئيسية ، ربما يمكن أن يصلح رمز CSS هذا ولكن ماذا عن فئات معينة)
لست متأكدًا لأنه سيكون هناك 50 موضوعًا على الأقل للمشاركين الذين يسجلون في جميع الدورات. ومع ذلك ، نحن نستخدم اقتراح @martin:
شكرا على الاقتراح @Stephen! ومع ذلك ، فإن الصفحة الرئيسية لجميع الأعضاء ونحن لا نريد تغيير ذلك. سيشارك المشاركون في الدورة في عدة دورات ولكن بعد كل دورة تتم دعوتهم للاستمرار في المشاركة في المجتمع.
مفهوم، ولكن بعد ذلك كان هذا خيار المسؤول لجعله رابط الدعوة ينتهي بعد عدد معين من الاستخدامات أو بعد تاريخ معين (بالإضافة إلى تقييده بفئات بريد إلكتروني محددة.) بالنسبة لنا لأننا لم نرغب أبدًا في انتهاء صلاحية رابط الدعوة، كان تاريخ انتهاء الصلاحية هو 2092 وعدد الاستخدامات كان 1000000 (وبالطبع لم نحدد قائمة عناوين البريد الإلكتروني لأننا أردنا أن يظل رابط الدعوة مفتوحًا لأي شخص يريد بالفعل الانضمام إلى موضوع المناقشة في الفئة الخاصة!) ومع ذلك، لا يمكنني الآن رؤية كيف ستكون هذه الخيارات مفيدة عندما ينتهي رابط الدعوة على أي حال بعد الاستخدام الأول لكل مستخدم فردي.
شخصيًا، ما زلت أعتقد أنه إذا تم فرض ذلك بشكل مختلف عن طريق إضافة خيار أثناء إنشاء رابط الدعوة الذي يشبه القيود المذكورة أعلاه (بشكل افتراضي، لن يكون رابط الدعوة قابلاً لإعادة الاستخدام إلا إذا ألغى المسؤول تحديد هذا الخيار وبمجرد إلغاء تحديده، سيكون هناك تحذير بشأن مشكلة الأمان التي يقلق فريق discourse بشأنها.) لكان ذلك قد جعل كل شيء أسهل بكثير من وجهة نظري.
