سياسة الخصوصية

آخر تحديث: 9 أكتوبر 2026 — إصدار السياسة: —

1. لماذا هذه السياسة

توضّح هذه السياسة ما تجمعه منصة نزور (WeVisit) من بيانات عنك، ولماذا، ومَن يراها، ومدة الاحتفاظ بها، وحقوقك تجاهها. نزور وسيط بين الزائر والجهة المستضيفة (انظر الشروط والأحكام §1)، وهذا ينعكس على من يرى بياناتك أدناه.

ملاحظة مهمة على منهجية هذه الوثيقة: كل بند بيانات هنا مأخوذ من الجداول الفعلية في قاعدة بيانات نزور. لا تحتوي هذه السياسة على أي بند "عام" لم يُتحقَّق من وجوده في الكود فعلاً.

2. البيانات التي نجمعها فعلياً اليوم

2.1 بيانات الحساب (كل الأدوار)

عند التسجيل: الاسم، البريد الإلكتروني (فريد إلزامي حالياً)، كلمة المرور (لا تُخزَّن كنص صريح أبداً — تُحفَظ كـ hash عبر BCrypt)، رقم الجوال (اختياري؛ يُحفَظ بالصيغة الدولية E.164؛ يُرفض الرقم الذي يحمله حساب آخر). لحساب الزائر الفردي عند التسجيل، اختيارياً: الجنسية، الجنس، العمر. يُخزَّن أيضاً: تاريخ إنشاء الحساب، حالة تفعيله، حالة توثيق البريد الإلكتروني، وحالة توثيق الجوال وتاريخه (IsPhoneVerified، PhoneVerifiedAt). إن كان في حسابك رقم جوال قديم بصيغة لم يستطع النظام تصحيحها آلياً، يُحفَظ في حقل منفصل (LegacyPhone) يراه الأدمن فقط (صفحة إدارة المستخدمين) ولا يُستخدَم للدخول.

سجل موافقتك على هذه السياسة: عند إنشاء حسابك بنفسك (زائراً أو مالك منشأة) يشترط النظام تأشير خانة الموافقة على الشروط والأحكام وسياسة الخصوصية، ويسجّل على حسابك تاريخ الموافقة ووقتها (بتوقيت UTC، يضبطه الخادم لا المتصفح) ورقم نسخة السياسة السارية حينها (TermsAcceptedAt، TermsVersion — رقم النسخة الحالية ظاهر أعلى هذه الصفحة). الحسابات التي أنشأها الأدمن نيابةً عن أصحابها، والحسابات المنشأة قبل اعتماد هذه الآلية، لا تحمل سجل موافقة (القيمة فارغة). هذا السجل يُحفَظ في قاعدة البيانات ولا يُعرض حالياً في أي شاشة، لا لك ولا للأدمن عبر الواجهة.

توثيق الجوال وتغييره: يمكنك تغيير رقم جوالك من إعدادات حسابك مباشرة؛ عند التغيير بهذه الطريقة يُسجَّل الحدث في سجل الدخول (§3) ويُرسَل تنبيه إلى بريدك الإلكتروني المسجَّل (وإلى رقمك القديم برسالة نصية متى توفّر مزوّد رسائل). توجد أيضاً في النظام آلية توثيق الجوال برمز تحقق يُرسَل برسالة نصية (POST /api/auth/phone/change/request ثم /verify)، لكنها لا تعمل على الإنتاج اليوم لأن مزوّد الرسائل النصية غير مفعَّل (تم قياسه على الإنتاج بتاريخ 2026-09-14: GET /api/auth/phone/login-availability → smsEnabled: false)؛ في هذه الحالة يجيب المسار بـ 503 قبل أن يكتب أي شيء. متى فُعِّل المزوّد، يُخزَّن لكل رمز جوال: الرقم، الغرض، بصمة الرمز (HMAC-SHA256 بمفتاح سرّي مشتق من مفتاح توقيع الخادم، مع ملح عشوائي — الرمز نفسه لا يُخزَّن أبداً)، وقت الانتهاء (إعداد OtpTtlMinutes، افتراضياً 5 دقائق)، عدّاد المحاولات الخاطئة، وعنوان IP الذي طلب الرمز؛ وتُحذف هذه الصفوف آلياً بعد 7 أيام (§5).

