Skip to content

1.12 · ข่าว นโยบาย การแจ้งเตือน

บทนี้รวมฟีเจอร์ "content" ของระบบ — ข่าวสาร, นโยบายคุณภาพ, คลังเอกสาร, และระบบ push notification

ทั้งหมดเป็น content ที่ HR/admin สร้างและ publish ให้พนักงานเห็น — ไม่ใช่ข้อมูลธุรกรรม


Notification — push + in-app

vtrc-api/api/src/typeDefs/notification.js:1-197

ระบบ notification ทำ 2 หน้าที่พร้อมกัน

  1. Push notification ผ่าน Firebase Cloud Messaging (FCM) — ไปที่ mobile app
  2. In-app notification — เก็บใน VTRC ให้พนักงานเปิดดูในเว็บได้

Notification Group

notification.js:154-165 — แยกตามหมวด

Groupใช้สื่อสารเรื่อง
NEWSข่าวสารทั่วไป
POLICYนโยบายใหม่
SCHEMEระเบียบ/กฎระเบียบ
SALARYสลิปเงินเดือนพร้อมแล้ว
EVENTกิจกรรม
ANNOUNCEMENTประกาศ
RELEASErelease notes ของระบบเอง
OTHERอื่นๆ
WELFAREสวัสดิการ (เช่น รออนุมัติ, โอนสำเร็จ)
MEETINGการประชุม

TypeSend — broadcast vs targeted

Typeพุ่งเป้า
ALLทุกคน
INDIVIDUALเฉพาะคน (ระบุ userId)

การส่ง notification

Mutationผู้ใช้หน้าที่
sendNotification(title, body, group, postId?, docId?, courseId?, isConfirm)HR adminส่งจาก backoffice
sendNotificationFrom3Party(notifications)subsystem (CONICLE, Meeting, ฯลฯ)ใช้โดยระบบอื่น และใช้โดย createWDHospital ด้วย

sendNotificationFrom3Party เป็นพิเศษ — VTRC เรียกเองด้วยตอน create WDHospital (push WELFARE "รออนุมัติ" ให้ approver) — withdraw/hospital.js:1441-1462


Notification field — feature flags

notification.js — แต่ละ notification มี flag หลายตัว

Fieldหน้าที่
read (0/1)อ่านแล้ว
isConfirm (0/1)บังคับให้กดยืนยันว่าอ่านแล้ว
confirm (null/0/1)user ยืนยันแล้วหรือยัง
dateConfirmtimestamp ตอนยืนยัน
notiFromชื่อระบบที่ส่งมา (เช่น WELFARE, CONICLE)

isConfirm = 1 ใช้สำหรับ notification สำคัญที่ HR อยาก tracking ว่าทุกคนเห็นแล้ว (เช่น นโยบายใหม่)


Models — ตาราง notification

vtrc-api/api/src/models/core/notification/

Modelหน้าที่
notification.jsmain row ของแต่ละ notification
notificationRead.jstracking ใครอ่านแล้วบ้าง
notificationRequest.jsrequest ที่รอส่ง (queue)
notificationResult.jsผลลัพธ์การส่งแต่ละครั้ง
notificationFail.jslog การส่งล้มเหลว
notificationUserSetting.jssetting ของ user (ปิด group ใด group หนึ่งได้)
notificationPublicDevice.jsdevice token สำหรับ anonymous push
queueNotification.jsqueue ก่อน FCM fan-out

News / Post

vtrc-api/api/src/typeDefs/post.js:1-60+

  • fetchListPost(type, status, category) — พนักงานเห็นแค่ที่ status = published
  • fetchListPostBackoffice — HR เห็นทั้งหมดรวม draft

Visibility matrix

postDivision: [[String]] — config เลือก division ที่เห็นโพสต์

เช่น ถ้าตั้งเป็น [["01"], ["02", "03"]] หมายถึงเห็นเฉพาะคนใน division 01, 02, 03

ถ้าไม่ตั้งค่า → เห็นทุกคน

