การตั้งค่า¶

ทุกอย่างในหน้านี้สำหรับ ผู้ดูแลระบบเท่านั้น คุณต้องอยู่ในกลุ่ม maintenance.group_equipment_manager (Maintenance / Administrator) สำหรับการแก้ไขขั้น และกลุ่มเดียวกันนี้เป็นสิ่งที่ปลดล็อกเมนูบันทึกการตรวจสอบ

ตรวจดูห้าขั้น¶

มีสองที่ในการดูนิยามของขั้น

จาก UI¶

1. เปิดโหมดนักพัฒนา (Settings → Developer Tools → Activate developer mode)
2. ไปที่ Maintenance → Configuration → Maintenance Stages
3. มุมมองรายการแสดง Sequence, Default Responsible Role, SLA Hours และ Is Done Stage

จากไฟล์ seed¶

แหล่งความจริงตามแบบฉบับคือ addons/roots/roots_hemms_workflow/data/maintenance_stage_data.xml ไฟล์นี้ทำเครื่องหมาย noupdate="1" ดังนั้นการแก้ไขของผู้ดูแลระบบต่อชั่วโมง SLA หรือบทบาทผู้รับผิดชอบจะ คงอยู่ผ่านการอัปเกรดโมดูล — คุณสามารถปรับใน UI ได้อย่างปลอดภัยโดยไม่ต้องกังวลว่า -u ครั้งถัดไปจะเขียนทับคุณ

ขั้น Received มี fold=True, done=True, roots_is_done_stage=True และ SLA 0.0 — ตัวจับเวลา SLA ไม่ทำงานบนขั้นปลายทาง

ปรับชั่วโมง SLA¶

งานผู้ดูแลระบบที่พบบ่อยที่สุด ป้ายการเกินกำหนดจะทำงานเมื่อใดก็ตามที่:

time_in_current_stage_hours > stage.roots_sla_hours
   AND
stage.roots_sla_hours > 0

ปรับต่อขั้น:

1. เปิดฟอร์มของขั้น (โหมดนักพัฒนา → Maintenance → Configuration → Maintenance Stages → คลิกแถว)
2. แก้ไข SLA Hours
3. บันทึก

การเปลี่ยนแปลงมีผล ทันทีกับทุกคำขอที่เปิดอยู่ ในขั้นนั้น (ธงการเกินกำหนด เป็นฟิลด์คำนวณ ไม่ได้จัดเก็บ) ไม่ต้องรีสตาร์ท cron หรือสร้างแคชใหม่

จุดเข้า PM Scheduled¶

โมดูลการบำรุงรักษาเชิงป้องกัน (roots_hemms_pm) — ติดตั้งพร้อมกับโมดูล ขั้นตอนการทำงานในการติดตั้ง HEMMS ทุกครั้ง — เพิ่มขั้นที่หก:

สองสิ่งที่ต้องรู้:

1. ลำดับ 5 วางไว้ก่อน Submitted (ลำดับ 10) เพื่อให้ PM และตั๋วเชิงแก้ไข ปรากฏเป็นคอลัมน์คู่ขนานในคัมบัง
2. คำขอ PM ที่สร้างโดย cron รายวันของ OCA maintenance_plan จะมาอยู่ ใน PM Scheduled โดยตรง ไม่ใช่ใน Submitted ช่างยอมรับงาน PM โดยเลื่อนไปยัง Pending Review จากนั้นจึงเข้าร่วมขั้นตอนเชิงแก้ไขมาตรฐาน

ขั้นนี้เป็นของ roots_hemms_pm — ดู การบำรุงรักษาเชิงป้องกัน → การตั้งค่า สำหรับการแก้ไข

กลุ่มความปลอดภัย¶

ACL ที่แน่นอนจาก security/ir.model.access.csv:

access_hemms_stage_transition_log_manager,...,maintenance.group_equipment_manager,1,1,1,0
access_hemms_stage_transition_log_user,...,base.group_user,1,0,1,0

สังเกตว่า ไม่มีใคร ลบแถวบันทึกการตรวจสอบได้ — perm_unlink=0 สำหรับ ทั้งสองกลุ่ม นี่เป็นความตั้งใจ: ร่องรอยมีไว้เพื่อเป็นหลักฐานที่แก้ไขไม่ได้ สำหรับผู้ตรวจประเมิน หากต้องการลบรายการตรวจสอบ คุณต้องเป็น superuser ของ ฐานข้อมูลที่ทำงานนอก ORM และการกระทำนั้นจะมองเห็นได้ใน ir.logging

กฎการเปลี่ยนผ่านถูกบังคับใช้อย่างไร¶

คำตอบสั้น ๆ: ไม่ถูกบังคับ ไม่มี _constrains ที่บล็อกการกระโดดขั้นเฉพาะ ผู้ใช้ใด ๆ ที่มีสิทธิ์เขียนบนคำขอซ่อมบำรุงสามารถลากการ์ดไปข้างหน้า ถอยหลัง หรือด้านข้างได้

คำตอบยาว: ทุกการเปลี่ยนผ่านถูกสังเกต ไม่ใช่ถูกควบคุม การ override write() (ดู models/maintenance_request.py) รันลำดับต่อไปนี้ภายในธุรกรรม เดียว:

