150 lines
10 KiB
Markdown
150 lines
10 KiB
Markdown
|
# برنامه‌ی رسیدگی به فهرست مشکلات ثبت‌شده
|
|||
|
|
|
|||
|
|
**تاریخ:** ۱۷ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۰۸)
|
|||
|
|
**منبع:** [`docs/parity/ISSUES.md`](./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) | — |
|
|||
|
|
| ۷ | بقیه‌ی بند «د» و «ه» به ترتیب | حذف‌ها ✅ |
|