Mutation

createPost / updatePost ได้เฉพาะ backoffice (SUPER_ADMIN/ADMIN/STAFF)


Policy

vtrc-api/api/src/typeDefs/policy.js

โครงสร้างคล้าย Post — CRUD pattern เดียวกัน

ใช้สำหรับเผยแพร่ "นโยบายคุณภาพ" ของสภากาชาด — เอกสารระดับองค์กรที่ทุกคนควรรู้


Document + DocumentGroup

vtrc-api/api/src/typeDefs/document.js:1-269

Document

Queryหน้าที่
fetchListDocument(docGroupId, docGroupCodeRef, search, offset, limit)list หลัก

Mutations

Mutationผู้ใช้หน้าที่
createDocument / updateDocument / destroyDocumentadminCRUD
createDocumentFrom3Party(docType)subsystem3rd-party ingestion

docType enum (document.js:263-268)

Typeตัวอย่าง
ANNOUNCEประกาศ
DICTATIONคำสั่ง
DECLARATIONประกาศิต
FORMแบบฟอร์ม

KCMH documents

กรณีพิเศษ — createKCMHDocumentByWorkSystem และ createKCMHDocumentByType (document.js:120-185)

ใช้สำหรับดึงเอกสารจากระบบคุณภาพของโรงพยาบาลจุฬาฯ (KCMH = King Chulalongkorn Memorial Hospital) — เป็น ingestion จากระบบภายนอกที่ KCMH ใช้เอง


ContactUs

vtrc-api/api/src/typeDefs/contactUs.js:1-229

เป็น directory ไม่ใช่ระบบป้ายคำถาม — เก็บข้อมูลติดต่อของ HR/หน่วยงาน

Entity

  • ContactUs — directory ของ HR/หน่วยงาน (เบอร์โทร, email, ชื่อหัวหน้า)
  • ContactUsTelDivision — เบอร์โทรแยกตาม division
  • ContactUsCategory — หมวดหมู่

Read เปิดให้ทุกคน — write เฉพาะ admin


Notification fan-out — performance caveat

เมื่อ HR ส่ง notification แบบ TypeSend = ALL — VTRC ต้อง fan-out ไป user ทุกคน (~พัน devices)

ไม่มี background queue จริงจัง — fan-out เกิดใน GraphQL resolver inline ถ้า user จำนวนมาก request อาจ timeout

notification.sendNotificationByThirdParty ใน controller จัดการ fan-out — ดู lib/controllers/notification/

ถ้า HR บ่นว่า "ส่ง notification แล้วค้าง" — น่าจะเป็นปัญหานี้ ลองแบ่งเป็นหลาย batch


การ tracking อ่านแล้ว

notificationRead table เก็บ (notificationId, userId, readAt) — แต่ละคนที่กดอ่าน

HR สามารถ query ได้ว่า notification นี้มีคนอ่านกี่คนจากกี่คน — เห็นในหน้ารายงาน notification


User Setting — ปิด notification group

notificationUserSetting table — พนักงานเลือกปิด group ใด group หนึ่งได้ (เช่นปิด MEETING ถ้าไม่สนใจ)

แต่บาง group บังคับรับไม่ได้ปิด — SALARY, WELFARE, POLICY (กำหนดใน controller)


ข้อควรระวัง

  • FCM token หมดอายุ — ถ้าพนักงานไม่เปิด mobile นานๆ token ถูก GC และ push ไม่ถึง
  • ไม่มี retry queue — ถ้า FCM ล่มตอนส่ง notification นั้นหาย
  • notificationFail เก็บ log ล้มเหลว แต่ไม่มี UI สำหรับ re-send — ต้องดูโดยตรงใน database
  • ระบบ subsystems (CONICLE, Meeting) push ผ่าน sendNotificationFrom3Party — ถ้า subsystem เหล่านี้ส่งมากเกินไป อาจกระทบ performance

ขั้นตอนถัดไป

ไป บท 1.13 Subsystems ฝั่ง backoffice →