1. ตรวจจับว่า stage_id กำลังถูกเปลี่ยนและต่างจากค่าปัจจุบัน (การเขียนที่ไม่มี ผลจะข้ามทุกอย่าง)
2. คำนวณ time_in_previous_stage_hours สำหรับแต่ละระเบียน
3. เรียก super().write(vals) — หาก Odoo เกิดข้อผิดพลาด (เช่น ข้อผิดพลาด ด้านสิทธิ์หรือ _constrains บนฟิลด์อื่น) ให้ยกเลิกทุกอย่าง; ไม่มีแถวบันทึก ที่กำพร้าถูกสร้าง
4. หลังจาก super สำเร็จ สร้างแถวบันทึกการตรวจสอบแบบกลุ่มและบันทึกข้อความ chatter

สองทางเลือกการออกแบบที่ควรรู้:

• vals["roots_stage_entered_at"] = now() ถูกตั้งค่า ก่อน super ดังนั้นการรีเซ็ตเกิดขึ้นพร้อมกับการเปลี่ยนขั้นอย่างเป็นอะตอม
• การบันทึกขั้นเริ่มต้น อยู่ในการ override create() ซึ่งเขียนแถว ตรวจสอบที่มี from_stage_id=False นี่เป็นเหตุผลว่าทำไมแถวแรกของแท็บ Audit Trail จึงเป็นเหตุการณ์การสร้างเสมอ

หากโรงพยาบาลต้องการบังคับใช้ขั้นตอนที่เข้มงวดกว่าภายหลัง (เช่น ห้ามเลื่อน ถอยหลัง) จุด hook ที่แนะนำคือ @api.constrains บน stage_id ที่อ่านจาก ค่าก่อนหน้าผ่าน _origin — แต่นั่นเป็นงานโมดูลปลายน้ำ ไม่ใช่ workflow-core

การเพิ่มขั้นแบบกำหนดเอง¶

เรา ไม่แนะนำ ให้เพิ่มขั้นแบบกำหนดเอง — ขั้นตอน 5 ขั้นเป็นรูปแบบหลักฐาน ต่อผู้ตรวจประเมินที่เราจัดมาให้สำหรับการรับรอง HA และการเพิ่มคอลัมน์ทำลายการ จับคู่กับเกณฑ์มาตรฐาน SLA ของอุตสาหกรรม แต่บางครั้งคุณก็จำเป็น (เช่น โรงพยาบาลที่มีคอลัมน์ "Awaiting Parts" แยกต่างหาก)

หากคุณจำเป็น:

1. โหมดนักพัฒนา → Maintenance → Configuration → Maintenance Stages → New
2. กรอกฟิลด์มาตรฐาน: Name (สองภาษา TH+EN ในสตริงเดียวกัน เช่น รอชิ้นส่วน (Awaiting Parts)), Sequence, Fold, Done
3. กรอกฟิลด์ส่วนขยายของ HEMMS:
   • SLA Hours — ตั้งเป็น 0 หากคุณไม่ต้องการตัวจับเวลา
   • Default Responsible Role — เลือกจากสี่บทบาท
   • Description (Thai) — สำหรับ tooltip ของขั้นในแอป
   • Is Done Stage — ปล่อยเป็น False เว้นแต่นี่เป็นคอลัมน์ปลายทาง
4. บันทึก

เลือกหมายเลขลำดับ ระหว่าง ขั้นที่มีอยู่ (เช่น 25 เพื่อแทรกระหว่าง Pending Review และ In Repair) หลีกเลี่ยงการเปลี่ยนหมายเลขขั้นที่เตรียมไว้ — XML ID ที่เตรียมไว้เป็นวิธีที่โมดูลปลายน้ำอ้างอิงถึง

การปรับการเก็บรักษาบันทึกการตรวจสอบ¶

ไม่มีการเก็บรักษาอัตโนมัติ ตาราง hemms.stage.transition.log เติบโตทีละหนึ่ง แถวต่อการเปลี่ยนผ่านขั้นต่อคำขอ และ ACL ที่เตรียมไว้ห้ามการลบ สำหรับโรงพยาบาล ที่มี 50 คำขอที่ใช้งานต่อวันโดยเฉลี่ย 4 การเปลี่ยนผ่านต่อคำขอ นั่นคือ ~73,000 แถวต่อปี — ดัชนีบน (request_id) และ (transitioned_at) ทำให้การสืบค้น รวดเร็วไปได้ไกลกว่านั้นมาก

หากคุณจำเป็นต้องเก็บถาวรแถวเก่าด้วยเหตุผลด้านการปฏิบัติตามกฎหมายหรือพื้นที่ จัดเก็บ ให้ทำผ่านกลยุทธ์การแบ่งพาร์ทิชันระดับฐานข้อมูล pg_dump ไม่ใช่ผ่าน ORM บันทึกการตรวจสอบมีไว้เพื่อเขียนและเก็บโดยตั้งใจ

หน้าที่เกี่ยวข้อง¶

• ขั้นตอนการทำงาน — แต่ละขั้นหมายถึงอะไรในทางปฏิบัติ
• การรายงาน — มุมมองที่เป็นมิตรกับผู้ตรวจประเมินเหนือ บันทึกการตรวจสอบ
• การบำรุงรักษาเชิงป้องกัน → การตั้งค่า — สำหรับขั้น PM Scheduled และ cron ของ OCA