DEV Community: Dr.A. Ali

تصميم Workflow لتوثيق العقود في إيجار: من الجاهزية إلى التوثيق

Dr.A. Ali — Thu, 13 Aug 2026 11:41:00 +0000

السلسلة: جاهزية التوثيق في إيجار

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

المقال السابق في السلسلة غطّى طبقة التحقق نفسها. هذا يغطّي ما بعدها: آلة الحالة، المال، والصلاحيات.

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

السياق

منصة إيجار توفّر خدمة رسمية للتكامل الرقمي مع المنصات العقارية، وقد أبرمت ١٢ اتفاقية تكامل معها. لكن أياً كان المسار — تكامل مباشر أو وسيط — يبقى ثابت واحد: إيجار تتحقق من الهويات عبر ربطها بوزارة الداخلية ومركز المعلومات الوطني، والبيانات الخاطئة تُرفض.

فالمسار كله مبني حول هذه الحقيقة.

عقد في النظام
   |
فحص جاهزية (واجهة، لحظي)
   |
إنشاء طلب  --> 400 + قائمة النواقص إن كان ناقصاً
   |
حساب الرسوم -> خصم من المحفظة -> PENDING
   |
IN_PROGRESS
   |
+-- COMPLETED  (يتطلب رقم عقد إيجار)
+-- REJECTED   (يتطلب سبباً -> استرجاع تلقائي -> إعادة المحاولة متاحة)

١. آلة الحالة: أربع حالات، لا أكثر

الإغراء أن تضيف حالات لكل فرق دقيق: DATA_READY، SUBMITTED، PENDING_PARTIES، PARTIALLY_SIGNED... قاومناه.

enum EjarRequestStatus {
  PENDING      // بانتظار التنفيذ
  IN_PROGRESS  // جاري التنفيذ
  COMPLETED    // تم التوثيق
  REJECTED     // مرفوض
}

القاعدة التي استخدمناها: الحالة تستحق الوجود إذا كان سلوك النظام يختلف فيها — لا إذا كان وصفها يختلف.

DATA_READY مثلاً لا تستحق حالة: جاهزية البيانات ليست مرحلة يمرّ بها الطلب، هي شرط لوجوده أصلاً. الطلب لا يُنشأ إلا وبياناته مكتملة، فحالة "بياناته جاهزة" لا تعني شيئاً.

وكل حالة إضافية تعني فرعاً في كل استعلام، وعموداً في كل لوحة، وحالة يجب أن تفكر فيها في كل ترحيل بيانات.

الحالتان النهائيتان محميتان صراحةً:

if (request.status === 'COMPLETED') throw new BadRequestException('الطلب مكتمل بالفعل');
if (request.status === 'REJECTED') throw new BadRequestException('الطلب مرفوض بالفعل');

بدون هذين السطرين، طلبان متزامنان من لوحة الإدارة يمكن أن يُنتجا استرجاعين لنفس المبلغ.

٢. البوابة قبل المال

ترتيب العمليات عند الإنشاء ليس اعتباطياً:

// 1. التحقق من اكتمال البيانات — قبل أي شيء له تكلفة
const missingFields = this.validateContractData(contract);
if (missingFields.length > 0) {
  throw new BadRequestException({
    message: 'البيانات غير مكتملة لإنشاء عقد إلكتروني',
    missingFields,
  });
}

// 2. حساب الرسوم
const durationYears = this.calculateDurationYears(contract.startDate, contract.endDate);
const fees = this.calculateFee(dto.propertyUsageType, durationYears);

// 3. الخصم من محفظة المكتب
const { transaction: walletTx } = await this.wallet.debit(
  agencyId, fees.totalFee, 'رسوم عقد إلكتروني', user.id, 'EJAR_REQUEST',
);

// 4. إنشاء الطلب ثم ربط الحركة المالية به مرجعياً

لماذا missingFields في جسم الاستثناء؟ لأن 400 Bad Request وحدها تجعل الواجهة تعرض "حدث خطأ". القائمة تجعلها تعرض "ناقص: تاريخ ميلاد المستأجر، رقم الصك" — وهذا فرق بين تذكرة دعم ومستخدم يُكمل عمله.

