مين يقدر يعدل إيه: صلاحيات الأونر والمانجر في الفريق

دورين بس، مفيش شاشة صلاحيات

افتح /admin/team بأي حساب غير الأونر نفسه، وهترجع على طول للوحة التحكم الرئيسية. الريدايركت ده بيحكي كل القصة: مفيش شاشة إعدادات فيها تربيعات لكل حاجة، "يقدر يعدل القائمة"، "يقدر يشوف الطلبات"، "يقدر يدير الفوترة". فيه أونر، وفيه مانجر، والنوع اللي بيحدد الاتنين في الكود عبارة عن كلمتين بس: 'owner' | 'manager'. الأونر هو اللي الـ uid بتاعه مطابق لحقل ownerId في التينانت. المانجر هو أي حد الأونر بعتله دعوة، وخلاص، مفيش طريقة يدخل بيها حد نفسه على حساب حد تاني من غير دعوة.

اللي بيفضل للأونر بس

فيه شوية صفحات وأفعال بتتشيك إنك أونر بالظبط، مش بس "حد عنده صلاحية". إدارة الفريق نفسها. الفوترة والاشتراك. مفتاح الـ API العام. إعداد الدومين المخصص. سجل التدقيق. إضافة أو حذف فرع. نسخ قائمة من فرع لفرع تاني، أو دفع تحديث قائمة لأكتر من فرع مرة واحدة. وشاشة التحليلات المجمّعة اللي بتجمع مرات المسح والزيارات من كل الفروع في رسم بياني واحد. ولا واحدة من دي بتتفتح مهما كان نطاق صلاحية المانجر، لأن السيرفر بيتشيك الدور نفسه على الطلبات دي، مش الفرع.

اللي المانجر فعلاً بيقدر يعمله

كل حاجة تانية في الفرع اللي محدد له: محرر القائمة، أسعار الأصناف، مفاتيح "خلص من المخزون"، مجموعات الإضافات، الطلبات، الحجوزات، الكوبونات، وإعدادات الثيم والتمبلت بتاعة صفحة الفرع ده العامة. الآلية كلها بترجع لدالة واحدة مشتركة اسمها resolveEditableTenantFromCookie، وكل نقطة كتابة في الـ API الخاص بلوحة التحكم بتناديها الأول قبل ما تعمل أي حاجة. الدالة بتحدد مين اللي بيطلب وعن أنهي تينانت، وبترجع إما أونر من غير أي قيود، أو مانجر ومعاه نطاق فرع. أي مسار محتاج يكون للأونر بس بيضيف سطر واحد فوق كده: لو الدور اللي رجع مش 'owner'، يرفض الطلب برسالة 403. باقي كل حاجة بتشتغل عادي على أي نطاق فرع راجع.

فرع واحد، أو كل الفروع

نطاق الفرع ده بيتحدد مرة واحدة، وقت الدعوة، وبيكون إما null (كل الفروع تحت الحساب) أو معرّف فرع بعينه. المانجر المحدد بـ null بيشوف كل فرع في قايمة اختيار الفروع بتاعته ويقدر يتنقل بينهم بحرية، زي إدارة أكتر من فرع تحت أونر واحد. المانجر المحدد بفرع واحد هيشوف الفرع ده بس في القايمة، خلاص، وحتى لو حصل معاه معرّف فرع تاني بأي شكل، السيرفر بيتشيك الفرع المطلوب مقابل النطاق المحفوظ ليه في كل طلب على حدة وبيرفض أي حاجة مش متطابقة. قايمة اختيار الفروع كمان بتخفي أزرار "إضافة فرع" و"إدارة الفروع" لأي حد مش الأونر، فالمانجر مش هيشوف دعوة يعمل حاجة أصلاً مش هيقدر يعملها.

بعت دعوة

صفحة الفريق فيها زرار واحد: دعوة عضو. بيفتح نافذة فيها خانة إيميل (اختيارية، هنشرح ليه تحت) واختيار نطاق فرع مضبوط افتراضياً على كل الفروع. دوس إرسال، والسيرفر بيولّد توكن عشوائي بطول 24 بايت، بيخزنه في مجموعة invites بمدة صلاحية 7 أيام، واللينك (/invite/{token}) بينسخ للكليبورد بتاعك على طول. لو كتبت إيميل فعلاً، منيو-مينا كمان بتبعته كإيميل حقيقي في الخلفية، بس الإرسال ده "أفضل محاولة": لو فشل، اللينك أصلاً موجود عندك في الكليبورد ومفيش حاجة بتتوقف عليه.

القبول، الإلغاء، والحذف

اللي بيفتح لينك الدعوة بيشوف اسم المطعم واللوجو بتاعه قبل ما يسجل دخول، وبعدين قبول الدعوة بيحصل في عملية واحدة متكاملة: بتتشيك إن الدعوة متاستخدمتش قبل كده ومنتهتش، وبتتشيك إن الشخص مش عضو أصلاً، وبعد كده بس بتتعمل العضوية وتتحدد الدعوة إنها اتقبلت. متنين مش هيقدروا يسبقوا بعض على نفس اللينك ويطلعوا بعضويتين. من ناحية الأونر، الدعوة المعلقة تقدر تلغيها، تعيد إرسالها (وده بيلغي التوكن القديم ويطلع واحد جديد بهدوء)، أو تنسخ لينكها تاني لو النسخة الأولى ضاعت. الدعوة اللي اتقبلت خلاص متقدرش تلغيها، مفيش حاجة تتلغي أصلاً، في الحالة دي شيل الشخص بيحصل من جدول أعضاء الفريق بدالها، ومعاه زرار تراجع لو الحذف كان بالغلط.

كل فعل من دول، دعوة، إلغاء، قبول، حذف، بيسجل سطر في سجل التدقيق فيه مين عمل إيه واتغير إيه. توكن الدعوة الحقيقي نفسه مبيتسجلش هناك، بس بصمة منه، لأن التوكن نفسه مفتاح دخول لأي حد يمسكه، وسجل التدقيق مالوش تاريخ انتهاء.