نجوم المشاركات

اما فكرتي هذه ......... وهي حتى الان غير قابلة للنشر ..... 💡 نظام متكامل لإدارة صلاحيات المستخدمين في Microsoft Access يهدف هذا البرنامج إلى توفير تحكم كامل ومرن في صلاحيات المستخدمين داخل قاعدة بيانات Access، بحيث يتم تخصيص الصلاحيات على مستوى النماذج والأزرار بشكل دقيق، مما يعزز الأمان وسهولة الاستخدام. 🔐 أولاً: إدارة صلاحيات النماذج يوفر النظام إمكانية التحكم في صلاحيات المستخدم لكل نموذج على حدة، وتشمل: ➕ إضافة بيانات (Add) ✏️ تعديل بيانات (Edit) ❌ حذف بيانات (Delete) حيث يمكن تحديد ما إذا كان المستخدم: يملك صلاحيات كاملة أو صلاحيات محدودة (عرض فقط أو إضافة بدون تعديل… إلخ) 🎛️ ثانياً: التحكم في الأزرار داخل النماذج يتميز النظام بإدارة ذكية لواجهة المستخدم من خلال: إظهار الأزرار المصرح بها فقط حسب صلاحيات المستخدم إخفاء الأزرار غير المسموح بها تلقائيًا إعادة ترتيب الأزرار ديناميكيًا بحيث: لا تظهر أي فراغات يتم عرض الأزرار بشكل متتالي ومنظم الحفاظ على الشكل الجمالي للنموذج 🎨 ثالثاً: تخصيص واجهة المستخدم يوفر البرنامج مرونة عالية في تخصيص الواجهة، مثل: ✍️ التحكم في مسميات الأزرار بسهولة 🖼️ تغيير أيقونات الأزرار 🏠 تخصيص الشاشة الرئيسية: أسماء العناصر الأيقونات ترتيب العرض وذلك بدون الحاجة لتعديل الكود، بل من خلال جداول إعدادات مخصصة. ⚙️ رابعاً: مميزات إضافية نظام يعتمد على مستويات المستخدمين (User Levels / Groups) سهولة التوسع وإضافة صلاحيات جديدة إمكانية ربط الصلاحيات بجداول لسهولة الإدارة واجهة ديناميكية تتكيف مع كل مستخدم تلقائيًا 🔐 خامساً: إدارة كلمات المرور واستعادتها يدعم النظام آليات متقدمة لإدارة حسابات المستخدمين، مما يعزز مستوى الأمان وسهولة الاستخدام، وتشمل: 📧 استعادة كلمة المرور عبر البريد الإلكتروني إمكانية استرجاع كلمة المرور في حال نسيانها إرسال رابط أو رمز تحقق (OTP) إلى البريد الإلكتروني الخاص بالمستخدم التحقق من هوية المستخدم قبل إعادة تعيين كلمة المرور ضمان حماية الحساب من الوصول غير المصرح به 🔄 تغيير كلمة المرور تمكين المستخدم من تغيير كلمة المرور الخاصة به في أي وقت التحقق من كلمة المرور الحالية قبل التغيير تطبيق سياسات أمان (مثل الحد الأدنى لطول كلمة المرور أو تعقيدها) حفظ كلمة المرور بشكل آمن (مشفّر) داخل قاعدة البيانات 🚀 الخلاصة هذا النظام يوفر بيئة عمل احترافية داخل Access من خلال: تعزيز الأمان تحسين تجربة المستخدم تقليل الأخطاء توفير واجهة مرنة وقابلة للتخصيص بالكامل القيديو يلخص ذلك :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

السلام عليكم هذة فكرة طرات في بالي منذ فترة ولكن لم اعمل على تطوريها او تجربتها المشكلة ان هناك اقسام للمستخدمين ولكن بعض المستخدمين لهم صلاحيات مخصصة والبعض لا ومن هنا جائت الفكرة الفكرة تعتمد على وجود جدول يحتوي على الازرار في صورة Btn ID (يتم حفظه داخل Btn Tag) و ID المستخدم مع امكانيات الاظهار و التمكين وعند فتح النموذج يقوم النموذج بمراجعة صلاحيات كل زر الهدف من استخدام Btn ID داخل الـ Tag هو اختصار الكثير من الازار داخل مجموعة من الـ Btns IDs (مجموعة من الازار لهم جميعا نفس الـ Btn ID) هي مجرد فكرة ولكن اتمنى راي حضراتكم