وحساب المدة يعامل جزء السنة كسنة كاملة، مطابقةً للتسعير الرسمي:

calculateDurationYears(startDate: Date, endDate: Date): number {
  const diffDays = (endDate.getTime() - startDate.getTime()) / (1000 * 60 * 60 * 24);
  return Math.ceil(diffDays / 365);
}

Math.ceil هنا قرار عمل لا قرار تقني — عقد ١٣ شهراً يُسعَّر سنتين. لو استخدمت Math.round لاختلفت الفاتورة، ولاكتشفت ذلك من شكوى عميل لا من اختبار.

٣. الصلاحيات: من يملك الطلب؟

النظام متعدد المكاتب. عند القراءة، الفلترة تُبنى في where لا تُطبَّق بعد الجلب:

const where: any = {};
if (filters.status) where.status = filters.status;

if (user.userType === 'AGENCY_ADMIN') {
  where.agencyId = user.agency?.id;
} else if (user.userType !== 'SUPER_ADMIN') {
  throw new ForbiddenException('لا تملك صلاحية لعرض الطلبات');
}

النقطة المهمة: العزل بين المكاتب يجب أن يكون في شرط الاستعلام، لا في تصفية بعد الجلب ولا في إخفاء بالواجهة. جلب كل الطلبات ثم تصفيتها في الذاكرة يعني أن أي خطأ لاحق في مسار التصفية يسرّب بيانات مكتب لآخر — والأسوأ أن الترقيم يصبح خاطئاً بصمت.

وagencyId يُشتق من العقار لا من المستخدم. المستخدم يقول ما يريد؛ البيانات تقول لمن تعود.

٤. الرفض: الاسترجاع جزء من الانتقال

أكثر خطأ رأيته في مسارات مشابهة: الرفض يُحدّث الحالة، والاسترجاع يُعالج لاحقاً. النتيجة أرصدة لا تتطابق.

عندنا الاسترجاع داخل نفس الانتقال:

if (dto.status === 'REJECTED') {
  if (!dto.rejectionReason) throw new BadRequestException('سبب الرفض مطلوب');
  updateData.rejectedAt = new Date();

  const { transaction: refundTx } = await this.wallet.refund(
    request.agencyId, Number(request.totalFee),
    'استرجاع رسوم عقد إلكتروني مرفوض',
    user.id, 'EJAR_REQUEST_REFUND', request.id,
  );

  updateData.refundTransactionId = refundTx.id;

  await this.prisma.contract.update({
    where: { id: request.contractId },
    data: { ejarRequested: false },
  });
}

ثلاثة تفاصيل: سبب الرفض إلزامي لأن رفضاً بلا سبب يولّد تذكرة دعم فورية. الاسترجاع مربوط بالطلب عبر request.id، فالحركتان تظهران في كشف المحفظة موصولتين بسببهما. وعلامة ejarRequested تُلغى وإلا بقي العقد يبدو "مطلوب توثيقه" إلى الأبد.

وفي المقابل، الإكمال يشترط رقم عقد إيجار. القاعدة العامة: إذا كانت الحالة تعني وجود بيانات، فاجعل تلك البيانات شرطاً للانتقال إليها. طلب COMPLETED بلا رقم عقد صف بيانات كاذب.

٥. إعادة المحاولة مقابل القيد الفريد

contractId @unique يمنع طلبين لعقد واحد. لكن الطلب المرفوض يجب أن يكون قابلاً لإعادة المحاولة، وإلا صار عقد المستخدم عالقاً بسبب خطأ إداري.

// السماح بإعادة الطلب إذا كان السابق مرفوضاً
if (contract.ejarRequest && contract.ejarRequest.status !== 'REJECTED') {
  throw new BadRequestException('يوجد طلب عقد إلكتروني قائم لهذا العقد');
}

// حذف الطلب المرفوض القديم (لأن contractId فريد)
if (contract.ejarRequest && contract.ejarRequest.status === 'REJECTED') {
  await this.prisma.ejarContractRequest.delete({ where: { id: contract.ejarRequest.id } });
}

