Forwarded from هندسة قواعد البيانات | امن سبراني وحاسوب
تطبيق واقعي لمفاهيم abstraction and polymorphism
تعال اذكرك بشيء انت سبق لك التعامل معه،
المجلدات
والملفات: ملفات نصية، ورد، اكسل وغيرها..
وطبعا تقدر تسوي للمجلد:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،
وكذلك اي ملف تقدر تسوي له:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،
لكن لو تركز معي، هل الطريقة مختلفة اللي تسوي به حذف لملف وحذف لمجلد؟ طبعا لا ولا يوجد اي اختلاف اتعامل معهم بنفس الطريقة وليس بطريقة مختلفة... هذا هو جوهر الabstraction
طيب لو جينا الان نشتي نطبق التجريد، بالبرمجة الكائنية معانا الpolymorphism
طيب ليش تعدد الاشكال؟ بقلك التجريد يقول اتعامل مع اشياء تنتمي لنفس العائلة بنفس الطريقة..
لكن لو قلت لك لمن تضغط حذف لمجلد، هل هي نفس الخطوات اللي لو كان الحذف على ملف؟ اكيد مختلف،
وبما انه مختلف السلوك، ومشترك بالهدف، فاختلاف السلوك يخلينا بحاجه لpolymorphism بحيث كل كائن يعيد ويطبق السلوك الذي يتناسب معه....
تمرين:
اذهب الى ويندوز واضغط خصائص على مجلد، او ملف اي ملف، ستجد ان فيه عمليات مشتركة:
فتح
حذف
اعادة تسميه
نقل
نسخ
عرض التفاصيل
انشاء ملف او مجلد ،
المطلوب تصميم كلاس اب، يورث لكلاس مجلد، وكلاس ملف،بحيث يحتوي على الدوال المشتركة، ويتم عمل لها overriding حسب الكلاس الابن..
كلاهما يشتركان بنفس الوظائف والصفات ايضا،
ونحن نتعامل مع الملف والمجلد بنفس الطريقة مافيش اي شيء مختلف سواء لو نشتي نحذف، او نغير الاسم، او نقل او نسخ، او عرض التفاصيل كلها تتعامل معها بطريقة موحدة، لكن يختلف التنفيذ لكل عملية سحب هل الكائن مجلد، ام ملف وهكذا....
تعال اذكرك بشيء انت سبق لك التعامل معه،
المجلدات
والملفات: ملفات نصية، ورد، اكسل وغيرها..
وطبعا تقدر تسوي للمجلد:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،
وكذلك اي ملف تقدر تسوي له:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،
لكن لو تركز معي، هل الطريقة مختلفة اللي تسوي به حذف لملف وحذف لمجلد؟ طبعا لا ولا يوجد اي اختلاف اتعامل معهم بنفس الطريقة وليس بطريقة مختلفة... هذا هو جوهر الabstraction
طيب لو جينا الان نشتي نطبق التجريد، بالبرمجة الكائنية معانا الpolymorphism
طيب ليش تعدد الاشكال؟ بقلك التجريد يقول اتعامل مع اشياء تنتمي لنفس العائلة بنفس الطريقة..
لكن لو قلت لك لمن تضغط حذف لمجلد، هل هي نفس الخطوات اللي لو كان الحذف على ملف؟ اكيد مختلف،
وبما انه مختلف السلوك، ومشترك بالهدف، فاختلاف السلوك يخلينا بحاجه لpolymorphism بحيث كل كائن يعيد ويطبق السلوك الذي يتناسب معه....
تمرين:
اذهب الى ويندوز واضغط خصائص على مجلد، او ملف اي ملف، ستجد ان فيه عمليات مشتركة:
فتح
حذف
اعادة تسميه
نقل
نسخ
عرض التفاصيل
انشاء ملف او مجلد ،
المطلوب تصميم كلاس اب، يورث لكلاس مجلد، وكلاس ملف،بحيث يحتوي على الدوال المشتركة، ويتم عمل لها overriding حسب الكلاس الابن..
كلاهما يشتركان بنفس الوظائف والصفات ايضا،
ونحن نتعامل مع الملف والمجلد بنفس الطريقة مافيش اي شيء مختلف سواء لو نشتي نحذف، او نغير الاسم، او نقل او نسخ، او عرض التفاصيل كلها تتعامل معها بطريقة موحدة، لكن يختلف التنفيذ لكل عملية سحب هل الكائن مجلد، ام ملف وهكذا....
Forwarded from Hussein
فرصة ذهبية متاحة للتقديم على موقع Yemen HR
https://yemenhr.com/jobs/backend-developer-qasemi-islamic-bank-sanaa-8b770764
مشاركة طيبة من الأخ والزميل أسامة الأسد بارك الله فيه🖤✨
https://yemenhr.com/jobs/backend-developer-qasemi-islamic-bank-sanaa-8b770764
مشاركة طيبة من الأخ والزميل أسامة الأسد بارك الله فيه🖤✨
Yemenhr
Backend Developer at Qasemi Islamic Bank | Yemen HR
Apply for Backend Developer at Qasemi Islamic Bank in Sana'a. Application deadline: 13 Jul, 26. Find details and how to apply on Yemen HR.
Forwarded from ن
التحليل من تحلل الشيء إذا تفسَّخت أجزاؤُه وانفصلت عناصرُه بعضُها عن بعض، وهذا الفصل مهم لأنه يصعب فهم الشيء أو المشكلة دفعة واحدة (والبرنامج كلما كبر زاد تعقيده حتى يستحيل على العقل أن يتصوره في ذهنه كاملا)، وعليك رد الشيء إلى عناصره ثم البحث في العلائق الرابطة بين هذه الأجزاء حتى تكون الصورة واضحة
وهو مهم لأن الحكم على الشيء فرع من تصوره كما يقول المناطقة، وقبل حل المشكلة عليك فهمها، فلا يعقل أن تبرمج للعميل برنامجاً لا تفهمه، فالتحليل هو الباب للفهم، والفهم أول الخطوات لحل المشكلة، وفهم المشكلة هي أول خطوة وضعها عالم الرياضيات جورج بوليا في كتابه How to Solve it
وهو مهم لأن الحكم على الشيء فرع من تصوره كما يقول المناطقة، وقبل حل المشكلة عليك فهمها، فلا يعقل أن تبرمج للعميل برنامجاً لا تفهمه، فالتحليل هو الباب للفهم، والفهم أول الخطوات لحل المشكلة، وفهم المشكلة هي أول خطوة وضعها عالم الرياضيات جورج بوليا في كتابه How to Solve it
Forwarded from Abdulrahman
وإذا فُهمت المشكلة بشكل خاطئ أو ناقص من البداية، فإن التصميم كله يُبنى على أساس خاطئ، وكل قرار لاحق (قاعدة البيانات، الواجهات، البنية) يرث هذا الانحراف. وقد يكتشف الفريق الانحراف غالبًا في مرحلة متأخرة حين تكون تكلفة التصحيح مرتفعة
Forwarded from Abdulrahman
Abdulrahman
وإذا فُهمت المشكلة بشكل خاطئ أو ناقص من البداية، فإن التصميم كله يُبنى على أساس خاطئ، وكل قرار لاحق (قاعدة البيانات، الواجهات، البنية) يرث هذا الانحراف. وقد يكتشف الفريق الانحراف غالبًا في مرحلة متأخرة حين تكون تكلفة التصحيح مرتفعة
وافضل تشبيه طائرة ارادت الاقلاع من المطار في المصدر الى مطار في الوجهه لو انها انحرفت قليلا فان الخطأ يتراكم طرديا مع المسافة
الشاهد من هذا القول الاهم في رحلة بناء السوفتوير هو وصف المشكلة توصيفا دقيقا
الشاهد من هذا القول الاهم في رحلة بناء السوفتوير هو وصف المشكلة توصيفا دقيقا
Forwarded from هندسة قواعد البيانات | امن سبراني وحاسوب
رحلة تامل قوة الOOP
كان لدي مشكلة مع تكرار كتابة الحقول في كل اغلب الكيانات والكود يتكرر وقواعد تحقق كثيرة
created at
created by
updated at
updated by
is edited
deleted at
deleted by
is deleted
activated at
activated by
deactivate at
deactivate by
approved at
approved by
rejected at
rejected by
rejectiion Reason
فكرت بالامر، قلت لماذا لا نسوي لهم كلاس ونورث لغيره منهم؟
اجبت حسنا، لكن ماذا لو الكلاس لا يحتاج كلهم؟ بل بعض منهما؟
السؤال الثاني ماذا لوكان الكيان هذا ينتمي لعائلة اي كلاس اب لا يمكن توريث الكلاس من ابوين...
قلت هل ثمة شيء درسته واقدر استفيد منه؟
تذكرت مبدا الinterface segregation حيث ذهبت وقسمتهما الى واجهات مستقله :
ICreatable
IUpdatable
IDeletable
IActivable
IApprovable
IRejectable
ثم اقوم بعمل كلاسات مجردة، تطبق هذا وتورث له والمطور يقوم باختيار الذي يناسبه..
لكن واجهتني مشكلة مع المعرفات ID بعضهما يستخدم رقم والاخر guid
قلت لنفسي ما الذي يمكنك من تحديد النوع لاحقا؟
الgenerics فكان لها قوة حقيقية مع ال interface
كان لدي مشكلة مع تكرار كتابة الحقول في كل اغلب الكيانات والكود يتكرر وقواعد تحقق كثيرة
created at
created by
updated at
updated by
is edited
deleted at
deleted by
is deleted
activated at
activated by
deactivate at
deactivate by
approved at
approved by
rejected at
rejected by
rejectiion Reason
فكرت بالامر، قلت لماذا لا نسوي لهم كلاس ونورث لغيره منهم؟
اجبت حسنا، لكن ماذا لو الكلاس لا يحتاج كلهم؟ بل بعض منهما؟
السؤال الثاني ماذا لوكان الكيان هذا ينتمي لعائلة اي كلاس اب لا يمكن توريث الكلاس من ابوين...
قلت هل ثمة شيء درسته واقدر استفيد منه؟
تذكرت مبدا الinterface segregation حيث ذهبت وقسمتهما الى واجهات مستقله :
ICreatable
IUpdatable
IDeletable
IActivable
IApprovable
IRejectable
ثم اقوم بعمل كلاسات مجردة، تطبق هذا وتورث له والمطور يقوم باختيار الذي يناسبه..
لكن واجهتني مشكلة مع المعرفات ID بعضهما يستخدم رقم والاخر guid
قلت لنفسي ما الذي يمكنك من تحديد النوع لاحقا؟
الgenerics فكان لها قوة حقيقية مع ال interface
Forwarded from abdullah
شوفاهم حاجة انك تعمل السيرفر في منطقة قريبة مثل سنغافور ، اليابان ، الصين
Forwarded from abdullah
انا اشتريت واحدة في امريكا خلي على ربك بعض الاحين زمن الاستجابة بيتاخر لوما تضبح
[٧/٧، ٧:٢٢ ص] أ. انور السياري IT: # Feature Specification: Tenant Relationship Lifecycle
Feature Branch:
Created: 2026-07-07
Status: Draft
Input: User description: "Rebuild and improve the TenantRelationship stored procedure family so it supports invitation, approval, rejection, suspension, reactivation, soft deletion, restoration, status updates, permission updates, role updates, service updates, validation, account creation, and consistent result contracts without creating new tables."
## User Scenarios & Testing *(mandatory)*
User stories are written as independently testable database and business workflows. Each story must be verified with tenant-scoped SQL examples that prove the resulting relationship row, related service/permission rows, related account row, audit log, rollback behavior, and structured result payload.
### User Story 1 - Invite User Into Tenant Relationship (Priority: P1)
A tenant owner or authorized administrator invites an existing user to establish a specific tenant relationship type, such as customer, supplier, accountant, sales employee, purchase employee, bank/cash, or deposit customer. The invitation records the tenant, invited user, relationship type, intended account parent from the relationship type, requested services, requested permissions, requested roles, and invitation metadata without activating access before approval.
Why this priority: Invitation is the entry point for every later lifecycle step. Duplicate or unauthorized invitations create financial-account ambiguity and permission leakage.
Independent Test: Execute the rebuilt invitation procedure with an authorized creator, active tenant, active device, active relation type, and optional services/permissions/roles payload; assert exactly one pending relationship row exists for
Acceptance Scenarios:
1. Given an active tenant, an active invited user, an active creator relationship allowed to invite, and an active relationship type, When the invitation procedure runs, Then a pending tenant relationship is created once, related requested service/permission/role metadata is staged consistently, and the response identifies the relationship.
2. Given an existing active, pending, suspended, disabled, rejected, or deleted relationship for the same tenant, user, and relationship type, When a duplicate invitation is attempted, Then the operation returns a structured conflict error and leaves all relationship, service, permission, role, account, and log state unchanged.
3. Given a creator without the required tenant relationship or permission, When the invitation procedure runs, Then the operation returns a structured permission error and no rows are written.
---
### User Story 2 - Approve Invitation And Create Financial Account (Priority: P1)
The invited user, or a tenant owner/authorized administrator acting on behalf of that user, approves a pending invitation. Approval activates the relationship and creates or reuses the proper tenant financial account for the invited user under the tenant chart of accounts based on the relationship type.
Why this priority: Relationship approval grants access and connects the user to tenant financial accounting. Account creation must be idempotent to prevent duplicate customer, supplier, employee, or bank accounts.
Independent Test: Approve a pending relationship twice under controlled data. The first approval activates the relationship and creates or links one tenant account with
Acceptance Scenarios:
Feature Branch:
[001-tenant-relationship-lifecycle]Created: 2026-07-07
Status: Draft
Input: User description: "Rebuild and improve the TenantRelationship stored procedure family so it supports invitation, approval, rejection, suspension, reactivation, soft deletion, restoration, status updates, permission updates, role updates, service updates, validation, account creation, and consistent result contracts without creating new tables."
## User Scenarios & Testing *(mandatory)*
User stories are written as independently testable database and business workflows. Each story must be verified with tenant-scoped SQL examples that prove the resulting relationship row, related service/permission rows, related account row, audit log, rollback behavior, and structured result payload.
### User Story 1 - Invite User Into Tenant Relationship (Priority: P1)
A tenant owner or authorized administrator invites an existing user to establish a specific tenant relationship type, such as customer, supplier, accountant, sales employee, purchase employee, bank/cash, or deposit customer. The invitation records the tenant, invited user, relationship type, intended account parent from the relationship type, requested services, requested permissions, requested roles, and invitation metadata without activating access before approval.
Why this priority: Invitation is the entry point for every later lifecycle step. Duplicate or unauthorized invitations create financial-account ambiguity and permission leakage.
Independent Test: Execute the rebuilt invitation procedure with an authorized creator, active tenant, active device, active relation type, and optional services/permissions/roles payload; assert exactly one pending relationship row exists for
(tenantId, userId, typeId), no active access is granted yet, a tenant log exists, and the result includes a success code, message, and relationship key.Acceptance Scenarios:
1. Given an active tenant, an active invited user, an active creator relationship allowed to invite, and an active relationship type, When the invitation procedure runs, Then a pending tenant relationship is created once, related requested service/permission/role metadata is staged consistently, and the response identifies the relationship.
2. Given an existing active, pending, suspended, disabled, rejected, or deleted relationship for the same tenant, user, and relationship type, When a duplicate invitation is attempted, Then the operation returns a structured conflict error and leaves all relationship, service, permission, role, account, and log state unchanged.
3. Given a creator without the required tenant relationship or permission, When the invitation procedure runs, Then the operation returns a structured permission error and no rows are written.
---
### User Story 2 - Approve Invitation And Create Financial Account (Priority: P1)
The invited user, or a tenant owner/authorized administrator acting on behalf of that user, approves a pending invitation. Approval activates the relationship and creates or reuses the proper tenant financial account for the invited user under the tenant chart of accounts based on the relationship type.
Why this priority: Relationship approval grants access and connects the user to tenant financial accounting. Account creation must be idempotent to prevent duplicate customer, supplier, employee, or bank accounts.
Independent Test: Approve a pending relationship twice under controlled data. The first approval activates the relationship and creates or links one tenant account with
relatedUserId and the relationship type's account parent. The second approval returns the existing activated relationship and account or a clear already-approved result, without creating a duplicate account.Acceptance Scenarios:
1. Given a pending invitation and a relationship type whose description defines the account parent and debit/credit behavior, When approval runs, Then the relationship becomes active, the account is created or reused exactly once, the relationship stores the resulting account id, tenant balances are initialized where required by the account contract, and a tenant log is written.
2. Given a pending invitation whose target account already exists for the same tenant, related user, and relationship type, When approval runs, Then the procedure links the existing active account and does not create another account.
3. Given a rejected, deleted, suspended, disabled, or nonexistent invitation, When approval is attempted, Then the operation returns a structured status-transition error and no partial account, service, permission, role, or log changes survive.
---
### User Story 3 - Reject Invitation (Priority: P1)
The invited user, tenant owner, or authorized administrator rejects a pending invitation with an optional reason. Rejection closes the invitation without creating or activating financial accounts or relationship service access.
Why this priority: Users and tenant administrators must be able to decline relationship requests without leaving ambiguous or half-active access.
Independent Test: Reject a pending invitation and then query the relationship, services, permissions, roles, accounts, and logs. Assert the relationship has the rejected status, no account was created for the rejection, related service access is not active, and the audit record includes the rejection reason.
Acceptance Scenarios:
1. Given a pending invitation, When the target user or authorized administrator rejects it, Then the relationship becomes rejected, no active relationship services are enabled, no financial account is created by rejection, and the response includes the rejected relationship key.
2. Given an active, deleted, disabled, suspended, or already rejected relationship, When rejection is attempted, Then the procedure returns a structured transition error and rolls back all changes.
---
### User Story 4 - Suspend, Disable, Reactivate, Soft Delete, And Restore (Priority: P2)
Tenant administrators manage existing relationships after approval. They can suspend or disable active relationships, reactivate suspended or disabled relationships, soft-delete relationships, and restore deleted relationships while preserving audit history and related service access state.
Why this priority: Tenant access must be reversible and auditable without physically deleting relationship history or breaking financial references.
Independent Test: Move an active relationship through disabled, reactivated, suspended, soft-deleted, and restored states. Assert only permitted transitions succeed, deleted relationships are hidden from active validation, restoration returns to the pre-delete status, and relationship service rows follow the same lifecycle rules.
Acceptance Scenarios:
1. Given an active relationship, When an authorized administrator suspends or disables it, Then the relationship validation procedures deny operational access, related services are disabled or suspended consistently, and a tenant log records the action.
2. Given a suspended or disabled relationship, When an authorized administrator reactivates it, Then the relationship becomes active only if the tenant, user, device, relationship type, account, services, permissions, and roles are valid.
3. Given a non-deleted relationship, When it is soft-deleted, Then relationship and related service access move to deleted-compatible statuses, active validation stops returning the relationship, and no physical row is removed.
4. Given a deleted relationship, When it is restored, Then the relationship returns to its pre-delete active, disabled, suspended, or rejected state where valid, and the response includes the restored related services.
---
2. Given a pending invitation whose target account already exists for the same tenant, related user, and relationship type, When approval runs, Then the procedure links the existing active account and does not create another account.
3. Given a rejected, deleted, suspended, disabled, or nonexistent invitation, When approval is attempted, Then the operation returns a structured status-transition error and no partial account, service, permission, role, or log changes survive.
---
### User Story 3 - Reject Invitation (Priority: P1)
The invited user, tenant owner, or authorized administrator rejects a pending invitation with an optional reason. Rejection closes the invitation without creating or activating financial accounts or relationship service access.
Why this priority: Users and tenant administrators must be able to decline relationship requests without leaving ambiguous or half-active access.
Independent Test: Reject a pending invitation and then query the relationship, services, permissions, roles, accounts, and logs. Assert the relationship has the rejected status, no account was created for the rejection, related service access is not active, and the audit record includes the rejection reason.
Acceptance Scenarios:
1. Given a pending invitation, When the target user or authorized administrator rejects it, Then the relationship becomes rejected, no active relationship services are enabled, no financial account is created by rejection, and the response includes the rejected relationship key.
2. Given an active, deleted, disabled, suspended, or already rejected relationship, When rejection is attempted, Then the procedure returns a structured transition error and rolls back all changes.
---
### User Story 4 - Suspend, Disable, Reactivate, Soft Delete, And Restore (Priority: P2)
Tenant administrators manage existing relationships after approval. They can suspend or disable active relationships, reactivate suspended or disabled relationships, soft-delete relationships, and restore deleted relationships while preserving audit history and related service access state.
Why this priority: Tenant access must be reversible and auditable without physically deleting relationship history or breaking financial references.
Independent Test: Move an active relationship through disabled, reactivated, suspended, soft-deleted, and restored states. Assert only permitted transitions succeed, deleted relationships are hidden from active validation, restoration returns to the pre-delete status, and relationship service rows follow the same lifecycle rules.
Acceptance Scenarios:
1. Given an active relationship, When an authorized administrator suspends or disables it, Then the relationship validation procedures deny operational access, related services are disabled or suspended consistently, and a tenant log records the action.
2. Given a suspended or disabled relationship, When an authorized administrator reactivates it, Then the relationship becomes active only if the tenant, user, device, relationship type, account, services, permissions, and roles are valid.
3. Given a non-deleted relationship, When it is soft-deleted, Then relationship and related service access move to deleted-compatible statuses, active validation stops returning the relationship, and no physical row is removed.
4. Given a deleted relationship, When it is restored, Then the relationship returns to its pre-delete active, disabled, suspended, or rejected state where valid, and the response includes the restored related services.
---
### User Story 5 - Maintain Permissions, Roles, Services, And Query Contracts (Priority: P2)
Tenant administrators update a relationship's permissions, assigned roles, and available services after invitation or approval. Callers can select one or many relationships with tenant isolation, filters, pagination, related service data, account data, and consistent result envelopes.
Why this priority: Relationship lifecycle behavior is incomplete if users cannot control what the relationship can access after it is created.
Independent Test: Update services, permissions, and roles for an active relationship and validate that selection procedures and validation procedures reflect the new access immediately while rejecting inactive, deleted, unauthorized, duplicate, or tenant-mismatched assignments.
Acceptance Scenarios:
1. Given an active relationship and a valid payload of tenant services and tenant permissions, When the service/permission update procedure runs, Then related rows are inserted, updated, disabled, or deleted according to the requested mode without duplicates and with a tenant log.
2. Given valid role assignments represented by existing relationship type, permission, user-permission, service, or relationship metadata, When roles are updated, Then the relationship validation procedure enforces the assigned roles consistently across future operations.
3. Given a caller with select permission, When list and single-select procedures run, Then results are tenant-scoped, paginated where applicable, exclude deleted rows by default, support explicit status filters, and include relevant account/service/permission/role context.
[٧/٧، ٧:٢٢ ص] أ. انور السياري IT: وصف المتطلبات بأسلوب Agile
[٧/٧، ٧:٣٣ ص] أ. انور السياري IT: الخطوة التالية يقوم رئيس الفريق او المطور المستلم للمتطلبات بتفصيل المتطلبات الى مهام ثم يتم رفعها الى taskissues على نفس البرنش ليبدء اعضاء الفريق العمل عليها ومراقبة التقدم في انجازها
[٧/٧، ٧:٣٤ ص] أ. انور السياري IT: # Tasks: Tenant Relationship Lifecycle
Prerequisites: plan.md, spec.md, research.md, data-model.md, contracts/
Tests: Runnable SQL examples are mandatory for this database feature.
Organization: Tasks are grouped by user story so each story can be implemented and tested independently.
## Phase 1: Setup (Shared Infrastructure)
Purpose: Establish the feature boundary, compatibility fixes, and canonical references.
- [ ] T001 Inventory affected TenantRelationship SQL files and current compile blockers in
- [ ] T002 Confirm no-new-table implementation boundary in
- [ ] T003 [P] Prepare relationship lifecycle example conventions in
---
## Phase 2: Foundational (Blocking Prerequisites)
Purpose: Define shared SQL contracts that block user story work.
CRITICAL: No user story work can begin until this phase is complete.
- [ ] T004 Make
- [ ] T005 Fix the
- [ ] T006 Update
- [ ] T007 [P] Rebuild
- [ ] T008 [P] Rebuild
Tenant administrators update a relationship's permissions, assigned roles, and available services after invitation or approval. Callers can select one or many relationships with tenant isolation, filters, pagination, related service data, account data, and consistent result envelopes.
Why this priority: Relationship lifecycle behavior is incomplete if users cannot control what the relationship can access after it is created.
Independent Test: Update services, permissions, and roles for an active relationship and validate that selection procedures and validation procedures reflect the new access immediately while rejecting inactive, deleted, unauthorized, duplicate, or tenant-mismatched assignments.
Acceptance Scenarios:
1. Given an active relationship and a valid payload of tenant services and tenant permissions, When the service/permission update procedure runs, Then related rows are inserted, updated, disabled, or deleted according to the requested mode without duplicates and with a tenant log.
2. Given valid role assignments represented by existing relationship type, permission, user-permission, service, or relationship metadata, When roles are updated, Then the relationship validation procedure enforces the assigned roles consistently across future operations.
3. Given a caller with select permission, When list and single-select procedures run, Then results are tenant-scoped, paginated where applicable, exclude deleted rows by default, support explicit status filters, and include relevant account/service/permission/role context.
[٧/٧، ٧:٢٢ ص] أ. انور السياري IT: وصف المتطلبات بأسلوب Agile
[٧/٧، ٧:٣٣ ص] أ. انور السياري IT: الخطوة التالية يقوم رئيس الفريق او المطور المستلم للمتطلبات بتفصيل المتطلبات الى مهام ثم يتم رفعها الى taskissues على نفس البرنش ليبدء اعضاء الفريق العمل عليها ومراقبة التقدم في انجازها
[٧/٧، ٧:٣٤ ص] أ. انور السياري IT: # Tasks: Tenant Relationship Lifecycle
Prerequisites: plan.md, spec.md, research.md, data-model.md, contracts/
Tests: Runnable SQL examples are mandatory for this database feature.
Organization: Tasks are grouped by user story so each story can be implemented and tested independently.
## Phase 1: Setup (Shared Infrastructure)
Purpose: Establish the feature boundary, compatibility fixes, and canonical references.
- [ ] T001 Inventory affected TenantRelationship SQL files and current compile blockers in
specs/001-tenant-relationship-lifecycle/tasks.md- [ ] T002 Confirm no-new-table implementation boundary in
specs/001-tenant-relationship-lifecycle/tasks.md- [ ] T003 [P] Prepare relationship lifecycle example conventions in
src/TenantRelationship/procedures/InsertTenantRelationshipExample.sql---
## Phase 2: Foundational (Blocking Prerequisites)
Purpose: Define shared SQL contracts that block user story work.
CRITICAL: No user story work can begin until this phase is complete.
- [ ] T004 Make
TenantRelationship.accountId nullable for pending invitations in src/TenantRelationship/table.sql- [ ] T005 Fix the
TenantRelationshipService relationship foreign key target in src/TenantRelationshipService/table.sql- [ ] T006 Update
TenantRelationshipData JSON defaults for nullable account ids and pending status in src/TenantRelationship/TenantRelationshipData.type.sql- [ ] T007 [P] Rebuild
ValidateTenantRelationship around (tenantId, userId, typeId) in src/TenantRelationship/procedures/ValidateTenantRelationship.sql- [ ] T008 [P] Rebuild
ValidateUserTenantRelationship with relationship, account, service, permission, and role checks in src/TenantRelationship/procedures/ValidateUserTenantRelationship.sql- [ ] T009 Create idempotent account helper
- [ ] T010 Create relationship service update helper
- [ ] T011 Create relationship permission update helper
- [ ] T012 Create relationship role update helper
- [ ] T013 Create suspend and reactivate helper procedures in
Checkpoint: Foundation ready - user story implementation can now begin.
---
## Phase 3: User Story 1 - Invite User Into Tenant Relationship (Priority: P1)
Goal: Authorized tenant users can send one pending invitation for a target user and relationship type without granting active access.
Independent Test: Run
### Tests for User Story 1
- [ ] T014 [P] [US1] Add invitation success and duplicate examples in
### Implementation for User Story 1
- [ ] T015 [US1] Rebuild
- [ ] T016 [US1] Document invitation behavior in
Checkpoint: User Story 1 is functional and independently testable.
---
## Phase 4: User Story 2 - Approve Invitation And Create Financial Account (Priority: P1)
Goal: Pending invitations can be approved and linked to exactly one idempotent tenant account.
Independent Test: Run
### Tests for User Story 2
- [ ] T017 [P] [US2] Add approval idempotency examples in
### Implementation for User Story 2
- [ ] T018 [US2] Rebuild
- [ ] T019 [US2] Document approval and account creation in
Checkpoint: User Stories 1 and 2 work independently.
---
## Phase 5: User Story 3 - Reject Invitation (Priority: P1)
Goal: Pending invitations can be rejected without creating accounts or enabling services.
Independent Test: Run
### Tests for User Story 3
- [ ] T020 [P] [US3] Add rejection examples in
### Implementation for User Story 3
- [ ] T021 [US3] Rebuild
- [ ] T022 [US3] Document rejection behavior in
Checkpoint: User Story 3 is functional and independently testable.
---
## Phase 6: User Story 4 - Suspend, Disable, Reactivate, Soft Delete, And Restore (Priority: P2)
Goal: Tenant administrators can move relationships through operational lifecycle states while preserving rows and audit history.
Independent Test: Run status, soft-delete, and restore examples and verify allowed transitions, rejected transitions, service cascades, validation behavior, and logs.
### Tests for User Story 4
EnsureTenantRelationshipAccount in src/TenantRelationship/procedures/EnsureTenantRelationshipAccount.sql- [ ] T010 Create relationship service update helper
UpdateTenantRelationshipServices in src/TenantRelationship/procedures/UpdateTenantRelationshipServices.sql- [ ] T011 Create relationship permission update helper
UpdateTenantRelationshipPermissions in src/TenantRelationship/procedures/UpdateTenantRelationshipPermissions.sql- [ ] T012 Create relationship role update helper
UpdateTenantRelationshipRoles in src/TenantRelationship/procedures/UpdateTenantRelationshipRoles.sql- [ ] T013 Create suspend and reactivate helper procedures in
src/TenantRelationship/procedures/SuspendTenantRelationship.sql and src/TenantRelationship/procedures/ReactivateTenantRelationship.sqlCheckpoint: Foundation ready - user story implementation can now begin.
---
## Phase 3: User Story 1 - Invite User Into Tenant Relationship (Priority: P1)
Goal: Authorized tenant users can send one pending invitation for a target user and relationship type without granting active access.
Independent Test: Run
src/TenantRelationship/procedures/InsertTenantRelationshipExample.sql and verify one pending relationship row, no account requirement, duplicate prevention, structured errors, and a tenant log.### Tests for User Story 1
- [ ] T014 [P] [US1] Add invitation success and duplicate examples in
src/TenantRelationship/procedures/InsertTenantRelationshipExample.sql### Implementation for User Story 1
- [ ] T015 [US1] Rebuild
InsertTenantRelationship in src/TenantRelationship/procedures/InsertTenantRelationship.sql- [ ] T016 [US1] Document invitation behavior in
src/TenantRelationship/procedures/InsertTenantRelationship.mdCheckpoint: User Story 1 is functional and independently testable.
---
## Phase 4: User Story 2 - Approve Invitation And Create Financial Account (Priority: P1)
Goal: Pending invitations can be approved and linked to exactly one idempotent tenant account.
Independent Test: Run
src/TenantRelationship/procedures/ApproveTenantRelationshipExample.sql twice and verify active status, one account, one balance set, no duplicate account, structured errors, and logs.### Tests for User Story 2
- [ ] T017 [P] [US2] Add approval idempotency examples in
src/TenantRelationship/procedures/ApproveTenantRelationshipExample.sql### Implementation for User Story 2
- [ ] T018 [US2] Rebuild
ApproveTenantRelationship in src/TenantRelationship/procedures/ApproveTenantRelationship.sql- [ ] T019 [US2] Document approval and account creation in
src/TenantRelationship/procedures/ApproveTenantRelationship.mdCheckpoint: User Stories 1 and 2 work independently.
---
## Phase 5: User Story 3 - Reject Invitation (Priority: P1)
Goal: Pending invitations can be rejected without creating accounts or enabling services.
Independent Test: Run
src/TenantRelationship/procedures/RejectTenantRelationshipExample.sql and verify status 40, no approval account, inactive validation, structured errors, and logs.### Tests for User Story 3
- [ ] T020 [P] [US3] Add rejection examples in
src/TenantRelationship/procedures/RejectTenantRelationshipExample.sql### Implementation for User Story 3
- [ ] T021 [US3] Rebuild
RejectTenantRelationship in src/TenantRelationship/procedures/RejectTenantRelationship.sql- [ ] T022 [US3] Document rejection behavior in
src/TenantRelationship/procedures/RejectTenantRelationship.mdCheckpoint: User Story 3 is functional and independently testable.
---
## Phase 6: User Story 4 - Suspend, Disable, Reactivate, Soft Delete, And Restore (Priority: P2)
Goal: Tenant administrators can move relationships through operational lifecycle states while preserving rows and audit history.
Independent Test: Run status, soft-delete, and restore examples and verify allowed transitions, rejected transitions, service cascades, validation behavior, and logs.
### Tests for User Story 4
- [ ] T023 [P] [US4] Add lifecycle status examples in
- [ ] T024 [P] [US4] Add soft-delete and restore examples in
### Implementation for User Story 4
- [ ] T025 [US4] Rebuild
- [ ] T026 [US4] Rebuild
- [ ] T027 [US4] Rebuild
- [ ] T028 [US4] Document lifecycle transitions in
Checkpoint: User Story 4 is functional and independently testable.
---
## Phase 7: User Story 5 - Maintain Permissions, Roles, Services, And Query Contracts (Priority: P2)
Goal: Relationship access can be updated and queried with tenant isolation and enriched related data.
Independent Test: Run service, permission, role, select, and validation examples and verify tenant-scoped results and access checks.
### Tests for User Story 5
- [ ] T029 [P] [US5] Add select and validation examples in
### Implementation for User Story 5
- [ ] T030 [US5] Rebuild
- [ ] T031 [US5] Rebuild
- [ ] T032 [US5] Document select and validation contracts in
Checkpoint: User Story 5 is functional and independently testable.
---
## Phase 8: Constitution and Regression Review
Purpose: Verify the work against the project constitution and canonical SQL model.
- [ ] T033 Update module overview documentation in
- [ ] T034 Verify no
- [ ] T035 Run static SQL text checks for duplicate parameters, unresolved
- [ ] T036 Capture final implementation notes in
---
## Dependencies & Execution Order
### Phase Dependencies
- Setup (Phase 1): No dependencies
- Foundational (Phase 2): Depends on Setup completion and blocks stories
- User Stories (Phase 3+): Depend on Foundational completion
- Constitution and Regression Review: Depends on all selected stories
### User Story Dependencies
- US1 is the MVP invitation path.
- US2 depends on US1 data shape and foundational account helper.
- US3 depends on US1 data shape.
- US4 depends on foundational transition validation and can run after US1.
- US5 depends on the rebuilt validation procedures and can run after foundational tasks.
### Parallel Opportunities
src/TenantRelationship/procedures/UpdateTenantRelationshipStatusExample.sql- [ ] T024 [P] [US4] Add soft-delete and restore examples in
src/TenantRelationship/procedures/SoftDeleteTenantRelationshipExample.sql and src/TenantRelationship/procedures/RestoreTenantRelationshipExample.sql### Implementation for User Story 4
- [ ] T025 [US4] Rebuild
UpdateTenantRelationshipStatus in src/TenantRelationship/procedures/UpdateTenantRelationshipStatus.sql- [ ] T026 [US4] Rebuild
SoftDeleteTenantRelationship in src/TenantRelationship/procedures/SoftDeleteTenantRelationship.sql- [ ] T027 [US4] Rebuild
RestoreTenantRelationship in src/TenantRelationship/procedures/RestoreTenantRelationship.sql- [ ] T028 [US4] Document lifecycle transitions in
src/TenantRelationship/procedures/UpdateTenantRelationshipStatus.md, src/TenantRelationship/procedures/SoftDeleteTenantRelationship.md, and src/TenantRelationship/procedures/RestoreTenantRelationship.mdCheckpoint: User Story 4 is functional and independently testable.
---
## Phase 7: User Story 5 - Maintain Permissions, Roles, Services, And Query Contracts (Priority: P2)
Goal: Relationship access can be updated and queried with tenant isolation and enriched related data.
Independent Test: Run service, permission, role, select, and validation examples and verify tenant-scoped results and access checks.
### Tests for User Story 5
- [ ] T029 [P] [US5] Add select and validation examples in
src/TenantRelationship/procedures/SelectTenantRelationshipExample.sql, src/TenantRelationship/procedures/SelectOneTenantRelationshipExample.sql, src/TenantRelationship/procedures/ValidateTenantRelationshipExample.sql, and src/TenantRelationship/procedures/ValidateUserTenantRelationshipExample.sql### Implementation for User Story 5
- [ ] T030 [US5] Rebuild
SelectTenantRelationship in src/TenantRelationship/procedures/SelectTenantRelationship.sql- [ ] T031 [US5] Rebuild
SelectOneTenantRelationship in src/TenantRelationship/procedures/SelectOneTenantRelationship.sql- [ ] T032 [US5] Document select and validation contracts in
src/TenantRelationship/procedures/SelectTenantRelationship.md, src/TenantRelationship/procedures/SelectOneTenantRelationship.md, src/TenantRelationship/procedures/ValidateTenantRelationship.md, and src/TenantRelationship/procedures/ValidateUserTenantRelationship.mdCheckpoint: User Story 5 is functional and independently testable.
---
## Phase 8: Constitution and Regression Review
Purpose: Verify the work against the project constitution and canonical SQL model.
- [ ] T033 Update module overview documentation in
src/TenantRelationship/readme.md and src/TenantRelationship/tenant_relationship_procedures.md- [ ] T034 Verify no
CREATE TABLE scripts were added for this feature in src/TenantRelationship, src/TenantRelationshipService, and specs/001-tenant-relationship-lifecycle- [ ] T035 Run static SQL text checks for duplicate parameters, unresolved
relationshipId, malformed placeholder examples, and ValidateUserTenantRelationship signature drift in src/TenantRelationship/procedures- [ ] T036 Capture final implementation notes in
specs/001-tenant-relationship-lifecycle/quickstart.md---
## Dependencies & Execution Order
### Phase Dependencies
- Setup (Phase 1): No dependencies
- Foundational (Phase 2): Depends on Setup completion and blocks stories
- User Stories (Phase 3+): Depend on Foundational completion
- Constitution and Regression Review: Depends on all selected stories
### User Story Dependencies
- US1 is the MVP invitation path.
- US2 depends on US1 data shape and foundational account helper.
- US3 depends on US1 data shape.
- US4 depends on foundational transition validation and can run after US1.
- US5 depends on the rebuilt validation procedures and can run after foundational tasks.
### Parallel Opportunities
- T003 can run alongside T001-T002.
- T007 and T008 can run in parallel after T004-T006.
- T014, T017, T020, T023, T024, and T029 touch different example files and can run in parallel.
- Documentation tasks for different procedures can run in parallel after their procedure implementation.
## Implementation Strategy
### MVP First
1. Complete Setup and Foundational phases.
2. Complete US1 invitation and duplicate prevention.
3. Complete US2 approval with idempotent account creation.
4. Complete US3 rejection to close the P1 lifecycle.
### Incremental Delivery
1. Add lifecycle state management.
2. Add service, permission, role, select, and validation contracts.
3. Run static SQL checks and update documentation.
## Notes
- No new database tables are allowed.
- Every completed implementation task must be marked
- Procedures should use structured JSON errors and tenant-scoped predicates.
- T007 and T008 can run in parallel after T004-T006.
- T014, T017, T020, T023, T024, and T029 touch different example files and can run in parallel.
- Documentation tasks for different procedures can run in parallel after their procedure implementation.
## Implementation Strategy
### MVP First
1. Complete Setup and Foundational phases.
2. Complete US1 invitation and duplicate prevention.
3. Complete US2 approval with idempotent account creation.
4. Complete US3 rejection to close the P1 lifecycle.
### Incremental Delivery
1. Add lifecycle state management.
2. Add service, permission, role, select, and validation contracts.
3. Run static SQL checks and update documentation.
## Notes
- No new database tables are allowed.
- Every completed implementation task must be marked
[X] in this file.- Procedures should use structured JSON errors and tenant-scoped predicates.