First commit of the Hedena Gold product (separate from gold-bank): branding, package names, and deploy defaults aligned to the new brand; legacy Henza trees stay local-only via .gitignore.
10 KiB
برنامهی رسیدگی به فهرست مشکلات ثبتشده
تاریخ: ۱۷ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۰۸)
منبع: docs/parity/ISSUES.md
روش کار: هر مورد بازِ آن فهرست با کد امروز دوباره سنجیده شد. بعضی در این فاصله درست شدهاند ولی فهرست بهروز نشده بود.
تا تأیید کارفرما هیچ کدی نوشته نمیشود. موارد «حساس» (دفتر بدهی، حذف داده) جداگانه هم تأیید میخواهند.
الف) درست شدهاند، فقط باید در فهرست بسته شوند
| شناسه | چه بود | وضعیت امروز |
|---|---|---|
| MON-01 / V2-01 | اپ نسخهی ۲ سقف موجودی نداشت؛ میشد بیشتر از موجودی سفارش داد | سقف در هر دو اپ هست |
| V2-02 / APP-02 | اسلایدر تنظیمشده در پنل در اپ نسخهی ۲ نمیآمد | اپ نسخهی ۲ آن را میخواند |
| MON-03 | عدد مثقال (۴٫۳۳۱۸۰۲) اعشاری معمولی بود و نگرانیِ گرد شدن داشت | سنجیده شد: هنگام محاسبه دقیقاً به همان رقم تبدیل میشود و هیچ خطایی نمیسازد |
| PERS-03 | ستونی برای تاریخ تولد مشتری نبود | ستونش با انتقال داده اضافه شد؛ فقط فیلد فرم مانده (پایین، بند ج) |
پیشنهاد: همینها را در فهرست ببندم. کد عوض نمیشود.
ب) قبل از راهاندازی واقعی — حتماً
۱. علاقهمندیها در اپ ذخیره نمیشوند (تازه پیدا شد — مرتبط با انتقال)
مشکل:
- اپ علاقهمندیها را فقط در حافظهی گوشی نگه میدارد، پس با بستن اپ پاک میشوند.
- ۸۷۴ علاقهمندیِ منتقلشده از سیستم قدیم در دیتابیس هست، ولی اپ هیچوقت آنها را نشان نمیدهد.
- سیستم قدیم علاقهمندی را روی سرور ذخیره میکرد.
پیشنهاد: سه مسیر ساده در سرور اضافه شود (فهرست، افزودن، حذف) و هر دو اپ به آن وصل شوند.
۲. تنظیمات امنیتی سرور (REL-01، REL-03، SEC-04، SEC-05)
اینها کد نیستند؛ تنظیم سرور هستند:
- کد ثابت ورود آزمایشی (REL-01): حذف شود. تا وقتی هست، هر کسی با آن کد وارد هر حسابی میشود.
- کلید رمز توکن مشتریها (REL-03): از کلید مدیرها جدا شود.
- کلید پیشفرض توکن (SEC-04): اگر کلید تنظیم نشده باشد، سرور با یک کلید پیشفرضِ معلوم بالا میآید.
پیشنهاد برای SEC-04: در محیط اصلی، بدون کلید اصلاً بالا نیاید. این تغییر کوچک است.
دو مورد دیگر:
- دسترسی از هر دامنه (CORS): هر سایتی میتواند به سرور درخواست بفرستد. باید فقط به دامنههای پنل و اپ محدود شود.
- حساب آزمایشی (SEC-05): دیتای اولیه یک حساب مدیر ارشد آزمایشی میسازد که رمزش همان شماره است. باید فقط در محیط توسعه ساخته شود.
۳. رمزهای لو رفتهی سیستم قدیم (SEC-06، SEC-12، SEC-17) — کارِ خود کارفرما
رمز پنل پیامک، توکن درگاه پرداخت و توکن تهحساب در کد سیستم قدیم نوشته شدهاند. باید عوض شوند. این کار از دست من برنمیآید.
۴. کالاهای بدون عکس (ACC-05)
کالای بدون عکس در اپ نمایش داده نمیشود و قابل سفارش نیست.
پیشنهاد: بعد از انتقال داده یک شمارش بگیرم که چند کالا عکس ندارند.
ج) درستی پول و سفارش — مهم
۵. بدهی دوبار ثبت میشود (ACC-03 = MON-04) — 🔴 مهمترین مورد پولی
مشکل: اگر سفارشی دوبار به وضعیت «تحویل به کارشناس» برود (مثلاً با برگرداندن وضعیت و جلو بردن دوباره)، بدهی طلا و ریالِ مشتری دوبار ثبت میشود.
پیشنهاد: پیش از ثبت بدهی، بررسی شود که برای همین سفارش قبلاً بدهی ثبت شده یا نه.
وضعیت: دفتر بدهی ناحیهی حفاظتشده است، پس تأیید جداگانهی شما لازم است.
۶. مشتری اجرت سفارش را خودش تعیین میکند (MON-08)
مشکل:
- درصد اجرت، تخفیف و هزینهی ریالی را اپ به سرور میفرستد و سرور همان را قبول میکند.
- کسی که درخواست را دستکاری کند، میتواند با اجرت صفر سفارش بدهد.
- سیستم قدیم هم همینطور بود (حتی بدتر).
پیشنهاد: سرور این اعداد را خودش از کالا و مشتری حساب کند و عدد اپ را نادیده بگیرد. این رفتار را عوض میکند، پس تأیید شما لازم است.
۷. «معلق کردن سفارش» و «احراز هویت» جلوی سفارش را نمیگیرند (MON-05)
مشکل: مدیر میتواند ثبت سفارش یک مشتری را معلق کند، ولی سرور موقع سفارش آن را بررسی نمیکند.
وضعیت سیستم قدیم: آن هم در سرور بررسی نمیکرد. اپ قدیم را باید ببینم که آنجا جلوی کار را میگرفت یا نه.
پیشنهاد: مشتریِ «عدم سفارش» نتواند سفارش ثبت کند. تأیید شما لازم است.
د) متوسط — بعد از موارد بالا
| شناسه | مشکل به زبان ساده | پیشنهاد |
|---|---|---|
| PERS-03 | فیلد تاریخ تولد در فرم مشتری نیست (۵۴۱ تاریخ تولد واقعی منتقل شده) | فیلد شمسی به فرم اضافه شود |
| SEC-07 | ذخیرهی دسترسیها هر متنی را قبول میکند، حتی دسترسی بیمعنی | فقط دسترسیهای معتبر پذیرفته شود |
| VAL-02 | بیشتر فرمهای پنل در سرور بررسی ورودی ندارند | بهتدریج برای فرمهای ثبت و ویرایش اضافه شود |
| MON-06 | تنظیمات کیف پول، اسلایدر و تخفیف خودکار در نصب تازه مقدار اولیه ندارند | مقدار پیشفرض ساخته شود |
| PERM-01 | دو دسترسی قدیمیِ داشبورد در دیتابیس هست که در صفحهی دسترسیها دیده نمیشود | حذفشان حذف داده است و تأیید میخواهد |
| PERS-02 | شهرها در قدیم استان ← شهر بودند؛ در جدید فهرست سادهاند | تصمیم با شما؛ فعلاً کار میکند |
| PERS-01 | در قدیم موبایل مشتری بعد از ثبت عوض نمیشد؛ در جدید میشود | قبلاً تصمیم گرفته شد که بماند؛ فقط یادآوری |
| REL-02 | اگر پیامک خراب باشد سرور فقط در گزارش داخلی مینویسد | یک صفحهی «وضعیت سلامت» که خرابی پیامک را نشان دهد |
| STUB-05 | شمارهی مدیرهایی که پیامک سفارش میگیرند | از تنظیمات خوانده شود (بخشیاش انجام شده؛ بررسی میکنم) |
| V2-03 | اپ نسخهی ۲ عکس هر مدل (واریانت) را نشان نمیدهد | — |
| V2-05 | اپ نسخهی ۲ برچسب موجودی روی مدلها ندارد | هر دو باید با اپ نسخهی ۱ یکسان شوند (فقط ظاهر باید فرق کند) |
| VAL-03 | اپ وقتی خطا میگیرد پیام درستی به کاربر نشان نمیدهد | — |
| ACC-01 | اتصال زرین روی نصب واقعی امتحان نشده | وقتی نصب واقعی داشتید |
| ACC-04 | روی دیتابیس کاملاً خالی، ترتیب تغییرات دیتابیس به هم میخورد | نام یک فایل عوض شود، بدون اثر روی دیتابیسهای موجود |
ه) کماهمیت / تمیزکاری
| شناسه | مشکل | پیشنهاد |
|---|---|---|
| DEAD-01..03 | کد و پوشهی بلااستفاده در اپها و ریشهی پروژه | حذف، با تأیید |
| PERF-01 | فهرست کارشناسان برای هر ردیف یک پرسوجو جدا میزند | الان با ۵۱ کارشناس مشکلی ندارد |
| REP-02 | گزارش مشتری برای هر بار نمایش کل تاریخچه را حساب میکند | الان مشکلی ندارد |
| DEPLOY-03 | قبل از ساخت نسخهی سرور باید خروجی تازه گرفته شود؛ وگرنه نسخهی کهنه ساخته میشود | در چکلیست انتشار هست؛ بعداً خودکار شود |
ترتیب پیشنهادی کار
| ترتیب | کار | نیاز به تأیید جداگانه |
|---|---|---|
| ۱ | بستن موارد درستشده در فهرست (بند الف) | — |
| ۲ | علاقهمندیها روی سرور (بند ۱) | — |
| ۳ | بدهی دوباره (بند ۵) | ✅ ناحیهی حفاظتشده |
| ۴ | امنیت سرور (بند ۲) | — |
| ۵ | اجرت از سرور (بند ۶) و جلوگیری از سفارشِ معلق (بند ۷) | ✅ تغییر رفتار |
| ۶ | فیلد تاریخ تولد (PERS-03) و بررسی دسترسیها (SEC-07) | — |
| ۷ | بقیهی بند «د» و «ه» به ترتیب | حذفها ✅ |