المقايضة صريحة: نخسر صف الطلب المرفوض، ونحتفظ بأثره في سجل النشاط. البديل — مفتاح مركّب على (contractId, status) أو عدّاد attempt — يحفظ تاريخاً أكمل بتعقيد أعلى في كل استعلام.

هذا نمط عام: القيد الفريد يمنع الازدواج، وإعادة المحاولة تحتاج مخرجاً منه. قرّر أيهما تدفع ثمنه — التعقيد أو التاريخ.

القرارات الهندسية باختصار

١. الحالة تستحق الوجود إذا اختلف سلوك النظام فيها، لا إذا اختلف وصفها.

٢. البوابة قبل المال: تحقق، ثم احسب، ثم اخصم.

٣. أرجع النواقص بأسمائها في جسم الخطأ.

٤. العزل بين المكاتب في where، واشتق المالك من البيانات لا من الطلب.

٥. المال جزء من انتقال الحالة، لا مهمة مؤجلة.

٦. اشترط بيانات الحالة قبل الانتقال إليها.

٧. القيد الفريد وإعادة المحاولة يتعارضان — احسم المقايضة صراحةً.

٨. لا تدّعِ تكاملاً لم تنضم إليه. "جاهزية بيانات إيجار" ≠ "متكامل مع إيجار".

Stack

NestJS · Prisma · PostgreSQL · Next.js · React Native

المصادر الرسمية: منصة إيجار (ejar.sa) | الهيئة العامة للعقار (rega.gov.sa)

المنصة: amlakire.com

Designing an Ejar Contract Registration Workflow: From Readiness to Registration

Dr.A. Ali — Thu, 13 Aug 2026 11:37:47 +0000

Series: Ejar Registration Readiness

At Amlaki we designed a full path for registering lease contracts through Saudi Arabia's government Ejar platform. This post covers the engineering decisions in the request lifecycle — from validation through registration, rejection, or retry.

The previous post in this series covered the validation layer itself. This one covers what comes after: the state machine, the money, and the permissions.

Disclosure: Amlaki has not yet joined the Ejar digital integration program. The path described here is a registration-request flow executed through a licensed broker, preceded by a data readiness layer.

Context

Ejar offers an official digital integration service for real estate platforms, and has concluded 12 integration agreements. But whichever path you take — direct integration or a broker — one constant holds: Ejar verifies identities through its links to the Ministry of Interior and the National Information Center, and wrong data is rejected.

The entire workflow is built around that fact.

Contract in the system
   |
Readiness check (client-side, live)
   |
Create request  --> 400 + list of gaps if incomplete
   |
Compute fees -> debit wallet -> PENDING
   |
IN_PROGRESS
   |
+-- COMPLETED  (requires an Ejar contract number)
+-- REJECTED   (requires a reason -> automatic refund -> retry available)

1. The state machine: four states, no more

The temptation is to add a state for every nuance: DATA_READY, SUBMITTED, PENDING_PARTIES, PARTIALLY_SIGNED... We resisted.

enum EjarRequestStatus {
  PENDING      // awaiting processing
  IN_PROGRESS  // being processed
  COMPLETED    // registered
  REJECTED     // rejected
}

The rule we used: a state earns its existence if system behavior differs in it — not if its description differs.

DATA_READY, for instance, doesn't earn one: data readiness isn't a phase the request passes through, it's a precondition for the request existing at all. A request is only created when its data is complete, so a "data is ready" state means nothing.

And every extra state means a branch in every query, a column in every dashboard, and a case you must think about in every migration.

Both terminal states are explicitly guarded:

if (request.status === 'COMPLETED') throw new BadRequestException('Request is already completed');
if (request.status === 'REJECTED') throw new BadRequestException('Request is already rejected');

Without those two lines, two concurrent admin actions can produce two refunds for the same amount.

2. The gate comes before the money

The order of operations at creation isn't arbitrary:

// 1. Validate completeness — before anything that costs money
const missingFields = this.validateContractData(contract);
if (missingFields.length > 0) {
  throw new BadRequestException({
    message: 'Contract data is incomplete for electronic registration',
    missingFields,
  });
}

// 2. Compute fees
const durationYears = this.calculateDurationYears(contract.startDate, contract.endDate);
const fees = this.calculateFee(dto.propertyUsageType, durationYears);

