InfraDZ Software

كان التحدي الحقيقي هو خدمة شركات عديدة مستقلة من نظام واحد دون أن تختلط بياناتها. فالشركة التي لا تشغّل سوى نقطة بيع لا ينبغي أن ترى بقية الوحدات؛ وأمين الصندوق لا ينبغي أن يرى شاشات المشتريات؛ والمتجر الذي يحذف منتجاً باعه الشهر الماضي يجب ألا يُفسد سجلّه التاريخي. يضاف إلى ذلك أن المنتج كان يجب أن يتوفر تطبيقَ ويب وتطبيقَ سطح مكتب قابلاً للتثبيت في آن واحد — وهو ما يعني عادةً صيانة واجهتين أماميتين منفصلتين.

التعدد المستأجري هنا بنيوي لا مضاف لاحقاً: «tenant» هو الكيان الأعلى في مخطط الجداول الأربعة والسبعين وفي الشيفرة كلها، وتُحدَّد صلاحيات الوصول لكل شركة وحدةً بوحدة. تنتقل الصلاحيات مع الجلسة — يعيدها المسار /auth/me — ويتحكم العميل في الوصول عبر الخطاف useCan والمكوّن <Can> وشريط جانبي مرشّح بالصلاحيات، فالشاشات التي لا يملك الدور استخدامها لا تُعرض أصلاً.

أما سطح المكتب فحُسم بـ Tauri v2: يشير تطبيق سطح المكتب إلى مصادر React الخاصة بعميل الويب، فتنتج قاعدة شيفرة واحدة كلا البناءين. وتخضع سلامة البيانات لقاعدة صارمة في الحذف الناعم: البيانات الرئيسية لا تُحذف نهائياً أبداً، بل يُقلب isActive إلى false مع إمكانية الاستعادة، فتبقى المستندات التاريخية مرتبطة بسجلات موجودة. وتتشارك وحدة نقطة البيع نوع «Article» الرئيسي مع بقية النظام، فيُعرَّف المنتج مرة واحدة ويسلك السلوك نفسه عند الصندوق وفي المخزون.