تمام لكن ممكن حضرتك تعمل صفحة اكسل وبها العمليات المطلوبة وتحت كل عملية مراحلها كما تتصور انت . وانا حاضر لك .

تفضل استاذ @أحمد الشحات85 الشرح والمرفق بعد التعديل بطلبك . ووافني بالرد . Ahmed ElShahat_2.rar

هذا الشيئ طبيعي فالبيانات تكون قليلة والأكواد مازالت في أول إصدار لها (أي أنها مثالية وفقاً للدراسة التي تمت عند التصميم) وهذا الشيئ أيضا طبيعي فأنت لا تقوم بأي عملية تطوير إلا لحل مشكلة طارئة أو تحسين وتبسيط للمهام بحسب طلب المستخدمين وأول ماستفكر به هو طالما وأن البرنامج يعمل بطريقة سليمة فسأبقي الوضع على ماهو عليه وسأقوم بإضافة بعض التعليمات البرمجية الجديدة التي من شأنها حل المشكلة التي طرأت أو تنفيذ التحسين المطلوب ولكنك وبدون أن تشعر تكون قد أضفت أعباء جديدة على البرنامج والتي تتراكم لتسبب بعض التأخير الذي يزداد مع زيادة حجم البيانات ليصبح التأخير مزعجاً. بالإضافة لما جاء ضمن رد الأخ @jjafferr فنصيحتي هنا أنه عند الوصول لهذه المرحلة فأن الأمر يتطلب منك مراجعة شاملة للبرنامج من حيث - إعادة بناء قاعدة البيانات بطريقة علمية سليمة وذلك لعدة أسباب منها - أن من ضمن الحلول التي كنت تضعها من المؤكد أنك قد تضطر لإجراء بعض التعديلات على الجداول - عند إنشاء البرنامج لأول مرة قد ترى أن هناك حقول لاتستدعي منك فصلها في جداول مستقلة ولكن مع تضخم البيانات فإن الأكواد التي تقوم بإسترجاع البيانات من هذه الحقول سيقل أداؤها لذلك سيكون من الافضل فصلها في جداول مستقلة وهذا ما سينتج عنه تسريع في الأداء - عدم التعامل مع بيانات الجدول مباشرة بل مع بيانات مفلترة منه (ماذا اقصد ؟) الان عندما تقوم بتحديد الجدول كاملاً كمصدر لبيانات النموذج او التقرير فإنه يتم تحميل جميع بياناته في كل مرة تقوم بفتح هذا النموذج او التقرير لذلك يفضل أن يتم فتح النموذج على بيانات محددة مثلاً نموذج المبيعات يفضل أن يرتبط ببيانات العام او الشهر الحالي فقط وهذا سيؤدي الى تحسن في سرعة الاداء تزداد ملاحظته مع زيادة حجم البيانات كذلك عمليات البحث كلما كانت عينة البحث اصغر كان البحث أسرع لذلك وعلى سبيل المثال عندما يكون لدينا كود يقوم باستخدام دوال تجميع المجال لإسترجاع بيانات من إستعلام يحتوي بيانات سنة مالية واحدة سيكون أداؤه اسرع من نفس الكود لو كان يبحث في الجدول ككل - تطبيق مفهوم الأرشفة مفهوم الارشفة يقوم على فصل البيانات التاريخية وإستبدالها بجداول تحتفظ ببيانات إحصائية للرجوع اليها في حال الاحتياج لها للتقارير طبعا هذا يعتمد على طريقة عمل كل شركة ورؤية المطور فإذا رأي المطور أن الاحتياج للبيانات التاريخية يقل للحد الادنى مع مرور الوقت فيمكنه اقتراح الفكرة لانشاء الية عمل تشبه آلية انشاء السنة المالية الجديدة حيث يتم فيها أرشفة البيانات التاريخية كل سنة بترحيل بيانات السنة السابقة الى قاعدة بيانات جديدة والاحتفاظ ببيانات احصائية منها (كآرصدة اول الفترة) وتصفية الجداول من جميع البيانات لتبدأ من الصفر للسنة المالية الجديدة بهذا سيظل البرنامج دائما خفيفا وسريعا - اعادة دراسة وتقييم التعليمات البرمجية من واقع تجربتي فإني أحياناُ كثيرة وأثناء مراجعتي لأكواد قديمة قمت بكتابنها في أكثر من تطبيق تكون ردة فعلي (بماذا كنت أفكر وقتها ؟؟؟) أو أضحك على بساطته وأعتقد أن الكثير منا مر بنفس التجربة وهذا شيئ طبيعي فمع مرور الوقت وتراكم الخبرة تجد أن ما كنت تعالجه بكود يحتوي عشرات الأسطر بإمكانك معالجته بكود لايتعدى العشرة أسطر كذلك الحال في الحالات التي ذكرتها في بداية كلامي فأنك قد تضطر إلى إضافة أكواد لحل مشاكل طارئة أو تبسيط مهام وتقضل إضافة الأكواد بدون مساس للاكواد الحالية وهذا قد يؤدي (وعن غير قصد) إلى مضاعفة العمل أو التعارض مع تعليمات برمجية قائمة وتحميلها بأعباء إضافية لم تنتبه لها في حينه أو إنتبهت لها ولكنك تجاهلتها إما لضيق الوقت أو لأثرها الغير ملحوظ وقتها على الاداء ومن خلال عملية إعادة دراسة وتقييم التعليمات البرمجية يمكنك إعادة كتابة التعليمات البرمجية التي يمكن إختصارها وتحسينها وهذا سيكون له الأثر الكبير في الأداء وعلى فكرة هذه العملية هي إجراء قياسي يقوم به جميع مطوري البرامج فدائماً ما يتم تنزيل تحديثات بسيطة لبرامج ويندوز تقوم بتصحيح أو إصلاح مشكلات بسيطة وفجأة نجد تحديث كبير ينتج عنه إصدار جديد كليا من البرنامج وغالبا مايكون بسبب تطوير شامل للبرنامج من حيث المظهر والوظائف تنويه - كل الملاحظات والنصائح المذكورة أعلاه هي مجرد تسليط للضوء على أهم أسباب تباطؤ تطبيقات أكسس (المرتبطة بالكائنات التابعة لأكسس) وطرق معالجتها وأريد على التأكيد على أنها لا تشمل كل الأسباب أو كل الحلول إنما هي أهم الأسباب والحلول (من وجهة نظري) يوجد أيضاً أسباب أخرى تكون مرتبطة بالشبكة والتي يكون حلها بأحد حلين (برمجي Software أو عتاد Hardware) - الحل البرمجي يقوم به المطور خصوصاً بتطبيق النصيحة الثانية المذكورة أعلاه (إستخدام البيانات المفلترة) فقد تكون المشكلة غير ملموسة عند العمل في الوضع العادي (قاعدة البيانات المحلية) ولكن يمكن أن تظهر عند العمل من خلال الشبكة لذلك سيكون من الأفضل تصفية البيانات التي يتم العمل معها إلى الحد الأدنى حتى لايتم تحميل الشبكة ببيانات إضافية لن يحتاجها المستخدم أثناء العمل. - الحل الثاني وهو مرتبط بالتجهيزات وخدمة الإتصال بالسيرفر وهذا الحل يجب أن يتم فيه إستشارة مهندسي الشبكات فهم من سيقدمون الحل الأفضل للمشكلة حيث سيكون لديهم الخبرة الكافية في أنواع التجهيزات الحديثة وأفضل أنواع الكابلات وأسرع خدمة إتصال يمكن الحصول عليها . الملاحظة التي يجب ذكرها أن الحل الثاني يعتمد إعتماداً كلياً على أداء التطبيق في الوضع العادي (قاعدة البيانات المحلية) فمن غير المعقول أن أبحث عن حل لمشكلة الشبكة والبرنامج أصلاً بطئ حتى بدون شبكة. في الأخير أرجو أن أكون قد قدمت فكرة بسيطة عن أهم مشاكل تباطؤ تطبيقات الأكسس