// 3. Debit
const { transaction: walletTx } = await this.wallet.debit(
  agencyId,
  fees.totalFee,
  `Electronic contract fee - contract ${contract.contractNumber}`,
  user.id,
  'EJAR_REQUEST',
);

// 4. Create the request
const ejarRequest = await this.prisma.ejarContractRequest.create({
  data: {
    contractId: contract.id,
    agencyId,
    requestedById: user.id,
    propertyUsageType: dto.propertyUsageType as any,
    contractDurationYears: durationYears,
    ejarFee: fees.ejarFee,
    brokerFee: fees.brokerFee,
    serviceFee: fees.serviceFee,
    totalFee: fees.totalFee,
    status: 'PENDING',
    walletTransactionId: walletTx.id,
  },
});

// 5. Back-link the wallet transaction to the request
await this.prisma.agencyWalletTransaction.update({
  where: { id: walletTx.id },
  data: { referenceId: ejarRequest.id },
});

Why missingFields in the exception body? Because a bare 400 Bad Request makes the UI render "something went wrong." The list lets it render "Missing: tenant birth date, deed number" — the difference between a support ticket and a user finishing their work.

Why is the back-link a separate step? Because the wallet transaction is created before the request, so it can't know the request's id yet. Step 5 closes the loop, making every line in the wallet statement traceable to its cause.

Duration treats a partial year as a full year, matching official pricing:

calculateDurationYears(startDate: Date, endDate: Date): number {
  const diffMs = endDate.getTime() - startDate.getTime();
  const diffDays = diffMs / (1000 * 60 * 60 * 24);
  return Math.ceil(diffDays / 365);
}

Math.ceil here is a business decision, not a technical one — a 13-month contract prices as two years. Had we used Math.round, the invoice would differ, and we'd have learned about it from a customer complaint rather than a test.

3. Permissions: who owns the request?

The system is multi-agency with several user types. The check at creation:

const agencyId = contract.unit?.property?.agencyId;
if (!agencyId) throw new BadRequestException('Cannot determine the agency for this contract');

if (user.userType !== 'SUPER_ADMIN') {
  if (user.userType === 'AGENCY_ADMIN' && user.agency?.id !== agencyId) {
    throw new ForbiddenException('You do not have permission for this contract');
  }
  if (
    (user.userType === 'OWNER' || user.userType === 'LINKED_OWNER') &&
    contract.unit?.property?.ownerId !== user.owner?.id
  ) {
    throw new ForbiddenException('You do not have permission for this contract');
  }
}

And on reads, the filter is built into where rather than applied after fetching:

const where: any = {};
if (filters.status) where.status = filters.status;

if (user.userType === 'AGENCY_ADMIN') {
  where.agencyId = user.agency?.id;
} else if (user.userType !== 'SUPER_ADMIN') {
  throw new ForbiddenException('You do not have permission to view requests');
}

The important point: tenant isolation belongs in the query predicate — not in post-fetch filtering, and certainly not in UI hiding. Fetching all requests and filtering in memory means any later bug in the filter path leaks one agency's data to another — and worse, pagination becomes silently wrong.

Note the first line too: agencyId is derived from the property, not from the user. The user states what they want; the data states who it belongs to.

4. Rejection: the refund is part of the transition

The most common mistake I've seen in similar flows: rejection updates the status, and the refund is "handled later." The result is balances that don't reconcile.

Ours lives inside the same transition:

if (dto.status === 'REJECTED') {
  if (!dto.rejectionReason) throw new BadRequestException('Rejection reason is required');
  updateData.rejectionReason = dto.rejectionReason;
  updateData.rejectedAt = new Date();

  const { transaction: refundTx } = await this.wallet.refund(
    request.agencyId,
    Number(request.totalFee),
    `Refund for rejected electronic contract - contract ${request.contract.contractNumber}`,
    user.id,
    'EJAR_REQUEST_REFUND',
    request.id,
  );

  updateData.refundTransactionId = refundTx.id;

  // Clear the request flag on the contract
  await this.prisma.contract.update({
    where: { id: request.contractId },
    data: { ejarRequested: false },
  });
}