⚠️ الدخول برقم الجوال + OTP بدل البريد وكلمة المرور (المهمة #42) — الأساس مبني لكن الميزة غير مفعَّلة. الخطة المعتمدة تُلغي البريد الإلكتروني وكلمة المرور لكل الأدوار (بما فيها الأدمن) وتجعل رقم الجوال المعرّف الوحيد، فريداً على مستوى قاعدة البيانات، مع رمز تحقق لمرة واحدة (OTP) لكل دخول. ما شُحن فعلاً حتى الآن (المرحلة 2a) هو البنية التحتية فقط: جداول الرموز وسجل الدخول ومسارات الدخول بالجوال — وهذه الأخيرة مقفلة بإعداد PhoneLoginEnabled = false وبغياب مزوّد الرسائل (تم قياسه على الإنتاج بتاريخ 2026-09-14: phoneLoginEnabled: false). حتى تفعيلها فعلياً على الإنتاج، الوصف في هذه الفقرة (بريد + كلمة مرور) هو ما يعمل حقاً.

2.2 رابط ورمز التحقق المؤقتان (بالبريد الإلكتروني — الآلية الحالية)

عند إعادة تعيين كلمة المرور أو توثيق البريد، نرسل إلى بريدك المسجَّل عبر بريد Microsoft 365 رسالة واحدة فيها رابط يُستخدَم مرة واحدة ورمز من 10 أرقام (كلاهما عشوائي تشفيرياً)، صالحان لمدة 15 دقيقة. يكفي أحدهما: استخدام الرابط أو الرمز بنجاح يُبطلهما معاً. يمكن كتابة الرمز بالأرقام العربية (٠–٩) أو اللاتينية، ومع مسافات. إعادة تعيين كلمة المرور عبر الرابط توثِّق بريدك أيضاً، لأن فتح الرابط يُثبت أنك تملك صندوق البريد؛ أما إعادة التعيين بالرمز فلا تغيّر حالة توثيق البريد. يُمسَح الرابط والرمز من حسابك بعد أول استخدام ناجح لأحدهما، أو عند إصدار رسالة جديدة تحل محلهما، أو عند تقديم الرمز أو الرابط بعد انتهاء صلاحيته، أو عندما يغيّر أحد المسؤولين عنوان بريدك أو يوثّقه (انظر §5 لما يبقى قبل ذلك). بعد 5 محاولات خاطئة بالرمز يُرفَض أي رمز يُقدَّم — صحيحاً كان أو خاطئاً — لكن ذلك لا يمسحهما، فيبقى الرابط صالحاً حتى يُستخدَم أو تنتهي صلاحيته أو تحل محله رسالة جديدة أو يغيّر أحد المسؤولين عنوان بريدك أو يوثّقه. وإلى جانب حدّ كل رمز، لكل حساب حدّ للرموز الخاطئة في إعادة تعيين كلمة المرور وتوثيق البريد معاً (50 رمزاً خاطئاً خلال آخر 60 دقيقة افتراضياً، قيمتان يديرهما الأدمن): متى بلغه حسابك يُرفَض أي رمز يُقدَّم — حتى الصحيح، وحتى رمز رسالة جديدة — حتى تخرج الرموز الخاطئة الأقدم من تلك المدة أو يمسح الأدمن هذا الحد لحسابك؛ ولا يخضع الرابط لهذا الحد. وعند بلوغ حسابك عدداً من الرموز الخاطئة يحدده الأدمن (10 افتراضياً) يصل كل أدمن نشط إشعار أمني داخل التطبيق يحمل رقم حسابك وبصمة لعنوان بريدك محسوبة بمفتاح سرّي، لا العنوان نفسه ولا اسمك؛ وإذا تجاوز عدد الحسابات المنبَّه عنها خلال المدة نفسها حداً يحدده الأدمن (20 افتراضياً) يصلهم بدلاً من ذلك إشعار بعدد الحسابات فقط، دون رقم حسابك (§2.8). لا يُخزَّن الرمز ولا الرابط نفسه في حسابك: تُحفَظ بصمتاهما فقط (HMAC-SHA256 بمفتاح سرّي مشتق من مفتاح توقيع الخادم، مع ملح عشوائي).

2.3 بيانات المنشأة (لمالكي المنشآت فقط)

اسم المنشأة (عربي/إنجليزي)، نوعها، وصفها، إقرار المالك بأن المنشأة مرخَّصة أو غير مرخَّصة (إلزامي عند التسجيل)، رقم السجل التجاري إن كانت مرخَّصة، البريد المؤسسي، رقم تواصل المنشأة العام (ContactPhone — رقم عمل يُتاح علناً عبر واجهة البرمجة مع بيانات الوجهة، انظر §3؛ عُبِّئ ابتداءً من رقم الجوال الذي كان مسجَّلاً على حساب المالك وقت إضافة هذا الحقل، ويستطيع المالك تعديله أو مسحه من إعدادات المنشأة)، وشعارها. هذه بيانات عن الجهة، لا عن أفراد، لكنها مرتبطة بحساب مالكها.

2.4 طلبات الزيارة

تاريخ الزيارة ووقتها، عدد الحضور (رقم فقط)، ملاحظاتك الاختيارية، الخدمات التي اخترتها من قائمة الخدمات التي تعرضها الوجهة (إن اخترت شيئاً)، حالة الطلب (قيد المراجعة / مقبول / مرفوض / مطلوب تعديل)، سبب الرفض إن رُفض، ورسالة الجهة المستضيفة إليك إن طلبت منك تعديل الطلب (انظر الشروط والأحكام §8.4).

2.5 سجل الزيارات

يُنشأ تلقائياً عند قبول طلب زيارة: التاريخ والوقت، عدد الأشخاص، الحالة (منتظرة/مكتملة/ملغاة). ويُنشأ كذلك سجل زيارة مكتملة عند انقضاء موعد زيارة خاصة مؤكَّدة (§2.15)، عدد الأشخاص فيه هو حجم المجموعة.

2.6 المرافقون المحفوظون (اختياري، من إعدادك أنت)

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

2.7 التقييمات

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

التقييم الذي أخفاه الإشراف لا يُعرض ولا يصل إلى متصفح الجمهور: الخدمة العامة التي تغذّي هذا القسم (GET /api/ratings) تشترط تحديد الوجهة، وتُرشِّح التقييمات المخفية على الخادم، وتعيد لكل تقييم خمسة حقول فقط (المعرّف، الدرجة، التعليق، اسم الحساب، التاريخ) — لا أعلام الإشراف ولا أي بيانات أخرى (المهمة #78، مُنفَّذة ومتحقَّق منها على الإنتاج بتاريخ 2026-09-14: الطلب بلا معرّف وجهة يُرفض بـ 400). لوحة الإشراف التي تُظهر أعلام الإخفاء والبلاغ مسار منفصل (/api/ratings/moderation) مقصور على الأدمن ومالك المنشأة صاحبة الوجهة.

2.8 الإشعارات داخل التطبيق والبريد الإلكتروني

آلية الإشعارات داخل التطبيق (جرس لوحة التحكم) مقيَّدة بحيث لا يرى كل مستخدم إلا إشعاراته (UserId). المواضع التي تُنشئ إشعاراً أو ترسل بريداً اليوم، كما في الكود: مسار رموز التحقق في §2.2 (مسار واحد يخدم إعادة تعيين كلمة المرور وتوثيق البريد معاً)، والمواضع التالية:

• عند تقديمك طلب زيارة جديداً: إشعار داخل التطبيق + بريد إلكتروني إلى مالك المنشأة (يحملان اسمك — انظر §3)؛ البريد ما لم يوقف الأدمن بريد الطلبات الجديدة من الإعدادات.
• عندما تطلب الجهة المستضيفة منك تعديل طلبك (المهمة #24): إشعار داخل التطبيق + بريد إلكتروني إليك أنت، يحملان رسالة الجهة.
• عندما تعدّل طلبك وتعيده للمراجعة: إشعار داخل التطبيق إلى مالك المنشأة فقط، بلا بريد.
• عند رفض طلبك: بريد إلكتروني إليك بسبب الرفض، فقط إن كتبت الجهة سبباً؛ لا إشعار داخل التطبيق.
• عند قبول طلبك: لا إشعار داخل التطبيق ولا بريد — تتحدّث حالة الطلب في صفحة «طلبات الزيارة».
• عند تغيير رقم جوالك — من إعدادات حسابك أنت، أو عندما يغيّره الأدمن لحسابك (مسار الدعم): بريد إلكتروني إلى بريد حسابك يحمل الرقم الجديد مقنَّعاً (§2.1)؛ ورسالة نصية إلى رقمك القديم متى فُعِّل مزوّد SMS (§8).
• عندما يغيّر الأدمن بريد حسابك إلى صندوق بريد آخر (المهمة #543): بريد إلكتروني إلى بريدك القديم يُعلمك بأن البريد المرتبط بحسابك تغيّر ويطلب منك التواصل مع الدعم إن لم تطلب ذلك؛ لا يحمل البريد الجديد ولا اسمك؛ لا إشعار داخل التطبيق. تغيير حالة الأحرف في العنوان نفسه لا يُرسل شيئاً.
• عند تكرار الرموز الخاطئة على حسابك (§2.2): إشعار أمني داخل التطبيق إلى كل أدمن نشط يحمل رقم حسابك وبصمة لعنوان بريدك محسوبة بمفتاح سرّي، دون العنوان نفسه ودون اسمك — أو، إذا تجاوز عدد الحسابات المنبَّه عنها خلال المدة نفسها حداً يحدده الأدمن (20 افتراضياً)، إشعار بعدد الحسابات فقط دون رقم حسابك؛ لا بريد. يُحذف آلياً مع سجل الدخول (§5).
• عندما يرفض الأدمن وجهة منشأتك أو يوقفها (لمالكي المنشآت): بريد إلكتروني يحمل السبب، فقط إن كتب الأدمن سبباً، إلى بريد المنشأة المؤسسي، وإن لم يكن مسجَّلاً فإلى بريد حساب المالك الشخصي؛ لا إشعار داخل التطبيق.

إشعارات إبداء الاهتمام بالفرص الاستثمارية موصوفة في §2.13، وإشعارات طلبات الزيارات المدرسية للفعاليات في §2.14، وإشعارات الزيارات الخاصة في §2.15.

2.9 تذاكر الدعم الفني

عنوان التذكرة، رسالتك، التصنيف، الأولوية، الحالة، وأي ردود من فريق الدعم — مرئية لك ولفريق نزور (الأدمن) فقط.

2.10 رسائل التواصل ونشرة الأخبار (بلا حساب بالضرورة)

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

2.11 الملفات التي تُرفعها (صور/فيديو الوجهات)

تتيح المنصة رفع صور (حتى 8 ميجابايت) وفيديو (حتى 60 ميجابايت) للوجهات، بأسماء ملفات عشوائية غير مرتبطة باسمك. الصور (JPEG/PNG/WebP/GIF) تُخزَّن بعد إزالة بياناتها الوصفية على الخادم (المهمة #81): تُحذف بيانات EXIF — ومنها إحداثيات GPS إن وُجدت — وXMP والتعليقات وكل حاوية بيانات وصفية غير لازمة للعرض، ولا يُحتفظ من EXIF إلا بوسم اتجاه الصورة (Orientation) حتى لا تُعرض مقلوبة؛ الصورة التالفة أو غير المدعومة تُرفض ولا يُخزَّن منها شيء. ومن الصورة بعد تنظيفها تُنشأ وتُخزَّن بجانبها نسخ مصغَّرة بصيغة WebP (بعرض 320 و640 و960 بكسل كحد أقصى، دون تكبير الصورة الأصغر من ذلك) لا تحمل بيانات وصفية، ولا تُنشأ لصور GIF، ولا لصور PNG أو WebP المتحركة، ولا للصور الكبيرة جداً. ملفات الفيديو تُخزَّن كما رُفعت دون معالجة بياناتها الوصفية. لا يوجد اليوم مسار برمجي يسمح برفع صورة شخصية (Avatar) لحساب المستخدم — الحقل موجود في قاعدة البيانات لكن لا شيء يكتب إليه حالياً.

2.12 ملفات الارتباط (Cookies) والتخزين المحلي

لا تستخدم نزور ملفات ارتباط (Cookies) ولا أي أداة تحليلات أو تتبّع طرف ثالث (تم التحقق ببحث شامل في كود الواجهة الأمامية عن Google Analytics وFacebook Pixel وما شابه — لا وجود لأي منها). يُخزَّن في التخزين المحلي (localStorage) لمتصفحك ثلاثة عناصر: رمز الدخول (JWT)؛ نسخة من بيانات حسابك لعرضها فوراً دون طلب إضافي، وتحتوي على اسمك، وبريدك الإلكتروني، ودورك، ورقم جوالك، وحالة توثيق الجوال، وحالة توثيق البريد، وقدرات حسابك (مثل الاستضافة والزيارة)، ورابط صورتك الشخصية إن وُجد؛ وتفضيل اللغة (عربي/إنجليزي). هذه البيانات تبقى على جهازك فقط ولا تُرسَل لأي طرف ثالث. عند تسجيل الخروج يُمسَح رمز الدخول ونسخة بيانات الحساب؛ أما تفضيل اللغة فيبقى على جهازك (لا يحمل بيانات شخصية). نزور نفسها لا تضع أي ملف ارتباط. موارد الخرائط من أطراف ثالثة (مكتبة Leaflet من unpkg وبلاطات الخريطة من OpenStreetMap على صفحات الوجهة والفعالية والفرصة الاستثمارية العامة — انظر §8) تخضع لسياسات تلك الأطراف الخاصة بها، لا لالتزام نزور هذا.

2.13 إبداء الاهتمام بالفرص الاستثمارية

تعرض المنصة فرصاً تجارية للاستثمار (الشروط والأحكام §10). إن أبديت اهتمامك بفرصة، يُخزَّن مع طلبك: نوع المستثمر (فرد أو منشأة)، واسم المنشأة ورقم سجلها التجاري إن كنت تمثّل منشأة، والقطاع ونطاق الميزانية اللذان تختارهما من قوائم المنصة، ورسالتك الاختيارية، واسم مسؤول التواصل، ورقم جوال التواصل (اختياري)، وبريد حسابك الإلكتروني (يُنسخ من حسابك، لا مما يُكتب في النموذج)، ووقت موافقتك الصريحة ورقم نسخة الشروط السارية حينها. هذه البيانات نسخة ثابتة وقت الإرسال: تعديلك لاحقاً لملفك لا يغيّر طلباً أُرسل. يتطلب الإرسال بريداً إلكترونياً موثَّقاً، وتأشير خانة الموافقة في كل طلب (لا تُؤشَّر مسبقاً).

حفظ بياناتك للمرات القادمة (اختياري): إن أشّرت خانة الحفظ المنفصلة، يُحفَظ في ملف مستثمر خاص بك: نوع المستثمر، واسم المنشأة ورقم سجلها التجاري، والقطاع، ونطاق الميزانية، ورقم جوال التواصل، ووقت موافقتك على الحفظ — لتعبئة النموذج لاحقاً. لا يُحفَظ فيه اسم مسؤول التواصل ولا رسالتك. تستطيع حذف هذا الملف بنفسك في أي وقت (زر «حذف الملف» في تبويب «طلبات الاستثمار» بصفحة «طلبات الزيارة»).

من يرى هذه البيانات: فريق نزور (الأدمن) وحده يطّلع داخل المنصة على طلبات إبداء الاهتمام كاملة، ويضيف إليها ملاحظات داخلية لا تظهر لك. لا يملك أي حساب آخر على المنصة — بما فيه حساب الجهة صاحبة الفرصة — صلاحية الاطلاع عليها. لترتيب التواصل، ينقل فريق نزور بياناتك المذكورة في نموذج الموافقة إلى الجهة صاحبة الفرصة (§3)؛ أما البريد الآلي الذي ترسله المنصة إلى عنوان التواصل المسجَّل للفرصة فيُعلمها بوصول اهتمام جديد فقط، ولا يحمل أي بيان عنك.

الإشعارات: عند إرسال اهتمامك يصل إشعار داخل التطبيق وبريد إلكتروني إلى الأدمن المعيَّن لمتابعة طلبات الاستثمار، أو — إن لم يُعيَّن أحد — إشعار داخل التطبيق لكل أدمن نشط، يحملان اسم منشأتك (أو اسم مسؤول التواصل إن لم تذكر منشأة) وعنوان الفرصة. وعندما يغيّر فريق نزور مرحلة طلبك فتتغيّر بذلك حالته الظاهرة لك («قيد المراجعة» / «تم التواصل» / «مغلق») يصلك إشعار داخل التطبيق وبريد إلكتروني. أما ترسية الفرصة نفسها أو سحبها فيجعل حالة طلبك «مغلق» دون أن يصلك إشعار أو بريد.

2.14 طلبات الزيارات المدرسية للفعاليات

تعرض الجهات المستضيفة على المنصة فعاليات، ويستطيع أي حساب مسجَّل تقديم طلب زيارة مدرسية لفعالية تقبل ذلك، ما لم تكن الفعالية تابعة لمنشأته هو. يُخزَّن مع الطلب، مرتبطاً بحسابك: اسم المدرسة، واسم مسؤول التواصل، ورقم جوال التواصل، وبريد التواصل الإلكتروني (كما تكتبها في النموذج)، وعدد الطلاب، والمرحلة الدراسية، والتاريخ المفضَّل ووقته (اختياري)، وملاحظاتك (اختيارية)؛ ثم حالة الطلب (قيد المراجعة / مقبول / مرفوض / ملغى) وسبب القرار إن كُتب. يخضع عدد الطلبات التي يقدّمها الحساب خلال 24 ساعة لحدّ يحدده الأدمن (5 طلبات افتراضياً).

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

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

2.15 الزيارات الخاصة

تتيح بعض الوجهات طلب زيارة خاصة لمجموعتك وفق عرض يراجعه فريق نزور. يتطلب تقديم الطلب حساباً ببريد إلكتروني موثَّق، ولا يُقبل على وجهة تابعة لمنشأتك. يُخزَّن مع الطلب، مرتبطاً بحسابك: نوع مقدّم الطلب (فرد / عائلة، شركة، جهة حكومية، منظِّم رحلات)؛ وبحسب النوع: اسم الجهة، ورقم السجل التجاري وطلب فاتورة ضريبية (للشركة)، ومستوى البروتوكول وخيار السرّية (للجهة الحكومية)، ورقم الترخيص (لمنظِّم الرحلات)؛ ثم حجم المجموعة، ولغة الإرشاد، ومن موعد إلى ثلاثة مواعيد مقترحة، والخدمات التي تختارها، وما تكتبه اختيارياً عن المناسبة واحتياجات الإتاحة (وقد تتضمّن معلومات صحية) وملاحظاتك، واسم مسؤول التواصل ورقم جواله، وبريد حسابك الإلكتروني (يُنسخ من حسابك). وخلال سير الطلب يُخزَّن أيضاً: رسائل الجهة إليك وردودك، وعروض السعر التي ترسلها الجهة (المبلغ، الموعد، ما يشمله العرض، مدة صلاحيته، سياسة الإلغاء)، وأسباب الرفض أو الإلغاء، وسجلّ زمني بكل خطوة. يتم أي دفع خارج المنصة؛ لا تُخزَّن بيانات دفع. يخضع عدد الطلبات التي يقدّمها الحساب خلال 24 ساعة لحدّ يحدده الأدمن (3 طلبات افتراضياً).

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

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

3. مع من نُشارك بياناتك

سجل الدخول (Login audit) — يعمل اليوم لكل الأدوار. عند كل محاولة دخول بالبريد وكلمة المرور، ناجحة كانت أو فاشلة، يسجّل النظام في قاعدة بياناته: وقت المحاولة، عنوان IP الذي جاءت منه، معرّف متصفحك (User-Agent، حتى 256 حرفاً)، ونتيجتها، ورقم جوال الحساب إن كان مسجَّلاً. المحاولة الفاشلة تُسجَّل دون ربطها بأي حساب (قد لا يكون البريد المُدخَل حساباً أصلاً). يُسجَّل أيضاً حدث تغيير رقم الجوال (من إعداداتك أو عبر الأدمن)، وكل رمز خاطئ يُقارَن برمز تحقق ساري الصلاحية لإعادة تعيين كلمة المرور أو توثيق البريد (الوقت، عنوان IP، المتصفح)، وإلغاء الأدمن لقفل هذه المحاولات على حسابك، وتوثيق الأدمن لبريدك دون رمز (المهمة #535)، وتغيير الأدمن لبريد حسابك إلى صندوق بريد آخر (المهمة #543) — هذه الثلاثة تُسجَّل مع رقم الأدمن، دون عنوان IP ودون أي عنوان بريد. الغرض أمني بحت (رصد إساءة الاستخدام) وتشغيلي (دعم). تستطيع الاطلاع على آخر 20 حدثاً في سجل حسابك من صفحة ملفك الشخصي (GET /api/auth/me/login-audit)، ويستطيع الأدمن الاطلاع على سجل أي حساب. تُحذف صفوف هذا السجل آلياً بعد انقضاء مدة الاحتفاظ (§5). (خوادم الاستضافة قد تحتفظ بسجلات وصول تقنية عامة خارج قاعدة بيانات التطبيق، كما هو معتاد في أي بنية استضافة، بصرف النظر عن نزور تحديداً.)

4. الغرض من كل بيان

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

5. مدة الاحتفاظ بالبيانات

• بيانات الحساب: طوال بقاء حسابك نشطاً، وحتى طلب إغلاقه (§7) ما لم يلزم الاحتفاظ بسجلّ أساسي لأغراض نظامية (مثل سجلات المعاملات المالية إن وُجدت مستقبلاً).
• رابط ورمز التحقق المؤقتان بالبريد (§2.2): يُمسَحان من حسابك فور استخدام أحدهما بنجاح، أو عند إصدار رسالة جديدة تحل محلهما، أو عند تقديم أحدهما بعد انتهاء صلاحيته (المهمة #81)، أو عندما يغيّر أحد المسؤولين عنوان بريدك أو يوثّقه. بلوغ عدد المحاولات الخاطئة المسموح بها بالرمز يمنع قبول الرمز لكنه لا يمسحهما، فيبقى الرابط صالحاً (المهمة #522). ما انتهت صلاحيته ولم يُقدَّم مرة أخرى ولم يُستبدل يبقى في حسابك (غير صالح للاستخدام) حتى تنطبق إحدى هذه الحالات — لا توجد مهمة مؤقَّتة تمسحه من تلقاء نفسها.
• رموز الجوال (PhoneOtp، متى فُعِّلت): تُحذف صفوفها آلياً بعد 7 أيام من إصدارها.
• سجل الدخول (§3): يُحذف آلياً بعد انقضاء مدة الاحتفاظ المحدَّدة في إعداد LoginAuditRetentionDays (90 يوماً افتراضياً، يديره الأدمن).
• رسائل التواصل واشتراك النشرة: حتى تُحذف من قِبل الأدمن أو يُطلَب حذفها.
• طلبات الزيارة وسجل الزيارات: تبقى في السجل التاريخي لحسابك لأغراض الدعم والإحصاء، ولا تُحذف تلقائياً بانقضاء مدة.
• إبداء الاهتمام بالفرص الاستثمارية: يبقى في السجل ما دام حسابك قائماً، ولا يُحذف تلقائياً بانقضاء مدة؛ يستطيع الأدمن حذف أي طلب. ملف المستثمر المحفوظ يبقى حتى تحذفه بنفسك أو يُحذف حسابك (§7).
• طلبات الزيارات المدرسية (§2.14) وطلبات الزيارات الخاصة (§2.15): تبقى في السجل بعد انتهائها، ولا تُحذف تلقائياً بانقضاء مدة؛ سحبك طلب زيارة مدرسية يجعل حالته «ملغى» ولا يحذفه. تُحذف مع حسابك (§7)، أو مع حذف المنشأة التي قُدِّمت إليها؛ وتُحذف طلبات الزيارات الخاصة كذلك مع حذف الوجهة. أما حذف الوجهة فلا يحذف طلبات الزيارات المدرسية، ولا يمكن حذف فعالية منشورة.
• مهمتان تشغيليتان آليتان تعملان اليوم: (1) LoginAuditPurgeService، مرة كل 24 ساعة، تحذف حصراً: صفوف سجل الدخول الأقدم من مدة الاحتفاظ، والتنبيهات الأمنية للأدمن عن الرموز الخاطئة (§2.8) الأقدم من المدة نفسها، وصفوف رموز الجوال الأقدم من 7 أيام. (2) PrivateVisitSweepService، كل 10 دقائق، تحدّث حالات طلبات الزيارات الخاصة (§2.15) — انتهاء صلاحية عرض السعر، واكتمال الزيارة مع إنشاء سجل زيارتها (§2.5)، وتنبيه الأدمن عن طلب تأخّر الرد عليه — ولا تحذف شيئاً. لا تحذف أيٌّ منهما أي بيانات أخرى (حسابات، طلبات، رسائل، تقييمات) — حذف تلك يتم بطلب، عبر الأدمن من لوحة التحكم للحسابات (انظر «حذف الحساب» في §7) ولرسائل التواصل، وبعملية يدوية على قاعدة البيانات لاشتراك النشرة الذي لا يملك مساراً للحذف داخل النظام.

6. أمن البيانات

كلمات المرور مُشفَّرة (hash) عبر BCrypt ولا تُخزَّن أبداً كنص صريح. الاتصال بالمنصة عبر HTTPS. التوثيق عبر JWT يُرسَل برأس Authorization، لا عبر ملف ارتباط. الدخول إلى بيانات كل مستخدم مقيّد ببرمجيات التصريح (Authorization) حسب الدور وملكية السجل — راجع "قواعد نطاق الملكية" في ANTIGRAVITY_RULES.md.

7. حقوقك تجاه بياناتك

• الاطلاع والتعديل: يمكنك تعديل اسمك ورقم جوالك وكلمة مرورك من إعدادات حسابك مباشرة. البريد الإلكتروني والدور غير قابلين للتعديل الذاتي حالياً — التواصل مع الدعم مطلوب لتغييرهما.
• الاطلاع على سجل دخول حسابك: آخر 20 حدثاً (الوقت، عنوان IP، المتصفح، النتيجة) معروضة في صفحة ملفك الشخصي (§3).
• حذف الحساب: ⚠️ لا تتوفر حالياً خاصية حذف ذاتي للحساب من داخل التطبيق. لطلب إغلاق حسابك وحذف بياناتك، تواصل مع الدعم الفني. ما ينفّذه النظام عند الطلب، كما هو مقاس على الكود: يحذف الأدمن أي حساب من لوحة التحكم في خطوة واحدة، بما في ذلك حساب له سجل زيارة واحد أو أكثر: تُحذف تلقائياً ضمن العملية نفسها طلبات الزيارة والتقييمات وتذاكر الدعم (مع ردودها) ورموز الجوال الخاصة بالحساب — بما فيها رموز الدخول المسجَّلة برقم جوالك — والمرافقون المحفوظون ومرافقو زياراتك، وإشعارات المنشآت التي تحمل اسمك عن طلبات زيارتك، وطلبات زياراتك المدرسية (§2.14) وطلبات زياراتك الخاصة (§2.15) مع عروض السعر والرسائل وسجلّها الزمني، والإشعارات المرتبطة بها لدى الجهات والأدمن، والتنبيهات الأمنية للأدمن عن حسابك (§2.8)، ويُمسح رقم الجوال من صفوف سجل الدخول (§3) المرتبطة بحسابك، ومن الصفوف التي تحمل رقمك دون أن تكون مرتبطة بأي حساب، مع بقاء الحدث والوقت وعنوان IP، ثم يُحذف الحساب نفسه. صفوف حساب آخر يحمل الرقم نفسه لا تُمسّ. سجلات الزيارة (Visit) تبقى محفوظة لأغراض إحصاء عدد الزيارات دون ربطها بالحساب المحذوف (تُفرَّغ الإشارة إليه)، وكذلك ردود الحساب — إن كان أدمن — على تذاكر دعم غير خاصة به، وتُعرض باسم «مستخدم محذوف». الحساب المالك لمنشأة يُرفض حذفه حتى تُحذف المنشأة أو تُنقَل ملكيتها أولاً. رسالة أو اشتراك نشرة قدّمتهما بالبريد نفسه هما موافقتان مستقلتان ولا يتأثران بحذف الحساب (§5). طلبات إبداء الاهتمام بالفرص الاستثمارية تبقى صفوفاً مجهَّلة لأغراض إحصاء الفرص: يُمسح منها الاسم والبريد والجوال واسم المنشأة ورقم السجل التجاري والرسالة وسبب الإغلاق، وتُفصل عن الحساب، وتُحذف الملاحظات الداخلية عليها والإشعارات المرتبطة بها؛ ويُحذف ملف المستثمر المحفوظ. المرافقون المحفوظون وملف المستثمر المحفوظ يمكن حذفهم ذاتياً من داخل حسابك متى شئت. أما التقييم الذي كتبته فلا يمكنك حذفه ولا تعديله ذاتياً بعد نشره — صلاحية حذف تقييم مقصورة على الأدمن ومالك المنشأة صاحبة الوجهة المقيَّمة، لغرض الإشراف على المحتوى؛ لطلب حذف تقييمك، تواصل مع الدعم الفني.
• سحب الموافقة على النشرة: الإلغاء عبر طلب يُوجَّه للدعم؛ لا يوجد حالياً رابط أو صفحة لإلغاء الاشتراك ذاتياً، ولا ترسل المنصة نفسها رسائل النشرة.
• تقديم شكوى: عبر الدعم الفني، أو الجهة التنظيمية المختصة في المملكة إن رأيت أن حقوقك لم تُحترَم.

8. المعالجون الخارجيون ومزوّدو المحتوى (Data Processors & Third-Party Content)

معالج البيانات الشخصية الوحيد المستخدَم فعلياً اليوم هو Microsoft 365 (بريد SMTP لإرسال رموز التحقق وإشعارات الطلبات والرفض). لا يوجد اليوم مزوّد تحليلات ولا مزوّد إعلانات ولا مزوّد رسائل SMS يعالج بياناتك الشخصية.

بالإضافة لذلك، تُحمِّل كل صفحة من صفحات المنصة موارد تقنية (خطوط، أيقونات، مكتبات برمجية) من خوادم أطراف ثالثة: Google Fonts (fonts.googleapis.com، fonts.gstatic.com)، Cloudflare cdnjs (cdnjs.cloudflare.com)، jsDelivr (cdn.jsdelivr.net)، ومكتبة الخرائط Leaflet عبر unpkg (unpkg.com). كل طلب لهذه الموارد يصل إلى خادم الطرف الثالث مباشرة من متصفحك، فيكشف له عنوان IP الخاص بك ومتصفحك (User-Agent) — كما يحدث مع أي موقع يستخدم شبكات توزيع محتوى (CDN) عامة. صفحات الوجهة والفعالية والفرصة الاستثمارية العامة تعرض أيضاً خريطة للموقع: عندما تكون الخريطة ظاهرة على الشاشة أو قريبة منها — عند تحميل الصفحة إن كانت قصيرة، وإلا عند الاقتراب منها أثناء التصفّح — تُحمِّل مكتبة الخرائط Leaflet من unpkg (unpkg.com) وبلاطات الخريطة من tile.openstreetmap.org، فيصل إلى هذين الخادمين عنوان IP الخاص بك ومتصفحك كما سبق. صفحات إدارة الوجهة لمالكي المنشآت (وصفحة تفاصيل المنشأة لدى الأدمن) تُحمِّل بلاطات الخريطة من tile.openstreetmap.org وترسل العنوان الذي يكتبه المستخدم — عند طلب البحث (بالضغط على زر البحث أو مفتاح Enter داخل حقل العنوان؛ الكتابة وحدها لا ترسل شيئاً) — إلى خدمة البحث الجغرافي Nominatim التابعة لـ OpenStreetMap (nominatim.openstreetmap.org) لتحويله إلى إحداثيات. وتعرض الصفحة الرئيسية (index.html) وصفحة «اكتشف السعودية» العامة (discover.html) خريطة تفاعلية: تُحمِّلان مكتبة الخرائط Leaflet وإضافة تجميع العلامات leaflet.markercluster من unpkg (unpkg.com)، وبلاطات الخريطة من tile.openstreetmap.org، فيصل إلى هذين الخادمين عنوان IP الخاص بك ومتصفحك كما سبق. وزر «موقعي الحالي» في صفحة «اكتشف السعودية» لا يطلب موقعك من المتصفح إلا عند الضغط عليه؛ ويُستخدَم الموقع داخل متصفحك فقط لعرض نقطة على الخريطة وتحريكها إليه، ولا يُرسَل إلى نزور ولا يُحفَظ في رابط الصفحة ولا في متصفحك — غير أن تحريك الخريطة إلى موقعك يجعل متصفحك يطلب بلاطات تلك المنطقة من tile.openstreetmap.org، كما يحدث عند تحريك الخريطة يدوياً. وزر «الأقرب إليك» في صفحة الوجهات (destinations.html) لا يطلب موقعك من المتصفح إلا عند الضغط عليه، ويُستخدَم الموقع داخل متصفحك فقط لترتيب الوجهات حسب المسافة، ولا يُرسَل إلى نزور. صفحات الوجهة والفعالية والفرصة الاستثمارية تعرض كذلك زراً أو رابطاً (مثل «التوجّه إلى الموقع») يفتح خرائط Google في تبويب جديد عند الضغط عليه فقط — لا يُرسَل شيء إلى Google قبل ذلك. وإن لم تكن للفعالية إحداثيات فقد تعرض صفحتها بدلاً من ذلك رابط خريطة خارجية أضافته الجهة المستضيفة، يُفتح كذلك في تبويب جديد عند الضغط عليه فقط. وبالمثل، إن أضافت الجهة المستضيفة لوجهتها رابط صفحة فيديو خارجية (مثل YouTube)، فإن صفحة الوجهة لا تُضمِّن تلك الصفحة، بل تعرض زر تشغيل يفتح الرابط في تبويب جديد عند الضغط عليه فقط؛ ما يحدث بعد ذلك يخضع لسياسة ذلك الموقع. أما ملف الفيديو المرفوع إلى نزور (§2.11) فيُشغَّل داخل الصفحة، ويجلبه متصفحك من خادم نزور عند تحميل الصفحة. ولا تقبل المنصة رابطاً مباشراً لملف فيديو على مضيف خارجي؛ وأي رابط كهذا أُدخل قبل ذلك يُفتح في تبويب جديد عند الضغط عليه فقط. هذه ليست أدوات تحليلات أو تتبّع (لا Google Analytics ولا Facebook Pixel ولا ما شابه — راجع §2.12)، لكنها أطراف ثالثة تستلم بيانات اتصال تقنية (IP) من متصفحك عند كل تحميل صفحة.

عند تفعيل مزوّد الرسائل النصية، يُصبح مزوّد SMS معالج بيانات شخصية جديداً لإرسال رموز توثيق الجوال ورموز الدخول بالجوال (المهمة #42). المزوّد المعتمد هو Msegat؛ التكامل الفعلي محجوب حالياً باعتماد اسم المرسل «WEVISIT» لدى المشغّل (المهمة #41)، ومقاس على الإنتاج بتاريخ 2026-09-14 أنه غير مفعَّل (§2.1)؛ سيُحدَّث هذا القسم فور إتمام التكامل وإطلاقه فعلياً على الإنتاج.

9. الأطفال

المنصة موجَّهة للاستخدام العام؛ لا نجمع عمداً بيانات أطفال دون إشراف ولي الأمر. حقل «العمر» اختياري عند تسجيل الزائر الفردي ولا يُستخدَم للتحقق الآلي من السن حالياً.

10. التعديلات على هذه السياسة

قد تُحدَّث هذه السياسة عند تغيّر ما نجمعه فعلياً (كتفعيل الدخول بالجوال في المهمة #42). يُنشَر أي تعديل جوهري مع تحديث تاريخ «آخر تحديث» ورقم نسخة السياسة (TermsVersion) الذي يُسجَّل مع موافقة كل حساب يُنشأ بالتسجيل الذاتي (§2.1)، ويتطلب اعتماد الرئيس التنفيذي مسبقاً، أسوةً بهذه الوثيقة نفسها.

11. التواصل

للاستفسار عن هذه السياسة أو ممارسة حقوقك، تواصل عبر صفحة «تواصل معنا» أو البريد الإلكتروني المنشور في تذييل الموقع (قيمة يديرها الأدمن من الإعدادات).

Last updated: 9 October 2026 — Policy version: —

This is a translation of the Arabic original above for convenience. In case of any conflict or ambiguity, the Arabic text is the authoritative version.

1. Why This Policy Exists

This policy explains what data WeVisit (نزور) collects about you, why, who sees it, how long we keep it, and your rights over it. WeVisit is an intermediary between the visitor and the hosting entity (see the Terms & Conditions §1), and that shapes who sees your data below.

A note on this document's method: every data item listed here is taken from WeVisit's actual database tables. This policy contains no "generic" item that was not actually verified against the code.

2. Data We Actually Collect Today

2.1 Account Data (all roles)

At registration: name, email (currently unique and required), password (never stored in plain text — hashed with BCrypt), phone number (optional; stored in international E.164 format; a number already held by another account is refused). For an individual visitor account at registration, optionally: nationality, gender, age. Also stored: account creation date, whether the account is active, whether the email is verified, and whether and when the phone was verified (IsPhoneVerified, PhoneVerifiedAt). If your account held an older phone number in a format the system could not normalise automatically, it is kept in a separate field (LegacyPhone) that only Admin sees (user-management page) and that is never used to sign in.

Your consent record for this policy: when you create your account yourself (as a visitor or an institution owner) the system requires the Terms & Conditions / Privacy Policy consent box to be ticked, and records on your account the date and time of consent (UTC, set by the server, not the browser) and the version of the policy in force at that moment (TermsAcceptedAt, TermsVersion — the current version number is shown at the top of this page). Accounts an Admin created on someone's behalf, and accounts created before this mechanism existed, carry no consent record (the value is empty). This record is kept in the database and is not currently displayed on any screen, neither to you nor to Admin through the interface.

Phone verification and changes: you can change your phone number directly from your account settings; a change made that way is written to the login audit (§3) and a notice is emailed to your registered address (and sent by SMS to your old number once an SMS provider is available). The system also contains a verify-your-phone-by-SMS-code mechanism (POST /api/auth/phone/change/request then /verify), but it does not operate on production today because no SMS provider is enabled (measured on production on 2026-09-14: GET /api/auth/phone/login-availability → smsEnabled: false); in that state the endpoint answers 503 before writing anything. Once a provider is enabled, each phone code stores: the number, the purpose, a fingerprint of the code (a keyed HMAC-SHA256 with a random salt, the key derived from the server's token-signing key — the code itself is never stored), the expiry time (OtpTtlMinutes setting, 5 minutes by default), a wrong-attempt counter, and the IP address that requested the code; these rows are deleted automatically after 7 days (§5).

⚠️ Phone + OTP login replacing email and password (issue #42) — foundation built, feature not enabled. The approved plan removes email and password for every role (Admin included) and makes phone the sole identifier, unique at the database level, with a one-time code (OTP) for every login. What has actually shipped so far (phase 2a) is only the infrastructure: the code tables, the login audit, and the phone-login routes — and those routes are locked behind the PhoneLoginEnabled = false setting and the absence of an SMS provider (measured on production on 2026-09-14: phoneLoginEnabled: false). Until it is actually enabled on production, the description above (email + password) is what is really running.

2.2 Temporary Verification Link and Code (email — today's mechanism)

For password reset or email verification, we send one message to your registered email via Microsoft 365 mail containing a single-use link and a 10-digit code (both cryptographically random), valid for 15 minutes. Either one is enough: using the link or the code successfully invalidates both. The code may be typed in Arabic-Indic digits (٠ to ٩) or Latin digits, and with spaces. A password reset completed through the link also verifies your email, because opening the link proves you control the mailbox; a reset with the code does not change your email's verification status. The link and the code are cleared from your account after the first successful use of either, when a new message is issued in their place, or when the code or the link is presented after it has expired, or when an administrator changes your email address or marks it verified (see §5 for what remains before then). After 5 wrong attempts with the code, any code presented — right or wrong — is refused, but this does not clear them, so the link keeps working until it is used, expires, is replaced by a new message, or an administrator changes your email address or marks it verified. Besides each code's own limit, each account has a limit on wrong codes across password reset and email verification together (by default 50 wrong codes within the last 60 minutes, two values managed by Admin): once your account reaches it, any code presented is refused — even the right one, and even the code of a new message — until the older wrong codes fall outside that period or an Admin clears this limit for your account; the link is not subject to this limit. When your account reaches a number of wrong codes set by Admin (10 by default), every active Admin receives an in-app security alert carrying your account number and a keyed fingerprint of your email address — not the address itself, nor your name; once more accounts than a limit set by Admin (20 by default) have been alerted on within that period, Admins instead receive a count of accounts only, without your account number (§2.8). Neither the code nor the link itself is stored on your account: only their fingerprints are kept (a keyed HMAC-SHA256 with a random salt, the key derived from the server's token-signing key).

2.3 Institution Data (institution owners only)

Institution name (Arabic/English), type, description, the owner's declaration that the institution is licensed or unlicensed (mandatory at registration), commercial registration number if licensed, institutional email, the institution's public contact phone (ContactPhone — a business number made publicly available through the API together with the destination data, see §3; it was initially filled from the phone number on the owner's account at the time this field was added, and the owner can edit or clear it from the institution settings), and logo. This is data about the entity, not an individual, but it is tied to its owner's account.

2.4 Visit Requests

Visit date and time, attendee count (a number only), your optional notes, the services you picked from the list the destination offers (if any), the request's status (under review / accepted / rejected / change requested), the rejection reason if declined, and the hosting entity's message to you if it asked you to change the request (see the Terms & Conditions §8.4).

2.5 Visit History

Created automatically when a request is accepted: date and time, number of people, status (pending/completed/cancelled). A completed visit record is also created once the time of a confirmed private visit has passed (§2.15), with the group size as its number of people.

2.6 Saved Companions (optional, your own choice)

If you choose to save a companion's details to speed up future bookings: name, ID number if you entered one, phone number, relation. This data is yours alone and is not seen by anyone else through the system's interface — not the hosting entity, and not even WeVisit's operating team query your individual records directly; only Admin manages your account as a whole through the separate user-management panel.

2.7 Ratings

If you rate a destination after visiting it: a score from 1 to 5, and an optional comment, both tied to your account name. Your individual rating is shown publicly on the destination page to any visitor, anonymous included (no login required): your account name as you entered it, the score, your comment, and the rating date — this is by design, not a mistake, and it is not limited to WeVisit's team. The destination page also shows the numeric average rating in the same section. WeVisit's operating team uses a separate ratings-moderation panel for content oversight (hiding an abusive comment, handling a report) — that panel is not the channel the public sees you through; the public sees you directly on the destination page itself.

A rating hidden by moderation is neither shown nor delivered to the public's browser: the public endpoint that feeds this section (GET /api/ratings) requires a destination to be named, filters hidden ratings on the server, and returns five fields per rating (id, score, comment, account name, date) — no moderation flags and no other data (issue #78, shipped and verified on production on 2026-09-14: a request without a destination id is refused with 400). The moderation panel that shows the hidden/reported flags is a separate path (/api/ratings/moderation) restricted to Admin and the owner of the rated destination's institution.

2.8 In-App Notifications and Email

The in-app notification mechanism (the dashboard bell) is scoped so each user sees only their own (UserId). The places that create a notification or send an email today, as in the code: the verification-code path of §2.2 (a single path that serves both password reset and email verification), and the following:

• When you submit a new visit request: an in-app notification + an email to the institution owner (both carry your name — see §3); the email unless Admin has switched off new-request emails in the settings.
• When the hosting entity asks you to change your request (issue #24): an in-app notification + an email to you, carrying the entity's message.
• When you edit your request and return it for review: an in-app notification to the institution owner only, no email.
• When your request is rejected: an email to you with the rejection reason, only if the entity wrote a reason; no in-app notification.
• When your request is accepted: no in-app notification and no email — the request's status updates on your "Visit Requests" page.
• When your phone number changes — by you from your account settings, or by an Admin on your account (the support path): an email to your account's email address carrying the new number in masked form (§2.1); and an SMS to your old number once an SMS provider is enabled (§8).
• When an Admin changes your account's email to a different mailbox (issue #543): an email to your old address telling you that the email on your account was changed and asking you to contact support if you did not ask for it; it carries neither the new address nor your name; no in-app notification. A change of letter case in the same address sends nothing.
• When wrong codes repeat on your account (§2.2): an in-app security alert to every active Admin carrying your account number and a keyed fingerprint of your email address, without the address itself and without your name — or, once more accounts than a limit set by Admin (20 by default) have been alerted on within that period, a count of accounts only, without your account number; no email. It is deleted automatically together with the login audit (§5).
• When an Admin rejects or suspends one of your institution's destinations (institution owners): an email carrying the reason, only if the Admin wrote a reason, to the institution's institutional email, or, if none is on file, to the owner's personal account email; no in-app notification.

The notifications about expressions of interest in investment opportunities are described in §2.13, those about school visit requests to events in §2.14, and those about private visits in §2.15.

2.9 Support Tickets

Ticket subject, your message, category, priority, status, and any support replies — visible to you and to WeVisit's team (Admin) only.

2.10 Contact Messages and Newsletter (no account necessarily required)

"Contact Us" form: name, email, phone (optional), subject, message — for anyone who submits the form, signed in or not. Newsletter subscription: your email address only, kept from the moment you subscribe until you ask to unsubscribe.

2.11 Files You Upload (destination photos/video)

The platform allows uploading images (up to 8 MB) and video (up to 60 MB) for destinations, saved under randomized filenames unrelated to your name. Images (JPEG/PNG/WebP/GIF) are stored after their metadata is stripped on the server (issue #81): EXIF data — including GPS coordinates if present — XMP, comments, and every metadata container not needed to render the image are dropped; the only EXIF tag preserved is the image's orientation, so it is not displayed rotated. A corrupt or unsupported image is refused and nothing is stored. From the cleaned image, smaller WebP copies (at most 320, 640 and 960 pixels wide; a narrower image is not enlarged) carrying no metadata are made and stored next to it; none are made for GIF images, for animated PNG or WebP images, or for very large images. Video files are stored as uploaded, with no metadata handling. There is currently no code path that lets a user upload a profile photo (avatar) — the field exists in the database, but nothing writes to it today.

2.12 Cookies and Local Storage

WeVisit does not use cookies and does not use any third-party analytics or tracking tool (verified by a full search of the frontend code for Google Analytics, Facebook Pixel, and similar — none exist). Your browser's local storage (localStorage) holds three items: your login token (JWT); a cached copy of your account data so it can be shown instantly without an extra request, containing your name, email address, role, phone number, phone-verification state, email-verification state, account capabilities (such as host/visit), and your avatar URL if any; and your language preference (Arabic/English). This data stays on your device only and is never sent to any third party. On sign-out the login token and the account-data copy are cleared; the language preference stays on your device (it carries no personal data). WeVisit itself sets no cookie. Third-party map resources (Leaflet from unpkg and map tiles from OpenStreetMap on public destination, event and investment-opportunity pages — see §8) are governed by those third parties' own policies, not by this commitment.

2.13 Expressions of Interest in Investment Opportunities

The platform lists business investment opportunities (Terms & Conditions §10). If you express interest in one, the following is stored with your submission: investor type (individual or company), the company's name and commercial registration number if you represent a company, the sector and budget band you pick from the platform's lists, your optional message, the contact name, a contact phone number (optional), your account's email address (copied from your account, not from anything typed in the form), and the time of your explicit consent and the version of the Terms in force at that moment. This data is a fixed snapshot at submission: editing your profile later does not change a submission already sent. Submitting requires a verified email address and ticking the consent box on every submission (it is never pre-ticked).

Saving your details for next time (optional): if you tick the separate save box, an investor profile of yours keeps: investor type, the company's name and commercial registration number, sector, budget band, contact phone number, and the time you consented to saving — to prefill the form later. It does not keep the contact name or your message. You can delete this profile yourself at any time (the "Delete profile" button in the "Investment requests" tab of your "Visit Requests" page).

Who sees this data: inside the platform, only WeVisit's team (Admin) sees full expressions of interest, and it can add internal notes to them that are not shown to you. No other account on the platform — including the opportunity owner's — can read them. To arrange contact, WeVisit's team passes the details listed in the consent form to the opportunity owner (§3); the automatic email the platform sends to the opportunity's registered contact address only tells it that a new expression of interest has arrived, and carries no data about you.

Notifications: when you submit, the Admin designated to follow up investment interest receives an in-app notification and an email — or, if none is designated, every active Admin receives an in-app notification — carrying your company's name (or the contact name if you gave no company) and the opportunity's title. When WeVisit's team moves your submission to a stage that changes the status you can see ("Under review" / "Contacted" / "Closed"), you receive an in-app notification and an email. When the opportunity itself is awarded or withdrawn, your status shows "Closed" and no notification or email is sent.

2.14 School Visit Requests to Events

Hosting entities list events on the platform, and any registered account can submit a school visit request to an event that accepts them, unless the event belongs to its own institution. The following is stored with the request, linked to your account: the school's name, the contact person's name, the contact phone number and the contact email address (as you type them in the form), the number of students, the educational stage, the preferred date and its time (optional), and your notes (optional); then the request's status (under review / accepted / rejected / cancelled) and the reason for a decision if one was written. The number of requests an account submits within 24 hours is subject to a limit set by Admin (5 by default).

Who sees this data: you, the event's hosting entity, and WeVisit's team (Admin) — each of them sees the whole request, including the contact details you typed and your account name. Nothing from the request appears on the public event pages. The contact details the hosting entity itself adds to its event (a name, a phone number and an email address), on the other hand, are publicly available with the event's data through the public API.

Notifications: when you submit, the institution owner receives an in-app notification and an email (the email unless Admin has switched off new-request emails in the settings) carrying the school's name, the event's name, the number of students and the date — not your name and not the contact details. When your request is accepted, rejected or cancelled by the entity or by Admin, you receive an in-app notification carrying the event's name and the reason if one was written; on a rejection with a written reason an email is also sent to your account's email address. If the event is postponed or cancelled while your request is under review or accepted, you receive an in-app notification with the reason. When you withdraw your request, the institution owner receives an in-app notification that does not carry your name.

2.15 Private Visits

Some destinations let you request a private visit for your group under an offer that WeVisit's team reviews. Submitting a request requires an account with a verified email address, and it is refused for a destination that belongs to your own institution. The following is stored with the request, linked to your account: the requester type (individual / family, company, government entity, tour operator); depending on the type, the organisation's name, the commercial registration number and a tax-invoice request (company), the protocol level and the confidentiality option (government entity), and the licence number (tour operator); then the group size, the guide language, one to three proposed dates, the services you pick, whatever you optionally write about the occasion, accessibility needs (which may include health information) and your notes, the contact person's name and phone number, and your account's email address (copied from your account). As the request proceeds, the following is stored too: the entity's messages to you and your replies, the price quotes the entity sends (amount, date, what the quote includes, how long it is valid, the cancellation policy), the reasons for a rejection or a cancellation, and a timeline of every step. Any payment is made outside the platform; no payment data is stored. The number of requests an account submits within 24 hours is subject to a limit set by Admin (3 by default).

Who sees this data: you, the owner of the destination's institution, and WeVisit's team (Admin) — each of them sees the whole request, including the contact person's name and phone number, your email address, your account name and what you wrote about accessibility needs. A government entity's confidentiality option hides the entity's name from notifications and emails only, not from the request screen of the institution owner. Nothing from the request appears on the public pages; however, a destination with a day taken by a confirmed full-closure private visit refuses regular visit requests for that day with a message saying it is closed for a private visit, without revealing who booked it.

Notifications: the institution owner receives an in-app notification and an email at every step that concerns it: a new request (the email unless Admin has switched off new-request emails), your reply, your acceptance or decline of a quote, your cancellation, and a quote's expiry. You receive an in-app notification and an email to your account's email address when the entity asks for more information (carrying its message), when a quote is sent, revised or withdrawn, when the entity rejects or cancels the request (carrying the reason), when a quote expires, and when the visit is completed (an invitation to rate it). When Admin cancels a request, both sides receive the notification and the email. What reaches the institution owner names the requester by the organisation's name, or "Individual / family" for individuals, or "Government entity (confidential)" for a confidential request, and carries neither your name nor your phone number nor your email address; it may carry the reason you write when declining a quote or cancelling the request. If a new request stays unanswered by the entity for a period set by Admin (48 hours by default), every active Admin receives an in-app notification with the request number and the destination's name, with no email.

3. Who We Share Your Data With

Login audit — live today, for every role. On every email + password sign-in attempt, successful or failed, the system records in its database: the time of the attempt, the IP address it came from, your browser identifier (User-Agent, up to 256 characters), and the outcome, plus the account's phone number if one is on file. A failed attempt is recorded without being linked to any account (the email entered may not be an account at all). A phone-number change (from your settings, or by an Admin) is recorded as an event too, and so is every wrong code that is checked against a live verification code for a password reset or an email verification (time, IP address, browser), an Admin's clearing of the lock on those attempts for your account, an Admin's marking of your email as verified without a code (issue #535), and an Admin's change of your account's email to a different mailbox (issue #543) — these three are recorded with the Admin's id, with no IP address and no email address. The purpose is purely security (abuse detection) and operational (support). You can view the last 20 events on your own account's log from your profile page (GET /api/auth/me/login-audit), and Admin can view any account's log. Rows in this log are deleted automatically once the retention period has elapsed (§5). (Hosting infrastructure may keep generic technical access logs outside the application database, as is normal for any hosting setup, independent of WeVisit specifically.)

4. Purpose of Each Data Item

We collect your data exclusively for: creating and running your account; organizing visit requests (school visit requests and private visits included) and facilitating communication about them between you and the hosting entity through the platform; verifying your identity when resetting your password; arranging contact about the investment opportunities you express interest in; responding to your inquiries and support tickets; sending the newsletter if you subscribed voluntarily; moderating content and rating quality; and complying with any legal obligation.

5. Data Retention

• Account data: for as long as your account stays active, and until you request closure (§7), unless a core record must be kept for regulatory purposes (e.g., financial transaction records, if introduced in the future).
• Temporary email verification link and code (§2.2): cleared from your account immediately when either is used successfully, when a new message is issued in their place, or when either is presented after it has expired (issue #81), or when an administrator changes your email address or marks it verified. Reaching the allowed number of wrong attempts with the code stops the code from being accepted but does not clear them, so the link keeps working (issue #522). A link and code that expired and were neither presented again nor replaced stay on your account (unusable) until one of those cases applies — no timer clears them on its own.
• Phone codes (PhoneOtp, once enabled): their rows are deleted automatically 7 days after issue.
• Login audit (§3): deleted automatically once the retention period set in the LoginAuditRetentionDays setting has elapsed (90 days by default, admin-managed).
• Contact messages and newsletter subscription: until deleted by Admin or deletion is requested.
• Visit requests and visit history: remain in your account's historical record for support and reporting purposes, and are not automatically deleted after any elapsed period.
• Expressions of interest in investment opportunities: remain on record for as long as your account exists, and are not automatically deleted after any elapsed period; Admin can delete any of them. The saved investor profile remains until you delete it yourself or your account is deleted (§7).
• School visit requests (§2.14) and private-visit requests (§2.15): remain on record after they end, and are not automatically deleted after any elapsed period; withdrawing a school visit request sets its status to "cancelled" and does not delete it. They are deleted with your account (§7) or when the institution they were sent to is deleted; private-visit requests are also deleted when their destination is deleted. Deleting a destination does not delete school visit requests, and a published event cannot be deleted.
• Two automated jobs run today: (1) LoginAuditPurgeService, once every 24 hours, deletes exactly: login-audit rows older than the retention period, the Admins' security alerts about wrong codes (§2.8) older than that same period, and phone-code rows older than 7 days. (2) PrivateVisitSweepService, every 10 minutes, updates the status of private-visit requests (§2.15) — a quote's expiry, a visit's completion with its visit record (§2.5), and an alert to Admins about a request left unanswered — and deletes nothing. Neither deletes any other data (accounts, requests, messages, ratings) — those are deleted on request, by Admin from the dashboard for accounts (see "Account deletion" in §7) and for contact messages, and by a manual operation on the database for a newsletter subscription, which has no in-system deletion path.

6. Data Security

Passwords are hashed with BCrypt and never stored in plain text. The platform is served over HTTPS. Authentication uses a JWT sent via the Authorization header, not a cookie. Access to each user's data is restricted by authorization logic based on role and record ownership — see "Ownership scoping" in ANTIGRAVITY_RULES.md.

7. Your Rights Over Your Data

• Access and update: you can update your name, phone number, and password directly from your account settings. Email and role cannot currently be self-edited — contacting support is required to change them.
• Viewing your account's login audit: the last 20 events (time, IP address, browser, outcome) are shown on your profile page (§3).
• Account deletion: ⚠️ Self-service account deletion is not currently available from within the app. To request your account be closed and your data deleted, contact support. What the system carries out on request, as measured on the code: Admin deletes any account from the dashboard in one step, including an account with one or more visit records: the account's own visit requests, ratings, support tickets (with their replies) and phone-verification codes — including login codes recorded against your phone number — its saved companions and the companions of its visits, its school visit requests (§2.14) and private-visit requests (§2.15) with their quotes, messages and timeline, the notifications about them held by institutions and Admins, the Admins' security alerts about the account (§2.8), and the institutions' notifications that carried your name about your visit requests are deleted automatically as part of the same operation; the phone number is blanked on the login-audit rows (§3) linked to the account, and on the rows that carry your number without being linked to any account, with the event, time and IP address kept; the account itself is then removed. The rows of another account holding the same number are not touched. The Visit records are kept for visit-count accuracy with the link to the deleted account cleared, and so are the account's replies — if it was an Admin — on other users' support tickets, shown as "Deleted user". An account that owns an institution is refused until its institution is deleted or reassigned first. A contact message or a newsletter subscription submitted under the same email address is a separate consent and is not affected by the account deletion (§5). Expressions of interest in investment opportunities stay as anonymised rows for opportunity statistics: the name, email, phone, company name, commercial registration number, message and closing reason are blanked, the link to the account is cleared, and their internal notes and related notifications are deleted; the saved investor profile is deleted. Saved companions and the saved investor profile can be self-deleted from within your account at any time. A rating you posted, however, cannot be self-deleted or self-edited once published — deleting a rating is restricted to Admin and the owning institution of the rated destination, for content-moderation purposes; to request your rating be removed, contact support.
• Withdrawing newsletter consent: unsubscribing today happens via a request to support; there is currently no self-service unsubscribe link or page, and the platform itself sends no newsletter messages.
• Filing a complaint: through support, or with the competent regulatory authority in the Kingdom if you believe your rights were not respected.

8. Third-Party Processors and Content Providers

The only personal-data processor actually in use today is Microsoft 365 (SMTP mail, to send verification codes and request/rejection notifications). There is no analytics provider, no advertising provider, and no SMS provider handling your personal data today.

In addition, every page on the platform loads technical resources (fonts, icons, script libraries) from third-party servers: Google Fonts (fonts.googleapis.com, fonts.gstatic.com), Cloudflare cdnjs (cdnjs.cloudflare.com), jsDelivr (cdn.jsdelivr.net), and the Leaflet mapping library via unpkg (unpkg.com). Each request for these resources goes straight from your browser to the third party's server, which reveals your IP address and browser (User-Agent) to it — as with any site using public content-delivery networks (CDNs). Public destination, event and investment-opportunity pages also show a map of the location: when the map is on or near the screen — at page load on a short page, otherwise when you scroll near it — they load the Leaflet mapping library from unpkg (unpkg.com) and map tiles from tile.openstreetmap.org, so those two servers receive your IP address and browser as described above. Institution-owner destination-management pages (and the Admin's institution-detail page) load map tiles from tile.openstreetmap.org and send the address the user types — when a search is requested (the search button, or the Enter key inside the address field; typing alone sends nothing) — to OpenStreetMap's Nominatim geocoding service (nominatim.openstreetmap.org) to convert it into coordinates. The home page (index.html) and the public "Discover Saudi Arabia" page (discover.html) show an interactive map: they load the Leaflet mapping library and its leaflet.markercluster marker-clustering add-on from unpkg (unpkg.com), and map tiles from tile.openstreetmap.org, so those two servers receive your IP address and browser as described above. The "Discover Saudi Arabia" page's "My location" button asks your browser for your location only when you click it; the location is used inside your browser only, to draw a dot on the map and move the map to it, and it is not sent to WeVisit and not stored in the page address or in your browser — but moving the map to your location does make your browser request the map tiles for that area from tile.openstreetmap.org, as happens whenever the map is moved by hand. The "Nearest to you" button on the destinations page (destinations.html) asks your browser for your location only when you click it; the location is used inside your browser only, to sort the destinations by distance, and it is not sent to WeVisit. The destination, event and investment-opportunity pages also offer a button or link (such as "Get directions") that opens Google Maps in a new tab only when you click it — nothing is sent to Google before that. If an event has no coordinates, its page may instead show an external map link that the hosting entity entered, which also opens in a new tab only when you click it. Likewise, if the hosting entity added a link to an external video page (e.g. YouTube) for its destination, the destination page does not embed that page; it shows a play button that opens the link in a new tab only when you click it, and what happens after that is governed by that site's policy. A video file uploaded to WeVisit (§2.11), on the other hand, plays inside the page and your browser fetches it from WeVisit's own server on page load. The platform does not accept a direct link to a video file on an external host; any such link entered before that opens in a new tab only when you click it. None of this is analytics or tracking (no Google Analytics, no Facebook Pixel, or similar — see §2.12), but these are third parties that receive technical connection data (your IP) on every page load.

Once an SMS provider is enabled, that SMS provider becomes a new personal-data processor delivering phone-verification and phone-login codes (issue #42). The selected provider is Msegat; the actual integration is currently blocked on approval of the sender name "WEVISIT" with the carrier (issue #41), and was measured as not enabled on production on 2026-09-14 (§2.1); this section will be updated once the integration is complete and actually live in production.

9. Children

The platform is intended for general use; we do not knowingly collect children's data without guardian supervision. The "age" field is optional at individual-visitor registration and is not currently used for any automated age check.

10. Changes to This Policy

This policy may be updated as what we actually collect changes (such as phone login being enabled under issue #42). Any material amendment is published with the "Last updated" date refreshed and the policy version number (TermsVersion) — the one recorded with each self-registered account's consent (§2.1) — updated, and requires the CEO's prior approval, exactly as this document itself does.

11. Contact

To ask about this policy or exercise your rights, reach us via the "Contact Us" page or the email address published in the site footer (an admin-managed setting).