Conversely, completion requires what the state is meaningless without:

if (dto.status === 'COMPLETED') {
  if (!dto.ejarContractNumber) throw new BadRequestException('Ejar contract number is required');
  updateData.ejarContractNumber = dto.ejarContractNumber;
  updateData.completedAt = new Date();

  await this.prisma.contract.update({
    where: { id: request.contractId },
    data: { ejarContractNumber: dto.ejarContractNumber },
  });
}

The general rule: if a state implies the existence of data, make that data a condition of transitioning into it. A COMPLETED request with no contract number is a lying row — it claims "registered" and can't prove it.

And Number(request.totalFee) isn't redundant: Prisma's Decimal isn't a JavaScript number, and passing it straight into a function expecting one is a source of silent bugs.

5. Retry versus the unique constraint

contractId @unique prevents two requests per contract — which is what we want. But a rejected request must be retryable, or a user's contract gets stuck because of an administrative error.

The two constraints appear to conflict. The resolution:

// Allow re-requesting if the previous request was rejected
if (contract.ejarRequest && contract.ejarRequest.status !== 'REJECTED') {
  throw new BadRequestException('An electronic contract request already exists for this contract');
}

// Delete the old rejected request (contractId is unique)
if (contract.ejarRequest && contract.ejarRequest.status === 'REJECTED') {
  await this.prisma.ejarContractRequest.delete({ where: { id: contract.ejarRequest.id } });
}

The trade-off is explicit: we lose the rejected request's row, and keep its trace in the activity log. The alternatives — a composite key on (contractId, status), an attempt counter, or deletedAt soft deletes — preserve fuller history at the cost of complexity in every query.

We chose simplicity because "how many times was this contract rejected?" wasn't a real question for our users. If it becomes one, the migration is straightforward.

This is a general pattern: a unique constraint prevents duplicates, and retries need an escape hatch from it. Decide which price you're paying — complexity or history.

Engineering decisions, condensed

1. A state earns existence if system behavior differs in it, not if its description does. Four states suffice.

2. The gate precedes the money. Validate, then compute, then debit — in that order.

3. Return gaps by name in the error body. A bare 400 produces a support ticket.

4. Tenant isolation belongs in where, not in post-fetch filtering. And derive ownership from the data, not the request.

5. Money is part of the state transition. The refund on rejection isn't a deferred job.

6. Require a state's data before transitioning into it. COMPLETED without a contract number is a lying row.

7. Unique constraints and retries conflict — resolve the trade-off explicitly and document it.

8. Don't claim an integration you haven't joined. "Ejar data readiness" ≠ "integrated with Ejar."

Stack

NestJS · Prisma · PostgreSQL · Next.js · React Native

Official sources: Ejar platform (ejar.sa) | Real Estate General Authority (rega.gov.sa)

Built at amlakire.com

بناء نظام صلاحيات متعدد الأدوار لمنصة عقارية بـ NestJS Guards

Dr.A. Ali — Fri, 01 May 2026 20:48:15 +0000

في أملاكي (amlakire.com)، عندنا ٦ أنواع مستخدمين على نفس المنصة. كيف نبني نظام صلاحيات مرن ودقيق؟

التحدي

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

الحل: Custom Guards + Decorators

1. Permission Decorator

// decorators/permissions.decorator.ts
import { SetMetadata } from '@nestjs/common';export const RequirePermissions = (...permissions: string[]) =>
  SetMetadata('permissions', permissions);

2. Permissions Guard

// guards/permissions.guard.ts
@Injectable()export class PermissionsGuard implements CanActivate {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const permissions = this.reflector.get(
      'permissions', context.getHandler()
    );
    if (!permissions) return true;

    const { user } = context.switchToHttp().getRequest();

    // SUPER_ADMIN & AGENCY_ADMIN = full access
    if (['SUPER_ADMIN', 'AGENCY_ADMIN'].includes(user.userType))
      return true;

    // OWNER = full on own properties
    if (user.userType === 'OWNER') {
      const ownerPermissions = [
        'properties.*', 'units.*', 'tenants.*',
        'contracts.*', 'payments.*', 'reports.view'
      ];
      return permissions.every(p =>
        ownerPermissions.some(op => this.matches(p, op))
      );
    }

    // LINKED_OWNER = read only
    if (user.userType === 'LINKED_OWNER')
      return permissions.every(p => p.endsWith('.view'));

    // AGENCY_STAFF = role-based
    if (user.userType === 'AGENCY_STAFF')
      return this.staffService.hasPermission(user.sub, permissions);

    return false;
  }
}

3. Controller Usage

@Controller('properties')@UseGuards(JwtAuthGuard, PermissionsGuard)
export class PropertiesController {
  @Post()  @RequirePermissions('properties.create')  create() {}

  @Get()  @RequirePermissions('properties.view')  findAll() {}

  @Delete(':id')  @RequirePermissions('properties.delete')  delete() {}
}

4. Data Isolation in Service

@Injectable()export class PropertiesService {
  async findAll(user: UserPayload) {
    const where: any = {};
    if (user.userType === 'AGENCY_ADMIN' || user.userType === 'AGENCY_STAFF')
      where.agencyId = user.agencyId;
    else if (user.userType === 'OWNER' || user.userType === 'LINKED_OWNER')
      where.owner = { userId: user.sub };
    return this.prisma.property.findMany({ where });
  }
}

النتيجة

٦ أنواع مستخدمين على نفس الكود
كل واحد يرى فقط ما يحق له
الصلاحيات تُفحص في طبقتين: Guard (HTTP) + Service (Data)

مبني في amlakire.com

Building Multi-Role Authorization for a Property Platform with NestJS Guards

Dr.A. Ali — Fri, 01 May 2026 20:43:56 +0000

At Amlaki (amlakire.com), we have 6 user types on the same platform. How do we build flexible, precise authorization?

The Challenge

Each user type has different permissions. Agency manages everything. Independent owner manages only their properties. Linked owner is read-only. Tenant sees only their data.

The Solution: Custom Guards + Decorators

1. Permission Decorator

import { SetMetadata } from '@nestjs/common';export const RequirePermissions = (...permissions: string[]) =>
  SetMetadata('permissions', permissions);

2. Permissions Guard

@Injectable()export class PermissionsGuard implements CanActivate {
  async canActivate(context: ExecutionContext) {
    const permissions = this.reflector.get(
      'permissions', context.getHandler()
    );
    const { user } = context.switchToHttp().getRequest();

    // Full access
    if (['SUPER_ADMIN', 'AGENCY_ADMIN'].includes(user.userType))
      return true;

    // Owner = full on own properties
    if (user.userType === 'OWNER') {
      const allowed = ['properties.*', 'units.*', 'tenants.*',
        'contracts.*', 'payments.*', 'reports.view'];
      return permissions.every(p =>
        allowed.some(a => this.matches(p, a)));
    }

    // Linked owner = read only
    if (user.userType === 'LINKED_OWNER')
      return permissions.every(p => p.endsWith('.view'));

    // Staff = role-based
    if (user.userType === 'AGENCY_STAFF')
      return this.staffService.hasPermission(user.sub, permissions);

    return false;
  }
}

3. Controller Usage

@Controller('properties')@UseGuards(JwtAuthGuard, PermissionsGuard)
export class PropertiesController {
  @Post()  @RequirePermissions('properties.create')  create() { /* Owner + Agency only */ }

  @Get()  @RequirePermissions('properties.view')  findAll() { /* Everyone except tenant */ }
}

4. Data Isolation in Service

async findAll(user: UserPayload) {
  const where: any = {};
  if (user.userType === 'AGENCY_ADMIN')
    where.agencyId = user.agencyId;
  else if (user.userType === 'OWNER')
    where.owner = { userId: user.sub };
  return this.prisma.property.findMany({ where });
}

Result

6 user types on the same codebase
Each sees only what they're authorized to
Permissions checked at two layers: Guard (HTTP) + Service (Data)

Built at amlakire.com

ZATCA VAT E-Invoicing for Saudi Property Management

Dr.A. Ali — Thu, 30 Apr 2026 17:31:32 +0000

Building a Dual Hijri/Gregorian Date Component in React Native

Dr.A. Ali — Wed, 29 Apr 2026 17:54:28 +0000