251117:1700 first commit

This commit is contained in:
2025-11-17 16:48:49 +07:00
commit a16e154531
84 changed files with 38385 additions and 0 deletions

View File

@@ -0,0 +1,3 @@
---
alwaysApply: true
---

View File

@@ -0,0 +1,6 @@
---
description: Documents Management Sytem Version 1.1.0
globs:
- docs/LCBP3-DMS_V1_1_0_*.md
alwaysApply: true
---

10
.cursorignore Normal file
View File

@@ -0,0 +1,10 @@
venv/
node_modules/
*.log
.env
.syncing_db/
@Recently-Snapshot/
logs/
design_specs/
legacy_code/

353
.gitignore vendored Normal file
View File

@@ -0,0 +1,353 @@
# ============================================
# Dependencies
# ============================================
/node_modules/
node_modules/
backend/node_modules/
frontend/node_modules/
jspm_packages/
bower_components/
web_modules/
# Yarn
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.*
.pnp.js
# ============================================
# Build Outputs & Cache
# ============================================
# Next.js
.next/
out/
# Production builds
build/
dist/
*.tsbuildinfo
# Build artifacts
build/Release
# Cache directories
.cache/
.parcel-cache
.nuxt
.docusaurus
.temp
**/.vitepress/dist
**/.vitepress/cache
.vuepress/dist
.fusebox/
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/
# ============================================
# Logs & Debug
# ============================================
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
.pnpm-debug.log*
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
# ============================================
# Environment & Config
# ============================================
.env
.env.local
.env.*.local
.env.development.local
.env.test.local
.env.production.local
*.pem
# ============================================
# Testing & Coverage
# ============================================
coverage/
*.lcov
.nyc_output
.vscode-test
# ============================================
# Runtime & Temp Files
# ============================================
pids
*.pid
*.seed
*.pid.lock
lib-cov
.grunt
.lock-wscript
.node_repl_history
*.tgz
.serverless/
.dynamodb/
.tern-port
# ============================================
# IDE & Editor
# ============================================
# VSCode
# .vscode/*
# !.vscode/settings.json
# !.vscode/tasks.json
# !.vscode/launch.json
# !.vscode/extensions.json
# *.code-workspace
# JetBrains IDEs
.idea/
*.iml
*.iws
*.ipr
out/
# Sublime Text
*.sublime-project
*.sublime-workspace
# Vim
*.swp
*.swo
*~
# Emacs
*~
\#*\#
.\#*
# ============================================
# OS Files
# ============================================
# macOS
.@upload_cache/
.qsync/
.syncing_db/
@Recently-Snapshot/
.DS_Store
.AppleDouble
.LSOverride
Icon
._*
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk
# Windows
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db
*.stackdump
[Dd]esktop.ini
$RECYCLE.BIN/
*.cab
*.msi
*.msix
*.msm
*.msp
*.lnk
# Linux
.directory
.Trash-*
.nfs*
# ============================================
# Optional Tools & Caches
# ============================================
# npm
.npm
.eslintcache
.stylelintcache
package-lock.json
npm-shrinkwrap.json
# TypeScript
next-env.d.ts
# Vercel
.vercel
# Turborepo
.turbo
# Sentry
.sentryclirc
# Storybook
storybook-static/
# Playwright
playwright-report/
playwright/.cache/
test-results/
# Jest
jest-results/
# Cypress
cypress/videos/
cypress/screenshots/
cypress/downloads/
# Docker
*.log
docker-compose.override.yml
# Terraform
*.tfstate
*.tfstate.*
.terraform/
.terraform.lock.hcl
# ============================================
# NestJS Specific
# ============================================
# NestJS build output
dist/
*.js.map
# NestJS documentation
documentation/
compodoc/
# NestJS testing
.jest/
coverage/
# ============================================
# Database
# ============================================
# MariaDB / MySQL
npm/letsencrypt/
*.sql.gz
*.sql.zip
mysql-data/
mariadb/data/
db-data/
# Database dumps
dump.rdb
*.dump
*.backup
# Database configuration (if contains credentials)
ormconfig.json
database.json
# ============================================
# n8n Workflow Automation
# ============================================
# n8n data directory
.n8n/
n8n/cache/
n8n/postgres/
n8n/pgadmin/sessions
# n8n encryption key
encryptionKey.txt
# n8n database
database.sqlite
# n8n configuration
n8n.config.json
# n8n credentials (IMPORTANT - never commit!)
credentials.json
credentials/
# n8n workflows (uncomment if you want to version control workflows)
# workflows/
# ============================================
# Node Version Management
# ============================================
# n (Node version manager)
.n-node-versions/
n/versions/
# nvm
.nvmrc.local
# Python (if using Python tools)
__pycache__/
*.py[cod]
*$py.class
venv/
env/
ENV/
# Ruby (if using Ruby tools)
*.gem
*.rbc
/.config
/InstalledFiles
/pkg/
/spec/reports/
/spec/examples.txt
/test/tmp/
/test/version_tmp/
/tmp/
.bundle/
vendor/bundle
#
.qsync/
@Recently-Snapshot/
.@__thumb
# ============================================
# Project Specific (Uncomment as needed)
# ============================================
# Design files
# *.sketch
# *.fig
# *.xd
# *.psd
# Documentation builds
# docs/_build/
# site/
# Database
# *.db
# *.sqlite
# *.sqlite3
# Compiled source
# *.com
# *.class
# *.dll
# *.exe
# *.o
# *.so
# Archives
# *.7z
# *.dmg
# *.gz
# *.iso
# *.jar
# *.rar
# *.tar
# *.zip

66
.vscode/extensions.json vendored Normal file
View File

@@ -0,0 +1,66 @@
{ "recommendations": [
"aaron-bond.better-comments",
"anbuselvanrocky.bootstrap5-vscode",
"bmewburn.vscode-intelephense-client",
"bradlc.vscode-tailwindcss",
"christian-kohler.path-intellisense",
"codezombiech.gitignore",
"davidanson.vscode-markdownlint",
"dbaeumer.vscode-eslint",
"dsznajder.es7-react-js-snippets",
"dunstontc.vscode-docker-syntax",
"eamodio.gitlens",
"easycodeai.chatgpt-gpt4-gpt3-vscode",
"ecmel.vscode-html-css",
"editorconfig.editorconfig",
"esbenp.prettier-vscode",
"firsttris.vscode-jest-runner",
"formulahendry.auto-rename-tag",
"github.copilot",
"github.copilot-chat",
"google.geminicodeassist",
"hansuxdev.bootstrap5-snippets",
"heybourn.headwind",
"humao.rest-client",
"imgildev.vscode-auto-barrel",
"imgildev.vscode-json-flow",
"imgildev.vscode-nestjs-generator",
"imgildev.vscode-nestjs-pack",
"imgildev.vscode-nestjs-snippets-extension",
"imgildev.vscode-nestjs-swagger-snippets",
"inferrinizzard.prettier-sql-vscode",
"jmkrivocapich.drawfolderstructure",
"mhutchie.git-graph",
"mikestead.dotenv",
"ms-azuretools.vscode-containers",
"ms-azuretools.vscode-docker",
"ms-edgedevtools.vscode-edge-devtools",
"ms-python.debugpy",
"ms-python.python",
"ms-vscode-remote.remote-containers",
"ms-vscode-remote.remote-ssh",
"ms-vscode-remote.remote-ssh-edit",
"ms-vscode.powershell",
"ms-vscode.remote-explorer",
"mtxr.sqltools",
"mtxr.sqltools-driver-mysql",
"oderwat.indent-rainbow",
"orta.vscode-jest",
"pdconsec.vscode-print",
"pmneo.tsimporter",
"postman.postman-for-vscode",
"prisma.prisma",
"redhat.vscode-yaml",
"rioj7.command-variable",
"ritwickdey.liveserver",
"rvest.vs-code-prettier-eslint",
"shardulm94.trailing-spaces",
"steoates.autoimport",
"stringham.move-ts",
"usernamehw.errorlens",
"vincaslt.highlight-matching-tag",
"vscode-icons-team.vscode-icons",
"yoavbls.pretty-ts-errors",
"yzhang.markdown-all-in-one",
]
}

12
.vscode/settings.json vendored Normal file
View File

@@ -0,0 +1,12 @@
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
]
}

0
.vscode/tasks.json vendored Normal file
View File

1878
01_lcbp3_v1_4_0.sql Normal file

File diff suppressed because it is too large Load Diff

4
backend/.prettierrc Normal file
View File

@@ -0,0 +1,4 @@
{
"singleQuote": true,
"trailingComma": "all"
}

48
backend/Dockerfile Normal file
View File

@@ -0,0 +1,48 @@
# File: Dockerfile
# บันทึกการแก้ไข: (สร้างไฟล์)
# --- STAGE 1: Builder ---
# ติดตั้ง Dependencies และ Build โค้ด
FROM node:18-alpine AS builder
WORKDIR /usr/src/app
# Copy package.json และ lock file
COPY package*.json ./
# ติดตั้ง Dependencies (สำหรับ Build)
RUN npm install
# Copy source code ทั้งหมด
COPY . .
# Build application
RUN npm run build
# ติดตั้งเฉพาะ Production Dependencies (สำหรับ Stage สุดท้าย)
RUN npm prune --production
# --- STAGE 2: Runner ---
# Image สุดท้ายที่มีขนาดเล็ก
FROM node:18-alpine
WORKDIR /usr/src/app
# (Security) สร้าง User ที่ไม่มีสิทธิ์ Root
RUN addgroup -S nestjs && adduser -S nestjs -G nestjs
USER nestjs
# Copy Production Dependencies (จาก Stage 1)
COPY --from=builder /usr/src/app/node_modules ./node_modules
# Copy Build Artifacts (จาก Stage 1)
COPY --from=builder /usr/src/app/dist ./dist
# Copy package.json (เผื่อจำเป็น)
COPY package*.json ./
# เปิด Port (อ่านจาก Environment Variable)
EXPOSE ${PORT:-3000}
# รัน Application
CMD [ "node", "dist/main" ]

98
backend/README.md Normal file
View File

@@ -0,0 +1,98 @@
<p align="center">
<a href="http://nestjs.com/" target="blank"><img src="https://nestjs.com/img/logo-small.svg" width="120" alt="Nest Logo" /></a>
</p>
[circleci-image]: https://img.shields.io/circleci/build/github/nestjs/nest/master?token=abc123def456
[circleci-url]: https://circleci.com/gh/nestjs/nest
<p align="center">A progressive <a href="http://nodejs.org" target="_blank">Node.js</a> framework for building efficient and scalable server-side applications.</p>
<p align="center">
<a href="https://www.npmjs.com/~nestjscore" target="_blank"><img src="https://img.shields.io/npm/v/@nestjs/core.svg" alt="NPM Version" /></a>
<a href="https://www.npmjs.com/~nestjscore" target="_blank"><img src="https://img.shields.io/npm/l/@nestjs/core.svg" alt="Package License" /></a>
<a href="https://www.npmjs.com/~nestjscore" target="_blank"><img src="https://img.shields.io/npm/dm/@nestjs/common.svg" alt="NPM Downloads" /></a>
<a href="https://circleci.com/gh/nestjs/nest" target="_blank"><img src="https://img.shields.io/circleci/build/github/nestjs/nest/master" alt="CircleCI" /></a>
<a href="https://discord.gg/G7Qnnhy" target="_blank"><img src="https://img.shields.io/badge/discord-online-brightgreen.svg" alt="Discord"/></a>
<a href="https://opencollective.com/nest#backer" target="_blank"><img src="https://opencollective.com/nest/backers/badge.svg" alt="Backers on Open Collective" /></a>
<a href="https://opencollective.com/nest#sponsor" target="_blank"><img src="https://opencollective.com/nest/sponsors/badge.svg" alt="Sponsors on Open Collective" /></a>
<a href="https://paypal.me/kamilmysliwiec" target="_blank"><img src="https://img.shields.io/badge/Donate-PayPal-ff3f59.svg" alt="Donate us"/></a>
<a href="https://opencollective.com/nest#sponsor" target="_blank"><img src="https://img.shields.io/badge/Support%20us-Open%20Collective-41B883.svg" alt="Support us"></a>
<a href="https://twitter.com/nestframework" target="_blank"><img src="https://img.shields.io/twitter/follow/nestframework.svg?style=social&label=Follow" alt="Follow us on Twitter"></a>
</p>
<!--[![Backers on Open Collective](https://opencollective.com/nest/backers/badge.svg)](https://opencollective.com/nest#backer)
[![Sponsors on Open Collective](https://opencollective.com/nest/sponsors/badge.svg)](https://opencollective.com/nest#sponsor)-->
## Description
[Nest](https://github.com/nestjs/nest) framework TypeScript starter repository.
## Project setup
```bash
$ npm install
```
## Compile and run the project
```bash
# development
$ npm run start
# watch mode
$ npm run start:dev
# production mode
$ npm run start:prod
```
## Run tests
```bash
# unit tests
$ npm run test
# e2e tests
$ npm run test:e2e
# test coverage
$ npm run test:cov
```
## Deployment
When you're ready to deploy your NestJS application to production, there are some key steps you can take to ensure it runs as efficiently as possible. Check out the [deployment documentation](https://docs.nestjs.com/deployment) for more information.
If you are looking for a cloud-based platform to deploy your NestJS application, check out [Mau](https://mau.nestjs.com), our official platform for deploying NestJS applications on AWS. Mau makes deployment straightforward and fast, requiring just a few simple steps:
```bash
$ npm install -g @nestjs/mau
$ mau deploy
```
With Mau, you can deploy your application in just a few clicks, allowing you to focus on building features rather than managing infrastructure.
## Resources
Check out a few resources that may come in handy when working with NestJS:
- Visit the [NestJS Documentation](https://docs.nestjs.com) to learn more about the framework.
- For questions and support, please visit our [Discord channel](https://discord.gg/G7Qnnhy).
- To dive deeper and get more hands-on experience, check out our official video [courses](https://courses.nestjs.com/).
- Deploy your application to AWS with the help of [NestJS Mau](https://mau.nestjs.com) in just a few clicks.
- Visualize your application graph and interact with the NestJS application in real-time using [NestJS Devtools](https://devtools.nestjs.com).
- Need help with your project (part-time to full-time)? Check out our official [enterprise support](https://enterprise.nestjs.com).
- To stay in the loop and get updates, follow us on [X](https://x.com/nestframework) and [LinkedIn](https://linkedin.com/company/nestjs).
- Looking for a job, or have a job to offer? Check out our official [Jobs board](https://jobs.nestjs.com).
## Support
Nest is an MIT-licensed open source project. It can grow thanks to the sponsors and support by the amazing backers. If you'd like to join them, please [read more here](https://docs.nestjs.com/support).
## Stay in touch
- Author - [Kamil Myśliwiec](https://twitter.com/kammysliwiec)
- Website - [https://nestjs.com](https://nestjs.com/)
- Twitter - [@nestframework](https://twitter.com/nestframework)
## License
Nest is [MIT licensed](https://github.com/nestjs/nest/blob/master/LICENSE).

View File

@@ -0,0 +1,62 @@
# File: docker-compose.yml
# บันทึกการแก้ไข: (สร้างไฟล์)
# (สำคัญ: ไฟล์นี้จะถูก import หรือคัดลอกไปใส่ใน UI ของ QNAP Container Station)
version: '3.8'
services:
# ---------------------------------
# Service 1: Backend (NestJS)
# (Req 2.3)
# ---------------------------------
backend:
build:
context: ./backend # (สมมติว่า Dockerfile อยู่ในโฟลเดอร์ backend)
dockerfile: Dockerfile
image: lcbp3-backend:1.3.0 # (ตั้งชื่อ Image)
container_name: lcbp3-backend
restart: unless-stopped
# (สำคัญ) กำหนด Environment Variables ที่นี่ (ห้ามใช้ .env)
# (Req 6.5, 2.1)
environment:
# --- App Config ---
- PORT=3000
- NODE_ENV=production
# --- Database (Req 2.4) ---
# (ชี้ไปที่ Service 'mariadb' ใน Network 'lcbp3')
- DATABASE_HOST=mariadb
- DATABASE_PORT=3306
- DATABASE_USER=your_db_user # (ต้องเปลี่ยน)
- DATABASE_PASSWORD=your_db_pass # (ต้องเปลี่ยน)
- DATABASE_NAME=lcbp3_dms
# --- Security (JWT) (Req 6.5) ---
- JWT_SECRET=YOUR_VERY_STRONG_JWT_SECRET_KEY # (ต้องเปลี่ยน)
- JWT_EXPIRATION_TIME=3600s # (เช่น 1 ชั่วโมง)
# --- Phase 4 Services ---
- ELASTICSEARCH_URL=http://elasticsearch:9200 # (ชี้ไปที่ Service ES ถ้ามี)
- N8N_WEBHOOK_URL=http://n8n:5678/webhook/your-webhook-id # (ชี้ไปที่ N8N)
# (สำคัญ) เชื่อมต่อ Network กลาง (Req 2.1)
networks:
- lcbp3
# (Deploy) ตั้งค่า Health Check
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/api/v1/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 20s # (รอให้ App เริ่มก่อน)
# ---------------------------------
# Network กลาง (Req 2.1)
# (ต้องสร้าง Network นี้ไว้ก่อนใน QNAP หรือสร้างพร้อมกัน)
# ---------------------------------
networks:
lcbp3:
external: true # (ถ้าสร้างไว้แล้ว)
# name: lcbp3 # (ถ้าต้องการให้ Compose สร้าง)

35
backend/eslint.config.mjs Normal file
View File

@@ -0,0 +1,35 @@
// @ts-check
import eslint from '@eslint/js';
import eslintPluginPrettierRecommended from 'eslint-plugin-prettier/recommended';
import globals from 'globals';
import tseslint from 'typescript-eslint';
export default tseslint.config(
{
ignores: ['eslint.config.mjs'],
},
eslint.configs.recommended,
...tseslint.configs.recommendedTypeChecked,
eslintPluginPrettierRecommended,
{
languageOptions: {
globals: {
...globals.node,
...globals.jest,
},
sourceType: 'commonjs',
parserOptions: {
projectService: true,
tsconfigRootDir: import.meta.dirname,
},
},
},
{
rules: {
'@typescript-eslint/no-explicit-any': 'off',
'@typescript-eslint/no-floating-promises': 'warn',
'@typescript-eslint/no-unsafe-argument': 'warn',
"prettier/prettier": ["error", { endOfLine: "auto" }],
},
},
);

8
backend/nest-cli.json Normal file
View File

@@ -0,0 +1,8 @@
{
"$schema": "https://json.schemastore.org/nest-cli",
"collection": "@nestjs/schematics",
"sourceRoot": "src",
"compilerOptions": {
"deleteOutDir": true
}
}

98
backend/package.json Normal file
View File

@@ -0,0 +1,98 @@
{
"name": "backend",
"version": "0.0.1",
"description": "",
"author": "",
"private": true,
"license": "UNLICENSED",
"scripts": {
"build": "nest build",
"format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
"start": "nest start",
"start:dev": "nest start --watch",
"start:debug": "nest start --debug --watch",
"start:prod": "node dist/main",
"lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
"test": "jest",
"test:watch": "jest --watch",
"test:cov": "jest --coverage",
"test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
"test:e2e": "jest --config ./test/jest-e2e.json"
},
"dependencies": {
"@elastic/elasticsearch": "^9.2.0",
"@nestjs/cache-manager": "^3.0.1",
"@nestjs/common": "^11.0.1",
"@nestjs/config": "^4.0.2",
"@nestjs/core": "^11.0.1",
"@nestjs/elasticsearch": "^11.1.0",
"@nestjs/jwt": "^11.0.1",
"@nestjs/passport": "^11.0.5",
"@nestjs/platform-express": "^11.1.9",
"@nestjs/schedule": "^6.0.1",
"@nestjs/swagger": "^11.2.1",
"@nestjs/typeorm": "^11.0.0",
"@types/nodemailer": "^7.0.3",
"@types/uuid": "^10.0.0",
"bcrypt": "^6.0.0",
"cache-manager": "^7.2.4",
"casl": "^0.2.0",
"class-transformer": "^0.5.1",
"class-validator": "^0.14.2",
"helmet": "^8.1.0",
"multer": "^2.0.2",
"mysql2": "^3.15.3",
"nodemailer": "^7.0.10",
"passport": "^0.7.0",
"passport-jwt": "^4.0.1",
"rate-limiter-flexible": "^8.2.1",
"reflect-metadata": "^0.2.2",
"rxjs": "^7.8.1",
"typeorm": "^0.3.27",
"uuid": "^13.0.0"
},
"devDependencies": {
"@eslint/eslintrc": "^3.2.0",
"@eslint/js": "^9.18.0",
"@nestjs/cli": "^11.0.0",
"@nestjs/schematics": "^11.0.0",
"@nestjs/testing": "^11.1.9",
"@types/express": "^5.0.0",
"@types/jest": "^30.0.0",
"@types/multer": "^2.0.0",
"@types/node": "^22.10.7",
"@types/passport-jwt": "^4.0.1",
"@types/supertest": "^6.0.2",
"eslint": "^9.18.0",
"eslint-config-prettier": "^10.0.1",
"eslint-plugin-prettier": "^5.2.2",
"globals": "^16.0.0",
"jest": "^30.2.0",
"prettier": "^3.4.2",
"source-map-support": "^0.5.21",
"supertest": "^7.1.4",
"ts-jest": "^29.2.5",
"ts-loader": "^9.5.2",
"ts-node": "^10.9.2",
"tsconfig-paths": "^4.2.0",
"typescript": "^5.7.3",
"typescript-eslint": "^8.20.0"
},
"jest": {
"moduleFileExtensions": [
"js",
"json",
"ts"
],
"rootDir": "src",
"testRegex": ".*\\.spec\\.ts$",
"transform": {
"^.+\\.(t|j)s$": "ts-jest"
},
"collectCoverageFrom": [
"**/*.(t|j)s"
],
"coverageDirectory": "../coverage",
"testEnvironment": "node"
}
}

View File

@@ -0,0 +1,22 @@
import { Test, TestingModule } from '@nestjs/testing';
import { AppController } from './app.controller';
import { AppService } from './app.service';
describe('AppController', () => {
let appController: AppController;
beforeEach(async () => {
const app: TestingModule = await Test.createTestingModule({
controllers: [AppController],
providers: [AppService],
}).compile();
appController = app.get<AppController>(AppController);
});
describe('root', () => {
it('should return "Hello World!"', () => {
expect(appController.getHello()).toBe('Hello World!');
});
});
});

View File

@@ -0,0 +1,12 @@
import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';
@Controller()
export class AppController {
constructor(private readonly appService: AppService) {}
@Get()
getHello(): string {
return this.appService.getHello();
}
}

10
backend/src/app.module.ts Normal file
View File

@@ -0,0 +1,10 @@
import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
@Module({
imports: [],
controllers: [AppController],
providers: [AppService],
})
export class AppModule {}

View File

@@ -0,0 +1,8 @@
import { Injectable } from '@nestjs/common';
@Injectable()
export class AppService {
getHello(): string {
return 'Hello World!';
}
}

8
backend/src/main.ts Normal file
View File

@@ -0,0 +1,8 @@
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

View File

@@ -0,0 +1,25 @@
import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication } from '@nestjs/common';
import request from 'supertest';
import { App } from 'supertest/types';
import { AppModule } from './../src/app.module';
describe('AppController (e2e)', () => {
let app: INestApplication<App>;
beforeEach(async () => {
const moduleFixture: TestingModule = await Test.createTestingModule({
imports: [AppModule],
}).compile();
app = moduleFixture.createNestApplication();
await app.init();
});
it('/ (GET)', () => {
return request(app.getHttpServer())
.get('/')
.expect(200)
.expect('Hello World!');
});
});

View File

@@ -0,0 +1,9 @@
{
"moduleFileExtensions": ["js", "json", "ts"],
"rootDir": ".",
"testEnvironment": "node",
"testRegex": ".e2e-spec.ts$",
"transform": {
"^.+\\.(t|j)s$": "ts-jest"
}
}

View File

@@ -0,0 +1,4 @@
{
"extends": "./tsconfig.json",
"exclude": ["node_modules", "test", "dist", "**/*spec.ts"]
}

25
backend/tsconfig.json Normal file
View File

@@ -0,0 +1,25 @@
{
"compilerOptions": {
"module": "nodenext",
"moduleResolution": "nodenext",
"resolvePackageJsonExports": true,
"esModuleInterop": true,
"isolatedModules": true,
"declaration": true,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"allowSyntheticDefaultImports": true,
"target": "ES2023",
"sourceMap": true,
"outDir": "./dist",
"baseUrl": "./",
"incremental": true,
"skipLibCheck": true,
"strictNullChecks": true,
"forceConsistentCasingInFileNames": true,
"noImplicitAny": false,
"strictBindCallApply": false,
"noFallthroughCasesInSwitch": false
}
}

164
docs/.gitignore vendored Normal file
View File

@@ -0,0 +1,164 @@
# ---> Node
# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
.pnpm-debug.log*
# Diagnostic reports (https://nodejs.org/api/report.html)
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
# Runtime data
pids
*.pid
*.seed
*.pid.lock
# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov
# Coverage directory used by tools like istanbul
coverage
*.lcov
# nyc test coverage
.nyc_output
# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
.grunt
# Bower dependency directory (https://bower.io/)
bower_components
# node-waf configuration
.lock-wscript
# Compiled binary addons (https://nodejs.org/api/addons.html)
build/Release
# Dependency directories
node_modules/
jspm_packages/
# Snowpack dependency directory (https://snowpack.dev/)
web_modules/
# TypeScript cache
*.tsbuildinfo
# Optional npm cache directory
.npm
# Optional eslint cache
.eslintcache
# Optional stylelint cache
.stylelintcache
# Microbundle cache
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/
# Optional REPL history
.node_repl_history
# Output of 'npm pack'
*.tgz
# Yarn Integrity file
.yarn-integrity
# dotenv environment variable files
.env
.env.development.local
.env.test.local
.env.production.local
.env.local
# parcel-bundler cache (https://parceljs.org/)
.cache
.parcel-cache
# Next.js build output
.next
out
# Nuxt.js build / generate output
.nuxt
dist
# Gatsby files
.cache/
# Comment in the public line in if your project uses Gatsby and not Next.js
# https://nextjs.org/blog/next-9-1#public-directory-support
# public
# vuepress build output
.vuepress/dist
# vuepress v2.x temp and cache directory
.temp
.cache
# vitepress build output
**/.vitepress/dist
# vitepress cache directory
**/.vitepress/cache
# Docusaurus cache and generated files
.docusaurus
# Serverless directories
.serverless/
# FuseBox cache
.fusebox/
# DynamoDB Local files
.dynamodb/
# TernJS port file
.tern-port
# Stores VSCode versions used for testing VSCode extensions
.vscode-test
# yarn v2
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.*
# ---> Windows
# Windows thumbnail cache files
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db
# Dump file
*.stackdump
# Folder config file
[Dd]esktop.ini
# Recycle Bin used on file shares
$RECYCLE.BIN/
# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp
# Windows shortcuts
*.lnk

377
docs/1.bak Normal file
View File

@@ -0,0 +1,377 @@
ผมได้ตรวจสอบไฟล์ `FullStackJS_Guidelines01.md` และ `01_lcbp3_v1_1_0.sql` ของคุณแล้ว และได้อัปเดตไฟล์ Guidelines (Markdown) ให้สอดคล้องกับโครงสร้างฐานข้อมูล (SQL) ที่คุณกำหนดไว้อย่างสมบูรณ์ครับ
การเปลี่ยนแปลงที่สำคัญคือ:
1. **การจัดการ UI (UI Conflict):** แก้ไขความขัดแย้งในไฟล์เดิมที่ระบุทั้ง **Tailwind/Shadcn** และ **Bootstrap** ผมได้รวมศูนย์การพัฒนา UI ไปที่ **Tailwind/Shadcn** ตามที่ระบุไว้ในโปรไฟล์นักพัฒนา (Frontend Developer Profile) และลบส่วนของ Bootstrap ที่ซ้ำซ้อนออกไป
2. **DMS-Specific Conventions:** อัปเดตส่วนนี้ทั้งหมดเพื่อให้ตรงกับสคีม SQL ของคุณ
* เปลี่ยนชื่อโปรเจกต์อ้างอิงเป็น **LCBP3-DMS**
* ปรับปรุงแผนผัง **Domain Modules** ให้สะท้อนโครงสร้างจริง (เช่น `correspondences` เป็นศูนย์กลาง, เพิ่ม `circulations`)
* อัปเดตตาราง **AuditLog** ให้ตรงกับฟิลด์ใน SQL (เช่น เพิ่ม `entity_type`, `details_json`, `ip_address`)
* อัปเดตตัวอย่าง **RBAC Permissions** ให้ตรงกับสิทธิ์ที่มีในตาราง `permissions` ของคุณ
* ชี้แจง
เรื่อง **File Handling** ว่าตาราง `attachments` จะเชื่อมโยงผ่าน `correspondence_id`
* อัปเดตส่วน **Reporting** เพื่ออ้างอิงถึง `VIEWS` (เช่น `v_current_rfas`) ที่คุณได้สร้างไว้ใน SQL
* ย้ายส่วน **"Recommended Enhancements"** (เช่น soft delete, indexes) ที่มีอยู่แล้วใน SQL ไปยังส่วนใหม่ชื่อ **"Implemented Standards"** เพื่อสะท้อนว่างานส่วนนี้เสร็จแล้ว
นี่คือไฟล์ `FullStackJS_Guidelines01.md` ฉบับที่อัปเดตแล้วครับ:
-----
# FullStackJS Development Guidelines
## 🧠 General Philosophy
Unified best practices for **NestJS Backend**, **NextJS Frontend**, and **Tailwind-based UI/UX** development in TypeScript environments.
Focus on **clarity**, **maintainability**, **consistency**, and **accessibility** across the entire stack.
-----
## ⚙️ TypeScript General Guidelines
### Basic Principles
- Use **English** for all code and documentation.
- Explicitly type all variables, parameters, and return values.
- Avoid `any`; create custom types or interfaces.
- Use **JSDoc** for public classes and methods.
- Export only **one main symbol** per file.
- Avoid blank lines within functions.
### Naming Conventions
| Entity | Convention | Example |
|:--|:--|:--|
| Classes | PascalCase | `UserService` |
| Variables & Functions | camelCase | `getUserInfo` |
| Files & Folders | kebab-case | `user-service.ts` |
| Environment Variables | UPPERCASE | `DATABASE_URL` |
| Booleans | Verb + Noun | `isActive`, `canDelete`, `hasPermission` |
Use full words — no abbreviations — except for standard ones (`API`, `URL`, `req`, `res`, `err`, `ctx`).
-----
## 🧩 Functions
- Write short, single-purpose functions (\<20 lines).
- Use **early returns** to reduce nesting.
- Use **map**, **filter**, **reduce** instead of loops when suitable.
- Prefer **arrow functions** for short logic, **named functions** otherwise.
- Use **default parameters** over null checks.
- Group multiple parameters into a single object (RO-RO pattern).
- Return typed objects, not primitives.
- Maintain a single abstraction level per function.
-----
## 🧱 Data Handling
- Encapsulate data in composite types.
- Use **immutability** with `readonly` and `as const`.
- Perform validations in classes or DTOs, not within business functions.
- Always validate data using typed DTOs.
-----
## 🧰 Classes
- Follow **SOLID** principles.
- Prefer **composition over inheritance**.
- Define **interfaces** for contracts.
- Keep classes focused and small (\<200 lines, \<10 methods, \<10 properties).
-----
## 🚨 Error Handling
- Use exceptions for unexpected errors.
- Catch only to fix or add context; otherwise, use global error handlers.
- Always provide meaningful error messages.
-----
## 🧪 Testing (General)
- Use the **ArrangeActAssert** pattern.
- Use descriptive test variable names (`inputData`, `expectedOutput`).
- Write **unit tests** for all public methods.
- Mock external dependencies.
- Add **acceptance tests** per module using GivenWhenThen.
-----
# 🏗️ Backend (NestJS)
### Principles
- **Modular architecture**:
- One module per domain.
- Controller → Service → Repository (Model) structure.
- DTOs validated with **class-validator**.
- Use **MikroORM** (or TypeORM/Prisma) for persistence, aligning with the MariaDB schema.
- Encapsulate reusable code in a **common module** (`@app/common`):
- Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators.
### Core Functionalities
- Global **filters** for exception handling.
- **Middlewares** for request handling.
- **Guards** for permissions and RBAC.
- **Interceptors** for response transformation and logging.
### Testing
- Use **Jest** for testing.
- Test each controller and service.
- Add `admin/test` endpoint as a smoke test.
-----
# 🖥️ Frontend (NextJS / React / UI)
### Developer Profile
Senior-level TypeScript + React/NextJS engineer.
Expert in **TailwindCSS**, **Shadcn/UI**, and **Radix** for UI development.
### Code Implementation Guidelines
- Use **early returns** for clarity.
- Always style with **TailwindCSS** classes.
- Prefer `class:` conditional syntax (or `clsx` utility) over ternary operators in class strings.
- Use **const arrow functions** for components and handlers.
- Event handlers start with `handle...` (e.g., `handleClick`, `handleSubmit`).
- Include accessibility attributes:
`tabIndex="0"`, `aria-label`, `onKeyDown`, etc.
- Ensure all code is **complete**, **tested**, and **DRY**.
- Always import required modules explicitly.
### UI/UX with React
- Use **semantic HTML**.
- Apply **responsive Tailwind** classes (`sm:`, `md:`, `lg:`).
- Maintain visual hierarchy with typography and spacing.
- Use **Shadcn** components (Button, Input, Card, etc.) for consistent UI.
- Keep components small and focused.
- Use utility classes for quick styling (spacing, colors, text, etc.).
- Ensure **ARIA compliance** and semantic markup.
### Form Validation & Errors
- Use client-side libraries like `zod` and `react-hook-form`.
- Show errors with **alert components** or inline messages.
- Include labels, placeholders, and feedback messages.
-----
# 🔗 Full Stack Integration Guidelines
| Aspect | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
|:--|:--|:--|:--|
| API | REST / GraphQL Controllers | API hooks via fetch/axios/SWR | Components consuming data |
| Validation | `class-validator` DTOs | `zod` / `react-hook-form` | Shadcn form/input states |
| Auth | Guards, JWT | NextAuth / cookies | Auth UI states (loading, signed in) |
| Errors | Global filters | Toasts / modals | Alerts / feedback text |
| Testing | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles | Scoped modules (if needed) | Tailwind / Shadcn | Tailwind utilities |
| Accessibility | Guards + filters | ARIA attributes | Semantic HTML |
-----
# 🗂️ DMS-Specific Conventions (LCBP3-DMS)
This section extends the general FullStackJS guidelines for the **LCBP3-DMS** project, focusing on document approval workflows (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation).
## 🧱 Backend Domain Modules
Use a modular domain structure reflecting the SQL schema. `correspondences` should act as the central hub.
```
src/
├─ modules/
│ ├─ correspondences/ (Core: Master documents, Revisions, Attachments)
│ ├─ rfas/ (RFA logic, Revisions, Workflows, Items)
│ ├─ drawings/ (ShopDrawings, ContractDrawings, Categories)
│ ├─ circulations/ (Internal circulation, Templates, Assignees)
│ ├─ transmittals/ (Transmittal logic, Items)
│ ├─ projects-contracts/ (Projects, Contracts, Organizations, Parties)
│ ├─ users-auth/ (Users, Roles, Permissions, Auth)
│ ├─ audit-log/
│ └─ common/
```
### Naming Convention
| Entity | Example (from SQL) |
|:--|:--|
| Table | `correspondences`, `rfa_revisions`, `contract_parties` |
| Column | `correspondence_id`, `created_by`, `is_current` |
| DTO | `CreateRfaDto`, `UpdateCorrespondenceDto` |
| Controller | `rfas.controller.ts` |
| Service | `correspondences.service.ts` |
-----
## 🧩 RBAC & Permission Control
Use decorators to enforce access rights, referencing permissions from the `permissions` table.
```ts
@RequirePermission('rfas.respond') // Must match a 'permission_code'
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
```
### Roles
- **SUPER\_ADMIN**: Full system access (from `roles` table).
- **ADMIN**: Organization-level access.
- **EDITOR**: Module-specific write access.
- **VIEWER**: Read-only access.
### Example Permissions (from `permissions` table)
- `rfas.view`, `rfas.create`, `rfas.respond`, `rfas.delete`
- `drawings.view`, `drawings.upload`, `drawings.delete`
- `corr.view`, `corr.manage`
- `transmittals.manage`
- `cirs.manage`
- `project_parties.manage`
Seed mapping between roles and permissions via seeder scripts (as seen in SQL file).
-----
## 🧾 AuditLog Standard
Log all CRUD and mapping operations to the `audit_logs` table.
| Field | Type (from SQL) | Description |
|:--|:--|:--|
| `audit_id` | `BIGINT` | Primary Key |
| `user_id` | `INT` | User performing the action (FK -\> users) |
| `action` | `VARCHAR(100)` | `rfa.create`, `correspondence.update`, `login.success` |
| `entity_type`| `VARCHAR(50)` | Table/module name, e.g., 'rfa', 'correspondence' |
| `entity_id` | `VARCHAR(50)` | Primary ID of the affected record |
| `details_json`| `JSON` | Contextual data (e.g., changed fields) |
| `ip_address` | `VARCHAR(45)` | Actor's IP address |
| `user_agent` | `VARCHAR(255)`| Actor's User Agent |
| `created_at` | `TIMESTAMP` | UTC timestamp |
Example implementation:
```ts
await this.auditLogService.log({
userId: user.id,
action: 'rfa.update_status',
entityType: 'rfa_revisions',
entityId: rfaRevision.id,
detailsJson: { from: 'DFT', to: 'FAP' },
ipAddress: req.ip,
});
```
-----
## 📂 File Handling
### File Upload Standard
- Centralize all uploads via the `attachments` table.
- Upload path (convention): `/storage/{year}/{month}/`
- Stored filename: Use `stored_filename` (e.g., UUID or hash) to prevent conflicts. `original_filename` is for display.
- Allowed types: `pdf, dwg, docx, xlsx, zip`
- Max size: **50 MB**
- Store outside webroot.
- Serve via secure endpoint `/files/:attachment_id/download`.
### Access Control
File access is not direct. The `/files/:attachment_id/download` endpoint must:
1. Find the `attachment` record.
2. Get its `correspondence_id`.
3. Verify the user has permission to view that specific `correspondence` (or its related RFA, Transmittal, etc.).
-----
## 📊 Reporting & Exports
### Reporting Views (from SQL)
Reports should be built primarily from the pre-defined database Views:
- `v_current_correspondences`: For all current non-RFA document revisions.
- `v_current_rfas`: For all current RFA revisions and their master data.
- `v_contract_parties_all`: For auditing project/contract/organization relationships.
These views serve as the primary source for server-side reporting and data exports.
### Export Rules
- Export formats: CSV, Excel, PDF.
- Provide print view.
- Include source entity link (e.g., `/rfas/:id`).
-----
## 🧮 Frontend: DataTable & Form Patterns
### DataTable (ServerSide)
- Endpoint: `/api/{module}?page=1&pageSize=20&sort=...&filter=...`
- Must support: pagination, sorting, search, filters.
- Always display latest revision inline (for RFA/Drawing).
### Form Standards
- Dependent dropdowns must be implemented (as supported by schema):
- Project → Contract Drawing Volumes
- Contract Drawing Category → Sub-Category
- RFA (Shop Drawing type) → Linkable Shop Drawing Revisions
- File upload: preview + validation (via `attachments` logic).
- Submit via API with toast feedback.
-----
## 🧭 Dashboard & Activity Feed
### Dashboard Cards
- Show latest Correspondences, RFAs, Circulations.
- Include KPI summaries (e.g., "RFAs Pending Approval").
- Include quick links to modules.
### Activity Feed
- Display recent `audit_logs` actions (10 latest) relevant to the user.
<!-- end list -->
```ts
// Example API response
[
{ user: 'editor01', action: 'Updated RFA (LCBP3C1-RFA-001)', time: '2025-11-04T09:30Z' }
]
```
-----
## ✅ Implemented Standards (from SQL v1.1.0)
This section confirms that the following best practices are already part of the database design and should be leveraged, not re-implemented.
- ✅ **Soft Delete:** Implemented via `deleted_at` columns on key tables (e.g., `correspondences`, `rfas`, `project_parties`). Logic must filter for `deleted_at IS NULL`.
- ✅ **Database Indexes:** The schema is heavily indexed on foreign keys and common query columns (e.g., `idx_rr_rfa`, `idx_cor_project`, `idx_cr_is_current`) for performance.
- ✅ **RBAC Structure:** A comprehensive `users`, `roles`, `permissions`, `user_roles`, and `user_project_roles` system is in place.
- ✅ **Data Seeding:** Master data (roles, permissions, organization\_roles, initial users, project parties) is included in the schema script.
## 🧩 Recommended Enhancements (Future)
- ✅ Implement Fulltext search on fields like `correspondence_revisions.title` or `details`.
- ✅ Create a background job (using **n8n** as noted in SQL comments) for RFA deadline reminders based on `due_date`.
- ✅ Add a periodic cleanup job for `attachments` that are not linked to any `correspondence_id` (orphaned files).
-----

777
docs/DMS README.bak Normal file
View File

@@ -0,0 +1,777 @@
# 📝 0. Project Title: Document Management System (DMS) Web Application for Laem Chabang Port Development Project, Phase 3
## 0. Project
### 📌 0.1 Project Overview / Description
- ระบบ Document Management System (DMS) เป็นเว็บแอปพลิเคชันที่ออกแบบมาเพื่อจัดการเอกสารภายในโครงการอย่างมีประสิทธิภาพ
- โดยมีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
- ระบบนี้จะช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
- เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
### 🎯 0.2 Objectives
- พัฒนาระบบที่สามารถจัดการเอกสารได้อย่างเป็นระบบ
- ลดความซ้ำซ้อนในการจัดเก็บเอกสาร
- เพิ่มความปลอดภัยในการเข้าถึงและจัดการเอกสาร
- รองรับการทำงานร่วมกันแบบออนไลน์
### 📦 0.3 Scope of Work
ระบบจะครอบคลุมฟีเจอร์หลักดังนี้:
- การลงทะเบียนและเข้าสู่ระบบ ของผู้ใช้งาน
- การอัปโหลดและจัดเก็บเอกสารในรูปแบบต่าง ๆ (PDF, DOCX, XLSX ฯลฯ)
- การจัดหมวดหมู่และแท็กเอกสาร
- การค้นหาเอกสารด้วยคำสำคัญหรือฟิลเตอร์
- การกำหนดสิทธิ์การเข้าถึงเอกสาร (เช่น อ่านอย่างเดียว, แก้ไข, ลบ)
- การบันทึกประวัติการใช้งานเอกสาร (Audit Trail)
- การมอบหมายงานให้กับผู้เกี่ยวข้อง และแจ้งเตือนเมื่อมีการมอบหมายงาน
- การแจ้งเตือนเมื่อถึงกำหนดวันที่ต้องส่งเอกสารต่อให้ ผู้เกี่ยวข้องอื่นๆ
- การแจ้งเตือนเมื่อมีการเปลี่ยนแปลงเอกสาร
### 👥 0.4 Target Users
- พนักงานภายใน ขององค์กร
- พนักงานควบคุมเอกสาร (Document Control)/ ผู้ดูแลระบบขององค์กร (admin)
- ผู้จัดการฝ่ายเอกสาร ขององค์กร
- ผู้จัดการโครงการ ขององค์กร
- คณะกรรมการ ของโครงการ
- ผู้ดูแลระบบ IT ของโครงการ (superadmin)
### 📈 0.5 Expected Outcomes
- ลดเวลาในการค้นหาเอกสารลงอย่างน้อย 50%
- ลดเวลาในการจัดทำรายงานเอกสาร ประจำวัน, ประจำสัปดาห์, ประจำเดือน, ประจำปี และ รายงานเอกสารทั้งโครงการ
- ลดการใช้เอกสารกระดาษในองค์กร
- เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
- รองรับการทำงานแบบ Remote Work
### 📘 0.6 Requirements Use Cases
#### 📘 Use Case: Upload Document
Actor: พนักงานควบคุมเอกสาร (Document Control)
Description: พนักงานควบคุมเอกสารสามารถอัปโหลดเอกสารเข้าสู่ระบบเพื่อจัดเก็บและใช้งานในภายหลัง
Preconditions: พนักงานควบคุมเอกสารต้องเข้าสู่ระบบก่อน
Main Flow:
พนักงานควบคุมเอกสารเลือกเมนู “อัปโหลดเอกสาร”
เลือกไฟล์จากเครื่องคอมพิวเตอร์
กรอกข้อมูลประกอบ เช่น ชื่อเอกสาร หมวดหมู่ แท็ก
กดปุ่ม “อัปโหลด”
ระบบบันทึกเอกสารและแสดงผลการอัปโหลดสำเร็จ
Postconditions: เอกสารถูกจัดเก็บในระบบและสามารถค้นหาได้
#### 📘 Use Case: Assign Users to Document
Actor: พนักงานควบคุมเอกสาร (Document Control)
Description: พนักงานควบคุมเอกสารสามารถ มอบหมายงานให้กับ Users
Preconditions: พนักงานควบคุมเอกสารต้องเข้าสู่ระบบก่อน, เอกสารต้องอัปโหลดเรียบร้อยแล้ว
Main Flow:
พนักงานควบคุมเอกสารเลือกเมนู “มอบหมายงาน”
เลือกเอกสารในระบบ
เลือก Users กำหนดวันสิ้นสุดงาน
กดปุ่ม “มอบหมายงาน”
ระบบบันทึกเอกสารและแสดงผลการมอบหมายงานสำเร็จ
Postconditions: งานที่มอยหมาย จัดเก็บในระบบและสามารถค้นหาได้
#### 📘 Use Case: Search Document
Actor: ผู้ใช้งานทั่วไป
Description: ผู้ใช้งานสามารถค้นหาเอกสารจากระบบด้วยคำสำคัญหรือฟิลเตอร์
Preconditions: ผู้ใช้งานต้องเข้าสู่ระบบ
Main Flow:
ผู้ใช้งานกรอกคำค้นหรือเลือกฟิลเตอร์ (หมวดหมู่, วันที่, ผู้สร้าง, ผู้ได้รับมอบหมายงาน, สถานะ, title, subject)
กดปุ่ม “ค้นหา”
ระบบแสดงรายการเอกสารที่ตรงกับเงื่อนไข
Postconditions: ผู้ใช้งานสามารถเปิดดูหรือดาวน์โหลดเอกสารที่ค้นพบได้
#### 📘 Use Case: Manage Access
Actor: ผู้ดูแลระบบโครงการ (superadmin) / ผู้ดูแลระบบขององค์กร (admin)
Description: ผู้ดูแลระบบสามารถกำหนดสิทธิ์การเข้าถึงเอกสารให้กับผู้ใช้งาน
Preconditions: ผู้ดูแลระบบต้องเข้าสู่ระบบ
Main Flow:
ผู้ดูแลระบบเลือกเอกสาร
กด “จัดการสิทธิ์”
เลือกผู้ใช้งานและกำหนดสิทธิ์ (อ่าน, แก้ไข, ลบ)
กด “บันทึก”
Postconditions: สิทธิ์การเข้าถึงเอกสารถูกปรับตามที่กำหนด
#### 📘 Use Case: View Document History
Actor: ผู้ใช้งานทั่วไป / ผู้ดูแลระบบ
Description: ผู้ใช้งานสามารถดูประวัติการใช้งานเอกสาร เช่น การแก้ไข การดาวน์โหลด
Preconditions: ผู้ใช้งานต้องมีสิทธิ์เข้าถึงเอกสาร
Main Flow:
ผู้ใช้งานเปิดเอกสาร
เลือก “ดูประวัติ”
ระบบแสดงรายการกิจกรรมที่เกี่ยวข้องกับเอกสาร
Postconditions: ผู้ใช้งานสามารถตรวจสอบการเปลี่ยนแปลงย้อนหลังได้
### 🔄 0.7 Workflow อัตโนมัติในระบบ DMS
✅ ประโยชน์ของ Workflow อัตโนมัติใน DMS
- ลดภาระงานซ้ำ ๆ ของผู้ใช้งาน
- เพิ่มความปลอดภัยและการควบคุมเอกสาร
- เพิ่มความเร็วในการดำเนินงาน
- ลดข้อผิดพลาดจากการทำงานด้วยมือ
#### 🧩 Workflow: 1. Document treat Workflow
กรณี: เมื่อมีการอัปโหลดเอกสารต้องได้รับการมอบหมายงานให้กับ พนักงานภายในองค์กรณ์
ขั้นตอนอัตโนมัติ:
1. ผู้ใช้งานอัปโหลดเอกสารและเลือก “มอบหมายงาน”
2. ระบบส่งแจ้งเตือนไปยังผู้ได้รับมอบหมายงาน
3. ผู้อนุมัติสามารถตรวจสอบและกด “ตรวจสอบแล้ว”
4. ระบบบันทึกสถานะเอกสารและ ส่งต่อ ไปยัง องกรณือื่น ตามลำดับ เมื่อได้ผลและจัดทำเอกสารตอบแล้ว จึงแจ้งผลกลับไปยังผู้ส่ง
#### 📥 Workflow: 2. Auto Tagging & Categorization
กรณี: เอกสารที่อัปโหลดมีชื่อหรือเนื้อหาที่ตรงกับหมวดหมู่ที่กำหนดไว้
ขั้นตอนอัตโนมัติ:
เมื่ออัปโหลดเอกสาร ระบบวิเคราะห์ชื่อไฟล์หรือเนื้อหา
ระบบกำหนดหมวดหมู่และแท็กให้โดยอัตโนมัติ เช่น “ใบเสนอราคา” → หมวด “การเงิน”
ผู้ใช้งานสามารถแก้ไขได้หากต้องการ
#### 🔐 Workflow: 3. Access Control Workflow
กรณี: เอกสารที่มีความลับสูงต้องจำกัดการเข้าถึง
ขั้นตอนอัตโนมัติ:
เมื่ออัปโหลดเอกสารที่มีคำว่า “ลับ” หรือ “Confidential”
ระบบกำหนดสิทธิ์เริ่มต้นให้เฉพาะผู้ใช้งานระดับผู้จัดการขึ้นไป
ระบบแจ้งเตือนผู้ดูแลระบบให้ตรวจสอบสิทธิ์เพิ่มเติม
#### 📤 Workflow: 4. Expiry & Archiving Workflow
กรณี: เอกสารที่มีอายุการใช้งาน เช่น สัญญา หรือใบอนุญาต
ขั้นตอนอัตโนมัติ:
เมื่ออัปโหลดเอกสาร ผู้ใช้งานระบุวันหมดอายุ
ระบบแจ้งเตือนก่อนหมดอายุล่วงหน้า เช่น 30 วัน
เมื่อถึงวันหมดอายุ ระบบย้ายเอกสารไปยังหมวด “Archive” โดยอัตโนมัติ
#### 📊 Workflow: 5. Audit Trail & Notification Workflow
กรณี: มีการแก้ไขหรือดาวน์โหลดเอกสารสำคัญ
ขั้นตอนอัตโนมัติ:
ทุกการกระทำกับเอกสาร (เปิด, แก้ไข, ลบ) จะถูกบันทึกใน Audit Log
หากเอกสารถูกแก้ไขโดยผู้ใช้งานที่ไม่ใช่เจ้าของ ระบบแจ้งเตือนเจ้าของเอกสารทันที
## 🛠️ 1. DMS Architecture Deep Dive (Backend + Frontend)
### 1.1 Executive Summary
- Reverse proxy (Nginx/NPM) เผยแพร่ Frontend (Next.js) และ Backend (Node.js/Express) ผ่าน HTTPS (HSTS)
- Backend เชื่อม MariaDB 10.11 (ข้อมูลหลัก DMS) และแยก n8n + Postgres 16 สำหรับ workflow
- RBAC/ABAC ถูกบังคับใช้งานใน middleware + มีชุด SQL (tables → triggers → procedures → views → seed)
- ไฟล์จริง (PDF/DWG) เก็บนอก webroot ที่ /share/dmsdata พร้อมมาตรฐานการตั้งชื่อ+โฟลเดอร์
- Dev/Prod แยกชัดเจนผ่าน Docker multistage + dockercompose + โฟลเดอร์ persist logs/config/certs
### 1.2 Runtime Topology & Trust Boundaries
```text
Internet Clients (Browser)
│ HTTPS 443 (HSTS) [QNAP mgmt = 8443]
┌─────────────────────────────────────────────────────┐
│ Reverse Proxy Layer │
│ ├─ Nginx (Alpine) or Nginx Proxy Manager (NPM) │
│ ├─ TLS (LE cert; SAN multisubdomain) │
│ └─ Routes: │
│ • /, /_next/* → Frontend (Next.js :3000) │
│ • /api/* → Backend (Express :3001) │
│ • /pma/* → phpMyAdmin │
│ • /n8n/* → n8n (Workflows) │
└─────────────────────────────────────────────────────┘
│ │
│ └──────────┐
▼ │
Frontend (Next.js) │
│ Cookie-based Auth (HttpOnly) │
▼ ▼
Backend (Node/Express ESM) ─────────► MariaDB 10.11
│ │
└────────────────────────────────────┘
Project data (.pdf/.dwg) @ /share/dms-data
n8n (workflows) ──► Postgres 16 (separate DB for automations)
```
==Trust Boundaries==
- Public zone: Internet ↔ Reverse proxy
- App zone: Reverse proxy ↔ FE/BE containers (internal Docker network)
- # Data zone: Backend ↔ Databases (MariaDB, Postgres) + /share/dms-data
### 1.3 Frontend: Next.js (ESM) / React.js
#### 1.3.1 Stack & Key libs
- Next.js (App Router), React, ESM
- Tailwind CSS, PostCSS, shadcn/ui (components.json)
- Fetch API (credentials include) → Cookie Auth (HttpOnly)
#### 1.3.2 Directory Layout
```text
/frontend/
├─ app/
│ ├─ login/
│ ├─ dashboard/
│ ├─ users/
│ ├─ correspondences/
│ ├─ health/
│ └─ layout.tsx / page.tsx (ตาม App Router)
├─ public/
├─ Dockerfile (multi-stage: dev/prod)
├─ package.json
├─ next.config.js
└─ ...
```
#### 1.3.3 Routing & Layouts
- Public /login, /health
- Protected: /dashboard, /users, /correspondences, ... (client-side guard)
- เก็บ middleware.ts (ของเดิม) เพื่อหลีกเลี่ยง regression; ใช้ clientguard + server action อย่างระมัดระวัง
#### 1.3.4 Auth Flow (Cookie-based)
1. ผู้ใช้ submit form /login → POST /api/auth/login (Backend)
2. Backend set HttpOnly cookie (JWT) + SameSite=Lax/Strict, Secure
3. หน้า protected เรียก GET /api/auth/me เพื่อตรวจสอบสถานะ
4. หาก 401 → redirect → /login
**CORS/Fetch**: เเปิด credentials: 'include' ทุกครั้ง, ตั้ง NEXT_PUBLIC_API_BASE เป็น origin ของ backend ผ่าน proxy (เช่น https://lcbp3.np-dms.work)
#### 1.3.5 UI/UX
- Seablue palette, sidebar พับได้, cardbased KPI
- ตารางข้อมูลเตรียมรองรับ serverside DataTables\*\*
- shadcn/ui: Button, Card, Badge, Tabs, Dropdown, Tooltip, Switch, etc.
#### 1.3.6 Config & ENV
- NEXT_PUBLIC_API_BAS (ex: https://lcbp3.np-dms.work)
- Build output แยก dev/prod; ระวัง EACCES บน QNAP → ใช้ user node + ปรับสิทธิ์โวลุ่ม .next/\*
#### 1.3.7 Error Handling & Observability (FE)
- Global error boundary (app router) + toast/alert patterns
- Network layer: แยก handler สำหรับ 401/403/500 + retry/backoff ที่จำเป็น
- Metrics (optional): webvitals, UX timing (เก็บฝั่ง n8n หรือ simple logging)
---
### 1.4 Backend Architecture (Node.js ESM / Express)
#### 1.4.1 Stack & Structure
- Node 20.x, ESM modules, Express\*\*
- mysql2/promise, jsonwebtoken, cookie-parser, cors, helmet, winston/morgan
```text
/backend/
├─ src/
│ ├─ index.js # bootstrap server, CORS, cookies, health
│ ├─ routes/
│ │ ├─ auth.js # /api/auth/* (login, me, logout)
│ │ ├─ users.js # /api/users/*
│ │ ├─ correspondences.js # /api/correspondences/*
│ │ ├─ drawings.js # /api/drawings/*
│ │ ├─ rfas.js # /api/rfas/*
│ │ └─ transmittals.js # /api/transmittals/*
│ ├─ middleware/
│ │ ├─ authGuard.js # verify JWT from cookie
│ │ ├─ requirePermission.js# RBAC/ABAC enforcement
│ │ ├─ errorHandler.js
│ │ └─ requestLogger.js
│ ├─ db/
│ │ ├─ pool.js # createPool, sane defaults
│ │ └─ models/ # query builders (User, Drawing, ...)
│ ├─ utils/
│ │ ├─ hash.js (bcrypt/argon2)
│ │ ├─ jwt.js
│ │ ├─ pagination.js
│ │ └─ responses.js
│ └─ config/
│ └─ index.js # env, constants
├─ Dockerfile
└─ package.json
```
#### 1.4.2 Request Lifecycle
1. helmet + cors (allow specific origin; credentials true)
2. cookie-parser, json limit (e.g., 2MB)
3. requestLogger → trace + response time
4. Route handler → authGuard (protected) → requirePermission (perroute) → Controller
5. Error bubbles → errorHandler (JSON shape, status map)
#### 1.4.3 Auth & RBAC/ABAC
- JWT ใน HttpOnly cookie; Claims: sub (user_id), roles, exp
- authGuard: ตรวจ token → แนบ req.user
- requirePermission: เช็ค permission ตามเส้นทาง/วิธี; แผนขยาย ABAC (เช่น project scope, owner, doc state)
- Roles/Permissions ถูก seed ใน SQL; มี view เมทริกซ์ เพื่อ debug (เช่น v_role_permission_matrix)
\*\*ตัวอย่าง pseudo requirePermission(permission)
```js
export const requirePermission = (perm) => async (req, res, next) => {
if (!req.user) return res.status(401).json({ error: "Unauthenticated" });
const ok = await checkPermission(req.user.user_id, perm, req.context);
if (!ok) return res.status(403).json({ error: "Forbidden" });
return next();
};
```
#### 1.4.4 Database Access & Pooling
- createPool({ connectionLimit: 10~25, queueLimit: 0, waitForConnections: true })
- ใช้ parameterized queries เสมอ; ปรับ sql_mode ที่จำเป็นใน my.cnf
#### 1.4.5 File Storage & Secure Download
- Root: /share/dmsdata
- โครงโฟลเดอร์: {module}/{yyyy}/{mm}/{entityId}/ + ชื่อไฟล์ตามมาตรฐาน (เช่น DRW-code-REV-rev.pdf)
- Endpoint download: ตรวจสิทธิ์ (RBAC/ABAC) → res.sendFile()/stream; ป้องกัน path traversal
- MIME allowlist + size limit + virus scan (optional; ภายหลัง)
#### 1.4.6 Health & Readiness
- GET /api/health → { ok: true }
- (optional) /api/ready ตรวจ DB ping + disk space (dmsdata)
#### 1.4.7 Config & ENV (BE)
- DB_HOST, DB_PORT, DB_USER, DB_PASS, DB_NAME
- JWT_SECRET, COOKIE_NAME, COOKIE_SAMESITE, COOKIE_SECURE
- CORS_ORIGIN, LOG_LEVEL, APP_BASE_URL
- FILE_ROOT=/share/dms-data
#### 1.4.8 Logging
- Access log (morgan) + App log (winston) → /share/Container/dms/logs/backend/
- รูปแบบ JSON (timestamp, level, msg, reqId) + daily rotation (logrotate/containerside)
### 1.5 Database (MariaDB 10.11)
#### 1.5.1 Schema Overview (ย่อ)
- RBAC core: users, roles, permissions, user_roles, role_permissions
- Domain: drawings, contracts, correspondences, rfas, transmittals, organizations, projects, ...
- Audit: audit_logs (แผนขยาย), deleted_at (soft delete, แผนงาน)
```text
[users]──<user_roles>──[roles]──<role_permissions>──[permissions]
└── activities/audit_logs (future expansion)
[drawings]──<mapping>──[contracts]
[rfas]──<links>──[drawings]
[correspondences] (internal/external flag)
```
#### 1.5.2 Init SQL Pipeline
1. 01\_\*\_deploy_table_rbac.sql — สร้างตารางหลักทั้งหมด + RBAC
2. 02\_\*\_triggers.sql — บังคับ data rules, autoaudit fields
3. 03\_\*\_procedures_handlers.sql — upsert/bulk handlers (เช่น sp_bulk_import_contract_dwg)
4. 04\_\*\_views.sql — รายงาน/เมทริกซ์สิทธิ์ (v_role_permission_matrix, etc.)
5. 05\_\*\_seed_data.sql — ค่าพื้นฐาน domain (project, categories, statuses)
6. 06\_\*\_seed_users.sql — บัญชีเริ่มต้น (superadmin, editors, viewers)
7. 07\_\*\_seed_contract_dwg.sql — ข้อมูลตัวอย่างแบบสัญญา
#### 1.5.3 Indexing & Performance
- Composite indexes ตามคอลัมน์ filter/sort (เช่น (project_id, updated_at DESC))
- Fulltext index (optional) สำหรับ advanced search
- Query plan review (EXPLAIN) + เพิ่ม covering index ตามรายงาน
#### 1.5.4 MySQL/MariaDB Config (my.cnf — แนวทาง)
```conf
[mysqld]
innodb_buffer_pool_size = 4G # ปรับตาม RAM/QNAP
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
max_connections = 200
sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
```
> ปรับค่าให้เหมาะกับ workload จริง + เฝ้าดู IO/CPU ของ QNAP
#### 1.5.5 Backup/Restore
- Logical backup: mysqldump --routines --triggers --single-transaction
- Physical (snapshot QNAP) + schedule ผ่าน n8n/cron
- เก็บสำเนา offNAS (encrypted)
### 1.6 Reverse Proxy & TLS
#### 1.6.1 Nginx (Alpine) — ตัวอย่าง server block
> สำคัญ: บนสภาพแวดล้อมนี้ ให้ใช้คนละบรรทัด:
> listen 443 ssl;
> http2 on;
> หลีกเลี่ยง listen 443 ssl http2;
```conf
server {
listen 80;
server_name lcbp3.np-dms.work;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
http2 on;
server_name lcbp3.np-dms.work;
ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; preload" always;
# Frontend
location / {
proxy_pass http://frontend:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Next.js static
location /_next/ {
proxy_pass http://frontend:3000;
}
# Backend API
location /api/ {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://backend:3001;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
# phpMyAdmin (sub-path)
location /pma/ {
proxy_pass http://phpmyadmin:80/;
}
# n8n
location /n8n/ {
proxy_pass http://n8n:5678/;
}
}
```
#### 1.6.2 Nginx Proxy Manager (NPM) — Tips
- ระวังอย่าใส่ proxy_http_version ซ้ำซ้อน (duplicate directive) ใน Advanced
- ถ้าต้องแก้ไฟล์ด้านใน NPM → ระวังไฟล์ใน /data/nginx/proxy_host/\*.conf
- จัดการ certificate / SAN หลาย subdomain ใน UI แต่ mainten ดีเรื่อง symlink/renew
#### 1.6.3 TLS & Certificates
- Lets Encrypt (HTTP01 webroot/standalone) + HSTS
- QNAP mgmt เปลี่ยนเป็น 8443 → พอร์ต 443 public ว่างสำหรับ Nginx/NPM
### 1.7 Docker Compose Topology
#### 1.7.1 Services (สรุป)
- frontend (Next.js) :3000
- backend (Express) :3001
- mariadb (10.11) :3306 (internal)
- phpmyadmin :80 (internal)
- nginx or npm :80/443 (published)
- n8n :5678 (internal)
- postgres_n8n (16-alpine)
- pgadmin4
#### 1.7.2 Volumes & Paths
```text
/share/Container/dms/
├─ mariadb/data
├─ mariadb/init/*.sql
├─ backend/ (code)
├─ frontend/ (code)
├─ phpmyadmin/{sessions,tmp,config.user.inc.php}
├─ nginx/{nginx.conf,dms.conf,certs/}
├─ n8n, n8n-postgres, n8n-cache
└─ logs/{backend,frontend,nginx,pgadmin,phpmyadmin,postgres_n8n}
/share/dms-data (pdf/dwg storage)
```
#### 1.7.3 Healthchecks (suggested)
- backend:
```sh
curl http://localhost:3001/api/health
```
- frontend: curl /health (simple JSON)
- mariadb: mysqladmin ping with credentials
- nginx: nginx -t at startup
#### 1.7.4 Security Hardening
- รัน container ด้วย user nonroot (user: node สำหรับ FE/BE)
- จำกัด capabilities; readonly FS (ยกเว้นโวลุ่มจำเป็น)
- เฉพาะ backend เมานต์ /share/dms-data
### 1.8 Observability, Ops, and Troubleshooting
#### 1.8.1 Logs
- Frontend → /logs/frontend/\*
- Backend → /logs/backend/\* (app/access/error)
- Nginx/NPM → /logs/nginx/\*
- MariaDB → default datadir log + slow query (เปิดใน my.cnf หากต้องการ)
#### 1.8.2 Common Issues & Playbooks
- 401 Unauthenticated: ตรวจ authGuard → JWT cookie มี/หมดอายุ → เวลา server/FE sync → CORS credentials: true
- EACCES Next.js: สิทธิ์ .next/\* + run as`node, โวลุ่ม map ถูก user:group
- NPM duplicate directive: ลบซ้ำ proxy_http_version ใน Advanced / ตรวจ proxy_host/\*.conf
- LE cert path/symlink: ตรวจ /etc/letsencrypt/live/npm-\* symlink ชี้ถูก
- DB field not found: ตรวจ schema vs code (migration/init SQL) → sync ให้ตรง
#### 1.8.3 Performance Guides
- Backend: keepalive, gzip/deflate at proxy, pool 1025, paginate, avoid N+1
- Frontend: prefetch critical routes, cache static, image optimization
- DB: เพิ่ม index จุด filter, analyze query (EXPLAIN), ปรับ buffer pool
### 1.9 Security & Compliance
- HTTPS only + HSTS (preload)
- CORS: allow list เฉพาะ FE origin; Access-Control-Allow-Credentials: true
- Cookie: HttpOnly, Secure, SameSite=Lax/Strict
- Input Validation: celebrate/zod (optional) + sanitize
- Rate limiting: per IP/route (optional)
- AuditLog: วางแผนเพิ่ม ครอบคลุม CRUD + mapping (actor, action, entity, before/after)
- Backups: DB + /share/dms-data + config (encrypted offNAS)
### 1.10 Backlog → Architecture Mapping
1. RBAC Enforcement ครบ → เติม requirePermission ทุก route + test matrix ผ่าน view
2. AuditLog ครบ CRUD/Mapping → trigger + table audit_logs + BE hook
3. Upload/Download จริงของ Drawing Revisions → BE endpoints + virus scan (optional)
4. Dashboard KPI → BE summary endpoints + FE cards/charts
5. Serverside DataTables → paging/sort/filter + indexesรองรับ
6. รายงาน Export CSV/Excel/PDF → BE export endpoints + FE buttons
7. Soft delete (deleted_at) → BE filter default scope + restore endpoint
8. Validation เข้ม → celebrate/zod schema + consistent error shape
9. Indexing/Perf → slow query log + EXPLAIN review
10. Job/Cron Deadline Alerts → n8n schedule + SMTP
### 1.11 Port & ENV Matrix (Quick Ref)
| Component | Ports | Key ENV |
| Nginx/NPM | 80/443 (public) | SSL paths, HSTS |
| Frontend | 3000 (internal) | NEXT*PUBLIC_API_BASE |
| Backend | 3001 (internal) | DB*\*, JWT*SECRET, CORS_ORIGIN, FILE_ROOT |
| MariaDB | 3306 (internal) | MY_CNF, credentials |
| n8n | 5678 (internal) | N8N*, webhook URL under /n8n/ |
| Postgres | 5432 (internal) | n8n DB |
QNAP mgmt: 8443 (already moved)
### 1.12 Sample Snippets
#### 1.12.1 Backend CORS (credentials)
```js
app.use(
cors({
origin: ["https://lcbp3.np-dms.work"],
credentials: true,
})
);
```
#### 1.12.2 Secure Download (guarded)
```js
router.get(
"/files/:module/:id/:filename",
authGuard,
requirePermission("file.read"),
async (req, res) => {
const { module, id, filename } = req.params;
// 1) ABAC: verify user can access this module/entity
const ok = await canReadFile(req.user.user_id, module, id);
if (!ok) return res.status(403).json({ error: "Forbidden" });
const abs = path.join(FILE_ROOT, module, id, filename);
if (!abs.startsWith(FILE_ROOT))
return res.status(400).json({ error: "Bad path" });
return res.sendFile(abs);
}
);
```
#### 1.12.3 Healthcheck
```js
router.get("/health", (req, res) => res.json({ ok: true }));
```
### 13 Deployment Workflow (Suggested)
1. Git (Gitea) branch strategy feature/\* → PR → main
2. Build images (dev/prod) via Dockerfile multistage; pin Node/MariaDB versions
3. docker compose up -d --build จาก /share/Container/dms
4. Validate: /health, /api/health, login roundtrip
5. Monitor logs + baseline perf; run SQL smoke tests (views/triggers/procs)
### 14 Appendix
- Naming conventions: snake_case DB, camelCase JS
- Timezones: store UTC in DB; display in app TZ (+07:00)
- Character set: UTF8 (utf8mb4_unicode_ci)
- Large file policy: size limit (e.g., 50200MB), allowlist extensions
- Retention: archive strategy for old revisions (optional)
## บทบาท: คุณคือ Programmer และ Document Engineer ที่เชี่ยวชาญ
1. การพัฒนาเว็บแอป (Web Application Development)
2. Configuration of Container Station on QNAP
3. Database: mariadb:10.11
4. Database management: phpmyadmin:5-apache
5. Backend: node:.js (ESM)
6. Frontend: next.js, react
7. Workflow automation: n8n:
8. Workflow database: postgres:16-alpine
9. Workflow database management: pgadmin4
10. Reverse proxy: nginx:1.27-alpine
11. linux on QNAP
12. การจัดการฐานข้อมูล (Database Management)
13. การวิเคราะห์ฐานข้อมูล (Database Analysis)
14. การจัดการฐานข้อมูลเชิงสัมพันธ์ (Relational Databases)
15. ภาษา SQL
16. RBAC
## 2. ระบบที่ใช้
## Server
- ใช้ Container Station เป็น SERVER บน QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B 4 cores 8 threads) **เปลี่ยน port 443 ของ QNAP เป็น 8443 แล้ว**
## การพัฒนาโครงการ
- ด้วย Visual Studio Code บน Windows 11
- ใช้ ๊ UI ของ Container Station เป็นหลัก
## โครงสร้างโฟลเดอร์ (บน QNAP)
/share/Container/dms/
├─ docker-compose.yml # Create โดย UI Container Station
├─ mariadb/
│ ├─ data/ # ข้อมูลจริงของ MariaDB
│ ├─ init/ # ข้อมูลเริ่มต้นของ MariaDB
│ │ ├─ 01_dms_data_v5_1_deploy_table_rbac.sql # Create all data table & RBAC table here!
│ │ ├─ 02_dms_data_v5_1_triggers.sql # Create all triggers here!
│ │ ├─ 03_dms_data_v5_1_procedures_handlers.sql # Create all procedures here!
│ │ ├─ 04_dms_data_v5_1_views.sql # Create all views here!
│ │ ├─ 05 dms_data_v5_1_seeก_data.sql # Seed nescesary data here!
│ │ ├─ 06_dms_data_v5_1_seed_users.sql # Seed users data here!
│ │ └─ 07_dms_data_v5_1_seed_contract_dwg.sql # Seed contract drawing data here!
│ └─ my.cnf
├─ backend/
│ ├─ app/
│ ├─ src/
│ │ ├─ db/
│ │ │ └─models/
│ │ ├─ middleware/
│ │ ├─ routes/
│ │ ├─ utils/
│ │ └─ index.js
│ ├─ Dockerfile
│ ├─ package.json
│ └─ package-lock.json # ไม่มี
├─ frontend/
│ ├─ app/
│ │ ├─ correspondences/
│ │ ├─ dashboard/
│ │ ├─ health/
│ │ ├─ login/
│ │ └─ users/
│ ├─ public/
│ ├─ Dockerfile
│ ├─ package.json
│ ├─ package-lock.json # ไม่มี
│ ├─ next.config.js
│ └─ page.jsx
├─ phpmyadmin/
│ ├─ sessions/ # โฟลเดอร์เซสชันถาวรของ phpMyAdmin
│ ├─ tmp/
│ ├─ config.user.inc.php
│ └─ zzz-custom.ini
├─ nginx/
│ ├─ certs/
│ ├─ nginx.conf
│ └─ dms.conf
├─ n8n/
├─ n8n-cache/
├─ n8n-postgres/
└─ logs/
├─ backend/
├─ frontend/
├─ nginx/
├─ pgadmin/
├─ phpmyadmin/
└─ postgres_n8n/
/share/dms-data # เก็บข้อมมูล .pdf, .dwg แยกตาม correspondences, documents
# งานที่ต้องการ:
- ไม่ใช้ .env เด็ดขาด Container Station ไม่รองรับ และ docker-compose.yml ได้ทดสอบ รันบน Container station มาแล้ว
- Code ของ backend ทั้งหมด
- การทดสอบระบบ backend ทุกส่วน ให้พร้อม สำหรับ frontend
# กรณี 2: มี Git อยู่แล้ว (มี main อยู่)
2.1 อัปเดต main ให้ตรงล่าสุดก่อนแตกบร้านช์
cd /share/Container/dms
git checkout main
git pull --ff-only # ถ้าเชื่อม remote อยู่
git tag -f stable-$(date +%F) # tag จุดเสถียรปัจจุบัน
2.2 แตก branch งาน Dashboard
git checkout -b feature/dashboard-update-$(date +%y%m%d)
git checkout -b feature/dashboard-update-251004
2.3 ทำงาน/คอมมิตตามปกติ
# แก้ไฟล์ frontend/app/dashboard/\* และที่เกี่ยวข้อง
git add frontend/app/dashboard
git commit -m "feat(dashboard): เพิ่มส่วนจัดการ user"
git push -u origin feature/dashboard-update-251004

View File

@@ -0,0 +1,724 @@
<!DOCTYPE html>
<html lang="th" class="scroll-smooth">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>DMS v1.3.0 - รายงานสรุปสถาปัตยกรรมระบบ</title>
<script src="https://cdn.tailwindcss.com"></script>
<script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.3/dist/chart.umd.min.js"></script>
<link href="https://fonts.googleapis.com/css2?family=Sarabun:wght@300;400;500;700&display=swap" rel="stylesheet">
<!-- Chosen Palette: Calm Harmony (Stone & Teal) -->
<!-- Application Structure Plan: A single-page application with a fixed top navigation (scroll-to-section). This structure is user-friendly, allowing exploration of the complex DMS specs thematically (Overview, Architecture, Modules, Features, Data Explorer) rather than forcing a linear read. The interactive "Data Explorer" is the key interaction, allowing users to dynamically query the database schema. This structure was chosen to synthesize all 4 source reports (Requirements, FullStack, Data Dictionary, SQL) into one cohesive and easily digestible dashboard for all stakeholders (devs, managers). -->
<!-- Visualization & Content Choices: 1. Architecture Diagram: (Report Info: Docker Stack from Req 2.1) -> (Goal: Organize) -> (Viz: HTML/Tailwind blocks) -> (Interaction: None) -> (Justification: No SVG/Mermaid rule. This is the clearest way to show the stack). 2. RBAC Chart: (Report Info: Roles/Permissions from Req 4.x, DD 2.x) -> (Goal: Compare) -> (Viz: Chart.js Horizontal Bar) -> (Interaction: Tooltip) -> (Justification: Clearly shows permission hierarchy). 3. Data Explorer: (Report Info: Data Dictionary/SQL) -> (Goal: Organize/Explore) -> (Viz: Dynamic HTML Table) -> (Interaction: Dropdown Select) -> (Justification: Makes the dense 44+ table schema interactive and searchable). -->
<!-- CONFIRMATION: NO SVG graphics used. NO Mermaid JS used. -->
<style>
body {
font-family: 'Sarabun', sans-serif;
background-color: #f5f5f4; /* stone-100 */
}
.chart-container {
position: relative;
width: 100%;
max-width: 600px; /* max-w-2xl */
margin-left: auto;
margin-right: auto;
height: 350px; /* h-~80 */
max-height: 40vh;
}
.chart-container-sm {
position: relative;
width: 100%;
max-width: 320px; /* max-w-xs */
margin-left: auto;
margin-right: auto;
height: 280px; /* h-72 */
max-height: 35vh;
}
@media (max-width: 640px) {
.chart-container {
height: 300px;
max-height: 50vh;
}
}
nav a {
transition: color 0.2s;
}
nav a:hover {
color: #0d9488; /* teal-600 */
}
.section-title {
font-size: 1.875rem; /* text-3xl */
font-weight: 700;
color: #1c1917; /* stone-900 */
margin-bottom: 1rem;
border-bottom: 2px solid #0d9488; /* teal-600 */
padding-bottom: 0.5rem;
}
.card {
background-color: #ffffff;
border-radius: 0.75rem; /* rounded-xl */
box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); /* shadow-lg */
padding: 1.5rem; /* p-6 */
transition: all 0.3s;
display: flex;
flex-direction: column;
}
.card-content {
flex-grow: 1;
}
.card:hover {
box-shadow: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1); /* shadow-xl */
transform: translateY(-2px);
}
.stat-card {
background-color: #f5f5f4; /* stone-100 */
border: 1px solid #d6d3d1; /* stone-300 */
border-radius: 0.5rem; /* rounded-lg */
padding: 1rem;
text-align: center;
}
.stat-value {
font-size: 2.25rem; /* text-4xl */
font-weight: 700;
color: #0d9488; /* teal-600 */
}
.stat-label {
font-size: 0.875rem; /* text-sm */
color: #57534e; /* stone-600 */
margin-top: 0.25rem;
}
.schema-relation {
font-size: 0.75rem; /* text-xs */
font-family: monospace;
color: #0d9488; /* teal-600 */
}
.schema-type {
font-size: 0.875rem; /* text-sm */
font-family: monospace;
color: #a16207; /* yellow-700 */
}
</style>
</head>
<body class="text-stone-700">
<!-- Header & Navigation -->
<header class="bg-white/80 backdrop-blur-md shadow-sm sticky top-0 z-50">
<nav class="container mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex justify-between items-center h-16">
<div class="flex-shrink-0">
<h1 class="text-xl font-bold text-stone-800">DMS v1.3.0 <span class="text-teal-600">Report</span></h1>
</div>
<div class="hidden md:flex md:space-x-6 lg:space-x-8">
<a href="#overview" class="nav-link font-medium text-stone-600">ภาพรวม</a>
<a href="#architecture" class="nav-link font-medium text-stone-600">สถาปัตยกรรม</a>
<a href="#modules" class="nav-link font-medium text-stone-600">โมดูลเอกสาร</a>
<a href="#features" class="nav-link font-medium text-stone-600">ฟีเจอร์หลัก</a>
<a href="#data-explorer" class="nav-link font-medium text-stone-600">โครงสร้างข้อมูล</a>
</div>
<div class="md:hidden">
<select id="mobile-nav" class="block w-full rounded-md border-stone-300 shadow-sm focus:border-teal-500 focus:ring-teal-500">
<option value="#overview">ภาพรวม</option>
<option value="#architecture">สถาปัตยกรรม</option>
<option value="#modules">โมดูลเอกสาร</option>
<option value="#features">ฟีเจอร์หลัก</option>
<option value="#data-explorer">โครงสร้างข้อมูล</option>
</select>
</div>
</div>
</nav>
</header>
<!-- Main Content -->
<main class="container mx-auto p-4 sm:p-6 lg:p-8 pt-24">
<!-- 1. Overview Section -->
<section id="overview" class="mb-16 -mt-16 pt-20">
<h2 class="section-title">ภาพรวมระบบ (Overview)</h2>
<p class="mb-8 text-lg text-stone-600">
นี่คือรายงานสรุปเชิงโต้ตอบสำหรับ **ระบบจัดการเอกสาร (DMS) v1.3.0** แอปพลิเคชันนี้ถูกออกแบบมาเพื่อวิเคราะห์ข้อกำหนดของระบบ, สถาปัตยกรรม, และโครงสร้างข้อมูล เพื่อให้ทีมพัฒนาและผู้มีส่วนได้ส่วนเสียสามารถทำความเข้าใจภาพรวมของโปรเจกต์ที่ซับซ้อนนี้ได้อย่างรวดเร็ว
</p>
<div class="grid grid-cols-2 md:grid-cols-4 gap-4">
<div class="stat-card">
<div class="stat-value">6+</div>
<div class="stat-label">โมดูลเอกสารหลัก</div>
</div>
<div class="stat-card">
<div class="stat-value">44+</div>
<div class="stat-label">ตารางข้อมูล (Tables)</div>
</div>
<div class="stat-card">
<div class="stat-value">5+</div>
<div class="stat-label">วิวข้อมูล (Views)</div>
</div>
<div class="stat-card">
<div class="stat-value">7</div>
<div class="stat-label">Services (Docker)</div>
</div>
</div>
</section>
<!-- 2. Architecture Section -->
<section id="architecture" class="mb-16 -mt-16 pt-20">
<h2 class="section-title">สถาปัตยกรรมและเทคโนโลยี (System Architecture)</h2>
<p class="mb-8 text-lg text-stone-600">
ระบบ DMS v1.3.0 ถูกออกแบบบนสถาปัตยกรรม Headless/API-First ที่ทันสมัย โดยทำงานทั้งหมดบน QNAP Server ผ่าน Container Station (Docker) เพื่อให้ง่ายต่อการจัดการและบำรุงรักษา
</p>
<div class="card">
<h3 class="text-xl font-bold text-stone-800 mb-6 text-center">แผนผังการเชื่อมต่อ (Docker Container Stack)</h3>
<div class="w-full bg-stone-50 p-6 rounded-lg border border-stone-200">
<!-- Nginx Reverse Proxy -->
<div class="relative p-4 border-2 border-teal-600 rounded-lg bg-teal-50/50">
<div class="absolute -top-3 left-4 bg-teal-600 text-white px-3 py-0.5 rounded-full text-sm font-medium">Nginx Proxy Manager</div>
<p class="text-center text-sm font-medium text-teal-800 pt-2">np-dms.work (HTTPS)</p>
<!-- Internal Network 'lcbp3' -->
<div class="mt-6 p-4 border-2 border-dashed border-stone-400 rounded-lg">
<div class="absolute -top-3 right-4 bg-stone-500 text-white px-3 py-0.5 rounded-full text-sm font-medium">Network: 'lcbp3'</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-4">
<!-- Frontend -->
<div class="flex flex-col items-center">
<div class="w-full p-4 bg-white border border-blue-500 rounded-lg shadow-md text-center">
<h4 class="font-bold text-blue-700">Next.js (Frontend)</h4>
<p class="text-xs text-stone-600">ให้บริการ UI (React)</p>
</div>
</div>
<!-- Backend -->
<div class="flex flex-col items-center">
<div class="w-full p-4 bg-white border border-red-500 rounded-lg shadow-md text-center">
<h4 class="font-bold text-red-700">NestJS (Backend)</h4>
<p class="text-xs text-stone-600">จัดการ API & Business Logic</p>
</div>
</div>
<!-- Other Services -->
<div class="flex flex-col items-center">
<div class="w-full p-4 bg-white border border-purple-500 rounded-lg shadow-md text-center">
<h4 class="font-bold text-purple-700">N8N (Automation)</h4>
<p class="text-xs text-stone-600">จัดการ Workflow & Line Notify</p>
</div>
</div>
</div>
<!-- Arrow (Backend -> Other Services) -->
<div class="relative h-10 my-2">
<div class="absolute top-1/2 left-1/3 md:left-1/2 w-2/3 md:w-1/2 -translate-x-1/2 -translate-y-1/2 border-t-2 border-stone-500"></div>
<div class="absolute top-1/2 left-1/3 md:left-1/2 -translate-x-1/2 -translate-y-1/2 text-stone-500"></div>
</div>
<!-- Data Layer -->
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="w-full p-4 bg-white border border-orange-500 rounded-lg shadow-md text-center md:col-start-2">
<h4 class="font-bold text-orange-700">MariaDB (Database)</h4>
<p class="text-xs text-stone-600">เก็บข้อมูลทั้งหมด (SQL)</p>
</div>
<div class="w-full p-4 bg-white border border-green-500 rounded-lg shadow-md text-center">
<h4 class="font-bold text-green-700">Elasticsearch (Search)</h4>
<p class="text-xs text-stone-600">ให้บริการค้นหาขั้นสูง</p>
</div>
</div>
</div>
</div>
</div>
</div>
</section>
<!-- 3. Document Modules Section -->
<section id="modules" class="mb-16 -mt-16 pt-20">
<h2 class="section-title">โมดูลเอกสารหลัก (Document Modules)</h2>
<p class="mb-8 text-lg text-stone-600">
ระบบ DMS แบ่งการจัดการเอกสารออกเป็นโมดูลย่อยที่ชัดเจน แต่ละโมดูลมี Workflow และตารางข้อมูลเฉพาะของตนเอง แต่ทั้งหมดเชื่อมโยงกับโครงสร้างเอกสารกลาง (Correspondence)
</p>
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">1. Correspondence (เอกสารโต้ตอบ)</h3>
<p class="text-sm text-stone-600 mb-4">โมดูลหลักสำหรับเอกสารเข้า-ออกทั่วไป (จดหมาย, เมโม) เป็นตาราง "แม่" สำหรับเอกสารประเภทอื่นเกือบทั้งหมด</p>
<span class="text-xs font-semibold text-stone-500">ตารางข้อมูลหลัก:</span>
<ul class="text-sm list-disc list-inside ml-2 text-stone-700">
<li>`correspondences` (Master)</li>
<li>`correspondence_revisions` (Child)</li>
<li>`correspondence_recipients`</li>
</ul>
</div>
</div>
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">2. RFA (ขออนุมัติ)</h3>
<p class="text-sm text-stone-600 mb-4">โมดูลสำหรับเอกสารขออนุมัติ (Request for Approval) เช่น ขออนุมัติแบบ, วัสดุ, หรือเอกสาร ที่มี Workflow ชัดเจน (Draft, Submit, Review, Approved)</p>
<span class="text-xs font-semibold text-stone-500">ตารางข้อมูลหลัก:</span>
<ul class="text-sm list-disc list-inside ml-2 text-stone-700">
<li>`rfas` (Master)</li>
<li>`rfa_revisions` (Child)</li>
<li>`rfa_status_codes`</li>
<li>`rfa_items` (เชื่อม Shop Drawing)</li>
</ul>
</div>
</div>
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">3. Drawing (แบบแปลน)</h3>
<p class="text-sm text-stone-600 mb-4">จัดการแบบแปลน 2 ประเภทหลัก: แบบตามสัญญา (Contract Drawing) และแบบสำหรับก่อสร้าง (Shop Drawing) ซึ่ง Shop Drawing จะถูกอ้างอิงใน RFA</p>
<span class="text-xs font-semibold text-stone-500">ตารางข้อมูลหลัก:</span>
<ul class="text-sm list-disc list-inside ml-2 text-stone-700">
<li>`contract_drawings`</li>
<li>`shop_drawings` (Master)</li>
<li>`shop_drawing_revisions` (Child)</li>
<li>`shop_drawing_revision_contract_refs`</li>
</ul>
</div>
</div>
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">4. Transmittal (เอกสารนำส่ง)</h3>
<p class="text-sm text-stone-600 mb-4">เอกสารนำส่ง (คล้ายใบปะหน้า) ที่ใช้สำหรับรวบรวมเอกสาร RFA หลายๆ ฉบับ เพื่อส่งให้ผู้รับในคราวเดียว</p>
<span class="text-xs font-semibold text-stone-500">ตารางข้อมูลหลัก:</span>
<ul class="text-sm list-disc list-inside ml-2 text-stone-700">
<li>`transmittals` (1:1 with Correspondence)</li>
<li>`transmittal_items` (เชื่อม RFA)</li>
</ul>
</div>
</div>
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">5. Circulation (ใบเวียนภายใน)</h3>
<p class="text-sm text-stone-600 mb-4">ระบบใบเวียนภายในองค์กร (Internal) ใช้สำหรับส่งเอกสาร (ที่อ้างอิงจาก Correspondence) เพื่อให้ทีมตรวจสอบ, รับทราบ, หรือดำเนินการ</p>
<span class="text-xs font-semibold text-stone-500">ตารางข้อมูลหลัก:</span>
<ul class="text-sm list-disc list-inside ml-2 text-stone-700">
<li>`circulations` (Master)</li>
<li>`circulation_assignees` (Tasks)</li>
<li>`circulation_actions` (Logs)</li>
</ul>
</div>
</div>
<div class="card">
<div class="card-content">
<h3 class="text-xl font-bold text-teal-700 mb-2">6. สัดส่วนตารางข้อมูล</h3>
<p class="text-sm text-stone-600 mb-4">แผนภูมิแสดงสัดส่วนตารางข้อมูลที่เกี่ยวข้องในแต่ละโมดูลหลัก (ไม่รวมตาราง Core และ RBAC)</p>
<div class="chart-container-sm">
<canvas id="moduleChart"></canvas>
</div>
</div>
</div>
</div>
</section>
<!-- 4. Core Features Section -->
<section id="features" class="mb-16 -mt-16 pt-20">
<h2 class="section-title">ฟีเจอร์หลัก (Core Features)</h2>
<p class="mb-8 text-lg text-stone-600">
นอกเหนือจากโมดูลเอกสาร ระบบยังมีฟีเจอร์สนับสนุนที่สำคัญ ซึ่งทำงานข้ามโมดูลต่างๆ เพื่อให้ระบบทำงานได้อย่างสมบูรณ์
</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="card">
<h3 class="text-xl font-bold text-stone-800 mb-4">การจัดการสิทธิ์ (RBAC)</h3>
<p class="text-sm text-stone-600 mb-4">
ระบบใช้ Role-Based Access Control (RBAC) ที่ละเอียดมาก ผู้ใช้ (Users) จะได้รับบทบาท (Roles) ซึ่งผูกกับสิทธิ์ (Permissions)
แผนภูมินี้แสดงตัวอย่างจำนวนสิทธิ์ (Permissions) ที่แต่ละบทบาทพื้นฐานอาจมี เพื่อให้เห็นภาพความซับซ้อนในการเข้าถึง
</p>
<div class="chart-container">
<canvas id="rbacChart"></canvas>
</div>
</div>
<div class="card">
<h3 class="text-xl font-bold text-stone-800 mb-4">การสร้างเลขที่เอกสาร (Numbering)</h3>
<p class="text-sm text-stone-600 mb-4">
หนึ่งในส่วนที่สำคัญที่สุด คือการสร้างเลขที่เอกสาร (Running Number) เพื่อป้องกันเลขที่ซ้ำ (Race Condition) ระบบใช้ Stored Procedure (`sp_get_next_document_number`) ใน MariaDB ซึ่งใช้คำสั่ง `SELECT ... FOR UPDATE` เพื่อ "ล็อก" แถวของตัวนับก่อนที่จะอัปเดตค่า
</p>
<pre class="bg-stone-900 text-stone-100 text-sm rounded-lg p-4 overflow-x-auto">
<span class="text-blue-400">SELECT</span> last_number
<span class="text-blue-400">INTO</span> v_last_number
<span class="text-blue-400">FROM</span> document_number_counters
<span class="text-blue-400">WHERE</span> project_id = p_project_id
<span class="text-blue-400">AND</span> ...
<span class="text-red-400">FOR UPDATE</span>;
<span class="text-blue-400">IF</span> v_last_number IS NULL <span class="text-blue-400">THEN</span>
<span class="text-blue-400">INSERT INTO</span> ... (last_number) <span class="text-blue-400">VALUES</span> (1);
<span class="text-blue-400">SET</span> p_next_number = 1;
<span class="text-blue-400">ELSE</span>
<span class="text-blue-400">SET</span> p_next_number = v_last_number + 1;
<span class="text-blue-400">UPDATE</span> document_number_counters
<span class="text-blue-400">SET</span> last_number = p_next_number
<span class="text-blue-400">WHERE</span> ...;
<span class="text-blue-400">END IF</span>;</pre>
</div>
<div class="card">
<h3 class="text-xl font-bold text-stone-800 mb-4">การค้นหา (Advanced Search)</h3>
<p class="text-sm text-stone-600 mb-4">
(Req 6.2) ระบบใช้ **Elasticsearch** เป็น Service แยกต่างหากสำหรับให้บริการค้นหาขั้นสูง
NestJS (Backend) จะทำการ Index ข้อมูลจาก Views (`v_current_correspondences`, `v_current_rfas` ฯลฯ) ไปยัง Elasticsearch
ทำให้ผู้ใช้สามารถค้นหาแบบ Full-text ข้ามโมดูลทั้งหมด (Correspondence, RFA, Drawing) ได้อย่างรวดเร็ว
</p>
</div>
<div class="card">
<h3 class="text-xl font-bold text-stone-800 mb-4">การแจ้งเตือน (Notifications)</h3>
<p class="text-sm text-stone-600 mb-4">
(Req 6.7) ระบบใช้ **N8N (Automation)** เป็นศูนย์กลางการแจ้งเตือน
เมื่อมีเหตุการณ์สำคัญ (เช่น มีการสร้างใบเวียนใหม่) NestJS (Backend) จะยิง Webhook ไปที่ N8N
จากนั้น N8N จะทำหน้าที่ส่งการแจ้งเตือนไปยัง **Line Notify** หรือ Email ตาม Workflow ที่ตั้งค่าไว้
</p>
</div>
</div>
</section>
<!-- 5. Data Explorer Section -->
<section id="data-explorer" class="mb-16 -mt-16 pt-20">
<h2 class="section-title">สำรวจโครงสร้างข้อมูล (Data Explorer)</h2>
<p class="mb-8 text-lg text-stone-600">
ระบบ DMS มีตารางข้อมูลมากกว่า 44 ตารางเพื่อรองรับฟีเจอร์ที่ซับซ้อน เลือกตารางจากรายการด้านล่างเพื่อดูโครงสร้าง, ประเภทข้อมูล, และความสัมพันธ์ (Foreign Keys)
</p>
<div class="card">
<div class="mb-4">
<label for="table-select" class="block text-sm font-medium text-stone-700 mb-1">เลือกตารางเพื่อดูรายละเอียด:</label>
<select id="table-select" class="block w-full md:w-1/2 lg:w-1/3 rounded-md border-stone-300 shadow-sm focus:border-teal-500 focus:ring-teal-500">
<option value="users">users (ผู้ใช้)</option>
<option value="roles">roles (บทบาท)</option>
<option value="permissions">permissions (สิทธิ์)</option>
<option value="user_project_roles">user_project_roles (สิทธิ์ในโปรเจกต์)</option>
<option value="correspondences">correspondences (เอกสาร - Master)</option>
<option value="correspondence_revisions">correspondence_revisions (เอกสาร - Child)</option>
<option value="rfas">rfas (RFA - Master)</option>
<option value="rfa_revisions">rfa_revisions (RFA - Child)</option>
<option value="shop_drawings">shop_drawings (Shop Drawing - Master)</option>
<option value="shop_drawing_revisions">shop_drawing_revisions (Shop Drawing - Child)</option>
<option value="circulations">circulations (ใบเวียน - Master)</option>
<option value="circulation_assignees">circulation_assignees (ใบเวียน - Tasks)</option>
<option value="attachments">attachments (ไฟล์แนบ - Master)</option>
</select>
</div>
<div>
<h4 id="schema-title" class="text-2xl font-bold text-teal-700 mb-1"></h4>
<p id="schema-description" class="text-sm text-stone-600 mb-6"></p>
<div class="overflow-x-auto border border-stone-200 rounded-lg">
<table class="min-w-full divide-y divide-stone-200">
<thead class="bg-stone-50">
<tr>
<th scope="col" class="px-6 py-3 text-left text-xs font-bold text-stone-600 uppercase tracking-wider">Column (Field)</th>
<th scope="col" class="px-6 py-3 text-left text-xs font-bold text-stone-600 uppercase tracking-wider">Type</th>
<th scope="col" class="px-6 py-3 text-left text-xs font-bold text-stone-600 uppercase tracking-wider">Description / Relation</th>
</tr>
</thead>
<tbody id="schema-body" class="bg-white divide-y divide-stone-200">
<!-- JS will populate this -->
</tbody>
</table>
</div>
</div>
</div>
</section>
</main>
<footer class="text-center py-8 mt-12 border-t border-stone-200">
<p class="text-sm text-stone-500">Interactive Report generated for DMS v1.3.0</p>
</footer>
<script>
document.addEventListener('DOMContentLoaded', () => {
// --- Chart.js Rendering ---
// 1. Module Chart (Donut)
const moduleCtx = document.getElementById('moduleChart');
if (moduleCtx) {
new Chart(moduleCtx, {
type: 'donut',
data: {
labels: ['Correspondence', 'RFA', 'Drawing', 'Circulation', 'Transmittal'],
datasets: [{
label: 'จำนวนตารางที่เกี่ยวข้อง',
data: [5, 5, 8, 5, 2],
backgroundColor: [
'rgb(20, 184, 166)', // teal-500
'rgb(15, 118, 110)', // teal-700
'rgb(107, 114, 128)', // stone-500
'rgb(55, 65, 81)', // stone-700
'rgb(245, 158, 11)' // amber-500
],
hoverOffset: 4
}]
},
options: {
responsive: true,
maintainAspectRatio: false,
plugins: {
legend: {
position: 'bottom',
labels: {
font: { family: 'Sarabun' }
}
}
}
}
});
}
// 2. RBAC Chart (Horizontal Bar)
const rbacCtx = document.getElementById('rbacChart');
if (rbacCtx) {
new Chart(rbacCtx, {
type: 'bar',
data: {
labels: ['Viewer (ผู้ดู)', 'Editor (ผู้แก้ไข)', 'Org Admin (แอดมินองค์กร)', 'Superadmin (ผู้ดูแลระบบ)'],
datasets: [{
label: 'จำนวนสิทธิ์ (ตัวอย่าง)',
data: [5, 12, 20, 30],
backgroundColor: 'rgba(13, 148, 136, 0.6)', // teal-600
borderColor: 'rgb(15, 118, 110)', // teal-700
borderWidth: 1
}]
},
options: {
indexAxis: 'y',
responsive: true,
maintainAspectRatio: false,
scales: {
x: {
beginAtZero: true,
grid: { display: false }
},
y: {
grid: { display: false }
}
},
plugins: {
legend: { display: false },
tooltip: {
callbacks: {
label: (context) => ` ${context.dataset.label}: ${context.raw} สิทธิ์`
}
}
}
}
});
}
// --- Data Explorer Logic ---
const databaseSchema = {
'users': {
description: 'ตารางเก็บข้อมูลผู้ใช้ในระบบ (Req 4.x)',
columns: [
{ name: 'user_id', type: 'INT (PK)', desc: 'ID หลักของผู้ใช้' },
{ name: 'username', type: 'VARCHAR(100)', desc: 'ชื่อเข้าระบบ (ต้อง Unique)' },
{ name: 'password_hash', type: 'VARCHAR(255)', desc: 'รหัสผ่านที่ถูก Hashed (Bcrypt)' },
{ name: 'email', type: 'VARCHAR(100)', desc: 'อีเมล' },
{ name: 'organization_id', type: 'INT', desc: 'องค์กรที่ผู้ใช้สังกัด', relation: 'organizations(id)' },
{ name: 'is_active', type: 'BOOLEAN', desc: 'สถานะการใช้งาน' },
{ name: 'is_superadmin', type: 'BOOLEAN', desc: 'สถานะผู้ดูแลสูงสุด' }
]
},
'roles': {
description: 'ตาราง Master เก็บ "บทบาท" ทั้งหมด (Req 4.3)',
columns: [
{ name: 'role_id', type: 'INT (PK)', desc: 'ID ของบทบาท' },
{ name: 'role_code', type: 'VARCHAR(50)', desc: 'รหัสบทบาท (เช่น EDITOR, VIEWER)' },
{ name: 'role_name', type: 'VARCHAR(100)', desc: 'ชื่อบทบาท (เช่น "ผู้แก้ไข")' },
{ name: 'is_system', type: 'BOOLEAN', desc: 'เป็นบทบาทของระบบ (ห้ามแอดมินลบ)' }
]
},
'permissions': {
description: 'ตาราง Master เก็บ "สิทธิ์" การกระทำทั้งหมดในระบบ (Req 4.3)',
columns: [
{ name: 'permission_id', type: 'INT (PK)', desc: 'ID ของสิทธิ์' },
{ name: 'permission_code', type: 'VARCHAR(100)', desc: 'รหัสสิทธิ์ (เช่น corr.create, rfa.view)' },
{ name: 'permission_group', type: 'VARCHAR(50)', desc: 'กลุ่มของสิทธิ์ (เช่น CORR, RFA, ADMIN)' }
]
},
'user_project_roles': {
description: 'ตารางเชื่อม M:N (Junction) ระหว่าง User, Role, และ Project',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของการผูกสิทธิ์' },
{ name: 'user_id', type: 'INT', desc: 'ผู้ใช้', relation: 'users(user_id)' },
{ name: 'role_id', type: 'INT', desc: 'บทบาท', relation: 'roles(role_id)' },
{ name: 'project_id', type: 'INT', desc: 'โปรเจกต์', relation: 'projects(id)' }
]
},
'correspondences': {
description: 'ตาราง "แม่" (Master) สำหรับเอกสารทั้งหมด (Req 3.2)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID หลักของเอกสาร' },
{ name: 'correspondence_number', type: 'VARCHAR(100)', desc: 'เลขที่เอกสาร (จาก Stored Procedure)' },
{ name: 'project_id', type: 'INT', desc: 'โปรเจกต์', relation: 'projects(id)' },
{ name: 'correspondence_type_id', type: 'INT', desc: 'ประเภทเอกสาร', relation: 'correspondence_types(id)' },
{ name: 'originator_id', type: 'INT', desc: 'องค์กรผู้ส่ง', relation: 'organizations(id)' },
{ name: 'recipient_id', type: 'INT', desc: 'องค์กรผู้รับ (หลัก)', relation: 'organizations(id)' },
{ name: 'deleted_at', type: 'DATETIME', desc: 'สำหรับ Soft Delete' }
]
},
'correspondence_revisions': {
description: 'ตาราง "ลูก" (Child) เก็บประวัติการแก้ไขและเนื้อหาของเอกสาร (Req 3.2)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของ Revision' },
{ name: 'correspondence_id', type: 'INT', desc: 'ID เอกสาร (Master)', relation: 'correspondences(id)' },
{ name: 'revision_number', type: 'INT', desc: 'เลข Revision (เช่น 0, 1, 2)' },
{ name: 'is_current', type: 'BOOLEAN', desc: 'เป็น Revision ปัจจุบันหรือไม่' },
{ name: 'title', type: 'VARCHAR(255)', desc: 'ชื่อเรื่อง/หัวข้อ' },
{ name: 'document_date', type: 'DATE', desc: 'วันที่ในเอกสาร' },
{ name: 'issued_date', type: 'DATETIME', desc: 'วันที่ส่ง (Submit)' },
{ name: 'details', type: 'JSON', desc: 'ข้อมูลอื่นๆ (ถ้ามี)' }
]
},
'rfas': {
description: 'ตาราง "แม่" (Master) สำหรับเอกสาร RFA (Req 3.5)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID หลักของ RFA' },
{ name: 'rfa_type_id', type: 'INT', desc: 'ประเภท RFA (DWG, MAT, DOC)', relation: 'rfa_types(id)' },
{ name: 'revision_number', type: 'INT', desc: 'Revision ล่าสุด (เช่น 0, 1)' }
]
},
'rfa_revisions': {
description: 'ตาราง "ลูก" (Child) เก็บประวัติและสถานะของ RFA (Req 3.5)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของ RFA Revision' },
{ name: 'correspondence_id', type: 'INT', desc: 'ID เอกสาร (Master)', relation: 'correspondences(id)' },
{ name: 'rfa_id', type: 'INT', desc: 'ID RFA (Master)', relation: 'rfas(id)' },
{ name: 'rfa_status_code_id', type: 'INT', desc: 'สถานะ (เช่น DFT, FAP)', relation: 'rfa_status_codes(id)' },
{ name: 'rfa_approve_code_id', type: 'INT', desc: 'ผลการอนุมัติ (เช่น A, B, C)', relation: 'rfa_approve_codes(id)' },
{ name: 'title', type: 'VARCHAR(255)', desc: 'ชื่อเรื่อง' }
]
},
'shop_drawings': {
description: 'ตาราง "แม่" (Master) สำหรับ Shop Drawing (Req 3.4)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID หลักของ Shop Drawing' },
{ name: 'project_id', type: 'INT', desc: 'โปรเจกต์', relation: 'projects(id)' },
{ name: 'drawing_number', type: 'VARCHAR(100)', desc: 'เลขที่แบบ (Unique)' },
{ name: 'title', type: 'VARCHAR(500)', desc: 'ชื่อแบบ' }
]
},
'shop_drawing_revisions': {
description: 'ตาราง "ลูก" (Child) เก็บ Revision ของ Shop Drawing (Req 3.4)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของ Revision' },
{ name: 'shop_drawing_id', type: 'INT', desc: 'ID Master', relation: 'shop_drawings(id)' },
{ name: 'revision_number', type: 'VARCHAR(10)', desc: 'เลข Revision (เช่น A, B, 0, 1)' },
{ name: 'revision_date', type: 'DATE', desc: 'วันที่ของ Revision' }
]
},
'circulations': {
description: 'ตาราง "แม่" (Master) สำหรับใบเวียนภายใน (Req 3.7)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของใบเวียน' },
{ name: 'correspondence_id', type: 'INT', desc: 'เอกสารที่อ้างอิง', relation: 'correspondences(id)' },
{ name: 'organization_id', type: 'INT', desc: 'องค์กรเจ้าของใบเวียน', relation: 'organizations(id)' },
{ name: 'circulation_no', type: 'VARCHAR(100)', desc: 'เลขที่ใบเวียน' },
{ name: 'circulation_subject', type: 'VARCHAR(500)', desc: 'เรื่อง' },
{ name: 'circulation_status_code', type: 'VARCHAR(20)', desc: 'สถานะ (OPEN, COMPLETED)', relation: 'circulation_status_codes(code)' }
]
},
'circulation_assignees': {
description: 'ตาราง "Task" สำหรับผู้ที่ต้องดำเนินการในใบเวียน (Req 3.7.4)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของ Task' },
{ name: 'circulation_id', type: 'INT', desc: 'ใบเวียน', relation: 'circulations(id)' },
{ name: 'user_id', type: 'INT', desc: 'ผู้ได้รับมอบหมาย', relation: 'users(user_id)' },
{ name: 'assignee_type', type: 'ENUM', desc: 'ประเภท (MAIN, ACTION, INFO)' },
{ name: 'deadline', type: 'DATE', desc: 'วันที่กำหนดเสร็จ' },
{ name: 'is_completed', type: 'BOOLEAN', desc: 'สถานะว่าเสร็จสิ้นหรือยัง' }
]
},
'attachments': {
description: 'ตาราง "แม่" (Master) สำหรับไฟล์แนบทั้งหมด (Req 3.9)',
columns: [
{ name: 'id', type: 'INT (PK)', desc: 'ID ของไฟล์' },
{ name: 'original_filename', type: 'VARCHAR(255)', desc: 'ชื่อไฟล์เดิม' },
{ name: 'stored_filename', type: 'VARCHAR(255)', desc: 'ชื่อไฟล์ที่เก็บ (UUID)' },
{ name: 'file_path', type: 'VARCHAR(500)', desc: 'Path ที่เก็บไฟล์บน Server' },
{ name: 'mime_type', type: 'VARCHAR(100)', desc: 'ประเภทไฟล์' },
{ name: 'file_size', type: 'INT', desc: 'ขนาดไฟล์ (bytes)' },
{ name: 'uploaded_by_user_id', type: 'INT', desc: 'ผู้อัปโหลด', relation: 'users(user_id)' }
]
}
};
const tableSelect = document.getElementById('table-select');
const schemaTitle = document.getElementById('schema-title');
const schemaDescription = document.getElementById('schema-description');
const schemaBody = document.getElementById('schema-body');
function updateSchemaView(tableName) {
const tableData = databaseSchema[tableName];
if (!tableData) return;
schemaTitle.textContent = tableName;
schemaDescription.textContent = tableData.description;
let html = '';
tableData.columns.forEach(col => {
const relationHtml = col.relation
? `<span class="schema-relation block">FK &rarr; ${col.relation}</span>`
: '';
html += `
<tr class="hover:bg-stone-50">
<td class="px-6 py-4 whitespace-nowrap">
<strong class="text-sm font-medium text-stone-900">${col.name}</strong>
</td>
<td class="px-6 py-4 whitespace-nowrap">
<span class="schema-type">${col.type}</span>
</td>
<td class="px-6 py-4">
<span class="text-sm text-stone-700">${col.desc}</span>
${relationHtml}
</td>
</tr>
`;
});
schemaBody.innerHTML = html;
}
tableSelect.addEventListener('change', (e) => updateSchemaView(e.target.value));
// Initial load
updateSchemaView(tableSelect.value);
// --- Navigation Logic ---
// 1. Mobile Navigation
const mobileNav = document.getElementById('mobile-nav');
mobileNav.addEventListener('change', (e) => {
const targetId = e.target.value;
const targetElement = document.querySelector(targetId);
if (targetElement) {
targetElement.scrollIntoView({ behavior: 'smooth' });
}
});
// 2. Desktop Smooth Scroll
const desktopLinks = document.querySelectorAll('a.nav-link');
desktopLinks.forEach(anchor => {
anchor.addEventListener('click', function (e) {
e.preventDefault();
const targetId = this.getAttribute('href');
const targetElement = document.querySelector(targetId);
if (targetElement) {
targetElement.scrollIntoView({ behavior: 'smooth' });
}
});
});
});
</script>
</body>
</html>

View File

@@ -0,0 +1,194 @@
# version: '3.8'
# ==========================================================
# Volumes (พื้นที่จัดเก็บข้อมูลถาวร)
# ==========================================================
volumes:
# (จากไฟล์เดิม)
backend_node_modules:
# (ที่เพิ่มใหม่)
db_data: # 2.4. Database
npm_data: # 2.8. Reverse Proxy
npm_letsencrypt: # 2.8. SSL Certs
es_data: # 6.2. Elasticsearch
n8n_data: # 2.7. n8n
gitea_data: # 2.2. Gitea
# ==========================================================
# Services (บริการทั้งหมดของระบบ)
# ==========================================================
services:
# --------------------------------------------------------
# Service 1: Reverse Proxy (Nginx Proxy Manager)
# --------------------------------------------------------
npm:
image: 'jc21/nginx-proxy-manager:latest'
container_name: npm
restart: unless-stopped
ports:
- '80:80' # HTTP
- '443:443' # HTTPS
- '81:81' # Admin UI
volumes:
- npm_data:/data
- npm_letsencrypt:/etc/letsencrypt
networks:
- lcbp3
# --------------------------------------------------------
# Service 2: Database (MariaDB)
# --------------------------------------------------------
mariadb:
image: mariadb:10.11
container_name: mariadb
restart: unless-stopped
ports:
- "3306:3306"
volumes:
- db_data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=YOUR_STRONG_ROOT_PASSWORD
- MYSQL_DATABASE=lcbp3
- MYSQL_USER=center
- MYSQL_PASSWORD=Center#2025
- TZ=Asia/Bangkok
networks:
- lcbp3
# --------------------------------------------------------
# Service 3: Database UI (phpMyAdmin)
# --------------------------------------------------------
pma:
image: phpmyadmin:5-apache
container_name: pma
restart: unless-stopped
ports:
- "8080:80"
environment:
- PMA_HOST=mariadb
- PMA_PORT=3306
- UPLOAD_LIMIT=256M
networks:
- lcbp3
depends_on:
- mariadb
# --------------------------------------------------------
# Service 4: Backend (NestJS)
# (ปรับแก้จากไฟล์ ของคุณ)
# --------------------------------------------------------
backend:
build:
context: /share/Container/lcbp3/backend
container_name: backend
restart: unless-stopped
stdin_open: true
tty: true
command: npm run start:dev
networks:
- lcbp3
ports:
- "3000:3000"
environment:
# --- Database Connection (จากไฟล์เดิม) ---
- DB_HOST=mariadb
- DB_PORT=3306
- DB_USER=center
- DB_PASSWORD=Center#2025
- DB_NAME=lcbp3
- PORT=3000
# --- Security (จากไฟล์เดิม) ---
- JWT_SECRET=9a6d8705a6695ab9bae4ca1cd46c72a6379aa72404b96e2c5b59af881bb55c639dd583afdce5a885c68e188da55ce6dbc1fb4aa9cd4055ceb51507e56204e4ca
- JWT_EXPIRES_IN=1d
# --- (เพิ่มใหม่) Environment Variables ที่ Service ต้องการ ---
- STORAGE_PATH=/app/storage # (Path ภายใน Container ที่เชื่อมกับ /share/dms-data)
- ELASTICSEARCH_NODE=http://elasticsearch:9200
- N8N_WEBHOOK_URL=http://n8n:5678/webhook/lcbp3-notify
volumes:
- /share/Container/lcbp3/backend:/app
- /share/dms-data:/app/storage # (เชื่อม Path จริงบน QNAP เข้ากับ Container)
- /share/Container/dms/logs/backend:/app/logs:rw
- backend_node_modules:/app/node_modules
depends_on:
- mariadb
# --------------------------------------------------------
# Service 5: Frontend (Next.js)
# --------------------------------------------------------
frontend:
build:
context: /share/Container/lcbp3/frontend
container_name: frontend
restart: unless-stopped
command: npm run dev
ports:
- "3001:3000" # (ใช้ Host Port 3001)
networks:
- lcbp3
volumes:
- /share/Container/lcbp3/frontend:/app
- /share/Container/lcbp3/frontend/node_modules:/app/node_modules
environment:
# (Frontend ต้องเรียก API ผ่าน Domain ที่ NPM จัดการ)
- NEXT_PUBLIC_API_URL=https://backend.np-dms.work
depends_on:
- backend
# --------------------------------------------------------
# Service 6: Search (Elasticsearch)
# --------------------------------------------------------
elasticsearch:
image: elasticsearch:8.11.0 # (แนะนำให้ระบุเวอร์ชัน)
container_name: elasticsearch
restart: unless-stopped
ports:
- "9200:9200"
volumes:
- es_data:/usr/share/elasticsearch/data
environment:
- discovery.type=single-node
- xpack.security.enabled=false # (ปิดการยืนยันตัวตนสำหรับ Dev)
- ES_JAVA_OPTS=-Xms512m -Xmx512m # (จำกัด RAM)
networks:
- lcbp3
# --------------------------------------------------------
# Service 7: Workflow (n8n)
# --------------------------------------------------------
n8n:
image: n8nio/n8n:latest
container_name: n8n
restart: unless-stopped
ports:
- "5678:5678"
volumes:
- n8n_data:/home/node/.n8n
environment:
- TZ=Asia/Bangkok
networks:
- lcbp3
# --------------------------------------------------------
# Service 8: Code Hosting (Gitea)
# --------------------------------------------------------
gitea:
image: gitea/gitea:latest
container_name: gitea
restart: unless-stopped
ports:
- "3002:3000" # (ใช้ Host Port 3002)
- "2222:22" # (ใช้ Host Port 2222 สำหรับ SSH)
volumes:
- gitea_data:/data
networks:
- lcbp3
depends_on:
- mariadb
# ==========================================================
# Networks (เครือข่ายกลาง)
# ==========================================================
networks:
lcbp3:
external: true

BIN
docs/Entity.xlsx Normal file

Binary file not shown.

View File

@@ -0,0 +1,655 @@
# 📋 แผนการพัฒนา Backend (NestJS) - LCBP3-DMS v1.4.0
## 🎯 ภาพรวมโครงการ
พัฒนา Backend สำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่รองรับการจัดการเอกสารที่ซับซ้อน มีระบบ Workflow การอนุมัติ และการควบคุมสิทธิ์แบบ RBAC 3 ระดับ
---
## 📐 สถาปัตยกรรมระบบ
### Technology Stack
- **Framework:** NestJS (TypeScript, ESM)
- **Database:** MariaDB 10.11
- **ORM:** TypeORM
- **Authentication:** JWT + Passport
- **Authorization:** CASL (RBAC)
- **File Upload:** Multer
- **Search:** Elasticsearch
- **Notification:** Nodemailer + n8n (Line Integration)
- **Scheduling:** @nestjs/schedule (Cron Jobs)
- **Documentation:** Swagger
### โครงสร้างโมดูล (Domain-Driven)
```tree
src/
├── common/ # Shared Module
│ ├── auth/ # JWT, Guards
│ ├── config/ # Configuration
│ ├── decorators/ # @RequirePermission
│ ├── entities/ # Base Entities
│ ├── exceptions/ # Global Filters
│ ├── file-storage/ # FileStorageService
│ ├── guards/ # RBAC Guard
│ ├── interceptors/ # Audit, Transform
│ └── services/ # Notification, etc.
├── modules/
│ ├── user/ # Users, Roles, Permissions
│ ├── project/ # Projects, Contracts, Organizations
│ ├── master/ # Master Data
│ ├── correspondence/ # Correspondence Management
│ ├── rfa/ # RFA & Workflows
│ ├── drawing/ # Shop/Contract Drawings
│ ├── circulation/ # Internal Circulation
│ ├── transmittal/ # Transmittals
│ ├── search/ # Elasticsearch
│ └── document-numbering/ # Internal Service
└── database/ # Migrations & Seeds
```
---
## 🗓️ แผนการพัฒนาแบบ Phase-Based
## **Phase 0: Infrastructure Setup (สัปดาห์ที่ 1)**
Milestone: สร้างโครงสร้างพื้นฐานและเชื่อมต่อ Services
### Phase 0: Tasks
- **[✅]T0.1 Setup QNAP Container Station**
- สร้าง Docker Network: `lcbp3`
- Setup docker-compose.yml สำหรับ:
- MariaDB (db.np-dms.work)
- PHPMyAdmin (pma.np-dms.work)
- Backend (backend.np-dms.work)
- Nginx Proxy Manager (npm.np-dms.work)
- กำหนด Environment Variables ใน docker-compose.yml (ไม่ใช้ .env)
- Deliverable: Services ทั้งหมดรันได้และเชื่อมต่อกันผ่าน Network
- **[✅]T0.2 Initialize NestJS Project**
- สร้างโปรเจกต์ใหม่ด้วย Nest CLI
- ติดตั้ง Dependencies:
```bash
npm install @nestjs/typeorm typeorm mysql2
npm install @nestjs/config
npm install class-validator class-transformer
npm install @nestjs/jwt @nestjs/passport passport passport-jwt
npm install casl
npm install @nestjs/platform-express multer
npm install @nestjs/swagger
npm install helmet rate-limiter-flexible
npm install bcrypt
npm install --save-dev @nestjs/testing jest @types/jest @types/passport-jwt @types/multer supertest
npm install @nestjs/cache-manager cache-manager
npm install @nestjs/schedule
npm install @nestjs/config
npm install @nestjs/elasticsearch @elastic/elasticsearch
npm install nodemailer @types/nodemailer
npm install uuid @types/uuid
```
````
- Setup โครงสร้างโฟลเดอร์ตาม Domain-Driven Architecture
- Deliverable: Project Structure พร้อม, แสดง Swagger ที่ `/api`
- **[✅]T0.3 Setup Database Connection**
- Import SQL Schema v1.4.0 เข้า MariaDB
- Run Seed Data (organizations, users, roles, permissions)
- Configure TypeORM ใน AppModule
- ทดสอบ Connection
- Deliverable: Database พร้อมใช้งาน, มี Seed Data
- **[✅]T0.4 Setup Git Repository**
- สร้าง Repository ใน Gitea (git.np-dms.work)
- Setup .gitignore, README.md
- Commit Initial Project
- Deliverable: Code อยู่ใน Version Control
---
## **Phase 1: Core Foundation (สัปดาห์ที่ 2-3)**
Milestone: ระบบ Authentication, Authorization และ Base Entities
### Phase 1: Tasks
- **[ ] T1.1 CommonModule - Base Infrastructure**
- [ ] สร้าง Base Entity (id, created_at, updated_at, deleted_at)
- [ ] สร้าง Global Exception Filter
- [ ] สร้าง Response Transform Interceptor
- [ ] สร้าง Audit Log Interceptor
- [ ] สร้าง RequestContextService - สำหรับเก็บข้อมูลระหว่าง Request
- [ ] สร้าง ConfigService - Centralized configuration management
- [ ] สร้าง CryptoService - สำหรับ encryption/decryption
- [ ] Deliverable: Common Services พร้อมใช้
- **[ ] T1.2 AuthModule - JWT Authentication**
- [ ] สร้าง Entity: User
- [ ] สร้าง AuthService:
- [ ] `login(username, password)` → JWT Token
- [ ] `validateUser(username, password)` → User | null
- [ ] Password Hashing (bcrypt)
- [ ] สร้าง JWT Strategy (Passport)
- [ ] สร้าง JwtAuthGuard
- [ ] สร้าง Controllers:
- [ ] `POST /auth/login` → { access_token }
- [ ] `POST /auth/register` (Admin only)
- [ ] `GET /auth/profile` (Protected)
- [ ] Deliverable: ล็อกอิน/ล็อกเอาต์ทำงานได้
- **[ ] T1.3 UserModule - User Management**
- [ ] สร้าง Entities: User, Role, Permission, UserRole
- [ ] สร้าง UserService CRUD
- [ ] สร้าง RoleService CRUD
- [ ] สร้าง PermissionService (Read-Only, จาก Seed)
- [ ] สร้าง Controllers:
- [ ] `GET /users` → List Users (Paginated)
- [ ] `GET /users/:id` → User Detail
- [ ] `POST /users` → Create User
- [ ] `PUT /users/:id` → Update User
- [ ] `DELETE /users/:id` → Soft Delete
- [ ] `GET /roles` → List Roles
- [ ] `POST /roles` → Create Role (Admin)
- [ ] `PUT /roles/:id/permissions` → Assign Permissions
- [ ] Deliverable: จัดการผู้ใช้และ Role ได้
- **[ ] T1.4 RBAC Guard - Authorization**
- [ ] สร้าง `@RequirePermission()` Decorator
- [ ] สร้าง RbacGuard ที่ตรวจสอบ:
- [ ] Global Permissions
- [ ] Organization Permissions
- [ ] Project Permissions
- [ ] Contract Permissions
- [ ] Permission Hierarchy Logic
```bash
// Current: 3-level hierarchy
// Recommended: 4-level hierarchy (Global → Organization → Project → Contract)
@Injectable()
export class RbacGuard implements CanActivate {
async canActivate(context: ExecutionContext): Promise<boolean> {
const requiredPermission = this.getRequiredPermission(context);
const user = this.getUser(context);
// Check permissions in order: Global → Org → Project → Contract
return await this.checkGlobalPermissions(user, requiredPermission) ||
await this.checkOrgPermissions(user, requiredPermission) ||
await this.checkProjectPermissions(user, requiredPermission) ||
await this.checkContractPermissions(user, requiredPermission);
}
}
````
- [ ] Integration กับ CASL
- [ ] Deliverable: ระบบสิทธิ์ทำงานได้ทั้ง 4 ระดับ
- **T1.5 ProjectModule - Base Structures**
- [ ] สร้าง Entities:
- [ ] Organization
- [ ] Project
- [ ] Contract
- [ ] ProjectOrganization (Junction)
- [ ] ContractOrganization (Junction)
- [ ] UserAssignment Entity - สำหรับจัดการ user assignments ตาม scope
- [ ] สร้าง Services & Controllers:
- [ ] `GET /organizations` → List
- [ ] `POST /projects` → Create (Superadmin)
- [ ] `GET /projects/:id/contracts` → List Contracts
- [ ] `POST /projects/:id/contracts` → Create Contract
- [ ] UserAssignment - สำหรับจัดการ user assignments ตาม scope
- [ ] ProjectOrganization - สำหรับจัดการความสัมพันธ์ project-organization
- [ ] ContractOrganization - สำหรับจัดการความสัมพันธ์ contract-organization
- [ ] Deliverable: จัดการโครงสร้างโปรเจกต์ได้
---
## **Phase 2: Master Data & File Management (สัปดาห์ที่ 4)**
Milestone: Master Data และระบบจัดการไฟล์
### Phase 2: Tasks
- **[ ] T2.1 MasterModule - Master Data Management**
- [ ] สร้าง Entities:
- [ ] CorrespondenceType
- [ ] CorrespondenceStatus
- [ ] RfaType
- [ ] RfaStatusCode
- [ ] RfaApproveCode
- [ ] CirculationStatusCode
- [ ] Tag
- [ ] สร้าง Services & Controllers (CRUD):
- [ ] `GET /master/correspondence-types`
- [ ] `POST /master/tags` → Create Tag
- [ ] `GET /master/tags` → List Tags (Autocomplete)
- [ ] Deliverable: Admin จัดการ Master Data ได้
- **[ ] T2.2 FileStorageService - Central File Management**
- [ ] สร้าง Attachment Entity
- [ ] สร้าง FileStorageService: (การจัดเก็บไฟล์ในรูปแบบ centralized storage, ครอบคลุมการจัดการไฟล์แนบทั้งหมด, Security Measures)
- [ ] `uploadFile(file: Express.Multer.File)` → Attachment
- [ ] `getFilePath(attachmentId)` → string
- [ ] `deleteFile(attachmentId)` → boolean
- [ ] จัดเก็บไฟล์ใน `/share/dms-data/uploads/{YYYY}/{MM}/`
- [ ] สร้าง Controller:
- [ ] `POST /files/upload` → { attachment_id, url }
- [ ] `GET /files/:id/download` → File Stream (Protected)
- [ ] Access Control: ตรวจสอบสิทธิ์ผ่าน Junction Table
- [ ] Deliverable: อัปโหลด/ดาวน์โหลดไฟล์ได้อย่างปลอดภัย
- **[ ] T2.3 DocumentNumberingModule - Internal Service**
- [ ] สร้าง Entities:
- [ ] DocumentNumberFormat
- [ ] DocumentNumberCounter
- [ ] สร้าง DocumentNumberingService: รวม Stored Procedure (sp_get_next_document_number), Error Handling และ Retry Logic
- [ ] `generateNextNumber(projectId, orgId, typeId, year)` → string
- [ ] เรียก Stored Procedure: `sp_get_next_document_number`
- [ ] Format ตาม Template: `{ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}`
- **ไม่มี Controller** (Internal Service เท่านั้น)
- [ ] Deliverable: Service สร้างเลขที่เอกสารได้ถูกต้อง
---
## **Phase 3: Correspondence & RFA Core (สัปดาห์ที่ 5-6)**
Milestone: ระบบเอกสารโต้ตอบและ RFA
### Phase 3: Tasks
- **[ ] T3.1 CorrespondenceModule - Basic CRUD**
- [ ] สร้าง Entities:
- [ ] Correspondence
- [ ] CorrespondenceRevision
- [ ] CorrespondenceRecipient
- [ ] CorrespondenceTag
- [ ] CorrespondenceReference
- [ ] CorrespondenceAttachment
- [ ] สร้าง CorrespondenceService: Complex Business Rules, State Machine สำหรับ Status Transitions
- [ ] `create(dto)` → Correspondence
- [ ] สร้าง Correspondence + Revision แรก (rev 0)
- [ ] เรียก DocumentNumberingService
- [ ] สร้าง Recipients (TO/CC)
- [ ] สร้าง Tags
- [ ] สร้าง Attachments
- [ ] `update(id, dto)` → Correspondence
- [ ] สร้าง Revision ใหม่
- [ ] Update `is_current` flag
- [ ] `findAll(filters)` → Paginated List
- [ ] `findById(id)` → Correspondence with Current Revision
- [ ] สร้าง Controllers:
- [ ] `POST /correspondences` → Create
- [ ] `GET /correspondences` → List (Filter by type, status, org)
- [ ] `GET /correspondences/:id` → Detail
- [ ] `PUT /correspondences/:id` → Update (Create new revision)
- [ ] `DELETE /correspondences/:id` → Soft Delete (Admin only)
- [ ] Deliverable: สร้าง/แก้ไข/ดูเอกสารได้
- **[ ] T3.2 CorrespondenceModule - Advanced Features**
- [ ] Implement Status Transitions:
- [ ] `DRAFT` → `SUBMITTED` (Document Control)
- [ ] `SUBMITTED` → `CLOSED` (Admin)
- [ ] `SUBMITTED` → `CANCELLED` (Admin + Reason)
- [ ] Implement References:
- [ ] `POST /correspondences/:id/references` → Link Documents
- [ ] Implement Search (Basic):
- `GET /correspondences/search?q=...`
- [ ] Deliverable: Workflow พื้นฐานทำงานได้
- **[ ] T3.3 RfaModule - Basic CRUD**
- [ ] สร้าง Entities:
- [ ] Rfa
- [ ] RfaRevision
- [ ] RfaItem (Junction to Shop Drawings)
- [ ] สร้าง RfaService: Complex Business Rules
- [ ] `create(dto)` → Rfa
- [ ] สร้าง Correspondence + Rfa + RfaRevision
- [ ] เชื่อม Shop Drawing Revisions (สำหรับ RFA_DWG)
- [ ] `findAll(filters)` → Paginated List
- [ ] `findById(id)` → Rfa with Items
- [ ] สร้าง Controllers:
- [ ] `POST /rfas` → Create
- [ ] `GET /rfas` → List
- [ ] `GET /rfas/:id` → Detail
- [ ] Deliverable: สร้าง RFA และเชื่อม Shop Drawings ได้
---
## **Phase 4: Drawing Management (สัปดาห์ที่ 7)**
Milestone: ระบบจัดการแบบ
### Phase 4: Tasks
- **[ ] T4.1 DrawingModule - Contract Drawings**
- [ ] สร้าง Entities:
- [ ] ContractDrawing
- [ ] ContractDrawingVolume
- [ ] ContractDrawingCat
- [ ] ContractDrawingSubCat
- [ ] ContractDrawingSubcatCatMap
- [ ] ContractDrawingAttachment
- [ ] สร้าง ContractDrawingService CRUD
- [ ] สร้าง Controllers:
- [ ] `GET /drawings/contract` → List
- [ ] `POST /drawings/contract` → Create (Admin)
- [ ] `GET /drawings/contract/:id` → Detail
- [ ] Deliverable: จัดการ Contract Drawings ได้
- **[ ] T4.2 DrawingModule - Shop Drawings**
- [ ] สร้าง Entities:
- [ ] ShopDrawing
- [ ] ShopDrawingRevision
- [ ] ShopDrawingMainCategory
- [ ] ShopDrawingSubCategory
- [ ] ShopDrawingRevisionContractRef
- [ ] ShopDrawingRevisionAttachment
- [ ] สร้าง ShopDrawingService CRUD
- [ ] สร้าง Controllers:
- [ ] `GET /drawings/shop` → List
- [ ] `POST /drawings/shop` → Create
- [ ] `POST /drawings/shop/:id/revisions` → Create Revision
- [ ] `GET /drawings/shop/:id` → Detail with Revisions
- [ ] Link Shop Drawing Revision → Contract Drawings
- [ ] Deliverable: จัดการ Shop Drawings และ Revisions ได้
---
## **Phase 5: Workflow Systems (สัปดาห์ที่ 8-9)**
Milestone: ระบบ Workflow ทั้งหมด
### Phase 5: Tasks
- **[ ] T5.1 RfaModule - Workflow Implementation**
- [ ] สร้าง Entities:
- [ ] RfaWorkflowTemplate
- [ ] RfaWorkflowTemplateStep
- [ ] RfaWorkflow (Transaction Log)
- [ ] สร้าง RfaWorkflowService: Advanced Workflow Features
- [ ] `initiateWorkflow(rfaId, templateId)` → void
- [ ] สร้าง RfaWorkflow records ตาม Template
- [ ] กำหนด Step 1 เป็น PENDING
- [ ] `completeStep(rfaId, stepNumber, action, comments)` → void
- [ ] Update Status → COMPLETED
- [ ] Set Next Step → PENDING
- [ ] Send Notifications
- [ ] `rejectStep(rfaId, stepNumber, reason)` → void
- [ ] Update Status → REJECTED
- [ ] Send back to Originator
- [ ] สร้าง Controllers:
- [ ] `POST /rfas/:id/workflow/start` → Start Workflow
- [ ] `POST /rfas/:id/workflow/steps/:stepNumber/complete` → Complete Step
- [ ] `GET /rfas/:id/workflow` → Get Workflow Status
- [ ] Deliverable: RFA Workflow ทำงานได้
- **[ ] T5.2 CirculationModule - Internal Routing**
- [ ] สร้าง Entities:
- [ ] Circulation
- [ ] CirculationTemplate
- [ ] CirculationTemplateAssignee
- [ ] CirculationRouting (Transaction Log)
- [ ] CirculationAttachment
- [ ] สร้าง CirculationService:
- [ ] `create(correspondenceId, dto)` → Circulation
- [ ] สร้าง Circulation (1:1 กับ Correspondence)
- [ ] สร้าง Routing ตาม Template
- [ ] `assignUser(circulationId, stepNumber, userId)` → void
- [ ] `completeStep(circulationId, stepNumber, comments)` → void
- [ ] `close(circulationId)` → void (เมื่อตอบกลับองค์กรผู้ส่งแล้ว)
- สร้าง Controllers:
- [ ] `POST /circulations` → Create
- [ ] `GET /circulations/:id` → Detail
- [ ] `POST /circulations/:id/steps/:stepNumber/complete` → Complete
- [ ] `POST /circulations/:id/close` → Close
- [ ] Deliverable: ใบเวียนภายในองค์กรทำงานได้
- **[ ] T5.3 TransmittalModule - Document Forwarding**
- [ ] สร้าง Entities:
- [ ] Transmittal
- [ ] TransmittalItem
- [ ] สร้าง TransmittalService:
- [ ] `create(dto)` → Transmittal
- [ ] สร้าง Correspondence + Transmittal
- [ ] เชื่อม Multiple Correspondences เป็น Items
- [ ] สร้าง Controllers:
- [ ] `POST /transmittals` → Create
- [ ] `GET /transmittals` → List
- [ ] `GET /transmittals/:id` → Detail with Items
- [ ] Deliverable: สร้าง Transmittal ได้
---
## **Phase 6: Advanced Features (สัปดาห์ที่ 10-11)**
Milestone: ฟีเจอร์ขั้นสูง
### Phase 6: Tasks
- **[ ] T6.1 SearchModule - Elasticsearch Integration**
- [ ] Setup Elasticsearch Container ใน docker-compose.yml
- [ ] สร้าง SearchService:
- [ ] `indexDocument(entity)` → void
- [ ] `updateDocument(entity)` → void
- [ ] `deleteDocument(entity)` → void
- [ ] `search(query, filters)` → SearchResult[]
- [ ] Index ทุกครั้งที่ Create/Update:
- [ ] Correspondence
- [ ] RFA
- [ ] Shop Drawing
- [ ] Contract Drawing
- [ ] Circulation
- [ ] Transmittal
- [ ] สร้าง Controllers:
- [ ] `GET /search?q=...&type=...&from=...&to=...` → Results
- [ ] Deliverable: ค้นหาขั้นสูงทำงานได้
- **[ ] T6.2 NotificationModule - Email & Line**
- [ ] สร้าง NotificationService:
- [ ] `sendEmail(to, subject, body)` → void (Nodemailer)
- [ ] `sendLine(userId, message)` → void (ผ่าน n8n Webhook)
- [ ] `createSystemNotification(userId, message, entityType, entityId)` → void
- [ ] Integrate กับ Workflow Events:
- [ ] เมื่อสร้าง Correspondence ใหม่ → แจ้ง Recipients
- [ ] เมื่อสร้าง Circulation → แจ้ง Assignees
- [ ] เมื่อ RFA Workflow ถึง Step → แจ้ง Responsible Org
- [ ] เมื่อใกล้ถึง Deadline → แจ้ง (Optional)
- [ ] สร้าง Controllers:
- [ ] `GET /notifications` → List User's Notifications
- [ ] `PUT /notifications/:id/read` → Mark as Read
- [ ] Deliverable: ระบบแจ้งเตือนทำงานได้
- **[ ] T6.3 Reporting & Analytics**
- [ ] สร้าง ReportService:
- [ ] `getCorrespondenceSummary(projectId, from, to)` → Report
- [ ] `getRfaSummary(projectId, from, to)` → Report
- [ ] `getActivityLog(userId, from, to)` → Report
- [ ] ใช้ Views จาก Database:
- [ ] `v_current_correspondences`
- [ ] `v_current_rfas`
- [ ] `v_user_tasks`
- [ ] `v_audit_log_details`
- [ ] สร้าง Controllers:
- [ ] `GET /reports/correspondence` → Summary (CSV, PDF)
- [ ] `GET /reports/rfa` → Summary
- [ ] `GET /reports/activity` → User Activity
- [ ] Deliverable: สร้างรายงานได้
- **T6.4 Audit Log & Activity Feed**
- [ ] AuditLogInterceptor ทำงานอัตโนมัติแล้ว (Phase 1)
- [ ] สร้าง AuditLogService:
- [ ] `log(userId, action, entityType, entityId, details)` → void
- [ ] `getUserActivity(userId, limit)` → AuditLog[]
- [ ] สร้าง Controllers:
- [ ] `GET /audit-logs` → List (Admin only)
- [ ] `GET /audit-logs/user/:userId` → User's Activity
- [ ] Deliverable: ดู Audit Log ได้
---
## **Phase 7: Testing & Optimization (สัปดาห์ที่ 12-13)**
Milestone: ทดสอบและปรับปรุงประสิทธิภาพ
### Phase 7: Tasks
- **[ ] T7.1 Unit Testing**
- [ ] เขียน Unit Tests สำหรับ Services สำคัญ:
- [ ] AuthService (login, validateUser)
- [ ] RbacGuard (permission checks)
- [ ] DocumentNumberingService (number generation)
- [ ] CorrespondenceService (create, update)
- [ ] RfaWorkflowService (workflow logic)
- [ ] Target: 70% Code Coverage
- [ ] Deliverable: Unit Tests ผ่านทั้งหมด
- **[ ] T7.2 Integration Testing**
- [ ] เขียน Integration Tests:
- [ ] Authentication Flow (login → access protected route)
- [ ] Document Creation Flow (create correspondence → attach files)
- [ ] RFA Workflow Flow (start → step 1 → step 2 → complete)
- [ ] Circulation Flow (create → assign → complete → close)
- [ ] ทดสอบ SQL Views (v_user_all_permissions, v_user_tasks)
- [ ] ใช้ Test Database แยกต่างหาก
- [ ] Deliverable: Integration Tests ผ่าน
- **[ ] T7.3 E2E Testing**
- [ ] เขียน E2E Tests:
- [ ] User Registration & Login
- [ ] Create Correspondence (Full Flow)
- [ ] Create RFA with Shop Drawings
- [ ] Complete RFA Workflow
- [ ] Search Documents
- [ ] Deliverable: E2E Tests ผ่าน
- **[ ] T7.4 Performance Optimization**
- [ ] Implement Caching:
- [ ] Cache Master Data (Roles, Permissions)
- [ ] Cache User Permissions (ใช้ @nestjs/cache-manager)
- [ ] Database Optimization:
- [ ] Review Indexes
- [ ] Optimize Queries (N+1 Problem)
- I[ ] mplement Pagination ทุก List Endpoint
- [ ] Deliverable: Response Time < 200ms (90th percentile)
- **[ ] T7.5 Security Hardening**
- [ ] Implement Rate Limiting (ใช้ rate-limiter-flexible)
- [ ] Setup Helmet (Security Headers)
- [ ] Review CORS Configuration
- [ ] Input Validation (ตรวจสอบ DTOs ทั้งหมด)
- [ ] Deliverable: Security Checklist ผ่าน
---
## **Phase 8: Documentation & Deployment (สัปดาห์ที่ 14)**
Milestone: เอกสารและ Deploy สู่ Production
### Phase 8: Tasks
- **[ ] T8.1 API Documentation**
- [ ] ครบทุก Endpoint ใน Swagger:
- [ ] ใส่ Description, Example Request/Response
- [ ] ระบุ Required Permissions
- [ ] ใส่ Error Responses
- [ ] Export Swagger JSON → Frontend Team
- [ ] Deliverable: Swagger Docs สมบูรณ์
- **[ ] T8.2 Technical Documentation**
- [ ] เขียนเอกสาร:
- [ ] Architecture Overview
- [ ] Module Structure
- [ ] Database Schema Diagram
- [ ] API Design Patterns
- [ ] Deployment Guide
- [ ] Deliverable: Technical Docs พร้อม
- **[ ] T8.3 Deployment Preparation**
- [ ] สร้าง Production docker-compose.yml
- [ ] Setup Environment Variables ใน QNAP
- [ ] Setup Nginx Proxy Manager (SSL Certificate)
- [ ] Setup Backup Scripts (Database + Files)
- [ ] Deliverable: Deployment Guide พร้อม
- **[ ] T8.4 Production Deployment**
- [ ] Deploy Backend ไปยัง backend.np-dms.work
- [ ] ทดสอบ API ผ่าน Postman
- [ ] Monitor Logs (Winston)
- [ ] Setup Health Check Endpoint (`GET /health`)
- [ ] Deliverable: Backend รันบน Production
- **T8.5 Handover to Frontend Team**
- [ ] Demo API ให้ Frontend Team
- [ ] ส่งมอบ Swagger Documentation
- [ ] ส่งมอบ Postman Collection
- [ ] Workshop: วิธีใช้ Authentication & RBAC
- [ ] Deliverable: Frontend เริ่มพัฒนาได้
---
## 📊 สรุป Timeline
| Phase | ระยะเวลา | จำนวนงาน | Output หลัก |
| ------- | -------------- | ------------ | ---------------------------- |
| Phase 0 | 1 สัปดาห์ | 4 | Infrastructure Ready |
| Phase 1 | 2 สัปดาห์ | 5 | Auth & User Management |
| Phase 2 | 1 สัปดาห์ | 3 | Master Data & File Storage |
| Phase 3 | 2 สัปดาห์ | 3 | Correspondence & RFA Core |
| Phase 4 | 1 สัปดาห์ | 2 | Drawing Management |
| Phase 5 | 2 สัปดาห์ | 3 | Workflow Systems |
| Phase 6 | 2 สัปดาห์ | 4 | Advanced Features |
| Phase 7 | 2 สัปดาห์ | 5 | Testing & Optimization |
| Phase 8 | 1 สัปดาห์ | 5 | Documentation & Deploy |
| **รวม** | **14 สัปดาห์** | **34 Tasks** | **Production-Ready Backend** |
---
## 🎯 Critical Success Factors
1. **Database First**: ใช้ Schema v1.4.0 เป็นหลัก ไม่แก้ไข Schema โดยไม่จำเป็น
2. **Emphasizing Soft Delete**: Service ทั้งหมดที่ทำการ Query ข้อมูล (เช่น findAll, findById) ต้อง ใช้ Global Filter หรือ Default Scope ของ TypeORM เพื่อกรอง WHERE deleted_at IS NULL เสมอ
3. **API Contract**: ทุก Endpoint ต้องมี Swagger Documentation สมบูรณ์
4. **Security**: RBAC ต้องทำงานถูกต้อง 100% ก่อน Deploy
5. **Testing**: Code Coverage อย่างน้อย 70% ก่อน Production
6. **Performance**: Response Time < 200ms (90th percentile)
7. **Documentation**: เอกสารต้องครบถ้วนเพื่อ Handover ให้ Frontend Team
---
## 🚀 ขั้นตอนถัดไป
1. **Approve แผนนี้** → ปรับแต่งตาม Feedback
2. **Setup Phase 0** → เริ่มสร้าง Infrastructure
3. **Daily Standup** → รายงานความก้าวหน้าทุกวัน
4. **Weekly Review** → ทบทวนความก้าวหน้าทุกสัปดาห์
5. **Deploy to Production** → Week 14
---
**หมายเหตุ:** แผนนี้สามารถปรับแต่งได้ตามความต้องการและข้อจำกัดของทีม หาก Phase ใดใช้เวลามากกว่าที่คาดการณ์ ควรปรับ Timeline ให้เหมาะสม

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,833 @@
# 📋 แผนการพัฒนา Frontend (NestJS) - LCBP3-DMS v1.4.0
# 📋 แผนการพัฒนา Frontend (Next.js) - LCBP3-DMS v1.4.0
## 🎯 ภาพรวมโครงการ
พัฒนา Frontend สำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่ทันสมัย responsive และใช้งานง่าย รองรับการจัดการเอกสารที่ซับซ้อน มี Dashboard แบบ Real-time และระบบ Workflow Visualization
---
## 📐 สถาปัตยกรรมระบบ
### Technology Stack
- **Framework:** Next.js 14+ (App Router, React 18+, TypeScript, ESM)
- **Styling:** Tailwind CSS + PostCSS
- **Component Library:** shadcn/ui (Radix UI)
- **State Management:**
- **Server State:** TanStack Query (React Query)
- **Global Client State:** Zustand
- **Form State:** React Hook Form + Zod
- **Data Fetching:** Axios + TanStack Query
- **Authentication:** NextAuth.js (JWT Strategy)
- **File Upload:** React Dropzone
- **Tables:** TanStack Table
- **Charts:** Recharts
- **Date Picker:** date-fns + shadcn/ui Calendar
- **Icons:** Lucide React
- **Testing:**
- **Unit/Integration:** Vitest + React Testing Library
- **E2E:** Playwright
- **API Mocking:** Mock Service Worker (MSW)
### โครงสร้างโปรเจกต์
```
app/
├── (public)/ # Public routes (Landing, Login)
│ ├── page.tsx # Landing Page
│ └── login/ # Login Page
├── (protected)/ # Protected routes
│ ├── layout.tsx # App Shell (Navbar + Sidebar)
│ ├── dashboard/ # Dashboard
│ ├── correspondences/ # Correspondence Management
│ ├── rfas/ # RFA Management
│ ├── drawings/ # Drawing Management
│ ├── circulations/ # Circulation Management
│ ├── transmittals/ # Transmittal Management
│ ├── search/ # Advanced Search
│ ├── reports/ # Reports
│ ├── admin/ # Admin Panel
│ └── profile/ # User Profile
├── api/ # API Routes (if needed)
components/
├── ui/ # shadcn/ui components
├── features/ # Feature-specific components
│ ├── auth/
│ ├── correspondence/
│ ├── rfa/
│ ├── drawing/
│ ├── circulation/
│ └── common/
└── layouts/ # Layout components
lib/
├── api/ # API client & hooks
├── stores/ # Zustand stores
├── utils/ # Utility functions
├── hooks/ # Custom hooks
└── types/ # TypeScript types
public/
├── images/
└── fonts/
```
---
## 🗓️ แผนการพัฒนาแบบ Phase-Based
## **Phase 0: Setup & Infrastructure (สัปดาห์ที่ 1)**
### Milestone: สร้างโครงสร้างพื้นฐานและ Development Environment
#### Tasks:
**T0.1 Initialize Next.js Project**
- สร้างโปรเจกต์ด้วย `create-next-app`:
```bash
npx create-next-app@latest lcbp3-frontend --typescript --tailwind --app --src-dir=false
```
- เลือก Options:
- ✅ TypeScript
- ✅ ESLint
- ✅ Tailwind CSS
- ✅ App Router
- ✅ Import alias (@/\*)
- Setup .gitignore, README.md
- Deliverable: ✅ โปรเจกต์เริ่มต้นพร้อม
**T0.2 Install Core Dependencies**
```bash
# State Management & Data Fetching
npm install @tanstack/react-query zustand
npm install axios
npm install react-hook-form @hookform/resolvers zod
# UI Components & Styling
npm install clsx tailwind-merge
npm install lucide-react
npm install date-fns
# File Upload
npm install react-dropzone
# Authentication
npm install next-auth
# Development Tools
npm install -D @types/node
```
- Deliverable: ✅ Dependencies ติดตั้งสมบูรณ์
**T0.3 Setup shadcn/ui**
```bash
npx shadcn-ui@latest init
```
- เลือก Style: Default
- เลือก Base Color: Slate
- ติดตั้ง Components เบื้องต้น:
```bash
npx shadcn-ui@latest add button input label card table dropdown-menu
npx shadcn-ui@latest add dialog sheet toast alert
npx shadcn-ui@latest add form select textarea checkbox
npx shadcn-ui@latest add calendar popover
```
- Deliverable: ✅ shadcn/ui พร้อมใช้งาน
**T0.4 Configure Tailwind CSS**
- แก้ไข `tailwind.config.ts`:
- เพิ่ม Custom Colors (ตาม Brand)
- เพิ่ม Custom Fonts (ภาษาไทย: Noto Sans Thai)
- Configure Container, Spacing
- สร้าง `app/globals.css` พร้อม Custom Styles
- Deliverable: ✅ Tailwind พร้อมใช้
**T0.5 Setup Development Environment**
- สร้าง `.env.local`:
```
NEXT_PUBLIC_API_URL=http://backend.np-dms.work/api
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=...
```
- Setup ESLint Rules (ไทย Comments OK)
- Setup Prettier
- Setup VS Code Settings
- Deliverable: ✅ Dev Environment พร้อม
**T0.6 Setup Git & Docker**
- Push โปรเจกต์ไปยัง Gitea (git.np-dms.work)
- สร้าง Dockerfile สำหรับ Next.js:
```dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
```
- สร้าง docker-compose.yml (เชื่อม Network `lcbp3`)
- Deliverable: ✅ Project อยู่ใน Git + Docker พร้อม
---
## **Phase 1: Authentication & App Shell (สัปดาห์ที่ 2-3)**
### Milestone: ระบบ Login และ Layout หลัก
#### Tasks:
**T1.1 Setup API Client**
- สร้าง `lib/api/client.ts`:
```typescript
import axios from "axios";
export const apiClient = axios.create({
baseURL: process.env.NEXT_PUBLIC_API_URL,
headers: {
"Content-Type": "application/json",
},
});
// Request Interceptor (Add JWT Token)
apiClient.interceptors.request.use((config) => {
const token = localStorage.getItem("access_token");
if (token) {
config.headers.Authorization = `Bearer ${token}`;
}
return config;
});
// Response Interceptor (Handle Errors)
apiClient.interceptors.response.use(
(response) => response,
(error) => {
if (error.response?.status === 401) {
// Redirect to login
window.location.href = "/login";
}
return Promise.reject(error);
}
);
```
- Deliverable: ✅ API Client พร้อมใช้
**T1.2 Setup TanStack Query**
- สร้าง `app/providers.tsx`:
```typescript
"use client";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { useState } from "react";
export function Providers({ children }: { children: React.ReactNode }) {
const [queryClient] = useState(
() =>
new QueryClient({
defaultOptions: {
queries: {
staleTime: 60 * 1000, // 1 minute
refetchOnWindowFocus: false,
},
},
})
);
return (
<QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
);
}
```
- Wrap ใน `app/layout.tsx`
- Deliverable: ✅ React Query พร้อม
**T1.3 Create Auth Store (Zustand)**
- สร้าง `lib/stores/auth-store.ts`:
```typescript
import { create } from "zustand";
import { persist } from "zustand/middleware";
interface User {
user_id: number;
username: string;
email: string;
first_name: string;
last_name: string;
primary_organization_id: number;
permissions: string[];
}
interface AuthStore {
user: User | null;
token: string | null;
setAuth: (user: User, token: string) => void;
clearAuth: () => void;
hasPermission: (permission: string) => boolean;
}
export const useAuthStore = create<AuthStore>()(
persist(
(set, get) => ({
user: null,
token: null,
setAuth: (user, token) => {
set({ user, token });
localStorage.setItem("access_token", token);
},
clearAuth: () => {
set({ user: null, token: null });
localStorage.removeItem("access_token");
},
hasPermission: (permission) => {
const user = get().user;
return user?.permissions.includes(permission) || false;
},
}),
{
name: "auth-storage",
}
)
);
```
- Deliverable: ✅ Auth Store พร้อม
**T1.4 Create Login Page**
- สร้าง `app/(public)/login/page.tsx`:
```typescript
"use client";
import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";
import * as z from "zod";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { useRouter } from "next/navigation";
import { useAuthStore } from "@/lib/stores/auth-store";
import { apiClient } from "@/lib/api/client";
const loginSchema = z.object({
username: z.string().min(1, "กรุณากรอกชื่อผู้ใช้"),
password: z.string().min(1, "กรุณากรอกรหัสผ่าน"),
});
export default function LoginPage() {
const router = useRouter();
const setAuth = useAuthStore((state) => state.setAuth);
const form = useForm({
resolver: zodResolver(loginSchema),
});
const handleLogin = async (data: z.infer<typeof loginSchema>) => {
try {
const response = await apiClient.post("/auth/login", data);
const { access_token, user } = response.data;
setAuth(user, access_token);
router.push("/dashboard");
} catch (error) {
console.error("Login failed:", error);
// แสดง Toast Error
}
};
return (
<div className="flex min-h-screen items-center justify-center">
<form onSubmit={form.handleSubmit(handleLogin)} className="w-96">
{/* Form Fields */}
</form>
</div>
);
}
```
- Deliverable: ✅ หน้า Login พร้อม
**T1.5 Create Landing Page**
- สร้าง `app/(public)/page.tsx`:
- Hero Section พร้อมข้อมูลโครงการ
- Feature Highlights
- CTA Button → Login
- ใช้ Tailwind + Animations
- Deliverable: ✅ Landing Page สวยงาม
**T1.6 Create Protected Layout (App Shell)**
- สร้าง `app/(protected)/layout.tsx`:
```typescript
"use client";
import { useEffect } from "react";
import { useRouter } from "next/navigation";
import { useAuthStore } from "@/lib/stores/auth-store";
import Navbar from "@/components/layouts/navbar";
import Sidebar from "@/components/layouts/sidebar";
export default function ProtectedLayout({
children,
}: {
children: React.ReactNode;
}) {
const router = useRouter();
const user = useAuthStore((state) => state.user);
useEffect(() => {
if (!user) {
router.push("/login");
}
}, [user, router]);
if (!user) return null;
return (
<div className="flex h-screen">
<Sidebar />
<div className="flex flex-1 flex-col">
<Navbar />
<main className="flex-1 overflow-y-auto p-6">{children}</main>
</div>
</div>
);
}
```
- Deliverable: ✅ App Shell พร้อม
**T1.7 Create Navbar Component**
- สร้าง `components/layouts/navbar.tsx`:
- แสดงชื่อระบบ
- แสดงชื่อผู้ใช้ + Avatar
- Dropdown Menu:
- Profile
- Settings
- Logout
- Responsive (Mobile Hamburger Menu)
- Deliverable: ✅ Navbar พร้อม
**T1.8 Create Sidebar Component**
- สร้าง `components/layouts/sidebar.tsx`:
- เมนูหลัก:
- Dashboard
- Correspondences
- RFAs
- Drawings (Shop & Contract)
- Circulations
- Transmittals
- Search
- Reports
- เมนู Admin (แสดงตามสิทธิ์):
- Users
- Roles & Permissions
- Master Data
- Document Numbering
- Collapsible Sidebar
- Active State Highlighting
- Deliverable: ✅ Sidebar พร้อม
---
## **Phase 2: Dashboard & Common Components (สัปดาห์ที่ 4)**
### Milestone: Dashboard และ Reusable Components
#### Tasks:
**T2.1 Create Reusable Components**
- `components/features/common/data-table.tsx`:
- ใช้ TanStack Table
- รองรับ Pagination, Sorting, Filtering
- Responsive
- `components/features/common/file-upload.tsx`:
- ใช้ React Dropzone
- รองรับ Multi-file Upload
- Drag & Drop
- Progress Bar
- `components/features/common/status-badge.tsx`:
- แสดง Status แบบสีสัน (Draft, Submitted, Approved)
- `components/features/common/permission-guard.tsx`:
- ซ่อน/แสดง Component ตามสิทธิ์
- Deliverable: ✅ Reusable Components พร้อม
**T2.2 Create Dashboard Page**
- สร้าง `app/(protected)/dashboard/page.tsx`:
- **KPI Cards Section**:
- จำนวนเอกสารทั้งหมด
- งานที่รอดำเนินการ
- เอกสารที่เกินกำหนด
- RFA ที่รออนุมัติ
- **My Tasks Table**:
- ดึงข้อมูลจาก `/api/circulations/my-tasks` (ใช้ `v_user_tasks`)
- แสดงรายการงานที่ต้องทำ (Pending, In Progress)
- Columns: Document Number, Title, Type, Status, Deadline, Actions
- คลิกแถวแล้วไปยังหน้า Detail
- **Recent Activity Feed**:
- ดึงข้อมูลจาก `/api/audit-logs/user/:userId`
- แสดง 10 รายการล่าสุด
- Deliverable: ✅ Dashboard ครบถ้วน
**T2.3 Create API Hooks**
- สร้าง `lib/api/hooks/use-my-tasks.ts`:
```typescript
import { useQuery } from "@tanstack/react-query";
import { apiClient } from "../client";
export function useMyTasks() {
return useQuery({
queryKey: ["my-tasks"],
queryFn: async () => {
const response = await apiClient.get("/circulations/my-tasks");
return response.data;
},
});
}
```
- สร้าง Hooks เพิ่มเติม:
- `use-dashboard-stats.ts`
- `use-recent-activity.ts`
- Deliverable: ✅ API Hooks พร้อม
---
## **Phase 3: Correspondence Management (สัปดาห์ที่ 5-6)**
### Milestone: ระบบจัดการเอกสารโต้ตอบ
#### Tasks:
**T3.1 Create Correspondence List Page**
- สร้าง `app/(protected)/correspondences/page.tsx`:
- Data Table แสดงรายการเอกสาร
- Columns:
- Document Number (คลิกไปยัง Detail)
- Title
- Type
- Status (Badge)
- Originator
- Date
- Actions (View, Edit, Delete)
- Filters:
- ประเภทเอกสาร (Dropdown)
- สถานะ (Dropdown)
- วันที่ (Date Range Picker)
- องค์กร (Dropdown)
- Pagination (Server-side)
- Search Box
- Create Button (ตรวจสิทธิ์)
- Deliverable: ✅ หน้ารายการเอกสาร
**T3.2 Create Correspondence Detail Page**
- สร้าง `app/(protected)/correspondences/[id]/page.tsx`:
- **Header Section**:
- Document Number (ใหญ่)
- Status Badge
- Action Buttons: Edit, Delete, Export PDF
- **Metadata Section**:
- Title, Description
- Document Date, Issued Date, Received Date
- Originator, Recipients (TO/CC)
- Due Date (ถ้ามี)
- **Revision History**:
- แสดง Revisions ทั้งหมดเป็น Timeline
- แต่ละ Revision แสดง: Revision Number, Date, Changes, User
- **Attachments**:
- แสดงไฟล์แนบทั้งหมด
- กำหนดไฟล์หลัก (Main Document) ด้วยไอคอน
- ปุ่ม Download
- **References**:
- แสดงเอกสารที่อ้างถึง (Links)
- **Tags**:
- แสดง Tags แบบ Chips
- **Activity Log**:
- แสดง Audit Log ของเอกสารนี้
- Deliverable: ✅ หน้า Detail ครบถ้วน
**T3.3 Create Correspondence Form (Create/Edit)**
- สร้าง `app/(protected)/correspondences/create/page.tsx`:
- สร้าง `app/(protected)/correspondences/[id]/edit/page.tsx`:
- Form Fields:
- **Basic Info**:
- Correspondence Type (Dropdown)
- Title (Text)
- Description (Textarea)
- Document Date (Date Picker)
- **Recipients**:
- TO: Multi-select Organizations
- CC: Multi-select Organizations
- **References**:
- Search & Select เอกสารอื่นๆ
- **Tags**:
- Autocomplete Tag Input
- **Attachments**:
- File Upload (Multi-file)
- กำหนด Main Document (Radio)
- **Deadline**:
- Due Date (Date Picker)
- Validation ด้วย Zod
- Submit → API → Redirect to Detail
- Deliverable: ✅ ฟอร์มสร้าง/แก้ไข
**T3.4 Create Status Management**
- ใน Detail Page เพิ่มปุ่ม Status Actions:
- **Draft → Submit** (Document Control)
- **Submit → Close** (Admin)
- **Submit → Cancel** (Admin + Dialog ให้กรอกเหตุผล)
- แสดง Confirmation Dialog ก่อนเปลี่ยนสถานะ
- Deliverable: ✅ เปลี่ยนสถานะได้
---
## **Phase 4: RFA & Workflow Visualization (สัปดาห์ที่ 7-8)**
### Milestone: ระบบ RFA และ Workflow
#### Tasks:
**T4.1 Create RFA List Page**
- สร้าง `app/(protected)/rfas/page.tsx`:
- คล้าย Correspondence List
- Columns เพิ่มเติม:
- RFA Type (DWG, DOC, MAT)
- Approval Status (Badge)
- Approval Code (1A, 3R, etc.)
- Filters:
- RFA Type
- Status
- Approval Code
- Deliverable: ✅ หน้ารายการ RFA
**T4.2 Create RFA Detail Page**
- สร้าง `app/(protected)/rfas/[id]/page.tsx`:
- คล้าย Correspondence Detail
- เพิ่ม Section:
- **Shop Drawings** (สำหรับ RFA_DWG):
- แสดงรายการ Shop Drawings ที่เชื่อมโยง
- แสดง Revision ของแต่ละแบบ
- Link ไปยัง Shop Drawing Detail
- **Workflow Visualization** (ดูรายละเอียดใน T4.3)
- Deliverable: ✅ หน้า Detail RFA
**T4.3 Create Workflow Visualization Component**
- สร้าง `components/features/rfa/workflow-visualizer.tsx`:
- **Layout**: Steps แนวนอน (Timeline)
- **Step States**:
- ✅ **Completed**: สีเขียว, ไอคอน Check
- ⏳ **Active**: สีฟ้า, ปุ่ม Action เปิดใช้งาน
- ⏸️ **Pending**: สีเทา, ปุ่ม disabled
- ❌ **Rejected**: สีแดง
- **Step Info Card** (เมื่อคลิก):
- Organization
- Assigned User
- Action Type (Review, Approve)
- Status
- Comments
- Completed Date
- **Actions** (สำหรับ Active Step):
- ปุ่ม "อนุมัติ" (Approve)
- ปุ่ม "ปฏิเสธ" (Reject)
- Dialog ให้กรอก Comments
- **Admin Override**:
- ปุ่ม "ไปยังขั้นตอนต่อไป" (Skip Step)
- ปุ่ม "ย้อนกลับ" (Previous Step)
- Deliverable: ✅ Workflow Component พร้อม
**T4.4 Create RFA Form (Create/Edit)**
- สร้าง `app/(protected)/rfas/create/page.tsx`:
- Form Fields:
- RFA Type (Dropdown)
- Title, Description
- Document Date
- **Shop Drawings Section** (สำหรับ RFA_DWG):
- Search & Select Shop Drawings
- แสดง Revisions ที่มี (Dropdown)
- เพิ่มได้หลายแบบ
- Attachments
- Workflow Template (Dropdown)
- Submit → สร้าง RFA + Start Workflow
- Deliverable: ✅ ฟอร์ม RFA พร้อม
**T4.5 Implement Workflow Actions API**
- สร้าง `lib/api/hooks/use-rfa-workflow.ts`:
```typescript
import { useMutation, useQueryClient } from "@tanstack/react-query";
import { apiClient } from "../client";
export function useCompleteWorkflowStep() {
const queryClient = useQueryClient();
return useMutation({
mutationFn: async ({ rfaId, stepNumber, action, comments }) => {
const response = await apiClient.post(
`/rfas/${rfaId}/workflow/steps/${stepNumber}/complete`,
{ action, comments }
);
return response.data;
},
onSuccess: (_, variables) => {
queryClient.invalidateQueries(["rfa", variables.rfaId]);
queryClient.invalidateQueries(["my-tasks"]);
},
});
}
```
- Hooks เพิ่มเติม:
- `use-reject-workflow-step.ts`
- `use-start-workflow.ts`
- Deliverable: ✅ Workflow Actions ทำงานได้
---
## **Phase 5: Drawing Management (สัปดาห์ที่ 9)**
### Milestone: ระบบจัดการแบบ
#### Tasks:
**T5.1 Create Shop Drawing List Page**
- สร้าง `app/(protected)/drawings/shop/page.tsx`:
- Data Table:
- Drawing Number
- Title
- Main Category
- Sub Category
- Current Revision
- Actions
- Filters:
- Category (Dropdown)
- Sub Category (Dropdown)
- Create Button
- Deliverable: ✅ หน้ารายการ Shop Drawings
**T5.2 Create Shop Drawing Detail Page**
- สร้าง `app/(protected)/drawings/shop/[id]/page.tsx`:
- **Header**: Drawing Number, Title
- **Current Revision Info**:
- Revision Number, Date
- Description
- Attachments (PDF, DWG)
- **Contract Drawing References**:
- แสดง Contract Drawings ที่อ้างถึง
- Links ไปยัง Contract Drawing Detail
- **Revision History**:
- แสดง Revisions ทั้งหมดเป็น Timeline
- **Related RFAs**:
- แสดง RFAs ที่เชื่อมโยงกับแบบนี้
- Deliverable: ✅ หน้า Detail Shop Drawing
**T5.3 Create Shop Drawing Form**
- สร้าง `app/(protected)/drawings/shop/create/page.tsx`:
- Form Fields:
- Drawing Number (Auto-generate หรือ Manual)
- Title
- Main Category (Dropdown)
- Sub Category (Dropdown, dependent on Main)
- **Contract Drawing References**:
- Search & Select Contract Drawings (Multi-select)
- **Revision Info**:
- Revision Number (Auto)
- Revision Label (A, B, C)
- Description
- **Attachments**:
- Upload PDF (Main)
- Upload DWG (Optional)
- Upload Other Files
- Deliverable: ✅ ฟอร์ม Shop Drawing
**T5.4 Create Contract Drawing List & Detail**
- สร้าง `app/(protected)/drawings/contract/page.tsx`:
- Data Table:
- Drawing Number
- Title
- Volume
- Category
- Sub Category
- Filters:
- Volume (Dropdown)
- Category (Dropdown)
- สร้าง `app/(protected)/drawings/contract/[id]/page.tsx`:
- แสดง Metadata
- Attachments
- **Referenced By**:
- แสดง Shop Drawings ที่อ้างถึงแบบนี้
- Deliverable: ✅ Contract Drawing Pages
---
## **Phase 6: Circulation & Transmittal (สัปดาห์ที่ 10)**
### Milestone: ระบบใบเวียนและเอกสารนำส่ง
#### Tasks:
**T6.1 Create Circulation List Page**
- สร้าง `app/(protected)/circulations/page.tsx`:
- Data Table:
- Circulation Number
- Subject
- Status (Badge)
- Created By
- Created Date
- Filters:
- Status
- Date Range
- Deliverable: ✅ หน้ารายการใบเวียน
**T6.2 Create Circulation Detail & Workflow**
- สร้าง `app/(protected)/circulations/[id]/page.tsx`:
- **Header**: Circulation Number, Subject, Status
- **Linked Correspondence**:
- Link ไปยังเอกสารต้นทาง
- **Workflow Visualization**:
- คล้าย RFA Workflow
- แสดง Steps:
- Organization
- Assigned Users (Main, Action, Information)
- Status
- Comments
- Deadline
- **Actions** (สำหรับ Assigned User):
- ปุ่ม "ดำเนินการเสร็จสิ้น" (Complete)
- Dialog ให้กรอก Comments
- **Close Circulation** (Document Control):
- ปุ่ม "ปิดใบเวียน" (เมื่อตอบกลับองค์กรผู้ส่งแล้ว)
- Deliverable: ✅ หน้า Detail ใบเวียน

View File

@@ -0,0 +1,480 @@
# **Documents Management Sytem Version 1.4.0: แนวทางการพัฒนา FullStackJS**
## **🧠 ปรัชญาทั่วไป**
แนวทางปฏิบัติที่ดีที่สุดแบบครบวงจรสำหรับการพัฒนา NestJS Backend, NextJS Frontend และ Tailwind-based UI/UX ในสภาพแวดล้อม TypeScript มุ่งเน้นที่ ความชัดเจน (clarity), ความง่ายในการบำรุงรักษา (maintainability), ความสอดคล้องกัน (consistency) และ การเข้าถึงได้ (accessibility) ตลอดทั้งสแต็ก
## **⚙️ แนวทางทั่วไปสำหรับ TypeScript**
### **หลักการพื้นฐาน**
* ใช้ **ภาษาอังกฤษ** สำหรับโค้ด
* ใช้ **ภาษาไทย** สำหรับ comment และเอกสารทั้งหมด
* กำหนดไทป์ (type) อย่างชัดเจนสำหรับตัวแปร, พารามิเตอร์ และค่าที่ส่งกลับ (return values) ทั้งหมด
* หลีกเลี่ยงการใช้ any; ให้สร้างไทป์ (types) หรืออินเทอร์เฟซ (interfaces) ที่กำหนดเอง
* ใช้ **JSDoc** สำหรับคลาส (classes) และเมธอด (methods) ที่เป็น public
* ส่งออก (Export) **สัญลักษณ์หลัก (main symbol) เพียงหนึ่งเดียว** ต่อไฟล์
* หลีกเลี่ยงบรรทัดว่างภายในฟังก์ชัน
* ระบุ // File: path/filename ในบรรทัดแรกของทุกไฟล์
* ระบุ // บันทึกการแก้ไข, หากมีการแก้ไขเพิ่มในอนาคต ให้เพิ่มบันทึก
### **ข้อตกลงในการตั้งชื่อ (Naming Conventions)**
| Entity (สิ่งที่ตั้งชื่อ) | Convention (รูปแบบ) | Example (ตัวอย่าง) |
| :---- | :---- | :---- |
| Classes | PascalCase | UserService |
| Property | snake_sase | user_id |
| Variables & Functions | camelCase | getUserInfo |
| Files & Folders | kebab-case | user-service.ts |
| Environment Variables | UPPERCASE | DATABASE\URL |
| Booleans | Verb \+ Noun | isActive, canDelete, hasPermission |
ใช้คำเต็ม — ไม่ใช้อักษรย่อ — ยกเว้นคำมาตรฐาน (เช่น API, URL, req, res, err, ctx)
## **🧩 ฟังก์ชัน (Functions)**
* เขียนฟังก์ชันให้สั้น และทำ **หน้าที่เพียงอย่างเดียว** (single-purpose) (\< 20 บรรทัด)
* ใช้ **early returns** เพื่อลดการซ้อน (nesting) ของโค้ด
* ใช้ **map**, **filter**, **reduce** แทนการใช้ loops เมื่อเหมาะสม
* ควรใช้ **arrow functions** สำหรับตรรกะสั้นๆ, และใช้ **named functions** ในกรณีอื่น
* ใช้ **default parameters** แทนการตรวจสอบค่า null
* จัดกลุ่มพารามิเตอร์หลายตัวให้เป็นอ็อบเจกต์เดียว (RO-RO pattern)
* ส่งค่ากลับ (Return) เป็นอ็อบเจกต์ที่มีไทป์กำหนด (typed objects) ไม่ใช่ค่าพื้นฐาน (primitives)
* รักษาระดับของสิ่งที่เป็นนามธรรม (abstraction level) ให้เป็นระดับเดียวในแต่ละฟังก์ชัน
## **🧱 การจัดการข้อมูล (Data Handling)**
* ห่อหุ้มข้อมูล (Encapsulate) ในไทป์แบบผสม (composite types)
* ใช้ **immutability** (การไม่เปลี่ยนแปลงค่า) ด้วย readonly และ as const
* ทำการตรวจสอบความถูกต้องของข้อมูล (Validations) ในคลาสหรือ DTOs ไม่ใช่ภายในฟังก์ชันทางธุรกิจ
* ตรวจสอบความถูกต้องของข้อมูลโดยใช้ DTOs ที่มีไทป์กำหนดเสมอ
## **🧰 คลาส (Classes)**
* ปฏิบัติตามหลักการ **SOLID**
* ควรใช้ **composition มากกว่า inheritance** (Prefer composition over inheritance)
* กำหนด **interfaces** สำหรับสัญญา (contracts)
* ให้คลาสมุ่งเน้นการทำงานเฉพาะอย่างและมีขนาดเล็ก (\< 200 บรรทัด, \< 10 เมธอด, \< 10 properties)
## **🚨 การจัดการข้อผิดพลาด (Error Handling)**
* ใช้ Exceptions สำหรับข้อผิดพลาดที่ไม่คาดคิด
* ดักจับ (Catch) ข้อผิดพลาดเพื่อแก้ไขหรือเพิ่มบริบท (context) เท่านั้น; หากไม่เช่นนั้น ให้ใช้ global error handlers
* ระบุข้อความข้อผิดพลาด (error messages) ที่มีความหมายเสมอ
## **🧪 การทดสอบ (ทั่วไป) (Testing (General))**
* ใช้รูปแบบ **ArrangeActAssert**
* ใช้ชื่อตัวแปรในการทดสอบที่สื่อความหมาย (inputData, expectedOutput)
* เขียน **unit tests** สำหรับ public methods ทั้งหมด
* จำลอง (Mock) การพึ่งพาภายนอก (external dependencies)
* เพิ่ม **acceptance tests** ต่อโมดูลโดยใช้รูปแบบ GivenWhen-Then
## **🏗️ แบ็กเอนด์ (NestJS) (Backend (NestJS))**
### **หลักการ**
* **สถาปัตยกรรมแบบโมดูลาร์ (Modular architecture)**:
* หนึ่งโมดูลต่อหนึ่งโดเมน
* โครงสร้างแบบ Controller → Service → Repository (Model)
* API-First: มุ่งเน้นการสร้าง API ที่มีคุณภาพสูง มีเอกสารประกอบ (Swagger) ที่ชัดเจนสำหรับ Frontend Team
* DTOs ที่ตรวจสอบความถูกต้องด้วย **class-validator**
* ใช้ **MikroORM** (หรือ TypeORM/Prisma) สำหรับการคงอยู่ของข้อมูล (persistence) ซึ่งสอดคล้องกับสคีมา MariaDB
* ห่อหุ้มโค้ดที่ใช้ซ้ำได้ไว้ใน **common module** (@app/common):
* Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators
### **ฟังก์ชันหลัก (Core Functionalities)**
* Global **filters** สำหรับการจัดการ exception
* **Middlewares** สำหรับการจัดการ request
* **Guards** สำหรับการอนุญาต (permissions) และ RBAC
* **Interceptors** สำหรับการแปลงข้อมูล response และการบันทึก log
### **ข้อจำกัดในการ Deploy (QNAP Container Station)**
* **ห้ามใช้ไฟล์ .env** ในการตั้งค่า Environment Variables [cite: 2.1]
* การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน docker-compose.yml โดยตรง** [cite: 6.5] ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station [cite: 2.1]
### **โครงสร้างโมดูลตามโดเมน (Domain-Driven Module Structure)**
เพื่อให้สอดคล้องกับสคีมา SQL (LCBP3-DMS) เราจะใช้โครงสร้างโมดูลแบบ **Domain-Driven (แบ่งตามขอบเขตธุรกิจ)** แทนการแบ่งตามฟังก์ชัน:
1. **CommonModule:**
* เก็บ Services ที่ใช้ร่วมกัน เช่น DatabaseModule, FileStorageService (จัดการไฟล์ใน QNAP), AuditLogService, NotificationService
* จัดการ audit_logs
* NotificationService ต้องรองรับ Triggers ที่ระบุใน Requirement 6.7 [cite: 6.7]
2. **AuthModule:**
* จัดการะการยืนยันตัวตน (JWT, Guards)
* **(สำคัญ)** ต้องรับผิดชอบการตรวจสอบสิทธิ์ **4 ระดับ** [cite: 4.2]: สิทธิ์ระดับระบบ (Global Role), สิทธิ์ระดับองกรณ์ (Organization Role), สิทธิ์ระดับโปรเจกต์ (Project Role), และ สิทธิ์ระดับสัญญา (Contract Role)
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
* ให้ Superadmin สร้าง Organizations และกำหนด Org Admin ได้ [cite: 4.6]
* ให้ Superadmin/Admin จัดการ document_number_formats (รูปแบบเลขที่เอกสาร), document_number_counters (Running Number) [cite: 3.10]
3. **UserModule:**
* จัดการ users, roles, permissions, global_default_roles, role_permissions, user_roles, user_project_roles
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
4. **ProjectModule:**
* จัดการ projects, organizations, contracts, project_parties, contract_parties
5. **MasterModule:**
* จัดการ master data (correspondence_types, rfa_types, rfa_status_codes, rfa_approve_codes, circulation_status_codes, correspondence_types, correspondence_status, tags) [cite: 4.5]
6. **CorrespondenceModule (โมดูลศูนย์กลาง):**
* จัดการ correspondences, correspondence_revisions, correspondence_tags
* **(สำคัญ)** Service นี้ต้อง Inject DocumentNumberingService เพื่อขอเลขที่เอกสารใหม่ก่อนการสร้าง
* **(สำคัญ)** ตรรกะการสร้าง/อัปเดต Revision จะอยู่ใน Service นี้
* จัดการ correspondence_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบ Routing **Correspondence Routing** (correspondence_routings, correspondence_routing_template_steps, correspondence_routing_templates, correspondence_status_transitions) สำหรับการส่งต่อเอกสารทั่วไประหว่างองค์กร
7. **RfaModule:**
* จัดการ rfas, rfa_revisions, rfa_items
* รับผิดชอบเวิร์กโฟลว์ **"RFA Workflows"** (rfa_workflows, rfa_workflow_templates, rfa_workflow_template_steps, rfa_status_transitions) สำหรับการอนุมัติเอกสารทางเทคนิค
8. **DrawingModule:**
* จัดการ shop_drawings, shop_drawing_revisions, contract_drawings, contract_drawing_volumes, contract_drawing_cats, contract_drawing_sub_cats, shop_drawing_main_categories, shop_drawing_sub_categories, contract_drawing_subcat_cat_maps, shop_drawing_revision_contract_refs
* จัดการ shop_drawing_revision_attachments และ contract_drawing_attachments(ตารางเชื่อมไฟล์แนบ)
9. **CirculationModule:**
* จัดการ circulations, circulation_templates, circulation_assignees
* จัดการ circulation_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Circulations"** (circulation_status_transitions, circulation_template_assignees, circulation_assignees, circulation_recipients, circulation_actions, circulation_action_documents)สำหรับการเวียนเอกสาร **ภายในองค์กร**
10. **TransmittalModule:**
* จัดการ transmittals และ transmittal_items
11. **SearchModule:**
* ให้บริการค้นหาขั้นสูง (Advanced Search) [cite: 6.2] โดยใช้ **Elasticsearch** เพื่อรองรับการค้นหาแบบ Full-text จากชื่อเรื่อง, รายละเอียด, เลขที่เอกสาร, ประเภท, วันที่, และ Tags
* ระบบจะใช้ Elasticsearch Engine ในการจัดทำดัชนีเพื่อการค้นหาข้อมูลเชิงลึกจากเนื้อหาของเอกสาร โดยข้อมูลจะถูกส่งไปทำดัชนีจาก Backend (NestJS) ทุกครั้งที่มีการสร้างหรือแก้ไขเอกสาร
12. **DocumentNumberingModule:**
* **สถานะ:** เป็น Module ภายใน (Internal Module) ไม่เปิด API สู่ภายนอก
* **หน้าที่:** ให้บริการ DocumentNumberingService ที่ Module อื่น (เช่น CorrespondenceModule) จะ Inject ไปใช้งาน
* **ตรรกะ:** รับผิดชอบการสร้างเลขที่เอกสาร โดยการเรียกใช้ Stored Procedure *sp_get_next_document_number** เพื่อป้องกัน Race Condition
### **สถาปัตยกรรมระบบ (System Architecture)**
โครงสร้างโมดูล (Module Structure)
```bash
📁 src
├── 📄 app.module.ts
├── 📄 main.ts
├── 📁 common # @app/common (โมดูลส่วนกลาง)
│ ├── 📁 auth # AuthModule (JWT, Guards)
│ ├── 📁 config # Configuration
│ ├── 📁 decorators # Custom Decorators (เช่น @RequirePermission)
│ ├── 📁 entities # Shared Entities (User, Role, Permission)
│ ├── 📁 exceptions # Global Exception Filters
│ ├── 📁 file-storage # FileStorageService
│ ├── 📁 guards # Custom Guards (RBAC Guard)
│ ├── 📁 interceptors # Interceptors (Audit Log, Transform)
│ └── 📁 services # Shared Services (NotificationService)
├── 📁 modules
│ ├── 📁 user # UserModule (จัดการ Users, Roles, Permissions)
│ ├── 📁 project # ProjectModule (จัดการ Projects, Organizations, Contracts)
│ ├── 📁 correspondence # CorrespondenceModule (จัดการเอกสารโต้ตอบ)
│ ├── 📁 rfa # RfaModule (จัดการเอกสารขออนุมัติ)
│ ├── 📁 drawing # DrawingModule (จัดการแบบแปลน)
│ ├── 📁 circulation # CirculationModule (จัดการใบเวียน)
│ ├── 📁 transmittal # TransmittalModule (จัดการเอกสารนำส่ง)
│ ├── 📁 search # SearchModule (ค้นหาขั้นสูงด้วย Elasticsearch)
│ └── 📁 document-numbering # DocumentNumberingModule (Internal Module)
└── 📁 database # Database Migration & Seeding Scripts
```
### **เเทคโนโลยีที่ใช้ (Technology Stack)**
| ส่วน | Library/Tool | หมายเหตุ |
|---|---|---|
| **Framework** | `@nestjs/core`, `@nestjs/common` | Core Framework |
| **Language** | `TypeScript` | ใช้ TypeScript ทั้งระบบ |
| **Database** | `MariaDB 10.11` | ฐานข้อมูลหลัก |
| **ORM** | `@nestjs/typeorm`, `typeorm` | 🗃️จัดการการเชื่อมต่อและ Query ฐานข้อมูล |
| **Validation** | `class-validator`, `class-transformer` | 📦ตรวจสอบและแปลงข้อมูลใน DTO |
| **Auth** | `@nestjs/jwt`, `@nestjs/passport`, `passport-jwt` | 🔐การยืนยันตัวตนด้วย JWT |
|**Authorization** | `casl` | 🔐จัดการสิทธิ์แบบ RBAC |
| **File Upload** | `multer` | 📁จัดการการอัปโหลดไฟล์ |
| **Search** | `@nestjs/elasticsearch` | 🔍สำหรับการค้นหาขั้นสูง |
| **Notification** | `nodemailer` | 📬ส่งอีเมลแจ้งเตือน |
| **Scheduling** | `@nestjs/schedule` | 📬สำหรับ Cron Jobs (เช่น แจ้งเตือน Deadline) |
| **Logging** | `winston` | 📊บันทึก Log ที่มีประสิทธิภาพ |
| **Testing** | `@nestjs/testing`, `jest`, `supertest` | 🧪ทดสอบ Unit, Integration และ E2E |
| **Documentation** | `@nestjs/swagger` | 🌐สร้าง API Documentation อัตโนมัติ |
| **Security** | `helmet`, `rate-limiter-flexible` | 🛡️เพิ่มความปลอดภัยให้ API |
เราจะแบ่งการทดสอบเป็น 3 ระดับ โดยใช้ **Jest** และ @nestjs/testing:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เป้าหมาย:** ทดสอบ Logic ภายใน Service, Guard, หรือ Pipe โดยจำลอง (Mock) Dependencies ทั้งหมด
* **สิ่งที่ต้องทดสอบ:** Business Logic (เช่น การเปลี่ยนสถานะ Workflow, การตรวจสอบ Deadline) [cite: 2.9.1], ตรรกะการตรวจสอบสิทธิ์ (Auth Guard) ทั้ง 4 ระดับ
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เป้าหมาย:** ทดสอบการทำงานร่วมกันของ Controller -> Service -> Repository (Database)
* **เทคนิค:** ใช้ **Test Database แยกต่างหาก** (ห้ามใช้ Dev DB) และใช้ supertest เพื่อยิง HTTP Request จริงไปยัง App
* **สิ่งที่ต้องทดสอบ:** การเรียก sp\get\next\document\number [cite: 2.9.3] และการทำงานของ Views (เช่น v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เป้าหมาย:** ทดสอบ API Contract ว่า Response Body Shape ตรงตามเอกสาร Swagger เพื่อรับประกันทีม Frontend
### **🗄️ Backend State Management**
Backend (NestJS) ควรเป็น **Stateless** (ไม่เก็บสถานะ) "State" ทั้งหมดจะถูกจัดเก็บใน MariaDB
* **Request-Scoped State (สถานะภายใน Request เดียว):**
* **ปัญหา:** จะส่งต่อข้อมูล (เช่น User ที่ล็อกอิน) ระหว่าง Guard และ Service ใน Request เดียวกันได้อย่างไร?
* **วิธีแก้:** ใช้ **Request-Scoped Providers** ของ NestJS (เช่น AuthContextService) เพื่อเก็บข้อมูล User ปัจจุบันที่ได้จาก AuthGuard และให้ Service อื่น Inject ไปใช้
* **Application-Scoped State (การ Caching):**
* **ปัญหา:** ข้อมูล Master (เช่น roles, permissions, organizations) ถูกเรียกใช้บ่อย
* **วิธีแก้:** ใช้ **Caching** (เช่น @nestjs/cache-manager) เพื่อ Caching ข้อมูลเหล่านี้ และลดภาระ Database
### **การไหลของข้อมูล (Data Flow)**
1. Request: ผ่าน Nginx Proxy Manager -> NestJS Controller
2. Authentication: JWT Guard ตรวจสอบ Token และดึงข้อมูล User
3. Authorization: RBAC Guard (ใช้ CASL) ตรวจสอบสิทธิ์จาก Decorators (@RequirePermission)
4. Validation: Validation Pipe (ใช้ class-validator) ตรวจสอบ DTO
5. Business Logic: Service Layer ประมวลผลตรรกะทางธุรกิจ
6. Data Access: Repository Layer (ใช้ TypeORM) ติดต่อกับฐานข้อมูล MariaDB
7. Response: ส่งกลับไปยัง Frontend พร้อมสถานะและข้อมูลที่เหมาะสม
# **🖥️ ฟรอนต์เอนด์ (NextJS / React / UI) (Frontend (NextJS / React / UI))**
### **โปรไฟล์นักพัฒนา (Developer Profile)**
วิศวกร TypeScript + React/NextJS ระดับ Senior
เชี่ยวชาญ TailwindCSS, Shadcn/UI, และ Radix สำหรับการพัฒนา UI
### **แนวทางการพัฒนาโค้ด (Code Implementation Guidelines)**
* ใช้ **early returns** เพื่อความชัดเจน
* ใช้คลาสของ **TailwindCSS** ในการกำหนดสไตล์เสมอ
* ควรใช้ class: syntax แบบมีเงื่อนไข (หรือ utility clsx) มากกว่าการใช้ ternary operators ใน class strings
* ใช้ **const arrow functions** สำหรับ components และ handlers
* Event handlers ให้ขึ้นต้นด้วย handle... (เช่น handleClick, handleSubmit)
* รวมแอตทริบิวต์สำหรับการเข้าถึง (accessibility) ด้วย:
tabIndex="0", aria-label, onKeyDown, ฯลฯ
* ตรวจสอบให้แน่ใจว่าโค้ดทั้งหมด **สมบูรณ์**, **ผ่านการทดสอบ**, และ **ไม่ซ้ำซ้อน (DRY)**
* ต้อง import โมดูลที่จำเป็นต้องใช้อย่างชัดเจนเสมอ
### **UI/UX ด้วย React**
* ใช้ **semantic HTML**
* ใช้คลาสของ **Tailwind** ที่รองรับ responsive (sm:, md:, lg:)
* รักษาลำดับชั้นของการมองเห็น (visual hierarchy) ด้วยการใช้ typography และ spacing
* ใช้ **Shadcn** components (Button, Input, Card, ฯลฯ) เพื่อ UI ที่สอดคล้องกัน
* ทำให้ components มีขนาดเล็กและมุ่งเน้นการทำงานเฉพาะอย่าง
* ใช้ utility classes สำหรับการจัดสไตล์อย่างรวดเร็ว (spacing, colors, text, ฯลฯ)
* ตรวจสอบให้แน่ใจว่าสอดคล้องกับ **ARIA** และใช้ semantic markup
### **การตรวจสอบฟอร์มและข้อผิดพลาด (Form Validation & Errors)**
* ใช้ไลบรารีฝั่ง client เช่น zod และ react-hook-form
* แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline
* ต้องมี labels, placeholders, และข้อความ feedback
### **🧪 Frontend Testing**
เราจะใช้ **React Testing Library (RTL)** สำหรับการทดสอบ Component และ **Playwright** สำหรับ E2E:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เครื่องมือ:** Vitest + RTL
* **เป้าหมาย:** ทดสอบ Component ขนาดเล็ก (เช่น Buttons, Inputs) หรือ Utility functions
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เครื่องมือ:** RTL + **Mock Service Worker (MSW)**
* **เป้าหมาย:** ทดสอบว่า Component หรือ Page ทำงานกับ API (ที่จำลองขึ้น) ได้ถูกต้อง
* **เทคนิค:** ใช้ MSW เพื่อจำลอง NestJS API และทดสอบว่า Component แสดงผลข้อมูลจำลองได้ถูกต้องหรือไม่ (เช่น ทดสอบหน้า Dashboard [cite: 5.3] ที่ดึงข้อมูลจาก v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เครื่องมือ:** **Playwright**
* **เป้าหมาย:** ทดสอบ User Flow ทั้งระบบโดยอัตโนมัติ (เช่น ล็อกอิน -> สร้าง RFA -> ตรวจสอบ Workflow Visualization [cite: 5.6])
### **🗄️ Frontend State Management**
สำหรับ Next.js App Router เราจะแบ่ง State เป็น 4 ระดับ:
1. **Local UI State (สถานะ UI ชั่วคราว):**
* **เครื่องมือ:** useState, useReducer
* **ใช้เมื่อ:** จัดการสถานะเล็กๆ ที่จบใน Component เดียว (เช่น Modal เปิด/ปิด, ค่าใน Input)
2. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์):**
* **เครื่องมือ:** **React Query (TanStack Query)** หรือ SWR
* **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API (เช่น รายการ correspondences, rfas, drawings)
* **ทำไม:** React Query เป็น "Cache" ที่จัดการ Caching, Re-fetching, และ Invalidation ให้โดยอัตโนมัติ
3. **Global Client State (สถานะส่วนกลางฝั่ง Client):**
* **เครื่องมือ:** **Zustand** (แนะนำ) หรือ Context API
* **ใช้เมื่อ:** จัดการข้อมูลที่ต้องใช้ร่วมกันทั่วทั้งแอป และ *ไม่ใช่* ข้อมูลจากเซิร์ฟเวอร์ (เช่น ข้อมูล User ที่ล็อกอิน, สิทธิ์ Permissions)
4. **Form State (สถานะของฟอร์ม):**
* **เครื่องมือ:** **React Hook Form** + **Zod**
* **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อน (เช่น ฟอร์มสร้าง RFA, ฟอร์ม Circulation [cite: 3.7])
# **🔗 แนวทางการบูรณาการ Full Stack (Full Stack Integration Guidelines)**
| Aspect (แง่มุม) | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
| :---- | :---- | :---- | :---- |
| API | REST / GraphQL Controllers | API hooks ผ่าน fetch/axios/SWR | Components ที่รับข้อมูล |
| Validation (การตรวจสอบ) | class-validator DTOs | zod / react-hook-form | สถานะของฟอร์ม/input ใน Shadcn |
| Auth (การยืนยันตัวตน) | Guards, JWT | NextAuth / cookies | สถานะ UI ของ Auth (loading, signed in) |
| Errors (ข้อผิดพลาด) | Global filters | Toasts / modals | Alerts / ข้อความ feedback |
| Testing (การทดสอบ) | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles (สไตล์) | Scoped modules (ถ้าจำเป็น) | Tailwind / Shadcn | Tailwind utilities |
| Accessibility (การเข้าถึง) | Guards + filters | ARIA attributes | Semantic HTML |
## **🗂️ ข้อตกลงเฉพาะสำหรับ DMS (LCBP3-DMS)**
ส่วนนี้ขยายแนวทาง FullStackJS ทั่วไปสำหรับโปรเจกต์ **LCBP3-DMS** โดยมุ่งเน้นไปที่เวิร์กโฟลว์การอนุมัติเอกสาร (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation)
### **🧩 RBAC และการควบคุมสิทธิ์ (RBAC & Permission Control)**
ใช้ Decorators เพื่อบังคับใช้สิทธิ์การเข้าถึง โดยอ้างอิงสิทธิ์จากตาราง permissions
@RequirePermission('rfas.respond') // ต้องตรงกับ 'permission\code'
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
### **Roles (บทบาท)**
* **Superadmin**: ไม่มีข้อจำกัดใดๆ [cite: 4.3]
* **Admin**: มีสิทธิ์เต็มที่ในองค์กร [cite: 4.3]
* **Document Control**: เพิ่ม/แก้ไข/ลบ เอกสารในองค์กร [cite: 4.3]
* **Editor**: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนด [cite: 4.3]
* **Viewer**: สามารถดู เอกสาร [cite: 4.3]
### **ตัวอย่าง Permissions (จากตาราง permissions)**
* rfas.view, rfas.create, rfas.respond, rfas.delete
* drawings.view, drawings.upload, drawings.delete
* corr.view, corr.manage
* transmittals.manage
* cirs.manage
* project\parties.manage
การจับคู่ระหว่าง roles และ permissions **เริ่มต้น** จะถูก seed ผ่านสคริปต์ (ดังที่เห็นในไฟล์ SQL)**อย่างไรก็ตาม AuthModule/UserModule ต้องมี API สำหรับ Admin เพื่อสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลัง** [cite: 4.3]
## **🧾 มาตรฐาน AuditLog (AuditLog Standard)**
บันทึกการดำเนินการ CRUD และการจับคู่ทั้งหมดลงในตาราง audit_logs
| Field (ฟิลด์) | Type (จาก SQL) | Description (คำอธิบาย) |
| :---- | :---- | :---- |
| audit_id | BIGINT | Primary Key |
| user_id | INT | ผู้ใช้ที่ดำเนินการ (FK -> users) |
| action | VARCHAR(100) | rfa.create, correspondence.update, login.success |
| entity_type | VARCHAR(50) | ชื่อตาราง/โมดูล เช่น 'rfa', 'correspondence' |
| entity_id | VARCHAR(50) | Primary ID ของระเบียนที่ได้รับผลกระทบ |
| details_json | JSON | ข้อมูลบริบท (เช่น ฟิลด์ที่มีการเปลี่ยนแปลง) |
| ip_address | VARCHAR(45) | IP address ของผู้ดำเนินการ |
| user_agent | VARCHAR(255) | User Agent ของผู้ดำเนินการ |
| created_at | TIMESTAMP | Timestamp (UTC) |
## **📂 การจัดการไฟล์ (File Handling) (ปรับปรุงใหม่)**
### **มาตรฐานการอัปโหลดไฟล์ (File Upload Standard)**
* **ตรรกะใหม่:** การอัปโหลดไฟล์ทั้งหมดจะถูกจัดการโดย FileStorageService และบันทึกข้อมูลไฟล์ลงในตาราง attachments (ตารางกลาง)
* ไฟล์จะถูกเชื่อมโยงไปยัง Entity ที่ถูกต้องผ่าน **ตารางเชื่อม (Junction Tables)** เท่านั้น:
* correspondence_attachments (เชื่อม Correspondence กับ Attachments)
* circulation_attachments (เชื่อม Circulation กับ Attachments)
* shop_drawing_revision_attachments (เชื่อม Shop Drawing Revision กับ Attachments)
* contract_drawing_attachments (เชื่อม Contract Drawing กับ Attachments)
* เส้นทางจัดเก็บไฟล์ (Upload path): อ้างอิงจาก Requirement 2.1 คือ /share/dms-data [cite: 2.1] โดย FileStorageService จะสร้างโฟลเดอร์ย่อยแบบรวมศูนย์ (เช่น /share/dms-data/uploads/{YYYY}/{MM}/[stored\filename])
* ประเภทไฟล์ที่อนุญาต: pdf, dwg, docx, xlsx, zip
* ขนาดสูงสุด: **50 MB**
* จัดเก็บนอก webroot
* ให้บริการไฟล์ผ่าน endpoint ที่ปลอดภัย /files/:attachment_id/download
### **การควบคุมการเข้าถึง (Access Control)**
การเข้าถึงไฟล์ไม่ใช่การเข้าถึงโดยตรง endpoint /files/:attachment_id/download จะต้อง:
1. ค้นหาระเบียน attachment
2. ตรวจสอบว่า attachment_id นี้ เชื่อมโยงกับ Entity ใด (เช่น correspondence, circulation, shop_drawing_revision, contract_drawing) ผ่านตารางเชื่อม
3. ตรวจสอบว่าผู้ใช้มีสิทธิ์ (permission) ในการดู Entity ต้นทางนั้นๆ หรือไม่
## **🔟 การจัดการเลขที่เอกสาร (Document Numbering) [cite: 3.10]**
* **เป้าหมาย:** สร้างเลขที่เอกสาร (เช่น correspondence\number) โดยอัตโนมัติ ตามรูปแบบที่กำหนด
* **ตรรกะการนับ:** การนับ Running number (SEQ) จะนับแยกตาม Key: **Project + Originator Organization + Document Type + Year**
* **ตาราง SQL:**
* document_number_formats: Admin ใช้กำหนด "รูปแบบ" (Template) ของเลขที่ (เช่น {ORG\CODE}-{TYPE\CODE}-{YEAR\SHORT}-{SEQ:4}) โดยกำหนดตาม **Project** และ **Document Type** [cite: 4.5]
* document_number_counters: ระบบใช้เก็บ "ตัวนับ" ล่าสุดของ Key (Project+Org+Type+Year)
* **การทำงาน (Backend):**
* DocumentNumberingModule จะให้บริการ DocumentNumberingService
* เมื่อ CorrespondenceModule ต้องการสร้างเอกสารใหม่, มันจะเรียก documentNumberingService.generateNextNumber(...)
* Service นี้จะเรียกใช้ Stored Procedure **sp_get_next_document_number** [cite: 2.9.3] ซึ่ง Procedure นี้จะจัดการ Database Transaction และ Row Lock (FOR UPDATE) ภายใน DB เพื่อรับประกันการป้องกัน Race Condition
## **📊 การรายงานและการส่งออก (Reporting & Exports)**
### **วิวสำหรับการรายงาน (Reporting Views) (จาก SQL)**
การรายงานควรสร้างขึ้นจาก Views ที่กำหนดไว้ล่วงหน้าในฐานข้อมูลเป็นหลัก:
* v_current_correspondences: สำหรับ revision ปัจจุบันทั้งหมดของเอกสารที่ไม่ใช่ RFA
* v_current_rfas: สำหรับ revision ปัจจุบันทั้งหมดของ RFA และข้อมูล master
* v_contract_parties_all: สำหรับการตรวจสอบความสัมพันธ์ของ project/contract/organization
* v_user_tasks: สำหรับ Dashboard "งานของฉัน"
* v_audit_log_details: สำหรับ Activity Feed
Views เหล่านี้ทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการรายงานฝั่งเซิร์ฟเวอร์และการส่งออกข้อมูล
### **กฎการส่งออก (Export Rules)**
* Export formats: CSV, Excel, PDF.
* จัดเตรียมมุมมองสำหรับพิมพ์ (Print view).
* รวมลิงก์ไปยังต้นทาง (เช่น /rfas/:id).
## **🧮 ฟรอนต์เอนด์: รูปแบบ DataTable และฟอร์ม (Frontend: DataTable & Form Patterns)**
### **DataTable (ServerSide)**
* Endpoint: /api/{module}?page=1\&pageSize=20\&sort=...\&filter=...
* ต้องรองรับ: การแบ่งหน้า (pagination), การเรียงลำดับ (sorting), การค้นหา (search), การกรอง (filters)
* แสดง revision ล่าสุดแบบ inline เสมอ (สำหรับ RFA/Drawing)
### **มาตรฐานฟอร์ม (Form Standards)**
* ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ):
* Project → Contract Drawing Volumes
* Contract Drawing Category → Sub-Category
* RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้
* **(ใหม่)** การอัปโหลดไฟล์: ต้องรองรับ **Multi-file upload (Drag-and-Drop)** [cite: 5.7]
* **(ใหม่)** UI ต้องอนุญาตให้ผู้ใช้กำหนดว่าไฟล์ใดเป็น **"เอกสารหลัก"** หรือ "เอกสารแนบประกอบ" [cite: 5.7]
* ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast
### **ข้อกำหนด Component เฉพาะ (Specific UI Requirements)**
* **Dashboard \- My Tasks:** ต้องพัฒนา Component ตาราง "งานของฉัน" (My Tasks)ซึ่งดึงข้อมูลงานที่ผู้ใช้ล็อกอินอยู่ต้องรับผิดชอบ (Main/Action) จาก v\user\tasks [cite: 5.3]
* **Workflow Visualization:** ต้องพัฒนา Component สำหรับแสดงผล Workflow (โดยเฉพาะ RFA)ที่แสดงขั้นตอนทั้งหมดเป็นลำดับ โดยขั้นตอนปัจจุบัน (active) เท่านั้นที่ดำเนินการได้ และขั้นตอนอื่นเป็น disabled [cite: 5.6] ต้องมีตรรกะสำหรับ Admin ในการ override หรือย้อนกลับขั้นตอนได้ [cite: 5.6]
* ** Admin Panel:** ต้องมีหน้า UI สำหรับ Superadmin/Admin เพื่อจัดการข้อมูลหลัก (Master Data [cite: 4.5]), การเริ่มต้นใช้งาน (Onboarding [cite: 4.6]), และ **รูปแบบเลขที่เอกสาร (Numbering Formats [cite: 3.10])**
## **🧭 แดชบอร์ดและฟีดกิจกรรม (Dashboard & Activity Feed)**
### **การ์ดบนแดชบอร์ด (Dashboard Cards)**
* แสดง Correspondences, RFAs, Circulations, Shop Drawing Revision ล่าสุด
* รวมสรุป KPI (เช่น "RFAs ที่รอการอนุมัติ", "Shop Drawing ที่รอการอนุมัติ") [cite: 5.3]
* รวมลิงก์ด่วนไปยังโมดูลต่างๆ
### **ฟีดกิจกรรม (Activity Feed)**
* แสดงรายการ v\audit\log\details ล่าสุด (10 รายการ) ที่เกี่ยวข้องกับผู้ใช้
// ตัวอย่าง API response
[
{ user: 'editor01', action: 'Updated RFA (LCBP3-RFA-001)', time: '2025-11-04T09:30Z' }
]
## **🛡️ ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
ส่วนนี้สรุปข้อกำหนด Non-Functional จาก requirements.md เพื่อให้ทีมพัฒนาทราบ
* **Audit Log [cite: 6.1]:** ทุกการกระทำที่สำคัญ (C/U/D) ต้องถูกบันทึกใน audit_logs
* **Performance [cite: 6.4]:** ต้องใช้ Caching สำหรับข้อมูลที่เรียกบ่อย และใช้ Pagination
* **Security [cite: 6.5]:** ต้องมี Rate Limiting และจัดการ Secret ผ่าน docker-compose.yml (ไม่ใช่ .env)
* **(ใหม่) Backup & Recovery [cite: 6.6]:** ต้องมีแผนสำรองข้อมูลทั้ง Database (MariaDB) และ File Storage (/share/dms-data) อย่างน้อยวันละ 1 ครั้ง
* **(ใหม่) Notification Strategy [cite: 6.7]:** ระบบแจ้งเตือน (Email/Line) ต้องถูก Trigger เมื่อมีเอกสารใหม่ส่งถึง, มีการมอบหมายงานใหม่ (Circulation), หรือ (ทางเลือก) เมื่องานเสร็จ/ใกล้ถึงกำหนด
## **✅ มาตรฐานที่นำไปใช้แล้ว (จาก SQL v1.1.0) (Implemented Standards (from SQL v1.1.0))**
ส่วนนี้ยืนยันว่าแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เป็นส่วนหนึ่งของการออกแบบฐานข้อมูลอยู่แล้ว และควรถูกนำไปใช้ประโยชน์ ไม่ใช่สร้างขึ้นใหม่
***Soft Delete:** นำไปใช้แล้วผ่านคอลัมน์ deleted_at ในตารางสำคัญ (เช่น correspondences, rfas, project_parties) ตรรกะการดึงข้อมูลต้องกรอง deleted_at IS NULL
***Database Indexes:** สคีมาได้มีการทำ index ไว้อย่างหนักหน่วงบน foreign keys และคอลัมน์ที่ใช้ค้นหาบ่อย (เช่น idx_rr_rfa, idx_cor_project, idx_cr_is_current) เพื่อประสิทธิภาพ
***โครงสร้าง RBAC:** มีระบบ users, roles, permissions, user_roles, และ user_project_roles ที่ครอบคลุมอยู่แล้ว
***Data Seeding:** ข้อมูล Master (roles, permissions, organization_roles, initial users, project parties) ถูกรวมอยู่ในสคริปต์สคีมาแล้ว
## **🧩 การปรับปรุงที่แนะนำ (สำหรับอนาคต) (Recommended Enhancements (Future))**
* ✅ สร้าง Background job (โดยใช้ **n8n** เพื่อเชื่อมต่อกับ **Line** [cite: 2.7] และ/หรือใช้สำหรับการแจ้งเตือน RFA ที่ใกล้ถึงกำหนด due_date [cite: 6.7])
* ✅ เพิ่ม job ล้างข้อมูลเป็นระยะสำหรับ attachments ที่ไม่ถูกเชื่อมโยงกับ Entity ใดๆ เลย (ไฟล์กำพร้า)

View File

@@ -0,0 +1,245 @@
# **📝 Documents Management Sytem Version 1.4.0: Application Requirements Specification**
## **📌 1. วัตถุประสงค์**
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System)ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
- มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
- ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
- เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
## **🛠️ 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)**
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
- **2.1. Infrastructure & Environment:**
- Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
- Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
- Development Environment: VS Code on Windows 11
- Domain: np-dms.work, www.np-dms.work
- ip: 159.192.126.103
- Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
- Data Storage: /share/dms-data บน QNAP
- ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
- **2.2. Code Hosting:**
- Application name: git
- Service: Gitea (Self-hosted on QNAP)
- Service name: gitea
- Domain: git.np-dms.work
- หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
- **2.3. Backend / Data Platform:**
- Application name: lcbp3-backend
- Service: NestJS
- Service name: backend
- Domain: backend.np-dms.work
- Framework: NestJS (Node.js, TypeScript, ESM)
- หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
- **2.4. Database:**
- Application name: lcbp3-db
- Service: mariadb:10.11
- Service name: mariadb
- Domain: db.np-dms.work
- หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
- Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
- **2.5. Database management:**
- Application name: lcbp3-db
- Service: phpmyadmin:5-apache
- Service name: pma
- Domain: pma.np-dms.work
- หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
- **2.6. Frontend:**
- Application name: lcbp3-frontend
- Service: next.js
- Service name: frontend
- Domain: lcbp3.np-dms.work
- Framework: Next.js (App Router, React, TypeScript, ESM)
- Styling: Tailwind CSS + PostCSS
- Component Library: shadcn/ui
- หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
- **2.7. Workflow automation:**
- Application name: lcbp3-n8n
- Service: n8nio/n8n:latest
- Service name: n8n
- Domain: n8n.np-dms.work
- หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
- **2.8. Reverse Proxy:**
- Application name: lcbp3-npm
- Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
- Service name: npm
- Domain: npm.np-dms.work
- หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
- **2.9. การจัดการตรรกะทางธุรกิจ (Business Logic Implementation):**
- 2.9.1. ตรรกะทางธุรกิจที่ซับซ้อนทั้งหมด (เช่น การเปลี่ยนสถานะ Workflow [cite: 3.5.4, 3.6.5], การบังคับใช้สิทธิ์ [cite: 4.4], การตรวจสอบ Deadline [cite: 3.2.5]) **จะถูกจัดการในฝั่ง Backend (NestJS)** [cite: 2.3] เพื่อให้สามารถบำรุงรักษาและทดสอบได้ง่าย (Testability)
- 2.9.2. **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก
- 2.9.3. **ข้อยกเว้น:** ตรรกะเดียวที่จะอยู่ในฐานข้อมูลคือ **Stored Procedure** สำหรับการสร้างเลขที่เอกสาร (Document Numbering) [cite: 3.10] เพื่อป้องกันการซ้ำซ้อนของข้อมูล (Race Condition)
## **📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)**
- **3.1. การจัดการโครงสร้างโครงการและองค์กร**
- 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
- 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
- 3.1.3. องค์กร (Organizations):
- มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
- Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
- **3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)**
- 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects), รองรับ To (ผู้รับหลัก) และ CC (ผู้รับสำเนา) หลายองค์กร
- 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
- 3.2.3. การสร้างเอกสาร (Correspondence):
- ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
- เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
- 3.2.4. การอ้างอิงและจัดกลุ่ม:
- เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
- สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
- 3.2.5. Routings : ต้องรองรับกระบวนการส่งต่อเอกสาร (Routing) ตามลำดับ เช่น
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Wouting ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
- 3.2.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่เป็นผู้รับได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
- **3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)**
- 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
- 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
- **3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)**
- 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
- 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
- **3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)**
- 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
- 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
- Request for Drawing Approval (RFA_DWG)
- Request for Document Approval (RFA_DOC)
- Request for Method statement Approval (RFA_MES)
- Request for Material Approval (RFA_MAT)
- 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.5.4. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA_DWG):
- เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
- Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
- ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
- 3.6.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
- 3.6.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
- **3.6.การจัดการเอกสารนำส่ง (Transmittals)**
- 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
- 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
- **3.7. ใบเวียนเอกสาร (Circulation Sheet)**
- 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
- 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
- 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
- ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
- ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
- ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
- 3.7.5. การติดตามงาน:
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
- มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
- สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
- **3.8. ประวัติการแก้ไข (Revisions):** ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
- **3.9. การจัดเก็บ: (ปรับปรุงตามสถาปัตยกรรมใหม่)**
- เอกสารและไฟล์แนบทั้งหมดจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) [cite: 2.1]
- ข้อมูล Metadata ของไฟล์ (เช่น ชื่อไฟล์, ขนาด, path) จะถูกเก็บในตาราง attachments (ตารางกลาง)
- ไฟล์จะถูกเชื่อมโยงกับเอกสารประเภทต่างๆ ผ่านตารางเชื่อม (Junction tables) เช่น correspondence_attachments, circulation_attachments, shop_drawing_revision_attachments ,และ contracy_drawing_attachments
- สถาปัตยกรรมแบบรวมศูนย์นี้ _แทนที่_ แนวคิดเดิมที่จะแยกโฟลเดอร์ตามประเภทเอกสาร เพื่อรองรับการขยายระบบที่ดีกว่า
- **3.10. การจัดการเลขที่เอกสาร (Document Numbering):**
- 3.10.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (เช่น correspondence_number) ได้โดยอัตโนมัติ
- 3.10.2. การนับเลข Running Number (SEQ) จะต้องนับแยกตาม Key ดังนี้: **โครงการ (Project)**, **องค์กรผู้ส่ง (Originator Organization)**, **ประเภทเอกสาร (Document Type)** และ **ปีปัจจุบัน (Year)**
- 3.10.3. ผู้ดูแลระบบ (Admin) ต้องสามารถกำหนด "รูปแบบ" (Format Template) ของเลขที่เอกสารได้ (เช่น {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}) โดยกำหนดแยกตามโครงการและประเภทเอกสาร
## **🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)**
- **4.1. ภาพรวม:** ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
- **4.2. ลำดับชั้นของสิทธิ์ (Permission Hierarchy)**
- Global: สิทธิ์สูงสุดของระบบ
- Organization: สิทธิ์ภายในองค์กร เป็นสิทธิ์พื้นฐานของผู้ใช้
- Project: สิทธิ์เฉพาะในโครงการ จะถูกพิจารณาเมื่อผู้ใช้อยู่ในโครงการนั้น
- Contract: สิทธิ์เฉพาะในสัญญา จะถูกพิจารณาเมื่อผู้ใช้อยู่ในสัญญานั้น (สัญญาเป็นส่วนหนึ่งของโครงการ)
กฎการบังคับใช้: เมื่อตรวจสอบสิทธิ์ ระบบจะพิจารณาสิทธิ์จากทุกระดับที่ผู้ใช้มี และใช้ สิทธิ์ที่มากที่สุด (Most Permissive) เป็นตัวตัดสิน
ตัวอย่าง: ผู้ใช้ A เป็น Viewer ในองค์กร แต่ถูกมอบหมายเป็น Editor ในโครงการ X เมื่ออยู่ในโครงการ X ผู้ใช้ A จะมีสิทธิ์แก้ไขได้
- **4.3. การกำหนดบทบาท (Roles) และขอบเขต (Scope)**
| บทบาท (Role) | ขอบเขต (Scope) | คำอธิบาย | สิทธิ์หลัก (Key Permissions) |
| :------------------- | :------------- | :---------------------- | :------------------------------------------------------------------------------------- |
| **Superadmin** | Global | ผู้ดูแลระบบสูงสุด | ทำทุกอย่างในระบบ, จัดการองค์กร, จัดการข้อมูลหลักระดับ Global |
| **Org Admin** | Organization | ผู้ดูแลองค์กร | จัดการผู้ใช้ในองค์กร, จัดการบทบาท/สิทธิ์ภายในองค์กร, ดูรายงานขององค์กร |
| **Document Control** | Organization | ควบคุมเอกสารขององค์กร | เพิ่ม/แก้ไข/ลบเอกสาร, กำหนดสิทธิ์เอกสารภายในองค์กร |
| **Editor** | Organization | ผู้แก้ไขเอกสารขององค์กร | เพิ่ม/แก้ไขเอกสารที่ได้รับมอบหมาย |
| **Viewer** | Organization | ผู้ดูเอกสารขององค์กร | ดูเอกสารที่มีสิทธิ์เข้าถึง |
| **Project Manager** | Project | ผู้จัดการโครงการ | จัดการสมาชิกในโครงการ (เพิ่ม/ลบ/มอบบทบาท), สร้าง/จัดการสัญญาในโครงการ, ดูรายงานโครงการ |
| **Contract Admin** | Contract | ผู้ดูแลสัญญา | จัดการสมาชิกในสัญญา, สร้าง/จัดการข้อมูลหลักเฉพาะสัญญา (ถ้ามี), อนุมัติเอกสารในสัญญา |
- **4.4. กระบวนการเริ่มต้นใช้งาน (Onboarding Workflow) ที่สมบูรณ์**
- 4.1. **สร้างองค์กร (Organization)**
- **Superadmin** สร้างองค์กรใหม่ (เช่น บริษัท A)
- **Superadmin** แต่งตั้งผู้ใช้อย่างน้อย 1 คนให้เป็น **Org Admin** หรือ **Document Control** ของบริษัท A
- 4.2. **เพิ่มผู้ใช้ในองค์กร**
- **Org Admin** ของบริษัท A เพิ่มผู้ใช้อื่นๆ (Editor, Viewer) เข้ามาในองค์กรของตน
- 4.3. **มอบหมายผู้ใช้ให้กับโครงการ (Project)**
- **Project Manager** ของโครงการ X (ซึ่งอาจมาจากบริษัท A หรือบริษัทอื่น) ทำการ "เชิญ" หรือ "มอบหมาย" ผู้ใช้จากองค์กรต่างๆ ที่เกี่ยวข้องเข้ามาในโครงการ X
- ในขั้นตอนนี้ **Project Manager** จะกำหนด **บทบาทระดับโครงการ** (เช่น Project Member, หรืออาจไม่มีบทบาทพิเศษ ให้ใช้สิทธิ์จากระดับองค์กรไปก่อน)
- 4.4. **เมอบหมายผู้ใช้ให้กับสัญญา (Contract)**
- **Contract Admin** ของสัญญา Y (ซึ่งเป็นส่วนหนึ่งของโครงการ X) ทำการเลือกผู้ใช้ที่อยู่ในโครงการ X แล้ว มอบหมายให้เข้ามาในสัญญา Y
- ในขั้นตอนนี้ **Contract Admin** จะกำหนด **บทบาทระดับสัญญา** (เช่น Contract Member) และสิทธิ์เฉพาะที่จำเป็น
- **4.5. การจัดการข้อมูลหลัก (Master Data Management) ที่แบ่งตามระดับ**
| ข้อมูลหลัก | ผู้มีสิทธิ์จัดการ | ระดับ |
| :---------------------------------- | :------------------------------ | :--------------------------------- |
| ประเภทเอกสาร (Correspondence, RFA) | **Superadmin** | Global |
| สถานะเอกสาร (Draft, Approved, etc.) | **Superadmin** | Global |
| หมวดหมู่แบบ (Shop Drawing) | **Project Manager** | Project (สร้างใหม่ได้ภายในโครงการ) |
| Tags | **Org Admin / Project Manager** | Organization / Project |
| บทบาทและสิทธิ์ (Custom Roles) | **Superadmin / Org Admin** | Global / Organization |
## **👥 5. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)**
- **5.1. Layout หลัก:** หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Document Control/เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
- **5.2. หน้า Landing Page:** เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
- **5.3. หน้า Dashboard:** เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
- **5.4. การติดตามสถานะ:** องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
- **5.5. การจัดการข้อมูลส่วนตัว (Profile Page):** ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
- **5.6. การจัดการเอกสารทางเทคนิค (RFA & Workflow):** ผู้ใช้สามารถดู RFA ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป
- **5.7. การจัดการใบเวียนเอกสาร (Circulation):** ผู้ใช้สามารถดู Circulation ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว,ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป
- **5.8. การจัดการเอกสารนำส่ง (Transmittals):** ผู้ใช้สามารถดู Transmittals ในรูปแบบรายการทั้งหมดได้ในหน้าเดียว
- **5.9. ข้อกำหนด UI/UX การแนบไฟล์ (File Attachment UX):**
- ระบบต้องรองรับการอัปโหลดไฟล์หลายไฟล์พร้อมกัน (Multi-file upload) เช่น การลากและวาง (Drag-and-Drop)
- ในหน้าอัปโหลด (เช่น สร้าง RFA หรือ Correspondence) ผู้ใช้ต้องสามารถกำหนดได้ว่าไฟล์ใดเป็น "เอกสารหลัก" (Main Document เช่น PDF) และไฟล์ใดเป็น "เอกสารแนบประกอบ" (Supporting Attachments เช่น .dwg, .docx, .zip)
## **6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
- **6.1. การบันทึกการกระทำ (Audit Log):** ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
- **6.2. การค้นหา (Search):** ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
- **6.3. การทำรายงาน (Reporting):** สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
- **6.4. ประสิทธิภาพ (Performance):** มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
- **6.5. ความปลอดภัย (Security):**
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
- **6.6. การสำรองข้อมูลและการกู้คืน (Backup & Recovery):**
- ระบบจะต้องมีกลไกการสำรองข้อมูลอัตโนมัติสำหรับฐานข้อมูล MariaDB [cite: 2.4] และไฟล์เอกสารทั้งหมดใน /share/dms-data [cite: 2.1] (เช่น ใช้ HBS 3 ของ QNAP หรือสคริปต์สำรองข้อมูล) อย่างน้อยวันละ 1 ครั้ง
- ต้องมีแผนการกู้คืนระบบ (Disaster Recovery Plan) ในกรณีที่ Server หลัก (QNAP) ใช้งานไม่ได้
- **6.7. กลยุทธ์การแจ้งเตือน (Notification Strategy):**
- ระบบจะส่งการแจ้งเตือน (ผ่าน Email หรือ Line [cite: 2.7]) เมื่อมีการกระทำที่สำคัญ ดังนี้:
1. เมื่อมีเอกสารใหม่ (Correspondence, RFA) ถูกส่งมาถึงองค์กรณ์ของเรา
2. เมื่อมีใบเวียน (Circulation) ใหม่ มอบหมายงานมาที่เรา
3. (ทางเลือก) เมื่อเอกสารที่เราส่งไป ถูกดำเนินการ (เช่น อนุมัติ/ปฏิเสธ)
4. (ทางเลือก) เมื่อใกล้ถึงวันครบกำหนด (Deadline) [cite: 3.2.5, 3.6.6, 3.7.5]

45
docs/LCBP3C2.ovpn Normal file
View File

@@ -0,0 +1,45 @@
## How to setup OpenVPN client?
## 1. Install OpenVPN software on your platform.
## 2. Double click LCBP3C2.ovpn file to create new connection profile.
## 3. Type username and password while connection.
client
dev tun
script-security 3
remote 159.192.126.103 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass
remote-cert-tls server
reneg-sec 0
cipher AES-128-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
comp-lzo
proto udp
explicit-exit-notify 1
<ca>
-----BEGIN CERTIFICATE-----
MIID2zCCA0SgAwIBAgIUBaWIp2IXBo22znekNT/ua2FyXuYwDQYJKoZIhvcNAQEL
BQAwgZ4xCzAJBgNVBAYTAlRXMQ8wDQYDVQQIEwZUYWl3YW4xDzANBgNVBAcTBlRh
aXBlaTEaMBgGA1UEChMRUU5BUCBTeXN0ZW1zIEluYy4xDDAKBgNVBAsTA05BUzEW
MBQGA1UEAxMNVFMgU2VyaWVzIE5BUzEMMAoGA1UEKRMDTkFTMR0wGwYJKoZIhvcN
AQkBFg5hZG1pbkBxbmFwLmNvbTAeFw0yNTEwMjIxNzAyNDFaFw0zNTEwMjAxNzAy
NDFaMIGeMQswCQYDVQQGEwJUVzEPMA0GA1UECBMGVGFpd2FuMQ8wDQYDVQQHEwZU
YWlwZWkxGjAYBgNVBAoTEVFOQVAgU3lzdGVtcyBJbmMuMQwwCgYDVQQLEwNOQVMx
FjAUBgNVBAMTDVRTIFNlcmllcyBOQVMxDDAKBgNVBCkTA05BUzEdMBsGCSqGSIb3
DQEJARYOYWRtaW5AcW5hcC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALBqU2XV3yBuKLKVUHom4IoKxUUAkUZ2BNuPFUhRP8lDFVVaYq0MfNZD1DkblCSu
YDeuaWERz2/M4XJ45mEyuSiUy74dHCYMp+JzeRnBnT0d8jXwjBAGXBTGhzgm5F28
bgXgJKfXAd41xjxWtgQbFHgY6sctoHgKbmnzrEZR7QypAgMBAAGjggESMIIBDjAd
BgNVHQ4EFgQUGgFl+Hy1Ry4AMr2ZuFXVJen0GPgwgd4GA1UdIwSB1jCB04AUGgFl
+Hy1Ry4AMr2ZuFXVJen0GPihgaSkgaEwgZ4xCzAJBgNVBAYTAlRXMQ8wDQYDVQQI
EwZUYWl3YW4xDzANBgNVBAcTBlRhaXBlaTEaMBgGA1UEChMRUU5BUCBTeXN0ZW1z
IEluYy4xDDAKBgNVBAsTA05BUzEWMBQGA1UEAxMNVFMgU2VyaWVzIE5BUzEMMAoG
A1UEKRMDTkFTMR0wGwYJKoZIhvcNAQkBFg5hZG1pbkBxbmFwLmNvbYIUBaWIp2IX
Bo22znekNT/ua2FyXuYwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOBgQBs
2+aU5QbKV9Is2MPLZLINaSPUs5ZFndiMYVzd4WsoEvZebpAOk07RiopIVANdsw/Q
gs9ZDRzaCTFFxFBM4YOgl6RHo2GfqSDze1GHkrqPKH2u7Sqd6xk+bge2L0eN5F7d
yMIK4go4ydLAqXZWom6ASEtz8zBXS+tMnCH+SULeLg==
-----END CERTIFICATE-----
</ca>

View File

@@ -0,0 +1,192 @@
# FullStackJS Development Guidelines
## 🧠 General Philosophy
Unified best practices for **NestJS Backend**, **NextJS Frontend**, and **Bootstrap-based UI/UX** development in TypeScript environments.
Focus on **clarity**, **maintainability**, **consistency**, and **accessibility** across the entire stack.
---
## ⚙️ TypeScript General Guidelines
### Basic Principles
- Use **English** for all code and documentation.
- Explicitly type all variables, parameters, and return values.
- Avoid `any`; create custom types or interfaces.
- Use **JSDoc** for public classes and methods.
- Export only **one main symbol** per file.
- Avoid blank lines within functions.
### Naming Conventions
| Entity | Convention | Example |
|:--|:--|:--|
| Classes | PascalCase | `UserService` |
| Variables & Functions | camelCase | `getUserInfo` |
| Files & Folders | kebab-case | `user-service.ts` |
| Environment Variables | UPPERCASE | `DATABASE_URL` |
| Booleans | Verb + Noun | `isActive`, `canDelete`, `hasPermission` |
Use full words — no abbreviations — except for standard ones (`API`, `URL`, `req`, `res`, `err`, `ctx`).
---
## 🧩 Functions
- Write short, single-purpose functions (<20 lines).
- Use **early returns** to reduce nesting.
- Use **map**, **filter**, **reduce** instead of loops when suitable.
- Prefer **arrow functions** for short logic, **named functions** otherwise.
- Use **default parameters** over null checks.
- Group multiple parameters into a single object (RO-RO pattern).
- Return typed objects, not primitives.
- Maintain a single abstraction level per function.
---
## 🧱 Data Handling
- Encapsulate data in composite types.
- Use **immutability** with `readonly` and `as const`.
- Perform validations in classes or DTOs, not within business functions.
- Always validate data using typed DTOs.
---
## 🧰 Classes
- Follow **SOLID** principles.
- Prefer **composition over inheritance**.
- Define **interfaces** for contracts.
- Keep classes focused and small (<200 lines, <10 methods, <10 properties).
---
## 🚨 Error Handling
- Use exceptions for unexpected errors.
- Catch only to fix or add context; otherwise, use global error handlers.
- Always provide meaningful error messages.
---
## 🧪 Testing (General)
- Use the **ArrangeActAssert** pattern.
- Use descriptive test variable names (`inputData`, `expectedOutput`).
- Write **unit tests** for all public methods.
- Mock external dependencies.
- Add **acceptance tests** per module using GivenWhenThen.
---
# 🏗️ Backend (NestJS)
### Principles
- **Modular architecture**:
- One module per domain.
- Controller → Service → Model structure.
- DTOs validated with **class-validator**.
- Use **MikroORM** or equivalent for persistence.
- Encapsulate reusable code in a **common module** (`@app/common`):
- Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators.
### Core Functionalities
- Global **filters** for exception handling.
- **Middlewares** for request handling.
- **Guards** for permissions and RBAC.
- **Interceptors** for response transformation and logging.
### Testing
- Use **Jest** for testing.
- Test each controller and service.
- Add `admin/test` endpoint as a smoke test.
---
# 🖥️ Frontend (NextJS / React)
### Developer Profile
Senior-level TypeScript + React/NextJS engineer.
Expert in **TailwindCSS**, **Shadcn/UI**, and **Radix** for UI development.
### Code Implementation Guidelines
- Use **early returns** for clarity.
- Always style with **TailwindCSS** classes.
- Prefer `class:` conditional syntax over ternary operators.
- Use **const arrow functions** for components and handlers.
- Event handlers start with `handle...` (e.g., `handleClick`, `handleSubmit`).
- Include accessibility attributes:
`tabIndex="0"`, `aria-label`, `onKeyDown`, etc.
- Ensure all code is **complete**, **tested**, and **DRY**.
- Always import required modules explicitly.
### UI/UX with React
- Use **semantic HTML**.
- Apply **responsive Tailwind** classes.
- Maintain visual hierarchy with typography and spacing.
- Use **Shadcn** components for consistent UI.
- Keep components small and focused.
---
# 🎨 UI/UX (Bootstrap Integration)
### Key Principles
- Use **Bootstrap 5+** for responsive design and consistent UI.
- Focus on **maintainability**, **readability**, and **accessibility**.
- Use clear and descriptive class names.
### Bootstrap Usage
- Structure layout with **container**, **row**, **col**.
- Use built-in **components** (buttons, modals, alerts, etc.) instead of custom CSS.
- Apply **utility classes** for quick styling (spacing, colors, text, etc.).
- Ensure **ARIA compliance** and semantic markup.
### Form Validation & Errors
- Use Bootstraps built-in validation states.
- Show errors with **alert components**.
- Include labels, placeholders, and feedback messages.
### Dependencies
- Bootstrap (latest CSS + JS)
- Optionally jQuery (for legacy interactive components)
### Bootstrap-Specific Guidelines
- Customize Bootstrap via **Sass variables** and **mixins**.
- Use responsive visibility utilities.
- Avoid overriding Bootstrap; extend it.
- Follow official documentation for examples.
### Performance Optimization
- Include only necessary Bootstrap modules.
- Use CDN for assets and caching.
- Optimize images and assets for mobile.
### Key Conventions
1. Follow Bootstraps naming and structure.
2. Prioritize **responsiveness** and **accessibility**.
3. Keep the file structure organized and modular.
---
# 🔗 Full Stack Integration Guidelines
| Aspect | Backend (NestJS) | Frontend (NextJS) | UI Layer (Bootstrap/Tailwind) |
|:--|:--|:--|:--|
| API | REST / GraphQL Controllers | API hooks via fetch/axios | Components consuming data |
| Validation | `class-validator` DTOs | `zod` / form-level validation | Bootstrap validation feedback |
| Auth | Guards, JWT | NextAuth / cookies | Auth UI states |
| Errors | Global filters | Toasts / modals | Alerts / feedback |
| Testing | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles | Scoped modules | Tailwind / Shadcn | Bootstrap utilities |
| Accessibility | Guards + filters | ARIA attributes | Semantic HTML |
---
# ✅ Final Notes
- Use a **shared types package** (`@types/shared`) for consistent interfaces.
- Document your modules and APIs.
- Run lint, type-check, and tests before commit.
- Use **Prettier + ESLint** for consistent formatting.
- Prefer **clarity over cleverness** — readable code wins.

View File

@@ -0,0 +1,364 @@
# FullStackJS Development Guidelines
## 🧠 General Philosophy
Unified best practices for **NestJS Backend**, **NextJS Frontend**, and **Bootstrap-based UI/UX** development in TypeScript environments.
Focus on **clarity**, **maintainability**, **consistency**, and **accessibility** across the entire stack.
---
## ⚙️ TypeScript General Guidelines
### Basic Principles
- Use **English** for all code and documentation.
- Explicitly type all variables, parameters, and return values.
- Avoid `any`; create custom types or interfaces.
- Use **JSDoc** for public classes and methods.
- Export only **one main symbol** per file.
- Avoid blank lines within functions.
### Naming Conventions
| Entity | Convention | Example |
|:--|:--|:--|
| Classes | PascalCase | `UserService` |
| Variables & Functions | camelCase | `getUserInfo` |
| Files & Folders | kebab-case | `user-service.ts` |
| Environment Variables | UPPERCASE | `DATABASE_URL` |
| Booleans | Verb + Noun | `isActive`, `canDelete`, `hasPermission` |
Use full words — no abbreviations — except for standard ones (`API`, `URL`, `req`, `res`, `err`, `ctx`).
---
## 🧩 Functions
- Write short, single-purpose functions (<20 lines).
- Use **early returns** to reduce nesting.
- Use **map**, **filter**, **reduce** instead of loops when suitable.
- Prefer **arrow functions** for short logic, **named functions** otherwise.
- Use **default parameters** over null checks.
- Group multiple parameters into a single object (RO-RO pattern).
- Return typed objects, not primitives.
- Maintain a single abstraction level per function.
---
## 🧱 Data Handling
- Encapsulate data in composite types.
- Use **immutability** with `readonly` and `as const`.
- Perform validations in classes or DTOs, not within business functions.
- Always validate data using typed DTOs.
---
## 🧰 Classes
- Follow **SOLID** principles.
- Prefer **composition over inheritance**.
- Define **interfaces** for contracts.
- Keep classes focused and small (<200 lines, <10 methods, <10 properties).
---
## 🚨 Error Handling
- Use exceptions for unexpected errors.
- Catch only to fix or add context; otherwise, use global error handlers.
- Always provide meaningful error messages.
---
## 🧪 Testing (General)
- Use the **ArrangeActAssert** pattern.
- Use descriptive test variable names (`inputData`, `expectedOutput`).
- Write **unit tests** for all public methods.
- Mock external dependencies.
- Add **acceptance tests** per module using GivenWhenThen.
---
# 🏗️ Backend (NestJS)
### Principles
- **Modular architecture**:
- One module per domain.
- Controller → Service → Model structure.
- DTOs validated with **class-validator**.
- Use **MikroORM** or equivalent for persistence.
- Encapsulate reusable code in a **common module** (`@app/common`):
- Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators.
### Core Functionalities
- Global **filters** for exception handling.
- **Middlewares** for request handling.
- **Guards** for permissions and RBAC.
- **Interceptors** for response transformation and logging.
### Testing
- Use **Jest** for testing.
- Test each controller and service.
- Add `admin/test` endpoint as a smoke test.
---
# 🖥️ Frontend (NextJS / React)
### Developer Profile
Senior-level TypeScript + React/NextJS engineer.
Expert in **TailwindCSS**, **Shadcn/UI**, and **Radix** for UI development.
### Code Implementation Guidelines
- Use **early returns** for clarity.
- Always style with **TailwindCSS** classes.
- Prefer `class:` conditional syntax over ternary operators.
- Use **const arrow functions** for components and handlers.
- Event handlers start with `handle...` (e.g., `handleClick`, `handleSubmit`).
- Include accessibility attributes:
`tabIndex="0"`, `aria-label`, `onKeyDown`, etc.
- Ensure all code is **complete**, **tested**, and **DRY**.
- Always import required modules explicitly.
### UI/UX with React
- Use **semantic HTML**.
- Apply **responsive Tailwind** classes.
- Maintain visual hierarchy with typography and spacing.
- Use **Shadcn** components for consistent UI.
- Keep components small and focused.
---
# 🎨 UI/UX (Bootstrap Integration)
### Key Principles
- Use **Bootstrap 5+** for responsive design and consistent UI.
- Focus on **maintainability**, **readability**, and **accessibility**.
- Use clear and descriptive class names.
### Bootstrap Usage
- Structure layout with **container**, **row**, **col**.
- Use built-in **components** (buttons, modals, alerts, etc.) instead of custom CSS.
- Apply **utility classes** for quick styling (spacing, colors, text, etc.).
- Ensure **ARIA compliance** and semantic markup.
### Form Validation & Errors
- Use Bootstraps built-in validation states.
- Show errors with **alert components**.
- Include labels, placeholders, and feedback messages.
### Dependencies
- Bootstrap (latest CSS + JS)
- Optionally jQuery (for legacy interactive components)
### Bootstrap-Specific Guidelines
- Customize Bootstrap via **Sass variables** and **mixins**.
- Use responsive visibility utilities.
- Avoid overriding Bootstrap; extend it.
- Follow official documentation for examples.
### Performance Optimization
- Include only necessary Bootstrap modules.
- Use CDN for assets and caching.
- Optimize images and assets for mobile.
### Key Conventions
1. Follow Bootstraps naming and structure.
2. Prioritize **responsiveness** and **accessibility**.
3. Keep the file structure organized and modular.
---
# 🔗 Full Stack Integration Guidelines
| Aspect | Backend (NestJS) | Frontend (NextJS) | UI Layer (Bootstrap/Tailwind) |
|:--|:--|:--|:--|
| API | REST / GraphQL Controllers | API hooks via fetch/axios | Components consuming data |
| Validation | `class-validator` DTOs | `zod` / form-level validation | Bootstrap validation feedback |
| Auth | Guards, JWT | NextAuth / cookies | Auth UI states |
| Errors | Global filters | Toasts / modals | Alerts / feedback |
| Testing | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles | Scoped modules | Tailwind / Shadcn | Bootstrap utilities |
| Accessibility | Guards + filters | ARIA attributes | Semantic HTML |
---
# ✅ Final Notes
- Use a **shared types package** (`@types/shared`) for consistent interfaces.
- Document your modules and APIs.
- Run lint, type-check, and tests before commit.
- Use **Prettier + ESLint** for consistent formatting.
- Prefer **clarity over cleverness** — readable code wins.
---
# 🗂️ DMS-Specific Conventions (Document Management System)
This section extends the general FullStackJS guidelines for projects similar to **npdms.work**, focusing on document approval workflows (RFA, Drawing, Contract, Revision, Transmittal, Report).
## 🧱 Backend Domain Modules
Use modular domain structure per document type:
```
src/
├─ modules/
│ ├─ rfas/
│ ├─ drawings/
│ ├─ contracts/
│ ├─ transmittals/
│ ├─ audit-log/
│ ├─ users/
│ └─ common/
```
### Naming Convention
| Entity | Example |
|:--|:--|
| Table | `rfa_revisions`, `drawing_contracts` |
| DTO | `CreateRfaDto`, `UpdateContractDto` |
| Controller | `rfas.controller.ts` |
| Service | `rfas.service.ts` |
---
## 🧩 RBAC & Permission Control
Use decorators to enforce access rights:
```ts
@RequirePermission('rfa.update')
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
```
### Roles
- **Admin**: Full access to all modules.
- **Editor**: Modify data within assigned modules.
- **Viewer**: Readonly access.
### Permissions
- `rfa.create`, `rfa.update`, `rfa.delete`, `rfa.view`
- `drawing.upload`, `drawing.map`, `drawing.view`
- `contract.assign`, `contract.view`
Seed mapping between roles and permissions via seeder scripts.
---
## 🧾 AuditLog Standard
Log all CRUD and mapping operations:
| Field | Description |
|:--|:--|
| `actor_id` | user performing the action |
| `module_name` | e.g. `rfa`, `drawing` |
| `action` | `create`, `update`, `delete`, `map` |
| `target_id` | primary id of the record |
| `timestamp` | UTC timestamp |
| `description` | contextual note |
Example implementation:
```ts
await this.auditLogService.log({
actorId: user.id,
moduleName: 'rfa',
action: 'update',
targetId: rfa.id,
description: `Updated revision ${rev}`,
});
```
---
## 📂 File Handling
### File Upload Standard
- Upload path: `/storage/{year}/{month}/`
- File naming: `{drawing_code}_{revision}_{timestamp}.pdf`
- Allowed types: `pdf, dwg, docx, xlsx, zip`
- Max size: **50 MB**
- Store outside webroot.
- Serve via secure endpoint `/files/:id/download`.
### Access Control
Each file download must verify user permission (`hasPermission('drawing.view')`).
---
## 📊 Reporting & Exports
| Report | Description |
|:--|:--|
| **Report A** | RFA → Drawings → All Drawing Revisions |
| **Report B** | RFA Revision Timeline vs Drawing Revision |
| **Dashboard KPI** | RFAs, Drawings, Revisions, Transmittals summary |
### Export Rules
- Export formats: CSV, Excel, PDF.
- Provide print view.
- Include source entity link (e.g., `/rfas/:id`).
---
## 🧮 Frontend: DataTable & Form Patterns
### DataTable (ServerSide)
- Endpoint: `/api/{module}?page=1&pageSize=20`
- Must support: pagination, sorting, search, filters.
- Always display latest revision inline (for RFA/Drawing).
### Form Standards
- Dependent dropdowns:
- Contract → Subcategory
- RFA → Related Drawing
- File upload: preview + validation.
- Submit via API with toast feedback.
---
## 🧭 Dashboard & Activity Feed
### Dashboard Cards
- Show latest RFA, Drawing, Transmittal, KPI summary.
- Include quick links to modules.
### Activity Feed
- Display recent AuditLog actions (10 latest).
```ts
// Example response
[
{ user: 'admin', action: 'Updated RFA 023-Rev02', time: '20251104T09:30Z' }
]
```
---
## ✅ Integration Summary
| Aspect | Backend | Frontend | Description |
|:--|:--|:--|
| **File Handling** | Secure storage, token check | Upload/Preview UI | Consistent standard path |
| **RBAC** | `RequirePermission` guard | Hide/disable UI actions | Unified permission logic |
| **AuditLog** | Persist actions | Show in dashboard | Traceable user activity |
| **Reports** | Aggregation queries | Export + Print | Consistent data pipeline |
| **DataTables** | Serverside paging | Filter/Search UI | Scalable dataset management |
---
## 🧩 Recommended Enhancements
- ✅ Add `deleted_at` for soft delete + restore.
- ✅ Fulltext search + date filters.
- ✅ Background job for RFA deadline reminders.
- ✅ Optimize DB with indexes on `rfa_id`, `drawing_id`, `contract_id`.
- ✅ Periodic cleanup for unused file uploads.
---

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View File

@@ -0,0 +1,136 @@
# LCBP3-DMS: Requirements Specification
เอกสารนี้สรุปข้อกำหนดของโปรเจ็ค LCBP3-DMS (Document Management System), สถาปัตยกรรมทางเทคนิค, และรายละเอียดการนำไปใช้ (Implementation) สำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System)
## 1. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)
ระบบใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา
- 1.1 Infrastructure & Environment:
Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration, debug
Development Environment: VS Code on Windows 11
Domain: np-dms.work, www.np-dms.work (มี Fixed IP)
Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
Data Storage: /share/dms-data บน QNAP
ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
- 1.2 Code Hosting:
Service: Gitea (Self-hosted on QNAP)
Service name: gitea
Domain: git.np-dms.work
หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
- 1.3 Backend / Data Platform:
Service: NestJS
Service name: backend
Domain: backend.np-dms.work
Framework: NestJS (Node.js, TypeScript, ESM)
หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
- 1.4 Database:
Service: mariadb:10.11
Service name: mariadb
Domain: db.np-dms.work
หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
- 1.5 Database management:
Service: phpmyadmin:5-apache
Service name: pma
Domain: pma.np-dms.work
หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
- 1.6 Frontend:
Service: next.js
Service name: frontend
Domain: lcbp3.np-dms.work
Framework: Next.js (App Router, React, TypeScript, ESM)
Styling: Tailwind CSS + PostCSS
Component Library: shadcn/ui
หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
- 1.7 Workflow automation:
Service: n8nio/n8n:latest
Service name: n8n
Domain: n8n.np-dms.work
หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
- 1.8 Reverse Proxy:
Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
Service name: npm
Domain: npm.np-dms.work
หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
## 2. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)
- 2.1. การจัดการโครงสร้างโครงการและองค์กร
- 2.1.1 โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
- 2.1.2 สัญญา (Contracts): ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
- 2.1.3 องค์กร (Organizations):
- มีหลายองค์กรในโครงการ บางองค์กรเช่น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
- Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
- 2.2. การจัดการเอกสาร (Correspondence Management)
- 2.2.1 ประเภทเอกสาร: ระบบต้องรองรับเอกสารหลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
- 2.2.2 การสร้างเอกสาร (Correspondence):
- ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ "ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
- เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
- 2.2.3 การอ้างอิงและจัดกลุ่ม:
- เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
- สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
- 2.2.4 ประวัติการแก้ไข (Revisions): เอกสารสามารถมีได้หลาย Revision โดยระบบจะเก็บประวัติการแก้ไขทั้งหมด
- 2.2.5 การจัดเก็บ: เอกสารและไฟล์แนบจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) โดยมีการอ้างอิงข้อมูล (Metadata) ในฐานข้อมูล และสามารถจัดเรียงตามวันที่ออกเอกสาร (Issue Date) ได้
- 2.3. การจัดการเอกสารนำส่ง (Transmittals)
- 2.3.1 วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Technical Documents (RFAS) หลายฉบับ ไปยังองค์กรอื่น
- 2.3.2 การอ้างอิง: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence และสามารถมี Technical Documents (RFAS) หลายฉบับ
- 2.4 ใบเวียนเอกสารภายใน (Internal Circulation Sheet)
- 2.4.1 วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
- 2.4.2 การระบุผู้รับผิดชอบ:
- ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
- ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
- ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
- 2.4.3 การติดตามงาน:
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
- มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
- สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว
- 2.5. การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow)
- 2.5.1 ประเภท: Technical Documents (RFAS) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
- Request for Drawing Approval (RFA_DWG)
- Request for Document Approval (RFA_DOC)
- Request for Method statement Approval (RFA_MES)
- Request for Material Approval (RFA_MAT)
- 2.5.2 Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น ส่งจาก Originator -> Org1 -> Org2 -> Org3 แล้วส่งผลกลับตามลำดับเดิม
- 2.5.3 การจัดการ Drawing (RFA_DWG):
- เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
- Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
- ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
## 3. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)
- 3.1 ภาพรวม: ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
- 3.2 ระดับของสิทธิ์:
- Global Roles: สิทธิ์ในภาพรวมของระบบ
- Project-Specific Roles: สิทธิ์ที่ถูกกำหนดให้ผู้ใช้สำหรับโครงการนั้นๆ โดยเฉพาะ (เช่น เป็น Editor ในโครงการ A แต่เป็น Viewer ในโครงการ B)
- 3.3 บทบาท (Roles) พื้นฐาน:
- Superadmin: ไม่มีข้อจำกัดใดๆ สามารถจัดการได้ทุกอย่างข้ามองค์กร
- Admin: มีสิทธิ์เต็มที่ แต่จำกัดเฉพาะในองค์กรที่ตัวเองสังกัด สามารถจัดการผู้ใช้ในองค์กรได้
- Document Control / Editor: สามารถ เพิ่ม/แก้ไข เอกสาร เฉพาะในองค์กรที่ตัวเองสังกัด ไม่สามารถจัดการผู้ใช้ได้
- สามารถสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลังผ่านหน้า Admin Panel
- 3.4 การบังคับใช้สิทธิ์: สิทธิ์ขององค์กรจะครอบคลุมสิทธิ์ของผู้ใช้ และการเข้าถึงข้อมูลที่เกี่ยวข้องกับโครงการ (เช่น การแก้ไขเอกสาร) จะถูกตรวจสอบเทียบกับสิทธิ์ที่ผู้ใช้มีในโครงการนั้นๆ โดยเฉพาะ
## 4. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)
- 4.1 Layout หลัก: หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
- 4.2 หน้า Landing Page: เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
- 4.3 หน้า Dashboard: เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
- 4.4 การติดตามสถานะ: องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
- 4.5 การจัดการข้อมูลส่วนตัว (Profile Page): ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
- 4.6 การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow): ผู้ใช้สามารถดู Technical Document ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ admin ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ admin ขึ้นไป
## 5. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)
- 5.1 การบันทึกการกระทำ (Audit Log): ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
- 5.2 การค้นหา (Search): ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสารจากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
- 5.3 การทำรายงาน (Reporting): สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
- 5.4 ประสิทธิภาพ (Performance): มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
- 5.5 ความปลอดภัย (Security):
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด

View File

@@ -0,0 +1,197 @@
# 📝 Documents Management Sytem Version 1.1.0: Application Requirements Specification
## 📌 1. วัตถุประสงค์
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
* มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
* ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
* เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
## 🛠️ 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
* 2.1. Infrastructure & Environment:
- Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
- Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
- Development Environment: VS Code on Windows 11
- Domain: np-dms.work, www.np-dms.work
- ip: 159.192.126.103
- Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
- Data Storage: /share/dms-data บน QNAP
- ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
* 2.2. Code Hosting:
- Application name: git
- Service: Gitea (Self-hosted on QNAP)
- Service name: gitea
- Domain: git.np-dms.work
- หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
* 2.3. Backend / Data Platform:
- Application name: lcbp3-backend
- Service: NestJS
- Service name: backend
- Domain: backend.np-dms.work
- Framework: NestJS (Node.js, TypeScript, ESM)
- หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
* 2.4. Database:
- Application name: lcbp3-db
- Service: mariadb:10.11
- Service name: mariadb
- Domain: db.np-dms.work
- หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
- Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
* 2.5. Database management:
- Application name: lcbp3-db
- Service: phpmyadmin:5-apache
- Service name: pma
- Domain: pma.np-dms.work
- หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
* 2.6. Frontend:
- Application name: lcbp3-frontend
- Service: next.js
- Service name: frontend
- Domain: lcbp3.np-dms.work
- Framework: Next.js (App Router, React, TypeScript, ESM)
- Styling: Tailwind CSS + PostCSS
- Component Library: shadcn/ui
- หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
* 2.7. Workflow automation:
- Application name: lcbp3-n8n
- Service: n8nio/n8n:latest
- Service name: n8n
- Domain: n8n.np-dms.work
- หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
* 2.8. Reverse Proxy:
- Application name: lcbp3-npm
- Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
- Service name: npm
- Domain: npm.np-dms.work
- หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
## 📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)
* 3.1. การจัดการโครงสร้างโครงการและองค์กร
- 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
- 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
- 3.1.3. องค์กร (Organizations):
- มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
- Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
* 3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)
- 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects)
- 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
- 3.2.3. การสร้างเอกสาร (Correspondence):
- ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
- เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
- 3.2.4. การอ้างอิงและจัดกลุ่ม:
- เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
- สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
- 3.2.5. การจัดการ: มีการจัดการอย่างน้อยดังนี้
0 - สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อเป็นผู้รับ ได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
* 3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)
- 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
- 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
* 3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)
- 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
- 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
* 3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)
- 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
- 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
- Request for Drawing Approval (RFA_DWG)
- Request for Document Approval (RFA_DOC)
- Request for Method statement Approval (RFA_MES)
- Request for Material Approval (RFA_MAT)
- 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.5.4. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA_DWG):
- เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
- Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
- ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
- 3.6.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
- 3.6.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
0 - สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
* 3.6.การจัดการเอกสารนำส่ง (Transmittals)
- 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
- 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
* 3.7. ใบเวียนเอกสารภายใน (Internal Circulation Sheet)
- 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
- 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
- 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
- ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
- ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
- ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
- 3.7.5. การติดตามงาน:
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
- มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
- สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
* 3.8. ประวัติการแก้ไข (Revisions): ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
* 3.9. การจัดเก็บ: เอกสารและไฟล์แนบจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) โดยมีการอ้างอิงข้อมูล (Metadata) ในฐานข้อมูล และสามารถจัดเรียงตามวันที่ในเอกสาร (Document Date) ได้ ตัวอย่างเช่น
- Correspondence จัดเก็บใน /share/dms-data/correspondences/YYMMDD/ชื่อไฟล์.pdf
- Request for Approval จัดเก็บใน /share/dms-data/rfas/YYMMDD/ชื่อไฟล์.pdf
- Shop Drawings จัดเก็บใน /share/dms-data/shop_drawings/YYMMDD/ชื่อไฟล์.pdf
## 🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)
* 4.1. ภาพรวม: ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
* 4.2. ระดับของสิทธิ์:
- Global Roles: สิทธิ์ในภาพรวมของระบบ
- Project-Specific Roles: สิทธิ์ที่ถูกกำหนดให้ผู้ใช้สำหรับโครงการนั้นๆ โดยเฉพาะ (เช่น เป็น Editor ในโครงการ A แต่เป็น Viewer ในโครงการ B)
- Contract-Specific Roles: สิทธิ์ที่ถูกกำหนดให้โครงการสำหรับสัญญานั้นๆ (เช่น เป็น Admin ในสัญญา 1 จะเป็น Admin ใน โครงการ A และ ฺB ที่อยู่ในสัญญา 1)
* 4.3. บทบาท (Roles) พื้นฐาน:
- Superadmin: ไม่มีข้อจำกัดใดๆ สามารถจัดการได้ทุกอย่างข้ามองค์กร
- Admin: มีสิทธิ์เต็มที่ แต่จำกัดเฉพาะในองค์กรที่ตัวเองสังกัด สามารถจัดการผู้ใช้ในองค์กรได้ สามารถสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลังผ่านหน้า Admin
- Document Control สามารถ เพิ่ม/แก้ไข/ลบ เอกสาร เฉพาะในองค์กรที่ตัวเองสังกัด ไม่สามารถจัดการผู้ใช้ได้
- Editor: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนดไว้ เฉพาะในองค์กรที่ตัวเองสังกัด
- Viewer: สามารถดู เอกสาร เฉพาะในองค์กรที่ตัวเองสังกัด
* 4.4. การบังคับใช้สิทธิ์: สิทธิ์ขององค์กรจะครอบคลุมสิทธิ์ของผู้ใช้ และการเข้าถึงข้อมูลที่เกี่ยวข้องกับโครงการ (เช่น การแก้ไขเอกสาร) จะถูกตรวจสอบเทียบกับสิทธิ์ที่ผู้ใช้มีในโครงการนั้นๆ โดยเฉพาะ
## 👥 5. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)
* 5.1. Layout หลัก: หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
* 5.2. หน้า Landing Page: เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
* 5.3. หน้า Dashboard: เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
* 5.4. การติดตามสถานะ: องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
* 5.5. การจัดการข้อมูลส่วนตัว (Profile Page): ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
* 5.6. การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow): ผู้ใช้สามารถดู Technical Document ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ admin ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ admin ขึ้นไป
## 6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)
* 6.1. การบันทึกการกระทำ (Audit Log): ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
* 6.2. การค้นหา (Search): ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสารจากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
* 6.3. การทำรายงาน (Reporting): สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
* 6.4. ประสิทธิภาพ (Performance): มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
* 6.5. ความปลอดภัย (Security):
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
## 📈 7.
## 🧩 8.
🎯
📤
📊
🔄

View File

@@ -0,0 +1,456 @@
# แนวทางการพัฒนา FullStackJS
## 🧠 ปรัชญาทั่วไป
แนวทางปฏิบัติที่ดีที่สุดแบบครบวงจรสำหรับการพัฒนา **NestJS Backend**, **NextJS Frontend** และ **Tailwind-based UI/UX** ในสภาพแวดล้อม TypeScript
มุ่งเน้นที่ **ความชัดเจน (clarity)**, **ความง่ายในการบำรุงรักษา (maintainability)**, **ความสอดคล้องกัน (consistency)** และ **การเข้าถึงได้ (accessibility)** ตลอดทั้งสแต็ก
-----
## ⚙️ แนวทางทั่วไปสำหรับ TypeScript
### หลักการพื้นฐาน
- ใช้ **ภาษาอังกฤษ** สำหรับโค้ดและเอกสารทั้งหมด
- กำหนดไทป์ (type) อย่างชัดเจนสำหรับตัวแปร, พารามิเตอร์ และค่าที่ส่งกลับ (return values) ทั้งหมด
- หลีกเลี่ยงการใช้ `any`; ให้สร้างไทป์ (types) หรืออินเทอร์เฟซ (interfaces) ที่กำหนดเอง
- ใช้ **JSDoc** สำหรับคลาส (classes) และเมธอด (methods) ที่เป็น public
- ส่งออก (Export) **สัญลักษณ์หลัก (main symbol) เพียงหนึ่งเดียว** ต่อไฟล์
- หลีกเลี่ยงบรรทัดว่างภายในฟังก์ชัน
### ข้อตกลงในการตั้งชื่อ (Naming Conventions)
| Entity (สิ่งที่ตั้งชื่อ) | Convention (รูปแบบ) | Example (ตัวอย่าง) |
|:--|:--|:--|
| Classes | PascalCase | `UserService` |
| Variables & Functions | camelCase | `getUserInfo` |
| Files & Folders | kebab-case | `user-service.ts` |
| Environment Variables | UPPERCASE | `DATABASE_URL` |
| Booleans | Verb + Noun | `isActive`, `canDelete`, `hasPermission` |
ใช้คำเต็ม — ไม่ใช้อักษรย่อ — ยกเว้นคำมาตรฐาน (เช่น `API`, `URL`, `req`, `res`, `err`, `ctx`)
-----
## 🧩 ฟังก์ชัน (Functions)
- เขียนฟังก์ชันให้สั้น และทำ **หน้าที่เพียงอย่างเดียว** (single-purpose) (\< 20 บรรทัด)
- ใช้ **early returns** เพื่อลดการซ้อน (nesting) ของโค้ด
- ใช้ **map**, **filter**, **reduce** แทนการใช้ loops เมื่อเหมาะสม
- ควรใช้ **arrow functions** สำหรับตรรกะสั้นๆ, และใช้ **named functions** ในกรณีอื่น
- ใช้ **default parameters** แทนการตรวจสอบค่า null
- จัดกลุ่มพารามิเตอร์หลายตัวให้เป็นอ็อบเจกต์เดียว (RO-RO pattern)
- ส่งค่ากลับ (Return) เป็นอ็อบเจกต์ที่มีไทป์กำหนด (typed objects) ไม่ใช่ค่าพื้นฐาน (primitives)
- รักษาระดับของสิ่งที่เป็นนามธรรม (abstraction level) ให้เป็นระดับเดียวในแต่ละฟังก์ชัน
-----
## 🧱 การจัดการข้อมูล (Data Handling)
- ห่อหุ้มข้อมูล (Encapsulate) ในไทป์แบบผสม (composite types)
- ใช้ **immutability** (การไม่เปลี่ยนแปลงค่า) ด้วย `readonly` และ `as const`
- ทำการตรวจสอบความถูกต้องของข้อมูล (Validations) ในคลาสหรือ DTOs ไม่ใช่ภายในฟังก์ชันทางธุรกิจ
- ตรวจสอบความถูกต้องของข้อมูลโดยใช้ DTOs ที่มีไทป์กำหนดเสมอ
-----
## 🧰 คลาส (Classes)
- ปฏิบัติตามหลักการ **SOLID**
- ควรใช้ **composition มากกว่า inheritance** (Prefer composition over inheritance)
- กำหนด **interfaces** สำหรับสัญญา (contracts)
- ให้คลาสมุ่งเน้นการทำงานเฉพาะอย่างและมีขนาดเล็ก (\< 200 บรรทัด, \< 10 เมธอด, \< 10 properties)
-----
## 🚨 การจัดการข้อผิดพลาด (Error Handling)
- ใช้ Exceptions สำหรับข้อผิดพลาดที่ไม่คาดคิด
- ดักจับ (Catch) ข้อผิดพลาดเพื่อแก้ไขหรือเพิ่มบริบท (context) เท่านั้น; หากไม่เช่นนั้น ให้ใช้ global error handlers
- ระบุข้อความข้อผิดพลาด (error messages) ที่มีความหมายเสมอ
-----
## 🧪 การทดสอบ (ทั่วไป) (Testing (General))
- ใช้รูปแบบ **ArrangeActAssert**
- ใช้ชื่อตัวแปรในการทดสอบที่สื่อความหมาย (`inputData`, `expectedOutput`)
- เขียน **unit tests** สำหรับ public methods ทั้งหมด
- จำลอง (Mock) การพึ่งพาภายนอก (external dependencies)
- เพิ่ม **acceptance tests** ต่อโมดูลโดยใช้รูปแบบ GivenWhenThen
-----
# 🏗️ แบ็กเอนด์ (NestJS) (Backend (NestJS))
### หลักการ
- **สถาปัตยกรรมแบบโมดูลาร์ (Modular architecture)**:
- หนึ่งโมดูลต่อหนึ่งโดเมน
- โครงสร้างแบบ Controller → Service → Repository (Model)
- DTOs ที่ตรวจสอบความถูกต้องด้วย **class-validator**
- ใช้ **MikroORM** (หรือ TypeORM/Prisma) สำหรับการคงอยู่ของข้อมูล (persistence) ซึ่งสอดคล้องกับสคีมา MariaDB
- ห่อหุ้มโค้ดที่ใช้ซ้ำได้ไว้ใน **common module** (`@app/common`):
- Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators
### ฟังก์ชันหลัก (Core Functionalities)
- Global **filters** สำหรับการจัดการ exception
- **Middlewares** สำหรับการจัดการ request
- **Guards** สำหรับการอนุญาต (permissions) และ RBAC
- **Interceptors** สำหรับการแปลงข้อมูล response และการบันทึก log
### ข้อจำกัดในการ Deploy (QNAP Container Station)
- **ห้ามใช้ไฟล์ `.env`** ในการตั้งค่า Environment Variables
- การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน `docker-compose.yml` โดยตรง** ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station
### โครงสร้างโมดูลตามโดเมน (Domain-Driven Module Structure)
เพื่อให้สอดคล้องกับสคีมา SQL (LCBP3-DMS) เราจะใช้โครงสร้างโมดูลแบบ **Domain-Driven (แบ่งตามขอบเขตธุรกิจ)** แทนการแบ่งตามฟังก์ชัน:
1. **CoreModule / CommonModule:**
* เก็บ Services ที่ใช้ร่วมกัน เช่น `DatabaseModule`, `FileStorageService` (จัดการไฟล์ใน QNAP), `AuditLogService`, และ `NotificationService`
2. **AuthModule / UserModule:**
* จัดการ `users`, `roles`, `permissions` และการยืนยันตัวตน (JWT, Guards)
* **(สำคัญ)** ต้องรับผิดชอบการตรวจสอบสิทธิ์ **3 ระดับ**: สิทธิ์ระดับระบบ (Global Role), สิทธิ์ระดับโปรเจกต์ (Project Role), และ **สิทธิ์ระดับสัญญา (Contract Role)**
* **(สำคัญ)** ต้องมี API สำหรับ Admin เพื่อ **สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก** (ไม่ใช่แค่ seed ข้อมูลเริ่มต้น)
3. **ProjectModule:**
* จัดการ `projects`, `organizations`, `contracts`, `project_parties`, `contract_parties`
4. **CorrespondenceModule (โมดูลศูนย์กลาง):**
* จัดการ `correspondences`, `correspondence_revisions`
* จัดการ `correspondence_attachments` (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Correspondence Routings"** (`correspondence_routings`) สำหรับการส่งต่อเอกสารทั่วไประหว่างองค์กร
5. **RfaModule:**
* จัดการ `rfas`, `rfa_revisions`, `rfa_items`
* รับผิดชอบเวิร์กโฟลว์ **"RFA Workflows"** (`rfa_workflows`) สำหรับการอนุมัติเอกสารทางเทคนิค
6. **DrawingModule:**
* จัดการ `shop_drawings`, `shop_drawing_revisions`, `contract_drawings` และหมวดหมู่ต่างๆ
* จัดการ `shop_drawing_revision_attachments` (ตารางเชื่อมไฟล์แนบ)
7. **CirculationModule:**
* จัดการ `circulations`, `circulation_templates`, `circulation_assignees`
* จัดการ `circulation_attachments` (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลGว์ **"Circulations"** สำหรับการเวียนเอกสาร **ภายในองค์กร**
8. **TransmittalModule:**
* จัดการ `transmittals` และ `transmittal_items`
9. **SearchModule:**
* **(สำหรับ V1)** ให้บริการค้นหาขั้นสูง (Advanced Search) โดยต้องรองรับการกรองจาก ชื่อเรื่อง (LIKE), ประเภท, วันที่, และ **Tags** (ผ่านการ Join ตาราง) โดยค้นหาผ่าน Views (`v_current_rfas`, `v_current_correspondences`)
### เครื่องมือและไลบรารีที่แนะนำ (Recommended Tools & Libraries)
🔐 **Authentication & Authorization**
* `@nestjs/passport`
* `@nestjs/jwt`
* `casl` สำหรับ RBAC (Role-Based Access Control)
🗃️ **Database & ORM**
* `@nestjs/typeorm` ORM สำหรับ SQL (หรือ `Prisma` เป็นทางเลือก)
* `typeorm-seeding` สำหรับสร้างข้อมูลจำลอง (seeding)
📦 **Validation & Transformation**
* `class-validator`
* `class-transformer`
📁 **File Upload & Storage**
* `@nestjs/platform-express`
* `multer` สำหรับจัดการไฟล์
🔍 **Search**
* **(สำหรับ V1)** เน้นการค้นหาขั้นสูงตาม Requirement 6.2 (Full-text search/Elasticsearch จะพิจารณาใน V2)
📬 **Notification**
* `nodemailer` สำหรับส่งอีเมล
* `@nestjs/schedule` สำหรับ cron job หรือแจ้งเตือนตามเวลา
📊 **Logging & Monitoring**
* `winston` หรือ `nestjs-pino` ระบบ log ที่ยืดหยุ่น
* `@nestjs/terminus` สำหรับ health check
🧪 **Testing**
* `@nestjs/testing`
* `jest` สำหรับ unit/integration test
🌐 **API Documentation**
* `@nestjs/swagger` **(สำคัญมาก)** สร้าง Swagger UI อัตโนมัติ ต้องใช้ DTOs อย่างเคร่งครัดเพื่อความชัดเจนของ API สำหรับทีม Frontend
🛡️ **Security**
* `helmet` ป้องกันช่องโหว่ HTTP
* `rate-limiter-flexible` ป้องกัน brute force
### การทดสอบ (Testing)
- ใช้ **Jest** สำหรับการทดสอบ
- ทดสอบทุก controller และ service
- เพิ่ม endpoint `admin/test` เพื่อใช้เป็น smoke test
-----
# 🖥️ ฟรอนต์เอนด์ (NextJS / React / UI) (Frontend (NextJS / React / UI))
### โปรไฟล์นักพัฒนา (Developer Profile)
วิศวกร TypeScript + React/NextJS ระดับ Senior
เชี่ยวชาญ **TailwindCSS**, **Shadcn/UI**, และ **Radix** สำหรับการพัฒนา UI
### แนวทางการพัฒนาโค้ด (Code Implementation Guidelines)
- ใช้ **early returns** เพื่อความชัดเจน
- ใช้คลาสของ **TailwindCSS** ในการกำหนดสไตล์เสมอ
- ควรใช้ `class:` syntax แบบมีเงื่อนไข (หรือ utility `clsx`) มากกว่าการใช้ ternary operators ใน class strings
- ใช้ **const arrow functions** สำหรับ components และ handlers
- Event handlers ให้ขึ้นต้นด้วย `handle...` (เช่น `handleClick`, `handleSubmit`)
- รวมแอตทริบิวต์สำหรับการเข้าถึง (accessibility) ด้วย:
`tabIndex="0"`, `aria-label`, `onKeyDown`, ฯลฯ
- ตรวจสอบให้แน่ใจว่าโค้ดทั้งหมด **สมบูรณ์**, **ผ่านการทดสอบ**, และ **ไม่ซ้ำซ้อน (DRY)**
- ต้อง import โมดูลที่จำเป็นต้องใช้อย่างชัดเจนเสมอ
### UI/UX ด้วย React
- ใช้ **semantic HTML**
- ใช้คลาสของ **Tailwind** ที่รองรับ responsive (`sm:`, `md:`, `lg:`)
- รักษาลำดับชั้นของการมองเห็น (visual hierarchy) ด้วยการใช้ typography และ spacing
- ใช้ **Shadcn** components (Button, Input, Card, ฯลฯ) เพื่อ UI ที่สอดคล้องกัน
- ทำให้ components มีขนาดเล็กและมุ่งเน้นการทำงานเฉพาะอย่าง
- ใช้ utility classes สำหรับการจัดสไตล์อย่างรวดเร็ว (spacing, colors, text, ฯลฯ)
- ตรวจสอบให้แน่ใจว่าสอดคล้องกับ **ARIA** และใช้ semantic markup
### การตรวจสอบฟอร์มและข้อผิดพลาด (Form Validation & Errors)
- ใช้ไลบรารีฝั่ง client เช่น `zod` และ `react-hook-form`
- แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline
- ต้องมี labels, placeholders, และข้อความ feedback
-----
# 🔗 แนวทางการบูรณาการ Full Stack (Full Stack Integration Guidelines)
| Aspect (แง่มุม) | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
|:--|:--|:--|:--|
| API | REST / GraphQL Controllers | API hooks ผ่าน fetch/axios/SWR | Components ที่รับข้อมูล |
| Validation (การตรวจสอบ) | `class-validator` DTOs | `zod` / `react-hook-form` | สถานะของฟอร์ม/input ใน Shadcn |
| Auth (การยืนยันตัวตน) | Guards, JWT | NextAuth / cookies | สถานะ UI ของ Auth (loading, signed in) |
| Errors (ข้อผิดพลาด) | Global filters | Toasts / modals | Alerts / ข้อความ feedback |
| Testing (การทดสอบ) | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles (สไตล์) | Scoped modules (ถ้าจำเป็น) | Tailwind / Shadcn | Tailwind utilities |
| Accessibility (การเข้าถึง) | Guards + filters | ARIA attributes | Semantic HTML |
-----
# 🗂️ ข้อตกลงเฉพาะสำหรับ DMS (LCBP3-DMS)
ส่วนนี้ขยายแนวทาง FullStackJS ทั่วไปสำหรับโปรเจกต์ **LCBP3-DMS** โดยมุ่งเน้นไปที่เวิร์กโฟลว์การอนุมัติเอกสาร (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation)
## 🧱 โมดูลโดเมนฝั่งแบ็กเอนด์ (Backend Domain Modules)
ใช้โครงสร้างโดเมนแบบโมดูลาร์ที่สะท้อนสคีมา SQL โดย `correspondences` จะทำหน้าที่เป็นศูนย์กลาง (โครงสร้างนี้จะอยู่ภายใต้ "Functional Modules" ที่กล่าวถึงข้างต้น)
```
src/
├─ modules/
│ ├─ correspondences/ (Core: Master documents, Revisions, correspondence_attachments)
│ ├─ rfas/ (RFA logic, Revisions, Workflows, Items)
│ ├─ drawings/ (ShopDrawings, Revisions, shop_drawing_revision_attachments)
│ ├─ circulations/ (Internal circulation, Templates, circulation_attachments)
│ ├─ transmittals/ (Transmittal logic, Items)
│ ├─ projects-contracts/ (Projects, Contracts, Organizations, Parties)
│ ├─ users-auth/ (Users, Roles, Permissions, Auth)
│ ├─ audit-log/
│ └─ common/
```
### ข้อตกลงการตั้งชื่อ (Naming Convention)
| Entity (สิ่งที่ตั้งชื่อ) | Example (ตัวอย่างจาก SQL) |
|:--|:--|
| Table | `correspondences`, `rfa_revisions`, `contract_parties` |
| Column | `correspondence_id`, `created_by`, `is_current` |
| DTO | `CreateRfaDto`, `UpdateCorrespondenceDto` |
| Controller | `rfas.controller.ts` |
| Service | `correspondences.service.ts` |
-----
## 🧩 RBAC และการควบคุมสิทธิ์ (RBAC & Permission Control)
ใช้ Decorators เพื่อบังคับใช้สิทธิ์การเข้าถึง โดยอ้างอิงสิทธิ์จากตาราง `permissions`
```ts
@RequirePermission('rfas.respond') // ต้องตรงกับ 'permission_code'
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
```
### Roles (บทบาท)
- **Superadmin**: ไม่มีข้อจำกัดใดๆ
- **Admin**: มีสิทธิ์เต็มที่ในองค์กร
- **Document Control**: เพิ่ม/แก้ไข/ลบ เอกสารในองค์กร
- **Editor**: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนด
- **Viewer**: สามารถดู เอกสาร
### ตัวอย่าง Permissions (จากตาราง `permissions`)
- `rfas.view`, `rfas.create`, `rfas.respond`, `rfas.delete`
- `drawings.view`, `drawings.upload`, `drawings.delete`
- `corr.view`, `corr.manage`
- `transmittals.manage`
- `cirs.manage`
- `project_parties.manage`
การจับคู่ระหว่าง roles และ permissions **เริ่มต้น** จะถูก seed ผ่านสคริปต์ (ดังที่เห็นในไฟล์ SQL) **อย่างไรก็ตาม `AuthModule`/`UserModule` ต้องมี API สำหรับ Admin เพื่อสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลัง**
-----
## 🧾 มาตรฐาน AuditLog (AuditLog Standard)
บันทึกการดำเนินการ CRUD และการจับคู่ทั้งหมดลงในตาราง `audit_logs`
| Field (ฟิลด์) | Type (จาก SQL) | Description (คำอธิบาย) |
|:--|:--|:--|
| `audit_id` | `BIGINT` | Primary Key |
| `user_id` | `INT` | ผู้ใช้ที่ดำเนินการ (FK -\> users) |
| `action` | `VARCHAR(100)` | `rfa.create`, `correspondence.update`, `login.success` |
| `entity_type`| `VARCHAR(50)` | ชื่อตาราง/โมดูล เช่น 'rfa', 'correspondence' |
| `entity_id` | `VARCHAR(50)` | Primary ID ของระเบียนที่ได้รับผลกระทบ |
| `details_json`| `JSON` | ข้อมูลบริบท (เช่น ฟิลด์ที่มีการเปลี่ยนแปลง) |
| `ip_address` | `VARCHAR(45)` | IP address ของผู้ดำเนินการ |
| `user_agent` | `VARCHAR(255)`| User Agent ของผู้ดำเนินการ |
| `created_at` | `TIMESTAMP` | Timestamp (UTC) |
ตัวอย่างการใช้งาน:
```ts
await this.auditLogService.log({
userId: user.id,
action: 'rfa.update_status',
entityType: 'rfa_revisions',
entityId: rfaRevision.id,
detailsJson: { from: 'DFT', to: 'FAP' },
ipAddress: req.ip,
});
```
-----
## 📂 การจัดการไฟล์ (File Handling) (ปรับปรุงใหม่)
### มาตรฐานการอัปโหลดไฟล์ (File Upload Standard)
- **ตรรกะใหม่:** การอัปโหลดไฟล์ทั้งหมดจะถูกจัดการโดย `FileStorageService` และบันทึกข้อมูลไฟล์ลงในตาราง `attachments` (ตารางกลาง)
- ไฟล์จะถูกเชื่อมโยงไปยัง Entity ที่ถูกต้องผ่าน **ตารางเชื่อม (Junction Tables)** เท่านั้น:
- `correspondence_attachments` (เชื่อม Correspondence กับ Attachments)
- `circulation_attachments` (เชื่อม Circulation กับ Attachments)
- `shop_drawing_revision_attachments` (เชื่อม Drawing Revision กับ Attachments)
- **(สำคัญ)** คอลัมน์ `file_path` ถูกลบออกจาก `shop_drawing_revisions` แล้ว ต้องใช้ระบบตารางเชื่อมใหม่นี้เท่านั้น
- เส้นทางจัดเก็บไฟล์ (Upload path): อ้างอิงจาก Requirement 2.1 คือ `/share/dms-data` โดย `FileStorageService` จะสร้างโฟลเดอร์ย่อยแบบรวมศูนย์ (เช่น `/share/dms-data/uploads/{YYYY}/{MM}/[stored_filename]`)
- **(หมายเหตุ)**: โครงสร้างนี้ *แทนที่* โครงสร้างแบบแยกโมดูลที่ระบุใน Requirement 3.9 เนื่องจากการออกแบบใหม่ได้รวมศูนย์ไฟล์ไว้ที่ตาราง `attachments` กลางแล้ว
- ประเภทไฟล์ที่อนุญาต: `pdf, dwg, docx, xlsx, zip`
- ขนาดสูงสุด: **50 MB**
- จัดเก็บนอก webroot
- ให้บริการไฟล์ผ่าน endpoint ที่ปลอดภัย `/files/:attachment_id/download`
### การควบคุมการเข้าถึง (Access Control)
การเข้าถึงไฟล์ไม่ใช่การเข้าถึงโดยตรง endpoint `/files/:attachment_id/download` จะต้อง:
1. ค้นหาระเบียน `attachment`
2. ตรวจสอบว่า `attachment_id` นี้ เชื่อมโยงกับ Entity ใด (เช่น `correspondence`, `circulation`, `shop_drawing_revision`) ผ่านตารางเชื่อม
3. ตรวจสอบว่าผู้ใช้มีสิทธิ์ (permission) ในการดู Entity ต้นทางนั้นๆ หรือไม่
-----
## 📊 การรายงานและการส่งออก (Reporting & Exports)
### วิวสำหรับการรายงาน (Reporting Views) (จาก SQL)
การรายงานควรสร้างขึ้นจาก Views ที่กำหนดไว้ล่วงหน้าในฐานข้อมูลเป็นหลัก:
- `v_current_correspondences`: สำหรับ revision ปัจจุบันทั้งหมดของเอกสารที่ไม่ใช่ RFA
- `v_current_rfas`: สำหรับ revision ปัจจุบันทั้งหมดของ RFA และข้อมูล master
- `v_contract_parties_all`: สำหรับการตรวจสอบความสัมพันธ์ของ project/contract/organization
Views เหล่านี้ทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการรายงานฝั่งเซิร์ฟเวอร์และการส่งออกข้อมูล
### กฎการส่งออก (Export Rules)
- Export formats: CSV, Excel, PDF.
- จัดเตรียมมุมมองสำหรับพิมพ์ (Print view).
- รวมลิงก์ไปยังต้นทาง (เช่น `/rfas/:id`).
-----
## 🧮 ฟรอนต์เอนด์: รูปแบบ DataTable และฟอร์ม (Frontend: DataTable & Form Patterns)
### DataTable (ServerSide)
- Endpoint: `/api/{module}?page=1&pageSize=20&sort=...&filter=...`
- ต้องรองรับ: การแบ่งหน้า (pagination), การเรียงลำดับ (sorting), การค้นหา (search), การกรอง (filters)
- แสดง revision ล่าสุดแบบ inline เสมอ (สำหรับ RFA/Drawing)
### มาตรฐานฟอร์ม (Form Standards)
- ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ):
- Project → Contract Drawing Volumes
- Contract Drawing Category → Sub-Category
- RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้
- การอัปโหลดไฟล์: ต้องมี preview + validation (ผ่านตรรกะของ `attachments` และตารางเชื่อมใหม่)
- ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast
### ข้อกำหนด Component เฉพาะ (Specific UI Requirements)
- **Dashboard - My Tasks:** ต้องพัฒนา Component ตาราง "งานของฉัน" (My Tasks) ซึ่งดึงข้อมูลงานที่ผู้ใช้ล็อกอินอยู่ต้องรับผิดชอบ (Main/Action) จากโมดูล `Circulations`
- **Workflow Visualization:** ต้องพัฒนา Component สำหรับแสดงผล Workflow (โดยเฉพาะ RFA) ที่แสดงขั้นตอนทั้งหมดเป็นลำดับ โดยขั้นตอนปัจจุบัน (active) เท่านั้นที่ดำเนินการได้ และขั้นตอนอื่นเป็น `disabled` ต้องมีตรรกะสำหรับ Admin ในการ override หรือย้อนกลับขั้นตอนได้
-----
## 🧭 แดชบอร์ดและฟีดกิจกรรม (Dashboard & Activity Feed)
### การ์ดบนแดชบอร์ด (Dashboard Cards)
- แสดง Correspondences, RFAs, Circulations ล่าสุด
- รวมสรุป KPI (เช่น "RFAs ที่รอการอนุมัติ")
- รวมลิงก์ด่วนไปยังโมดูลต่างๆ
### ฟีดกิจกรรม (Activity Feed)
- แสดงรายการ `audit_logs` ล่าสุด (10 รายการ) ที่เกี่ยวข้องกับผู้ใช้
<!-- end list -->
```ts
// ตัวอย่าง API response
[
{ user: 'editor01', action: 'Updated RFA (LCBP3-RFA-001)', time: '2025-11-04T09:30Z' }
]
```
-----
## ✅ มาตรฐานที่นำไปใช้แล้ว (จาก SQL v1.1.0) (Implemented Standards (from SQL v1.1.0))
ส่วนนี้ยืนยันว่าแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เป็นส่วนหนึ่งของการออกแบบฐานข้อมูลอยู่แล้ว และควรถูกนำไปใช้ประโยชน์ ไม่ใช่สร้างขึ้นใหม่
-**Soft Delete:** นำไปใช้แล้วผ่านคอลัมน์ `deleted_at` ในตารางสำคัญ (เช่น `correspondences`, `rfas`, `project_parties`) ตรรกะการดึงข้อมูลต้องกรอง `deleted_at IS NULL`
-**Database Indexes:** สคีมาได้มีการทำ index ไว้อย่างหนักหน่วงบน foreign keys และคอลัมน์ที่ใช้ค้นหาบ่อย (เช่น `idx_rr_rfa`, `idx_cor_project`, `idx_cr_is_current`) เพื่อประสิทธิภาพ
-**โครงสร้าง RBAC:** มีระบบ `users`, `roles`, `permissions`, `user_roles`, และ `user_project_roles` ที่ครอบคลุมอยู่แล้ว
-**Data Seeding:** ข้อมูล Master (roles, permissions, organization\_roles, initial users, project parties) ถูกรวมอยู่ในสคริปต์สคีมาแล้ว
## 🧩 การปรับปรุงที่แนะนำ (สำหรับอนาคต) (Recommended Enhancements (Future))
-**(V2)** นำ Fulltext search หรือ Elasticsearch มาใช้กับฟิลด์เช่น `correspondence_revisions.title` หรือ `details`
- ✅ สร้าง Background job (โดยใช้ **n8n** เพื่อเชื่อมต่อกับ **Line** และ/หรือใช้สำหรับการแจ้งเตือน RFA ที่ใกล้ถึงกำหนด `due_date`)
- ✅ เพิ่ม job ล้างข้อมูลเป็นระยะสำหรับ `attachments` ที่ไม่ถูกเชื่อมโยงกับ Entity ใดๆ เลย (ไฟล์กำพร้า)
-----

View File

@@ -0,0 +1,201 @@
# 📝 Documents Management Sytem Version 1.1.0: Application Requirements Specification
## 📌 1. วัตถุประสงค์
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
* มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
* ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
* เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
## 🛠️ 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
* 2.1. Infrastructure & Environment:
- Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
- Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
- Development Environment: VS Code on Windows 11
- Domain: np-dms.work, www.np-dms.work
- ip: 159.192.126.103
- Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
- Data Storage: /share/dms-data บน QNAP
- ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
* 2.2. Code Hosting:
- Application name: git
- Service: Gitea (Self-hosted on QNAP)
- Service name: gitea
- Domain: git.np-dms.work
- หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
* 2.3. Backend / Data Platform:
- Application name: lcbp3-backend
- Service: NestJS
- Service name: backend
- Domain: backend.np-dms.work
- Framework: NestJS (Node.js, TypeScript, ESM)
- หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
* 2.4. Database:
- Application name: lcbp3-db
- Service: mariadb:10.11
- Service name: mariadb
- Domain: db.np-dms.work
- หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
- Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
* 2.5. Database management:
- Application name: lcbp3-db
- Service: phpmyadmin:5-apache
- Service name: pma
- Domain: pma.np-dms.work
- หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
* 2.6. Frontend:
- Application name: lcbp3-frontend
- Service: next.js
- Service name: frontend
- Domain: lcbp3.np-dms.work
- Framework: Next.js (App Router, React, TypeScript, ESM)
- Styling: Tailwind CSS + PostCSS
- Component Library: shadcn/ui
- หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
* 2.7. Workflow automation:
- Application name: lcbp3-n8n
- Service: n8nio/n8n:latest
- Service name: n8n
- Domain: n8n.np-dms.work
- หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
* 2.8. Reverse Proxy:
- Application name: lcbp3-npm
- Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
- Service name: npm
- Domain: npm.np-dms.work
- หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
## 📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)
* 3.1. การจัดการโครงสร้างโครงการและองค์กร
- 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
- 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
- 3.1.3. องค์กร (Organizations):
- มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
- Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
* 3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)
- 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects)
- 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
- 3.2.3. การสร้างเอกสาร (Correspondence):
- ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
- เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
- 3.2.4. การอ้างอิงและจัดกลุ่ม:
- เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
- สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
- 3.2.5. การจัดการ: มีการจัดการอย่างน้อยดังนี้
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อเป็นผู้รับ ได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
* 3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)
- 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
- 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
* 3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)
- 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
- 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
* 3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)
- 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
- 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
- Request for Drawing Approval (RFA\_DWG)
- Request for Document Approval (RFA\_DOC)
- Request for Method statement Approval (RFA\_MES)
- Request for Material Approval (RFA\_MAT)
- 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.5.4. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA\_DWG):
- เอกสาร RFA\_DWG จะประกอบไปด้วย Shop Drawing (shop\_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
- Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract\_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
- ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
- 3.6.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
- ส่งจาก Originator -\> Organization 1 -\> Organization 2 -\> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
- 3.6.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
* 3.6.การจัดการเอกสารนำส่ง (Transmittals)
- 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
- 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
- 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
* 3.7. ใบเวียนเอกสารภายใน (Internal Circulation Sheet)
- 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
- 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
- 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
- ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
- ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
- ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
- 3.7.5. การติดตามงาน:
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
- มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
- สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
* 3.8. ประวัติการแก้ไข (Revisions): ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
* **3.9. การจัดเก็บ: (ปรับปรุงตามสถาปัตยกรรมใหม่)**
- เอกสารและไฟล์แนบทั้งหมดจะถูกจัดเก็บในโฟลเดอร์บน Server (`/share/dms-data/`)
- ข้อมูล Metadata ของไฟล์ (เช่น ชื่อไฟล์, ขนาด, path) จะถูกเก็บในตาราง `attachments` (ตารางกลาง)
- ไฟล์จะถูกเชื่อมโยงกับเอกสารประเภทต่างๆ ผ่านตารางเชื่อม (Junction tables) เช่น `correspondence_attachments`, `circulation_attachments`, และ `shop_drawing_revision_attachments`
- สถาปัตยกรรมแบบรวมศูนย์นี้ *แทนที่* แนวคิดเดิมที่จะแยกโฟลเดอร์ตามประเภทเอกสาร เพื่อรองรับการขยายระบบที่ดีกว่า
## 🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)
* 4.1. ภาพรวม: ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
* 4.2. ระดับของสิทธิ์:
- Global Roles: สิทธิ์ในภาพรวมของระบบ
- Project-Specific Roles: สิทธิ์ที่ถูกกำหนดให้ผู้ใช้สำหรับโครงการนั้นๆ โดยเฉพาะ (เช่น เป็น Editor ในโครงการ A แต่เป็น Viewer ในโครงการ B)
- Contract-Specific Roles: สิทธิ์ที่ถูกกำหนดให้โครงการสำหรับสัญญานั้นๆ (เช่น เป็น Admin ในสัญญา 1 จะเป็น Admin ใน โครงการ A และ ฺB ที่อยู่ในสัญญา 1)
* 4.3. บทบาท (Roles) พื้นฐาน:
- Superadmin: ไม่มีข้อจำกัดใดๆ สามารถจัดการได้ทุกอย่างข้ามองค์กร
- Admin: มีสิทธิ์เต็มที่ แต่จำกัดเฉพาะในองค์กรที่ตัวเองสังกัด สามารถจัดการผู้ใช้ในองค์กรได้ สามารถสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลังผ่านหน้า Admin
- Document Control สามารถ เพิ่ม/แก้ไข/ลบ เอกสาร เฉพาะในองค์กรที่ตัวเองสังกัด ไม่สามารถจัดการผู้ใช้ได้
- Editor: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนดไว้ เฉพาะในองค์กรที่ตัวเองสังกัด
- Viewer: สามารถดู เอกสาร เฉพาะในองค์กรที่ตัวเองสังกัด
* 4.4. การบังคับใช้สิทธิ์: สิทธิ์ขององค์กรจะครอบคลุมสิทธิ์ของผู้ใช้ และการเข้าถึงข้อมูลที่เกี่ยวข้องกับโครงการ (เช่น การแก้ไขเอกสาร) จะถูกตรวจสอบเทียบกับสิทธิ์ที่ผู้ใช้มีในโครงการนั้นๆ โดยเฉพาะ
## 👥 5. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)
* 5.1. Layout หลัก: หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
* 5.2. หน้า Landing Page: เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
* 5.3. หน้า Dashboard: เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
* 5.4. การติดตามสถานะ: องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
* 5.5. การจัดการข้อมูลส่วนตัว (Profile Page): ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
* 5.6. การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow): ผู้ใช้สามารถดู Technical Document ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ admin ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ admin ขึ้นไป
## 6\. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)
* 6.1. การบันทึกการกระทำ (Audit Log): ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน `audit_logs` เพื่อการตรวจสอบย้อนหลัง
* 6.2. การค้นหา (Search): ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสารจากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
* 6.3. การทำรายงาน (Reporting): สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
* 6.4. ประสิทธิภาพ (Performance): มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
* 6.5. ความปลอดภัย (Security):
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด

View File

@@ -0,0 +1,55 @@
# Documents Management Sytem Version 1.1.0: Application Databases Specification
## 1. วัตถุประสงค์
## 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)
correspondences ตารางเอกสารโต้ตอบ
-- 2.7.5 : n.n.5 for shop_drawing
shop_drawings;
-- 2.6.6 : n.n.6 for contract_drawing
contract_drawings;
-- 2.5.2 : n.n.2 for rfa
rfas;
-- 2.4.4 : n.n.4 for transmittal
transmittals;
-- 2.3.3: n.n.3 for circulation
circulations;
users;
-- 4.7
projects ตารางโครงการ
-- 4.6
contracts ตารางสัญญา
-- 4.2
permissions;
-- 4.1
roles;
-- Level 5: ตารางที่เป็นรากฐานที่สุด
-- 5.2
organizations ตารางองกรณ์;
-- 5.1
organization_roles;
-- 1.2
attachments;
-- 1.1
global_default_roles;
audit_logs;
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
* 2.1. Infrastructure & Environment:
- Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
- Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
- Development Environment: VS Code on Windows 11
- Domain: np-dms.work, www.np-dms.work
- ip: 159.192.126.103
- Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
- Data Storage: /share/dms-data บน QNAP
- ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
*

View File

@@ -0,0 +1,682 @@
# **สรุปตารางฐานข้อมูล (Data Dictionary) \- LCBP3-DMS**
เอกสารนี้สรุปโครงสร้างตาราง, Foreign Keys (FK), และ Constraints ที่สำคัญทั้งหมดในฐานข้อมูล LCBP3-DMS (v1.1.1) เพื่อใช้เป็นเอกสารอ้างอิงสำหรับทีมพัฒนา Backend (NestJS) และ Frontend (Next.js)
## **1\. 🏢 Core & Master Data (องค์กร, โครงการ, สัญญา)**
#### **1.1. organization\_roles**
ตาราง Master เก็บประเภทบทบาทขององค์กร (เช่น OWNER, CONTRACTOR)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| role\_name | VARCHAR(20) | UK | ชื่อบทบาท (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD PARTY) |
* **Unique Keys (UK):** ux\_roles\_name (role\_name)
#### **1.2. organizations**
ตาราง Master เก็บข้อมูลองค์กรทั้งหมดที่เกี่ยวข้องในระบบ
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| organization\_code | VARCHAR(20) | UK | รหัสองค์กร |
| organization\_name | VARCHAR(255) | | ชื่อองค์กร |
| role\_id | INT | FK | บทบาทขององค์กร (FK \-\> organization\_roles(id)) |
| is\_active | BOOLEAN | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* role\_id \-\> organization\_roles(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_organizations\_code (organization\_code)
#### **1.3. projects**
ตาราง Master เก็บข้อมูลโครงการ (เช่น LCBP3C1, LCBP3C2)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| project\_code | VARCHAR(50) | UK | รหัสโครงการ |
| project\_name | VARCHAR(255) | | ชื่อโครงการ |
| parent\_project\_id | INT | FK | รหัสโครงการหลัก (ถ้ามี) (FK \-\> projects(id)) |
| contractor\_organization\_id | INT | FK | รหัสองค์กรผู้รับเหมา (ถ้ามี) (FK \-\> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* parent\_project\_id \-\> projects(id) (ON DELETE SET NULL)
* contractor\_organization\_id \-\> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_pro\_code (project\_code)
#### **1.4. contracts**
ตาราง Master เก็บข้อมูลสัญญา
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| contract\_code | VARCHAR(50) | UK | รหัสสัญญา |
| contract\_name | VARCHAR(255) | | ชื่อสัญญา |
| description | TEXT | | คำอธิบายสัญญา |
* **Unique Keys (UK):** ux\_contracts\_code (contract\_code)
#### **1.5. project\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง โครงการ, องค์กร, และบทบาท (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-\> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-\> organizations(id)) |
| role | ENUM(...) | **PK** | บทบาทในโครงการ (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD\_PARTY) |
| is\_contractor | TINYINT(1) | UK | (Generated) \= 1 ถ้า role \= 'CONTRACTOR' |
* **Foreign Keys (FK):**
* project\_id \-\> projects(id) (ON DELETE CASCADE)
* organization\_id \-\> organizations(id) (ON DELETE RESTRICT)
* **Unique Keys (UK):**
* uq\_project\_parties\_contractor (project\_id, is\_contractor) \- **(Constraint สำคัญ)** บังคับว่า 1 โครงการมี CONTRACTOR ได้เพียง 1 องค์กร (ตาม Req 3.1.3)
#### **1.6. contract\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง สัญญา, โครงการ, และองค์กร (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| contract\_id | INT | **PK**, FK | ID ของสัญญา (FK \-\> contracts(id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-\> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-\> organizations(id)) |
* **Foreign Keys (FK):**
* contract\_id \-\> contracts(id) (ON DELETE CASCADE)
* project\_id \-\> projects(id) (ON DELETE CASCADE)
* organization\_id \-\> organizations(id) (ON DELETE CASCADE)
## **2\. 👥 Users & RBAC (ผู้ใช้, สิทธิ์, บทบาท)**
#### **2.1. users**
ตาราง Master เก็บข้อมูลผู้ใช้งาน (User)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| user\_id | INT | **PK** | ID ของตาราง |
| username | VARCHAR(50) | UK | ชื่อผู้ใช้งาน |
| password\_hash | VARCHAR(255) | | รหัสผ่าน (Hashed) |
| first\_name | VARCHAR(50) | | ชื่อจริง |
| last\_name | VARCHAR(50) | | นามสกุล |
| email | VARCHAR(100) | UK | อีเมล |
| organization\_id | INT | FK | สังกัดองค์กร (FK \-\> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* organization\_id \-\> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_users\_username (username), ux\_users\_email (email)
#### **2.2. roles**
ตาราง Master เก็บ "บทบาท" ของผู้ใช้ในระบบ (เช่น SUPER\_ADMIN, ADMIN, EDITOR)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| role\_id | INT | **PK** | ID ของตาราง |
| role\_code | VARCHAR(50) | UK | รหัสบทบาท (เช่น SUPER\_ADMIN, ADMIN, EDITOR, VIEWER) |
| role\_name | VARCHAR(100) | | ชื่อบทบาท |
| is\_system | BOOLEAN | | (1 \= บทบาทของระบบ ลบไม่ได้) |
* **Unique Keys (UK):** role\_code
#### **2.3. permissions**
ตาราง Master เก็บ "สิทธิ์" (Permission) หรือ "การกระทำ" ทั้งหมดในระบบ
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| permission\_id | INT | **PK** | ID ของตาราง |
| permission\_code | VARCHAR(100) | UK | รหัสสิทธิ์ (เช่น rfas.create, rfas.view) |
| module | VARCHAR(50) | | โมดูลที่เกี่ยวข้อง |
| scope\_level | ENUM(...) | | ระดับของสิทธิ์ (GLOBAL, ORG, PROJECT) |
* **Unique Keys (UK):** ux\_permissions\_code (permission\_code)
#### **2.4. role\_permissions (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง roles และ permissions (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-\> roles(role\_id)) |
| permission\_id | INT | **PK**, FK | ID ของสิทธิ์ (FK \-\> permissions(permission\_id)) |
* **Foreign Keys (FK):**
* role\_id \-\> roles(role\_id) (ON DELETE CASCADE)
* permission\_id \-\> permissions(permission\_id) (ON DELETE CASCADE)
#### **2.5. user\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Global** (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-\> users(user\_id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-\> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-\> users(user\_id) (ON DELETE CASCADE)
* role\_id \-\> roles(role\_id) (ON DELETE CASCADE)
#### **2.6. user\_project\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Project-Specific** (M:N) (Req 4.2)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-\> users(user\_id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-\> projects(id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-\> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-\> users(user\_id) (ON DELETE CASCADE)
* project\_id \-\> projects(id) (ON DELETE CASCADE)
* role\_id \-\> roles(role\_id) (ON DELETE CASCADE)
## **3\. ✉️ Correspondences (เอกสารหลัก, Revisions)**
#### **3.1. correspondence\_types**
ตาราง Master เก็บประเภทเอกสารโต้ตอบ (เช่น RFA, RFI, LETTER, MOM)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| type\_code | VARCHAR(50) | UK | รหัสประเภท (เช่น RFA, RFI) |
| type\_name | VARCHAR(255) | | ชื่อประเภท |
* **Unique Keys (UK):** type\_code
#### **3.2. correspondence\_status**
ตาราง Master เก็บสถานะของเอกสาร (เช่น DRAFT, SUBMITTED, CLOSED)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| status\_code | VARCHAR(50) | UK | รหัสสถานะ (เช่น DRAFT, SUBOWN) |
| status\_name | VARCHAR(255) | | ชื่อสถานะ |
* **Unique Keys (UK):** status\_code
#### **3.3. correspondences (Master)**
ตาราง "แม่" ของเอกสารโต้ตอบ เก็บข้อมูลที่ไม่เปลี่ยนแปลงตาม Revision (เช่น เลขที่เอกสาร)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง (นี่คือ "Master ID" ที่ใช้เชื่อมโยง) |
| correspondence\_number | VARCHAR(100) | UK | เลขที่เอกสาร (สร้างจาก DocumentNumberingModule) |
| correspondence\_type\_id | INT | FK | ประเภทเอกสาร (FK \-\> correspondence\_types(id)) |
| is\_internal\_communication | TINYINT(1) | | (1 \= ภายใน, 0 \= ภายนอก) |
| project\_id | INT | FK | อยู่ในโครงการ (FK \-\> projects(id)) |
| originator\_id | INT | FK | องค์กรผู้ส่ง (FK \-\> organizations(id)) |
| recipient\_id | INT | FK | องค์กรผู้รับ (FK \-\> organizations(id)) |
| created\_by | INT | FK | ผู้สร้าง (FK \-\> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* correspondence\_type\_id \-\> correspondence\_types(id) (ON DELETE RESTRICT)
* project\_id \-\> projects(id) (ON DELETE CASCADE)
* originator\_id \-\> organizations(id) (ON DELETE SET NULL)
* recipient\_id \-\> organizations(id) (ON DELETE SET NULL)
* created\_by \-\> users(user\_id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_corr\_no\_per\_project (project\_id, correspondence\_number)
#### **3.4. correspondence\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติการแก้ไข (Revisions) ของ correspondences (1:N) **(ปรับปรุง)** id เป็น PK ใหม่ เพื่อรองรับ 1:N
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK, UK | Master ID (FK \-\> correspondences(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| revision\_label | VARCHAR(10) | | Revision ที่แสดง (เช่น A, B, 1.1) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| correspondence\_status\_id | INT | FK | สถานะของ Revision นี้ (FK \-\> correspondence\_status(id)) |
| title | VARCHAR(255) | | เรื่อง |
| document\_date | DATE | | วันที่ในเอกสาร |
| issued\_date | DATETIME | | วันที่ออกเอกสาร |
| received\_date | DATETIME | | วันที่ลงรับ |
| due\_date | DATETIME | | **(ไม่สอดคล้องกับ Req 3.2.5)** วันที่ครบกำหนด (ควรย้ายไป correspondence\_recipients) |
| details | JSON | | ข้อมูลเฉพาะ (เช่น RFI details) |
| created\_by | INT | FK | ผู้สร้าง (FK \-\> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-\> correspondences(id) (ON DELETE CASCADE)
* correspondence\_status\_id \-\> correspondence\_status(id) (ON DELETE RESTRICT)
* created\_by \-\> users(user\_id) (ON DELETE SET NULL)
* **Unique Keys (UK):**
* uq\_master\_revision\_number (correspondence\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_master\_current (correspondence\_id, is\_current) (ป้องกันการมี is\_current \= TRUE ซ้ำใน Master เดียว)
* **Check Constraints (CHK):** chk\_rev\_format (ตรวจสอบรูปแบบ revision\_label)
#### **3.5. correspondence\_recipients (ตารางเชื่อม)**
ตารางเชื่อมผู้รับ (TO/CC) สำหรับเอกสารแต่ละฉบับ (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-\> correspondence\_revisions(correspondence\_id)) |
| recipient\_organization\_id | INT | **PK**, FK | ID องค์กรผู้รับ (FK \-\> organizations(id)) |
| recipient\_type | ENUM('TO', 'CC') | **PK** | ประเภทผู้รับ (TO หรือ CC) |
* **Foreign Keys (FK):**
* correspondence\_id \-\> correspondence\_revisions(correspondence\_id) (ON DELETE CASCADE)
* recipient\_organization\_id \-\> organizations(id) (ON DELETE RESTRICT)
#### **3.6. correspondence\_references (ตารางเชื่อม)**
ตารางเชื่อมการอ้างอิงระหว่างเอกสาร (M:N) (Req 3.2.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| src\_correspondence\_id | INT | **PK**, FK | ID เอกสารต้นทาง (FK \-\> correspondences(id)) |
| tgt\_correspondence\_id | INT | **PK**, FK | ID เอกสารเป้าหมาย (FK \-\> correspondences(id)) |
* **Foreign Keys (FK):**
* src\_correspondence\_id \-\> correspondences(id) (ON DELETE CASCADE)
* tgt\_correspondence\_id \-\> correspondences(id) (ON DELETE CASCADE)
#### **3.7. correspondence\_routing\_templates / ...\_steps / ...\_routings**
ตารางที่เกี่ยวข้องกับ Workflow การส่งต่อเอกสาร (Req 3.5.4)
* **correspondence\_routing\_templates:** ตาราง Master เก็บแม่แบบสายงาน (เช่น "ส่งให้ CSC ตรวจสอบ")
* **correspondence\_routing\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: ส่งไป Org A, Step 2: ส่งไป Org B)
* **correspondence\_routings:** ตารางประวัติ (Log) การส่งต่อของเอกสารจริงตาม Workflow
## **4\. approval: RFA (เอกสารขออนุมัติ, Workflows)**
#### **4.1. rfa\_types / ...\_status\_codes / ...\_approve\_codes**
ตาราง Master สำหรับ RFA
* **rfa\_types:** ประเภท RFA (เช่น DWG, DOC, MAT) (Req 3.5.2)
* **rfa\_status\_codes:** สถานะ RFA (เช่น DFT \- Draft, FAP \- For Approve)
* **rfa\_approve\_codes:** รหัสผลการอนุมัติ (เช่น 1A \- Approved, 3R \- Revise and Resubmit)
#### **4.2. rfas (Master)**
ตาราง "แม่" ของ RFA (มีความสัมพันธ์ 1:N กับ rfa\_revisions)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง (RFA Master ID) |
| rfa\_type\_id | INT | FK | ประเภท RFA (FK \-\> rfa\_types(id)) |
| revision\_number | INT | | หมายเลข Revision ล่าสุด (ควรย้ายไป rfa\_revisions) |
| created\_by | INT | FK | ผู้สร้าง (FK \-\> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* rfa\_type\_id \-\> rfa\_types(id)
* created\_by \-\> users(user\_id) (ON DELETE SET NULL)
#### **4.3. rfa\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ rfas (1:N) **(ปรับปรุง)** id เป็น PK ใหม่ เพื่อรองรับ 1:N
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK | Master ID ของ Correspondence (FK \-\> correspondences(id)) |
| rfa\_id | INT | FK, UK | Master ID ของ RFA (FK \-\> rfas(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| rfa\_status\_code\_id | INT | FK | สถานะ RFA (FK \-\> rfa\_status\_codes(id)) |
| rfa\_approve\_code\_id | INT | FK | ผลการอนุมัติ (FK \-\> rfa\_approve\_codes(id)) |
| title | VARCHAR(255) | | เรื่อง |
| due\_date | DATETIME | | **(ไม่สอดคล้องกับ Req 3.6.6)** วันที่ครบกำหนด (ควรย้ายไป rfa\_workflows) |
| created\_by | INT | FK | ผู้สร้าง (FK \-\> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-\> correspondences(id) (ON DELETE CASCADE)
* rfa\_id \-\> rfas(id) (ON DELETE CASCADE)
* rfa\_status\_code\_id \-\> rfa\_status\_codes(id)
* rfa\_approve\_code\_id \-\> rfa\_approve\_codes(id) (ON DELETE SET NULL)
* created\_by \-\> users(user\_id) (ON DELETE SET NULL)
* **Unique Keys (UK):**
* uq\_rr\_rev\_number (rfa\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_rr\_current (rfa\_id, is\_current) (ป้องกัน is\_current=TRUE ซ้ำใน Master เดียว)
#### **4.4. rfa\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง rfa\_revisions (ที่เป็นประเภท DWG) กับ shop\_drawing\_revisions (M:N) (Req 3.5.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| rfarev\_correspondence\_id | INT | **PK**, FK | ID ของ RFA Revision (FK \-\> rfa\_revisions(correspondence\_id)) |
| shop\_drawing\_revision\_id | INT | **PK**, UK, FK | ID ของ Shop Drawing Revision (FK \-\> shop\_drawing\_revisions(id)) |
* **Foreign Keys (FK):**
* rfarev\_correspondence\_id \-\> rfa\_revisions(correspondence\_id) (ON DELETE CASCADE)
* shop\_drawing\_revision\_id \-\> shop\_drawing\_revisions(id) (ON DELETE CASCADE)
#### **4.5. rfa\_workflow\_templates / ...\_steps / ...\_workflows**
ตารางที่เกี่ยวข้องกับ Workflow การอนุมัติ RFA (Req 3.6.5)
* **rfa\_workflow\_templates:** ตาราง Master เก็บแม่แบบสายอนุมัติ (เช่น "สายอนุมัติ 3 ขั้นตอน")
* **rfa\_workflow\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: Org A (Review), Step 2: Org B (Approve))
* **rfa\_workflows:** ตารางประวัติ (Log) การอนุมัติของ RFA จริงตามสายงาน
## **5\. 📐 Drawings (แบบ, หมวดหมู่)**
#### **5.1. contract\_drawing\_volumes / ...\_cats / ...\_sub\_cats / ...\_subcat\_cat\_maps**
ตาราง Master สำหรับ "แบบคู่สัญญา" (Contract Drawings) (Req 3.3)
* **contract\_drawing\_volumes:** เก็บ "เล่ม" ของแบบ
* **contract\_drawing\_cats:** เก็บ "หมวดหมู่หลัก" ของแบบ
* **contract\_drawing\_sub\_cats:** เก็บ "หมวดหมู่ย่อย" ของแบบ
* **contract\_drawing\_subcat\_cat\_maps:** ตารางเชื่อมระหว่าง หมวดหมู่หลัก-ย่อย (M:N)
#### **5.2. contract\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบคู่สัญญา" (Req 3.3.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-\> projects(id)) |
| condwg\_no | VARCHAR(255) | UK | เลขที่แบบสัญญา |
| title | VARCHAR(255) | | ชื่อแบบ |
| sub\_cat\_id | INT | FK | หมวดหมู่ย่อย (FK \-\> contract\_drawing\_sub\_cats(id)) |
| volume\_id | INT | FK | เล่ม (FK \-\> contract\_drawing\_volumes(id)) |
* **Foreign Keys (FK):**
* fk\_condwg\_project (project\_id) \-\> projects(id) (ON DELETE CASCADE)
* fk\_condwg\_subcat\_same\_project (project\_id, sub\_cat\_id) \-\> contract\_drawing\_sub\_cats(project\_id, id)
* fk\_condwg\_volume\_same\_project (project\_id, volume\_id) \-\> contract\_drawing\_volumes(project\_id, id)
* **Unique Keys (UK):** ux\_condwg\_no\_project (project\_id, condwg\_no)
#### **5.3. shop\_drawing\_main\_categories / ...\_sub\_categories**
ตาราง Master สำหรับ "แบบก่อสร้าง" (Shop Drawings) (Req 3.4)
* **shop\_drawing\_main\_categories:** เก็บ "หมวดหมู่หลัก" (เช่น ARCH, STR)
* **shop\_drawing\_sub\_categories:** เก็บ "หมวดหมู่ย่อย" (เช่น STR-COLUMN)
#### **5.4. shop\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบก่อสร้าง" (Req 3.4.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK | โครงการ (FK \-\> projects(id)) |
| drawing\_number | VARCHAR(100) | UK | เลขที่ Shop Drawing |
| title | VARCHAR(500) | | ชื่อแบบ |
| main\_category\_id | INT | FK | หมวดหมู่หลัก (FK \-\> shop\_drawing\_main\_categories(id)) |
| sub\_category\_id | INT | FK | หมวดหมู่ย่อย (FK \-\> shop\_drawing\_sub\_categories(id)) |
* **Foreign Keys (FK):** project\_id, main\_category\_id, sub\_category\_id
* **Unique Keys (UK):** ux\_sd\_drawing\_number (drawing\_number)
#### **5.5. shop\_drawing\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ shop\_drawings (1:N) **(ปรับปรุง)** ลบ file\_path ออกแล้ว
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของ Revision |
| shop\_drawing\_id | INT | FK, UK | Master ID (FK \-\> shop\_drawings(id)) |
| revision\_number | VARCHAR(10) | UK | หมายเลข Revision (เช่น A, B, 0, 1\) |
| revision\_date | DATE | | วันที่ของ Revision |
| description | TEXT | | คำอธิบายการแก้ไข |
* **Foreign Keys (FK):**
* shop\_drawing\_id \-\> shop\_drawings(id) (ON DELETE CASCADE)
* **Unique Keys (UK):** ux\_sd\_rev\_drawing\_revision (shop\_drawing\_id, revision\_number)
#### **5.6. shop\_drawing\_revision\_contract\_refs (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง shop\_drawing\_revisions กับ contract\_drawings (M:N) (Req 3.5.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| shop\_drawing\_revision\_id | INT | FK | ID ของ Shop Drawing Revision (FK \-\> shop\_drawing\_revisions(id)) |
| contract\_drawing\_id | INT | FK | ID ของ Contract Drawing (FK \-\> contract\_drawings(id)) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, contract\_drawing\_id
## **6\. 🔄 Circulations (ใบเวียนภายใน)**
#### **6.1. circulation\_status\_codes**
ตาราง Master เก็บสถานะใบเวียน (เช่น OPEN, IN\_REVIEW, COMPLETED)
#### **6.2. circulations (Master)**
ตาราง "แม่" ของใบเวียนเอกสารภายใน (Req 3.7)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| correspondence\_id | INT | UK, FK | เอกสารที่ใช้อ้างอิง (FK \-\> correspondences(id)) |
| organization\_id | INT | FK, UK | องค์กรเจ้าของใบเวียน (FK \-\> organizations(id)) |
| circulation\_no | VARCHAR(100) | UK | เลขที่ใบเวียน |
| circulation\_subject | VARCHAR(500) | | เรื่อง |
| circulation\_status\_code | VARCHAR(20) | FK | สถานะใบเวียน (FK \-\> circulation\_status\_codes(code)) |
| created\_by\_user\_id | INT | FK | ผู้สร้าง (FK \-\> users(user\_id)) |
* **Foreign Keys (FK):** correspondence\_id, organization\_id, circulation\_status\_code, created\_by\_user\_id
* **Unique Keys (UK):**
* correspondence\_id (1 ใบเวียน ต่อ 1 เอกสาร)
* uq\_cir\_org\_no (organization\_id, circulation\_no) (เลขที่ใบเวียนห้ามซ้ำในองค์กร)
#### **6.3. circulation\_recipients / ...\_assignees / ...\_actions**
ตาราง "ลูก" ของ circulations
* **circulation\_recipients:** รายชื่อผู้รับ (TO/CC) ภายในองค์กร
* **circulation\_assignees:** รายชื่อผู้รับผิดชอบ (MAIN, ACTION, INFO) (Req 3.7.4) และเก็บ deadline (Req 3.7.5)
* **circulation\_actions:** ประวัติการดำเนินการ (เช่น Comment, Forward, Close)
* **circulation\_action\_documents:** ตารางเชื่อม circulation\_actions กับ attachments (ไฟล์แนบระหว่างดำเนินการ)
#### **6.4. circulation\_templates / ...\_assignees**
ตารางสำหรับแม่แบบใบเวียน (Templates)
* **circulation\_templates:** ตาราง Master เก็บแม่แบบใบเวียน
* **circulation\_template\_assignees:** ตารางลูก เก็บผู้รับผิดชอบที่กำหนดไว้ล่วงหน้าในแม่แบบ
## **7\. 📤 Transmittals (เอกสารนำส่ง)**
#### **7.1. transmittals**
ตารางข้อมูลเฉพาะของเอกสารนำส่ง (เป็นตารางลูก 1:1 ของ correspondences) (Req 3.6)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-\> correspondences(id)) |
| purpose | ENUM(...) | | วัตถุประสงค์ (FOR\_APPROVAL, FOR\_INFORMATION, ...) |
| remarks | TEXT | | หมายเหตุ |
* **Foreign Keys (FK):** correspondence\_id \-\> correspondences(id) (ON DELETE CASCADE)
#### **7.2. transmittal\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง transmittals และ rfa\_revisions (M:N) (Req 3.6.1)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| transmittal\_id | INT | **PK**, FK | ID ของ Transmittal (FK \-\> transmittals(correspondence\_id)) |
| rfarev\_id | INT | **PK**, FK | ID ของ RFA Revision (FK \-\> rfa\_revisions(correspondence\_id)) |
* **Foreign Keys (FK):**
* transmittal\_id \-\> transmittals(correspondence\_id) (ON DELETE CASCADE)
* rfarev\_id \-\> rfa\_revisions(correspondence\_id) (ON DELETE CASCADE)
* **Unique Keys (UK):** ux\_transmittal\_item (transmittal\_id, rfarev\_id)
## **8\. 📎 File Management (ไฟล์แนบ)**
#### **8.1. attachments (Master)**
ตาราง "กลาง" เก็บไฟล์แนบทั้งหมดของระบบ **(ปรับปรุง)** เป็นตารางกลาง ไม่มี FK ไปยังตารางอื่น
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของไฟล์แนบ |
| original\_filename | VARCHAR(255) | | ชื่อไฟล์ดั้งเดิม |
| stored\_filename | VARCHAR(255) | | ชื่อไฟล์ที่เก็บจริง (ป้องกันซ้ำ) |
| file\_path | VARCHAR(500) | | Path ที่เก็บไฟล์ (บน QNAP /share/dms-data/) |
| mime\_type | VARCHAR(100) | | ประเภทไฟล์ (เช่น application/pdf) |
| file\_size | INT | | ขนาดไฟล์ (bytes) |
| uploaded\_by\_user\_id | INT | FK | ผู้อัปโหลด (FK \-\> users(user\_id)) |
* **Foreign Keys (FK):** uploaded\_by\_user\_id \-\> users(user\_id) (ON DELETE CASCADE)
#### **8.2. correspondence\_attachments (ตารางเชื่อม \- ใหม่)**
ตารางเชื่อม correspondences กับ attachments (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-\> correspondences(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-\> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) (Req 5.7) |
* **Foreign Keys (FK):** correspondence\_id, attachment\_id
#### **8.3. circulation\_attachments (ตารางเชื่อม \- ใหม่)**
ตารางเชื่อม circulations กับ attachments (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| circulation\_id | INT | **PK**, FK | ID ของใบเวียน (FK \-\> circulations(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-\> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** circulation\_id, attachment\_id
#### **8.4. shop\_drawing\_revision\_attachments (ตารางเชื่อม \- ใหม่)**
ตารางเชื่อม shop\_drawing\_revisions กับ attachments (M:N)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| shop\_drawing\_revision\_id | INT | **PK**, FK | ID ของ Drawing Revision (FK \-\> shop\_drawing\_revisions(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-\> attachments(id)) |
| file\_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) (Req 5.7) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, attachment\_id
## **9\. 🔢 Document Numbering (การสร้างเลขที่เอกสาร)**
#### **9.1. document\_number\_formats (ตารางตั้งค่า \- ใหม่)**
ตาราง Master เก็บ "รูปแบบ" Template ของเลขที่เอกสาร (Req 3.10)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-\> projects(id)) |
| correspondence\_type\_id | INT | FK, UK | ประเภทเอกสาร (FK \-\> correspondence\_types(id)) |
| format\_template | VARCHAR(255) | | รูปแบบ Template (เช่น {ORG\_CODE}-{TYPE\_CODE}-{SEQ:4}) |
* **Foreign Keys (FK):** project\_id, correspondence\_type\_id
* **Unique Keys (UK):** uk\_project\_type (project\_id, correspondence\_type\_id)
#### **9.2. document\_number\_counters (ตารางตัวนับ \- ใหม่)**
ตารางเก็บ "ตัวนับ" (Running Number) ล่าสุด (Req 3.10.2)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| project\_id | INT | **PK**, FK | โครงการ (FK \-\> projects(id)) |
| originator\_organization\_id | INT | **PK**, FK | องค์กรผู้ส่ง (FK \-\> organizations(id)) |
| correspondence\_type\_id | INT | **PK**, FK | ประเภทเอกสาร (FK \-\> correspondence\_types(id)) |
| current\_year | INT | **PK** | ปี ค.ศ. ของตัวนับ |
| last\_number | INT | | เลขที่ล่าสุดที่ใช้ไป |
* **Foreign Keys (FK):** project\_id, originator\_organization\_id, correspondence\_type\_id
## **10\. ⚙️ System & Logs (ระบบและ Log)**
#### **10.1. tags**
ตาราง Master เก็บ Tags ทั้งหมดที่ใช้ในระบบ (Req 6.2)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| id | INT | **PK** | ID ของตาราง |
| tag\_name | VARCHAR(100) | UK | ชื่อ Tag |
* **Unique Keys (UK):** ux\_tag\_name (tag\_name)
#### **10.2. correspondence\_tags (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง correspondences และ tags (M:N) (Req 3.2.4)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-\> correspondences(id)) |
| tag\_id | INT | **PK**, FK | ID ของ Tag (FK \-\> tags(id)) |
* **Foreign Keys (FK):** correspondence\_id, tag\_id
#### **10.3. audit\_logs**
ตารางเก็บบันทึกการกระทำของผู้ใช้ (Req 6.1)
| Column | Type | Key | Description |
| :---- | :---- | :---- | :---- |
| audit\_id | BIGINT | **PK** | ID ของ Log |
| user\_id | INT | FK | ผู้กระทำ (FK \-\> users(user\_id)) |
| action | VARCHAR(100) | | การกระทำ (เช่น rfa.create) |
| entity\_type | VARCHAR(50) | | ตาราง/โมดูล (เช่น rfas) |
| entity\_id | VARCHAR(50) | | ID ของสิ่งที่ถูกกระทำ |
| details\_json | JSON | | ข้อมูลเพิ่มเติม |
| ip\_address | VARCHAR(45) | | IP Address |
| created\_at | TIMESTAMP | | เวลาที่กระทำ |
* **Foreign Keys (FK):** user\_id \-\> users(user\_id) (ON DELETE SET NULL)
## **11\. 📋 Views & Procedures (วิว และ โปรซีเดอร์)**
#### **11.1. sp\_get\_next\_document\_number (Procedure)**
**(ใหม่)** Stored Procedure เดียวที่ใช้ในระบบ (Req 2.9.3)
* **หน้าที่:** ดึงเลขที่เอกสารถัดไป (Next Running Number) จากตาราง document\_number\_counters
* **ตรรกะ:** ใช้ SELECT ... FOR UPDATE เพื่อ "ล็อก" แถว ป้องกัน Race Condition (การที่ผู้ใช้ 2 คนได้เลขที่ซ้ำกัน)
#### **11.2. v\_current\_correspondences (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ correspondences ทั้งหมด (ที่ไม่ใช่ RFA)
#### **11.3. v\_current\_rfas (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ rfa\_revisions ทั้งหมด
#### **11.4. v\_user\_tasks (View)**
**(ใหม่)**
* **หน้าที่:** แสดงรายการ "งานของฉัน" (My Tasks) ที่ยังไม่เสร็จ (Req 5.3)
* **ตรรกะ:** JOIN ตาราง circulations กับ circulation\_assignees (ที่ is\_completed \= FALSE)
#### **11.5. v\_audit\_log\_details (View)**
**(ใหม่)**
* **หน้าที่:** แสดง audit\_logs พร้อมข้อมูล username และ email ของผู้กระทำ (Req 6.1)
#### **11.6. v\_user\_all\_permissions (View)**
**(ใหม่)**
* **หน้าที่:** รวมสิทธิ์ทั้งหมด (Global \+ Project) ของผู้ใช้ทุกคน เพื่อให้ Backend ตรวจสอบสิทธิ์ได้ง่าย (Req 4.2)
* **ตรรกะ:** UNION ข้อมูลจาก user\_roles และ user\_project\_roles

View File

@@ -0,0 +1,777 @@
---
# **สรุปตารางฐานข้อมูล (Data Dictionary) - LCBP3-DMS (V1.2.1)**
เอกสารนี้สรุปโครงสร้างตาราง, Foreign Keys (FK), และ Constraints ที่สำคัญทั้งหมดในฐานข้อมูล LCBP3-DMS (v1.2.0) เพื่อใช้เป็นเอกสารอ้างอิงสำหรับทีมพัฒนา Backend (NestJS) และ Frontend (Next.js)
## **1\. 🏢 Core & Master Data (องค์กร, โครงการ, สัญญา)**
#### **1.1. organization\_roles**
ตาราง Master เก็บประเภทบทบาทขององค์กร (เช่น OWNER, CONTRACTOR)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| role\_name | VARCHAR(20) | UK | ชื่อบทบาท (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD PARTY) |
* **Unique Keys (UK):** ux\_roles\_name (role\_name)
#### **1.2. organizations**
ตาราง Master เก็บข้อมูลองค์กรทั้งหมดที่เกี่ยวข้องในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| organization\_code | VARCHAR(20) | UK | รหัสองค์กร |
| organization\_name | VARCHAR(255) | | ชื่อองค์กร |
| role\_id | INT | FK | บทบาทขององค์กร (FK \-> organization\_roles(id)) |
| is\_active | BOOLEAN | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* role\_id \-> organization\_roles(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_organizations\_code (organization\_code)
#### **1.3. projects**
ตาราง Master เก็บข้อมูลโครงการ (เช่น LCBP3C1, LCBP3C2)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_code | VARCHAR(50) | UK | รหัสโครงการ |
| project\_name | VARCHAR(255) | | ชื่อโครงการ |
| parent\_project\_id | INT | FK | รหัสโครงการหลัก (ถ้ามี) (FK \-> projects(id)) |
| contractor\_organization\_id | INT | FK | รหัสองค์กรผู้รับเหมา (ถ้ามี) (FK \-> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* parent\_project\_id \-> projects(id) (ON DELETE SET NULL)
* contractor\_organization\_id \-> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_pro\_code (project\_code)
#### **1.4. contracts**
ตาราง Master เก็บข้อมูลสัญญา
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| contract\_code | VARCHAR(50) | UK | รหัสสัญญา |
| contract\_name | VARCHAR(255) | | ชื่อสัญญา |
| description | TEXT | | คำอธิบายสัญญา |
* **Unique Keys (UK):** ux\_contracts\_code (contract\_code)
#### **1.5. project\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง โครงการ, องค์กร, และบทบาท (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-> organizations(id)) |
| role | ENUM(...) | **PK** | บทบาทในโครงการ (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD\_PARTY) |
| is\_contractor | TINYINT(1) | UK | (Generated) \= 1 ถ้า role \= 'CONTRACTOR' |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* project\_id \-> projects(id) (ON DELETE CASCADE)
* organization\_id \-> organizations(id) (ON DELETE RESTRICT)
* **Unique Keys (UK):**
* uq\_project\_parties\_contractor (project\_id, is\_contractor) \- **(Constraint สำคัญ)** บังคับว่า 1 โครงการมี CONTRACTOR ได้เพียง 1 องค์กร
#### **1.6. contract\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง สัญญา, โครงการ, และองค์กร (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| contract\_id | INT | **PK**, FK | ID ของสัญญา (FK \-> contracts(id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-> organizations(id)) |
* **Foreign Keys (FK):**
* contract\_id \-> contracts(id) (ON DELETE CASCADE)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* organization\_id \-> organizations(id) (ON DELETE CASCADE)
---
## **2\. 👥 Users & RBAC (ผู้ใช้, สิทธิ์, บทบาท)**
#### **2.1. users**
ตาราง Master เก็บข้อมูลผู้ใช้งาน (User)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK** | ID ของตาราง |
| username | VARCHAR(50) | UK | ชื่อผู้ใช้งาน |
| password\_hash | VARCHAR(255) | | รหัสผ่าน (Hashed) |
| first\_name | VARCHAR(50) | | ชื่อจริง |
| last\_name | VARCHAR(50) | | นามสกุล |
| email | VARCHAR(100) | UK | อีเมล |
| organization\_id | INT | FK | สังกัดองค์กร (FK \-> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* organization\_id \-> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_users\_username (username), ux\_users\_email (email)
#### **2.2. roles**
ตาราง Master เก็บ "บทบาท" ของผู้ใช้ในระบบ (เช่น SUPER\_ADMIN, ADMIN, EDITOR)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| role\_id | INT | **PK** | ID ของตาราง |
| role\_code | VARCHAR(50) | UK | รหัสบทบาท (เช่น SUPER\_ADMIN, ADMIN, EDITOR, VIEWER) |
| role\_name | VARCHAR(100) | | ชื่อบทบาท |
| is\_system | BOOLEAN | | (1 \= บทบาทของระบบ ลบไม่ได้) |
* **Unique Keys (UK):** role\_code
#### **2.3. permissions**
ตาราง Master เก็บ "สิทธิ์" (Permission) หรือ "การกระทำ" ทั้งหมดในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| permission\_id | INT | **PK** | ID ของตาราง |
| permission\_code | VARCHAR(100) | UK | รหัสสิทธิ์ (เช่น rfas.create, rfas.view) |
| module | VARCHAR(50) | | โมดูลที่เกี่ยวข้อง |
| scope\_level | ENUM(...) | | ระดับของสิทธิ์ (GLOBAL, ORG, PROJECT) |
* **Unique Keys (UK):** ux\_permissions\_code (permission\_code)
#### **2.4. role\_permissions (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง roles และ permissions (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
| permission\_id | INT | **PK**, FK | ID ของสิทธิ์ (FK \-> permissions(permission\_id)) |
* **Foreign Keys (FK):**
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
* permission\_id \-> permissions(permission\_id) (ON DELETE CASCADE)
#### **2.5. user\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Global** (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user\_id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-> users(user\_id) (ON DELETE CASCADE)
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
#### **2.6. user\_project\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Project-Specific** (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user\_id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-> users(user\_id) (ON DELETE CASCADE)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
---
## **3\. ✉️ Correspondences (เอกสารหลัก, Revisions)**
#### **3.1. correspondence\_types**
ตาราง Master เก็บประเภทเอกสารโต้ตอบ (เช่น RFA, RFI, LETTER, MOM)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| type\_code | VARCHAR(50) | UK | รหัสประเภท (เช่น RFA, RFI) |
| type\_name | VARCHAR(255) | | ชื่อประเภท |
* **Unique Keys (UK):** type\_code
#### **3.2. correspondence\_status**
ตาราง Master เก็บสถานะของเอกสาร (เช่น DRAFT, SUBMITTED, CLOSED)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| status\_code | VARCHAR(50) | UK | รหัสสถานะ (เช่น DRAFT, SUBOWN) |
| status\_name | VARCHAR(255) | | ชื่อสถานะ |
* **Unique Keys (UK):** status\_code
#### **3.3. correspondences (Master)**
ตาราง "แม่" ของเอกสารโต้ตอบ เก็บข้อมูลที่ไม่เปลี่ยนแปลงตาม Revision (เช่น เลขที่เอกสาร)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง (นี่คือ "Master ID" ที่ใช้เชื่อมโยง) |
| correspondence\_number | VARCHAR(100) | UK | เลขที่เอกสาร (สร้างจาก DocumentNumberingModule) |
| correspondence\_type\_id | INT | FK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| is\_internal\_communication | TINYINT(1) | | (1 \= ภายใน, 0 \= ภายนอก) |
| project\_id | INT | FK | อยู่ในโครงการ (FK \-> projects(id)) |
| originator\_id | INT | FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| recipient\_id | INT | FK | องค์กรผู้รับ (FK \-> organizations(id)) |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* correspondence\_type\_id \-> correspondence\_types(id) (ON DELETE RESTRICT)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* originator\_id \-> organizations(id) (ON DELETE SET NULL)
* recipient\_id \-> organizations(id) (ON DELETE SET NULL)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_corr\_no\_per\_project (project\_id, correspondence\_number)
#### **3.4. correspondence\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติการแก้ไข (Revisions) ของ correspondences (1:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK, UK | Master ID (FK \-> correspondences(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| **revision\_label** | **VARCHAR(10)** | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| correspondence\_status\_id | INT | FK | สถานะของ Revision นี้ (FK \-> correspondence\_status(id)) |
| title | VARCHAR(255) | | เรื่อง |
| document\_date | DATE | | วันที่ในเอกสาร |
| issued\_date | DATETIME | | วันที่ออกเอกสาร |
| received\_date | DATETIME | | วันที่ลงรับ |
| **description** | **TEXT** | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| details | JSON | | ข้อมูลเฉพาะ (เช่น RFI details) |
| **created\_at** | **DATETIME** | | **(ใหม่)** วันที่สร้างเอกสาร |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| **updated\_by** | **INT** | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* correspondence\_status\_id \-> correspondence\_status(id) (ON DELETE RESTRICT)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **updated\_by \-> users(user\_id) (ON DELETE SET NULL)**
* **Unique Keys (UK):**
* uq\_master\_revision\_number (correspondence\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_master\_current (correspondence\_id, is\_current) (ป้องกันการมี is\_current \= TRUE ซ้ำใน Master เดียว)
* **Check Constraints (CHK):** chk\_rev\_format (ตรวจสอบรูปแบบ revision\_label)
#### **3.5. correspondence\_recipients (ตารางเชื่อม)**
ตารางเชื่อมผู้รับ (TO/CC) สำหรับเอกสารแต่ละฉบับ (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondence\_revisions(correspondence\_id)) |
| recipient\_organization\_id | INT | **PK**, FK | ID องค์กรผู้รับ (FK \-> organizations(id)) |
| recipient\_type | ENUM('TO', 'CC') | **PK** | ประเภทผู้รับ (TO หรือ CC) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondence\_revisions(correspondence\_id) (ON DELETE CASCADE)
* recipient\_organization\_id \-> organizations(id) (ON DELETE RESTRICT)
#### **3.6. correspondence\_references (ตารางเชื่อม)**
ตารางเชื่อมการอ้างอิงระหว่างเอกสาร (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| src\_correspondence\_id | INT | **PK**, FK | ID เอกสารต้นทาง (FK \-> correspondences(id)) |
| tgt\_correspondence\_id | INT | **PK**, FK | ID เอกสารเป้าหมาย (FK \-> correspondences(id)) |
* **Foreign Keys (FK):**
* src\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* tgt\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
#### **3.7. correspondence\_routing\_templates / ...\_steps / ...\_routings**
ตารางที่เกี่ยวข้องกับ Workflow การส่งต่อเอกสาร (Req 3.5.4)
* **correspondence\_routing\_templates:** ตาราง Master เก็บแม่แบบสายงาน (เช่น "ส่งให้ CSC ตรวจสอบ")
* **correspondence\_routing\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: ส่งไป Org A, Step 2: ส่งไป Org B)
* **correspondence\_routings:** ตารางประวัติ (Log) การส่งต่อของเอกสารจริงตาม Workflow
---
## **4\. approval: RFA (เอกสารขออนุมัติ, Workflows)**
#### **4.1. rfa\_types / ...\_status\_codes / ...\_approve\_codes**
ตาราง Master สำหรับ RFA
* **rfa\_types:** ประเภท RFA (เช่น DWG, DOC, MAT)
* **rfa\_status\_codes:** สถานะ RFA (เช่น DFT \- Draft, FAP \- For Approve)
* **rfa\_approve\_codes:** รหัสผลการอนุมัติ (เช่น 1A \- Approved, 3R \- Revise and Resubmit)
#### **4.2. rfas (Master)**
ตาราง "แม่" ของ RFA (มีความสัมพันธ์ 1:N กับ rfa\_revisions)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง (RFA Master ID) |
| rfa\_type\_id | INT | FK | ประเภท RFA (FK \-> rfa\_types(id)) |
| revision\_number | INT | | หมายเลข Revision ล่าสุด (ข้อมูลนี้ถูกย้ายไป rfa\_revisions) |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* rfa\_type\_id \-> rfa\_types(id)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
#### **4.3. rfa\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ rfas (1:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK | Master ID ของ Correspondence (FK \-> correspondences(id)) |
| rfa\_id | INT | FK, UK | Master ID ของ RFA (FK \-> rfas(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| **revision\_label** | **VARCHAR(10)** | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| rfa\_status\_code\_id | INT | FK | สถานะ RFA (FK \-> rfa\_status\_codes(id)) |
| rfa\_approve\_code\_id | INT | FK | ผลการอนุมัติ (FK \-> rfa\_approve\_codes(id)) |
| title | VARCHAR(255) | | เรื่อง |
| **document\_date** | **DATE** | | **(ใหม่)** วันที่ในเอกสาร |
| **issued\_date** | **DATE** | | **(ใหม่)** วันที่ส่งขออนุมัติ |
| **received\_date** | **DATETIME** | | **(ใหม่)** วันที่ลงรับเอกสาร |
| **approved\_date** | **DATE** | | **(ใหม่)** วันที่อนุมัติ |
| **description** | **TEXT** | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| **created\_at** | **DATETIME** | | **(ใหม่)** วันที่สร้างเอกสาร |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| **updated\_by** | **INT** | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* rfa\_id \-> rfas(id) (ON DELETE CASCADE)
* rfa\_status\_code\_id \-> rfa\_status\_codes(id)
* rfa\_approve\_code\_id \-> rfa\_approve\_codes(id) (ON DELETE SET NULL)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **updated\_by \-> users(user\_id) (ON DELETE SET NULL)**
* **Unique Keys (UK):**
* uq\_rr\_rev\_number (rfa\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_rr\_current (rfa\_id, is\_current) (ป้องกัน is\_current=TRUE ซ้ำใน Master เดียว)
#### **4.4. rfa\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง rfa\_revisions (ที่เป็นประเภท DWG) กับ shop\_drawing\_revisions (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| rfarev\_correspondence\_id | INT | **PK**, FK | ID ของ RFA Revision (FK \-> rfa\_revisions(correspondence\_id)) |
| shop\_drawing\_revision\_id | INT | **PK**, UK, FK | ID ของ Shop Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
* **Foreign Keys (FK):**
* rfarev\_correspondence\_id \-> rfa\_revisions(correspondence\_id) (ON DELETE CASCADE)
* shop\_drawing\_revision\_id \-> shop\_drawing\_revisions(id) (ON DELETE CASCADE)
#### **4.5. rfa\_workflow\_templates / ...\_steps / ...\_workflows**
ตารางที่เกี่ยวข้องกับ Workflow การอนุมัติ RFA
* **rfa\_workflow\_templates:** ตาราง Master เก็บแม่แบบสายอนุมัติ (เช่น "สายอนุมัติ 3 ขั้นตอน")
* **rfa\_workflow\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: Org A (Review), Step 2: Org B (Approve))
* **rfa\_workflows:** ตารางประวัติ (Log) การอนุมัติของ RFA จริงตามสายงาน
---
## **5\. 📐 Drawings (แบบ, หมวดหมู่)**
#### **5.1. contract\_drawing\_volumes / ...\_cats / ...\_sub\_cats**
ตาราง Master สำหรับ "แบบคู่สัญญา" (Contract Drawings)
* **contract\_drawing\_volumes:** เก็บ "เล่ม" ของแบบ
* **contract\_drawing\_cats:** เก็บ "หมวดหมู่หลัก" ของแบบ
* **contract\_drawing\_sub\_cats:** เก็บ "หมวดหมู่ย่อย" ของแบบ
#### **5.2. contract\_drawing\_subcat\_cat\_maps (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อมระหว่าง หมวดหมู่หลัก-ย่อย (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | ID ของโครงการ |
| sub\_cat\_id | INT | **PK**, FK | ID ของหมวดหมู่ย่อย |
| cat\_id | INT | **PK**, FK | ID ของหมวดหมู่หลัก |
* **Foreign Keys (FK) (ตามเจตนา):**
* (project\_id, sub\_cat\_id) \-> contract\_drawing\_sub\_cats(project\_id, id)
* (project\_id, cat\_id) \-> contract\_drawing\_cats(project\_id, id)
* **Unique Keys (UK):**
* ux\_map\_unique (project\_id, sub\_cat\_id, cat\_id)
* ***ข้อสังเกตจาก DBA:*** *สคริปต์ SQL (1.3.6) มีการอ้างอิง FK ไปยังตารางและคอลัมน์ (`contract_dwg_sub_cat(project_id, sub_cat_id)`) ที่ไม่มีอยู่จริง ตารางนี้แสดงตามเจตนาที่ถูกต้อง*
#### **5.3. contract\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบคู่สัญญา"
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| condwg\_no | VARCHAR(255) | UK | เลขที่แบบสัญญา |
| title | VARCHAR(255) | | ชื่อแบบ |
| sub\_cat\_id | INT | FK | หมวดหมู่ย่อย (FK \-> contract\_drawing\_sub\_cats(id)) |
| volume\_id | INT | FK | เล่ม (FK \-> contract\_drawing\_volumes(id)) |
* **Foreign Keys (FK):**
* fk\_condwg\_project (project\_id) \-> projects(id) (ON DELETE CASCADE)
* fk\_condwg\_subcat\_same\_project (project\_id, sub\_cat\_id) \-> contract\_drawing\_sub\_cats(project\_id, id)
* fk\_condwg\_volume\_same\_project (project\_id, volume\_id) \-> contract\_drawing\_volumes(project\_id, id)
* **Unique Keys (UK):** ux\_condwg\_no\_project (project\_id, condwg\_no)
#### **5.4. shop\_drawing\_main\_categories / ...\_sub\_categories**
ตาราง Master สำหรับ "แบบก่อสร้าง" (Shop Drawings)
* **shop\_drawing\_main\_categories:** เก็บ "หมวดหมู่หลัก" (เช่น ARCH, STR)
* **shop\_drawing\_sub\_categories:** เก็บ "หมวดหมู่ย่อย" (เช่น STR-COLUMN)
#### **5.5. shop\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบก่อสร้าง"
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK | โครงการ (FK \-> projects(id)) |
| drawing\_number | VARCHAR(100) | UK | เลขที่ Shop Drawing |
| title | VARCHAR(500) | | ชื่อแบบ |
| main\_category\_id | INT | FK | หมวดหมู่หลัก (FK \-> shop\_drawing\_main\_categories(id)) |
| sub\_category\_id | INT | FK | หมวดหมู่ย่อย (FK \-> shop\_drawing\_sub\_categories(id)) |
* **Foreign Keys (FK):** project\_id, main\_category\_id, sub\_category\_id
* **Unique Keys (UK):** ux\_sd\_drawing\_number (drawing\_number)
#### **5.6. shop\_drawing\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ shop\_drawings (1:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของ Revision |
| shop\_drawing\_id | INT | FK, UK | Master ID (FK \-> shop\_drawings(id)) |
| revision\_number | VARCHAR(10) | UK | หมายเลข Revision (เช่น A, B, 0, 1) |
| revision\_date | DATE | | วันที่ของ Revision |
| description | TEXT | | คำอธิบายการแก้ไข |
* **Foreign Keys (FK):**
* shop\_drawing\_id \-> shop\_drawings(id) (ON DELETE CASCADE)
* **Unique Keys (UK):** ux\_sd\_rev\_drawing\_revision (shop\_drawing\_id, revision\_number)
#### **5.7. shop\_drawing\_revision\_contract\_refs (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง shop\_drawing\_revisions กับ contract\_drawings (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| shop\_drawing\_revision\_id | INT | FK | ID ของ Shop Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
| contract\_drawing\_id | INT | FK | ID ของ Contract Drawing (FK \-> contract\_drawings(id)) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, contract\_drawing\_id
---
## **6\. 🔄 Circulations (ใบเวียนภายใน)**
#### **6.1. circulation\_status\_codes**
ตาราง Master เก็บสถานะใบเวียน (เช่น OPEN, IN\_REVIEW, COMPLETED)
#### **6.2. circulations (Master)**
ตาราง "แม่" ของใบเวียนเอกสารภายใน
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| correspondence\_id | INT | UK, FK | เอกสารที่ใช้อ้างอิง (FK \-> correspondences(id)) |
| organization\_id | INT | FK, UK | องค์กรเจ้าของใบเวียน (FK \-> organizations(id)) |
| circulation\_no | VARCHAR(100) | UK | เลขที่ใบเวียน |
| circulation\_subject | VARCHAR(500) | | เรื่อง |
| circulation\_status\_code | VARCHAR(20) | FK | สถานะใบเวียน (FK \-> circulation\_status\_codes(code)) |
| created\_by\_user\_id | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
* **Foreign Keys (FK):** correspondence\_id, organization\_id, circulation\_status\_code, created\_by\_user\_id
* **Unique Keys (UK):**
* correspondence\_id (1 ใบเวียน ต่อ 1 เอกสาร)
* uq\_cir\_org\_no (organization\_id, circulation\_no) (เลขที่ใบเวียนห้ามซ้ำในองค์กร)
#### **6.3. circulation\_recipients / ...\_assignees / ...\_actions**
ตาราง "ลูก" ของ circulations
* **circulation\_recipients:** รายชื่อผู้รับ (TO/CC) ภายในองค์กร
* **circulation\_assignees:** รายชื่อผู้รับผิดชอบ (MAIN, ACTION, INFO) และเก็บ deadline
* **circulation\_actions:** ประวัติการดำเนินการ (เช่น Comment, Forward, Close)
* **circulation\_action\_documents:** ตารางเชื่อม circulation\_actions กับ attachments (ไฟล์แนบระหว่างดำเนินการ)
#### **6.4. circulation\_templates / ...\_assignees**
ตารางสำหรับแม่แบบใบเวียน (Templates)
* **circulation\_templates:** ตาราง Master เก็บแม่แบบใบเวียน
* **circulation\_template\_assignees:** ตารางลูก เก็บผู้รับผิดชอบที่กำหนดไว้ล่วงหน้าในแม่แบบ
---
## **7\. 📤 Transmittals (เอกสารนำส่ง)**
#### **7.1. transmittals**
ตารางข้อมูลเฉพาะของเอกสารนำส่ง (เป็นตารางลูก 1:1 ของ correspondences)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| purpose | ENUM(...) | | วัตถุประสงค์ (FOR\_APPROVAL, FOR\_INFORMATION, ...) |
| remarks | TEXT | | หมายเหตุ |
* **Foreign Keys (FK):** correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
#### **7.2. transmittal\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง transmittals และเอกสารที่นำส่ง (M:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| **id** | **INT** | **PK** | **(ใหม่)** ID ของรายการ |
| transmittal\_id | INT | **FK**, UK | ID ของ Transmittal (FK \-> transmittals(correspondence\_id)) |
| **item\_correspondence\_id** | **INT** | **FK**, UK | **(เปลี่ยน)** ID ของเอกสารที่แนบไป (FK \-> correspondences(id)) |
| **quantity** | **INT** | | **(ใหม่)** จำนวน |
| **remarks** | **VARCHAR(255)** | | **(ใหม่)** หมายเหตุสำหรับรายการนี้ |
* **Foreign Keys (FK):**
* transmittal\_id \-> transmittals(correspondence\_id) (ON DELETE CASCADE)
* **item\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)**
* **Unique Keys (UK):** ux\_transmittal\_item (transmittal\_id, item\_correspondence\_id)
---
## **8\. 📎 File Management (ไฟล์แนบ)**
#### **8.1. attachments (Master)**
ตาราง "กลาง" เก็บไฟล์แนบทั้งหมดของระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของไฟล์แนบ |
| original\_filename | VARCHAR(255) | | ชื่อไฟล์ดั้งเดิม |
| stored\_filename | VARCHAR(255) | | ชื่อไฟล์ที่เก็บจริง (ป้องกันซ้ำ) |
| file\_path | VARCHAR(500) | | Path ที่เก็บไฟล์ (บน QNAP /share/dms-data/) |
| mime\_type | VARCHAR(100) | | ประเภทไฟล์ (เช่น application/pdf) |
| file\_size | INT | | ขนาดไฟล์ (bytes) |
| uploaded\_by\_user\_id | INT | FK | ผู้อัปโหลด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):** uploaded\_by\_user\_id \-> users(user\_id) (ON DELETE CASCADE)
#### **8.2. correspondence\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม correspondences กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** correspondence\_id, attachment\_id
#### **8.3. circulation\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม circulations กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| circulation\_id | INT | **PK**, FK | ID ของใบเวียน (FK \-> circulations(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** circulation\_id, attachment\_id
#### **8.4. shop\_drawing\_revision\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม shop\_drawing\_revisions กับ attachments (M:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| shop\_drawing\_revision\_id | INT | **PK**, FK | ID ของ Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file\_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| **is\_main\_document** | **BOOLEAN** | | **(ใหม่)** (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, attachment\_id
#### **8.5. contract\_drawing\_attachments (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อม contract\_drawings กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| contract\_drawing\_id | INT | **PK**, FK | ID ของ Contract Drawing (FK \-> contract\_drawings(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file\_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):**
* contract\_drawing\_id \-> contract\_drawings(id) (ON DELETE CASCADE)
* attachment\_id \-> attachments(id) (ON DELETE CASCADE)
---
## **9\. 🔢 Document Numbering (การสร้างเลขที่เอกสาร)**
#### **9.1. document\_number\_formats (ตารางตั้งค่า - ใหม่)**
ตาราง Master เก็บ "รูปแบบ" Template ของเลขที่เอกสาร
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| correspondence\_type\_id | INT | FK, UK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| format\_template | VARCHAR(255) | | รูปแบบ Template (เช่น {ORG\_CODE}-{TYPE\_CODE}-{SEQ:4}) |
* **Foreign Keys (FK):** project\_id, correspondence\_type\_id
* **Unique Keys (UK):** uk\_project\_type (project\_id, correspondence\_type\_id)
#### **9.2. document\_number\_counters (ตารางตัวนับ - ใหม่)**
ตารางเก็บ "ตัวนับ" (Running Number) ล่าสุด
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | โครงการ (FK \-> projects(id)) |
| originator\_organization\_id | INT | **PK**, FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| correspondence\_type\_id | INT | **PK**, FK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| current\_year | INT | **PK** | ปี ค.ศ. ของตัวนับ |
| last\_number | INT | | เลขที่ล่าสุดที่ใช้ไป |
* **Foreign Keys (FK):** project\_id, originator\_organization\_id, correspondence\_type\_id
---
## **10\. ⚙️ System & Logs (ระบบและ Log)**
#### **10.1. tags**
ตาราง Master เก็บ Tags ทั้งหมดที่ใช้ในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| tag\_name | VARCHAR(100) | UK | ชื่อ Tag |
* **Unique Keys (UK):** ux\_tag\_name (tag\_name)
#### **10.2. correspondence\_tags (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง correspondences และ tags (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| tag\_id | INT | **PK**, FK | ID ของ Tag (FK \-> tags(id)) |
* **Foreign Keys (FK):** correspondence\_id, tag\_id
#### **10.3. audit\_logs**
ตารางเก็บบันทึกการกระทำของผู้ใช้
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| audit\_id | BIGINT | **PK** | ID ของ Log |
| user\_id | INT | FK | ผู้กระทำ (FK \-> users(user\_id)) |
| action | VARCHAR(100) | | การกระทำ (เช่น rfa.create) |
| entity\_type | VARCHAR(50) | | ตาราง/โมดูล (เช่น rfas) |
| entity\_id | VARCHAR(50) | | ID ของสิ่งที่ถูกกระทำ |
| details\_json | JSON | | ข้อมูลเพิ่มเติม |
| ip\_address | VARCHAR(45) | | IP Address |
| created\_at | TIMESTAMP | | เวลาที่กระทำ |
* **Foreign Keys (FK):** user\_id \-> users(user\_id) (ON DELETE SET NULL)
#### **10.4. global\_default\_roles (ใหม่)**
ตารางเก็บค่าเริ่มต้นของบทบาทองค์กร (เช่น OWNER, DESIGNER)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | TINYINT | **PK** | ID คงที่ ( \= 1) |
| role | ENUM(...) | **PK** | บทบาท (OWNER, DESIGNER, CONSULTANT) |
| position | TINYINT | **PK** | ลำดับที่ในบทบาท (1..n) |
| organization\_id | INT | FK, UK | ID องค์กร (FK \-> organizations(id)) |
* **Foreign Keys (FK):** organization\_id \-> organizations(id) (ON DELETE RESTRICT)
* **Unique Keys (UK):** ux\_gdr\_unique\_org\_per\_role (id, role, organization\_id)
#### **10.5. Workflow Transition Rules (ใหม่)**
ตารางกำหนด Business Rules สำหรับการเปลี่ยนสถานะ
* **correspondence\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ Correspondences (ทั่วไป)
* **rfa\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ RFA
* **circulation\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ Circulations (ใบเวียน)
---
## **11\. 📋 Views & Procedures (วิว และ โปรซีเดอร์)**
#### **11.1. sp\_get\_next\_document\_number (Procedure)**
**(ใหม่)** Stored Procedure เดียวที่ใช้ในระบบ
* **หน้าที่:** ดึงเลขที่เอกสารถัดไป (Next Running Number) จากตาราง document\_number\_counters
* **ตรรกะ:** ใช้ `SELECT ... FOR UPDATE` เพื่อ "ล็อก" แถว ป้องกัน Race Condition (การที่ผู้ใช้ 2 คนได้เลขที่ซ้ำกัน)
#### **11.2. v\_current\_correspondences (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ correspondences ทั้งหมด (ที่ไม่ใช่ RFA)
#### **11.3. v\_current\_rfas (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ rfa\_revisions ทั้งหมด
#### **11.4. v\_contract\_parties\_all (View)**
* **หน้าที่:** แสดงความสัมพันธ์ทั้งหมดระหว่าง Contract, Project, และ Organization
#### **11.5. v\_user\_tasks (View)**
**(ใหม่)**
* **หน้าที่:** แสดงรายการ "งานของฉัน" (My Tasks) ที่ยังไม่เสร็จ
* **ตรรกะ:** JOIN ตาราง circulations กับ circulation\_assignees (ที่ is\_completed \= FALSE)
#### **11.6. v\_audit\_log\_details (View)**
**(ใหม่)**
* **หน้าที่:** แสดง audit\_logs พร้อมข้อมูล username และ email ของผู้กระทำ
#### **11.7. v\_user\_all\_permissions (View)**
**(ใหม่)**
* **หน้าที่:** รวมสิทธิ์ทั้งหมด (Global \+ Project) ของผู้ใช้ทุกคน เพื่อให้ Backend ตรวจสอบสิทธิ์ได้ง่าย
* **ตรรกะ:** UNION ข้อมูลจาก user\_roles และ user\_project\_roles

View File

@@ -0,0 +1,459 @@
# **Documents Management Sytem Version 1.2.1: แนวทางการพัฒนา FullStackJS**
## **🧠 ปรัชญาทั่วไป**
แนวทางปฏิบัติที่ดีที่สุดแบบครบวงจรสำหรับการพัฒนา NestJS Backend, NextJS Frontend และ Tailwind-based UI/UX ในสภาพแวดล้อม TypeScript มุ่งเน้นที่ ความชัดเจน (clarity), ความง่ายในการบำรุงรักษา (maintainability), ความสอดคล้องกัน (consistency) และ การเข้าถึงได้ (accessibility) ตลอดทั้งสแต็ก
## **⚙️ แนวทางทั่วไปสำหรับ TypeScript**
### **หลักการพื้นฐาน**
* ใช้ **ภาษาอังกฤษ** สำหรับโค้ดและเอกสารทั้งหมด
* กำหนดไทป์ (type) อย่างชัดเจนสำหรับตัวแปร, พารามิเตอร์ และค่าที่ส่งกลับ (return values) ทั้งหมด
* หลีกเลี่ยงการใช้ any; ให้สร้างไทป์ (types) หรืออินเทอร์เฟซ (interfaces) ที่กำหนดเอง
* ใช้ **JSDoc** สำหรับคลาส (classes) และเมธอด (methods) ที่เป็น public
* ส่งออก (Export) **สัญลักษณ์หลัก (main symbol) เพียงหนึ่งเดียว** ต่อไฟล์
* หลีกเลี่ยงบรรทัดว่างภายในฟังก์ชัน
### **ข้อตกลงในการตั้งชื่อ (Naming Conventions)**
| Entity (สิ่งที่ตั้งชื่อ) | Convention (รูปแบบ) | Example (ตัวอย่าง) |
| :---- | :---- | :---- |
| Classes | PascalCase | UserService |
| Variables & Functions | camelCase | getUserInfo |
| Files & Folders | kebab-case | user-service.ts |
| Environment Variables | UPPERCASE | DATABASE\URL |
| Booleans | Verb \+ Noun | isActive, canDelete, hasPermission |
ใช้คำเต็ม — ไม่ใช้อักษรย่อ — ยกเว้นคำมาตรฐาน (เช่น API, URL, req, res, err, ctx)
## **🧩 ฟังก์ชัน (Functions)**
* เขียนฟังก์ชันให้สั้น และทำ **หน้าที่เพียงอย่างเดียว** (single-purpose) (\< 20 บรรทัด)
* ใช้ **early returns** เพื่อลดการซ้อน (nesting) ของโค้ด
* ใช้ **map**, **filter**, **reduce** แทนการใช้ loops เมื่อเหมาะสม
* ควรใช้ **arrow functions** สำหรับตรรกะสั้นๆ, และใช้ **named functions** ในกรณีอื่น
* ใช้ **default parameters** แทนการตรวจสอบค่า null
* จัดกลุ่มพารามิเตอร์หลายตัวให้เป็นอ็อบเจกต์เดียว (RO-RO pattern)
* ส่งค่ากลับ (Return) เป็นอ็อบเจกต์ที่มีไทป์กำหนด (typed objects) ไม่ใช่ค่าพื้นฐาน (primitives)
* รักษาระดับของสิ่งที่เป็นนามธรรม (abstraction level) ให้เป็นระดับเดียวในแต่ละฟังก์ชัน
## **🧱 การจัดการข้อมูล (Data Handling)**
* ห่อหุ้มข้อมูล (Encapsulate) ในไทป์แบบผสม (composite types)
* ใช้ **immutability** (การไม่เปลี่ยนแปลงค่า) ด้วย readonly และ as const
* ทำการตรวจสอบความถูกต้องของข้อมูล (Validations) ในคลาสหรือ DTOs ไม่ใช่ภายในฟังก์ชันทางธุรกิจ
* ตรวจสอบความถูกต้องของข้อมูลโดยใช้ DTOs ที่มีไทป์กำหนดเสมอ
## **🧰 คลาส (Classes)**
* ปฏิบัติตามหลักการ **SOLID**
* ควรใช้ **composition มากกว่า inheritance** (Prefer composition over inheritance)
* กำหนด **interfaces** สำหรับสัญญา (contracts)
* ให้คลาสมุ่งเน้นการทำงานเฉพาะอย่างและมีขนาดเล็ก (\< 200 บรรทัด, \< 10 เมธอด, \< 10 properties)
## **🚨 การจัดการข้อผิดพลาด (Error Handling)**
* ใช้ Exceptions สำหรับข้อผิดพลาดที่ไม่คาดคิด
* ดักจับ (Catch) ข้อผิดพลาดเพื่อแก้ไขหรือเพิ่มบริบท (context) เท่านั้น; หากไม่เช่นนั้น ให้ใช้ global error handlers
* ระบุข้อความข้อผิดพลาด (error messages) ที่มีความหมายเสมอ
## **🧪 การทดสอบ (ทั่วไป) (Testing (General))**
* ใช้รูปแบบ **ArrangeActAssert**
* ใช้ชื่อตัวแปรในการทดสอบที่สื่อความหมาย (inputData, expectedOutput)
* เขียน **unit tests** สำหรับ public methods ทั้งหมด
* จำลอง (Mock) การพึ่งพาภายนอก (external dependencies)
* เพิ่ม **acceptance tests** ต่อโมดูลโดยใช้รูปแบบ GivenWhen-Then
# **🏗️ แบ็กเอนด์ (NestJS) (Backend (NestJS))**
### **หลักการ**
* **สถาปัตยกรรมแบบโมดูลาร์ (Modular architecture)**:
* หนึ่งโมดูลต่อหนึ่งโดเมน
* โครงสร้างแบบ Controller → Service → Repository (Model)
* DTOs ที่ตรวจสอบความถูกต้องด้วย **class-validator**
* ใช้ **MikroORM** (หรือ TypeORM/Prisma) สำหรับการคงอยู่ของข้อมูล (persistence) ซึ่งสอดคล้องกับสคีมา MariaDB
* ห่อหุ้มโค้ดที่ใช้ซ้ำได้ไว้ใน **common module** (@app/common):
* Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators
### **ฟังก์ชันหลัก (Core Functionalities)**
* Global **filters** สำหรับการจัดการ exception
* **Middlewares** สำหรับการจัดการ request
* **Guards** สำหรับการอนุญาต (permissions) และ RBAC
* **Interceptors** สำหรับการแปลงข้อมูล response และการบันทึก log
### **ข้อจำกัดในการ Deploy (QNAP Container Station)**
* **ห้ามใช้ไฟล์ .env** ในการตั้งค่า Environment Variables [cite: 2.1]
* การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน docker-compose.yml โดยตรง** [cite: 6.5] ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station [cite: 2.1]
### **โครงสร้างโมดูลตามโดเมน (Domain-Driven Module Structure)**
เพื่อให้สอดคล้องกับสคีมา SQL (LCBP3-DMS) เราจะใช้โครงสร้างโมดูลแบบ **Domain-Driven (แบ่งตามขอบเขตธุรกิจ)** แทนการแบ่งตามฟังก์ชัน:
1. **CoreModule / CommonModule:**
* เก็บ Services ที่ใช้ร่วมกัน เช่น DatabaseModule, FileStorageService (จัดการไฟล์ใน QNAP), AuditLogService, NotificationService
* NotificationService ต้องรองรับ Triggers ที่ระบุใน Requirement 6.7 [cite: 6.7]
2. **AuthModule / UserModule:**
* จัดการ users, roles, permissions และการยืนยันตัวตน (JWT, Guards)
* **(สำคัญ)** ต้องรับผิดชอบการตรวจสอบสิทธิ์ **3 ระดับ** [cite: 4.2]: สิทธิ์ระดับระบบ (Global Role), สิทธิ์ระดับโปรเจกต์ (Project Role), และ **สิทธิ์ระดับสัญญา (Contract Role)**
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
* จัดการ Master Data (เช่น correspondence_types, tags) [cite: 4.5]
* ให้ Superadmin สร้าง Organizations และกำหนด Org Admin ได้ [cite: 4.6]
* ให้ Superadmin/Admin จัดการ document_number_formats (รูปแบบเลขที่เอกสาร) [cite: 3.10]
3. **ProjectModule:**
* จัดการ projects, organizations, contracts, project_parties, contract_parties
4. **CorrespondenceModule (โมดูลศูนย์กลาง):**
* จัดการ correspondences, correspondence\revisions
* **(สำคัญ)** Service นี้ต้อง Inject DocumentNumberingService เพื่อขอเลขที่เอกสารใหม่ก่อนการสร้าง
* **(สำคัญ)** ตรรกะการสร้าง/อัปเดต Revision จะอยู่ใน Service นี้
* จัดการ correspondence_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Correspondence Routings"** (correspondence\routings) สำหรับการส่งต่อเอกสารทั่วไประหว่างองค์กร
5. **RfaModule:**
* จัดการ rfas, rfa_revisions, rfa_items
* รับผิดชอบเวิร์กโฟลว์ **"RFA Workflows"** (rfa_workflows) สำหรับการอนุมัติเอกสารทางเทคนิค
6. **DrawingModule:**
* จัดการ shop_drawings, shop_drawing_revisions, contract_drawings และหมวดหมู่ต่างๆ
* จัดการ shop_drawing_revision_attachments และ contract_drawing_attachments(ตารางเชื่อมไฟล์แนบ)
7. **CirculationModule:**
* จัดการ circulations, circulation_templates, circulation_assignees
* จัดการ circulation_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Circulations"** สำหรับการเวียนเอกสาร **ภายในองค์กร**
8. **TransmittalModule:**
* จัดการ transmittals และ transmittal_items
9. **SearchModule:**
* ให้บริการค้นหาขั้นสูง (Advanced Search) [cite: 6.2] โดยใช้ **Elasticsearch** เพื่อรองรับการค้นหาแบบ Full-text จากชื่อเรื่อง, รายละเอียด, เลขที่เอกสาร, ประเภท, วันที่, และ Tags
10. **DocumentNumberingModule:**
* **สถานะ:** เป็น Module ภายใน (Internal Module) ไม่เปิด API สู่ภายนอก
* **หน้าที่:** ให้บริการ DocumentNumberingService ที่ Module อื่น (เช่น CorrespondenceModule) จะ Inject ไปใช้งาน
* **ตรรกะ:** รับผิดชอบการสร้างเลขที่เอกสาร โดยการเรียกใช้ Stored Procedure *sp_get_next_document_number** เพื่อป้องกัน Race Condition
### **เครื่องมือและไลบรารีที่แนะนำ (Recommended Tools & Libraries)**
🔐 **Authentication & Authorization**
* @nestjs/passport
* @nestjs/jwt
* casl สำหรับ RBAC (Role-Based Access Control)
🗃️ **Database & ORM**
* @nestjs/typeorm ORM สำหรับ SQL (หรือ Prisma เป็นทางเลือก)
* typeorm-seeding สำหรับสร้างข้อมูลจำลอง (seeding)
📦 **Validation & Transformation**
* class-validator
* class-transformer
📁 **File Upload & Storage**
* @nestjs/platform-express
* multer สำหรับจัดการไฟล์
🔍 **Search**
* @nestjs/elasticsearch สำหรับ Full-text search [cite: 6.2]
📬 **Notification**
* nodemailer สำหรับส่งอีเมล
* @nestjs/schedule สำหรับ cron job หรือแจ้งเตือนตามเวลา
📊 **Logging & Monitoring**
* winston หรือ nestjs-pino ระบบ log ที่ยืดหยุ่น
* @nestjs/terminus สำหรับ health check
🧪 **Testing**
* @nestjs/testing
* jest สำหรับ unit/integration test
🌐 **API Documentation**
* @nestjs/swagger **(สำคัญมาก)** สร้าง Swagger UI อัตโนมัติ ต้องใช้ DTOs อย่างเคร่งครัดเพื่อความชัดเจนของ API สำหรับทีม Frontend
🛡️ **Security**
* helmet ป้องกันช่องโหว่ HTTP
* rate-limiter-flexible ป้องกัน brute force
### **🧪 Backend Testing**
เราจะแบ่งการทดสอบเป็น 3 ระดับ โดยใช้ **Jest** และ @nestjs/testing:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เป้าหมาย:** ทดสอบ Logic ภายใน Service, Guard, หรือ Pipe โดยจำลอง (Mock) Dependencies ทั้งหมด
* **สิ่งที่ต้องทดสอบ:** Business Logic (เช่น การเปลี่ยนสถานะ Workflow, การตรวจสอบ Deadline) [cite: 2.9.1], ตรรกะการตรวจสอบสิทธิ์ (Auth Guard) ทั้ง 3 ระดับ
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เป้าหมาย:** ทดสอบการทำงานร่วมกันของ Controller -> Service -> Repository (Database)
* **เทคนิค:** ใช้ **Test Database แยกต่างหาก** (ห้ามใช้ Dev DB) และใช้ supertest เพื่อยิง HTTP Request จริงไปยัง App
* **สิ่งที่ต้องทดสอบ:** การเรียก sp\get\next\document\number [cite: 2.9.3] และการทำงานของ Views (เช่น v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เป้าหมาย:** ทดสอบ API Contract ว่า Response Body Shape ตรงตามเอกสาร Swagger เพื่อรับประกันทีม Frontend
### **🗄️ Backend State Management**
Backend (NestJS) ควรเป็น **Stateless** (ไม่เก็บสถานะ) "State" ทั้งหมดจะถูกจัดเก็บใน MariaDB
* **Request-Scoped State (สถานะภายใน Request เดียว):**
* **ปัญหา:** จะส่งต่อข้อมูล (เช่น User ที่ล็อกอิน) ระหว่าง Guard และ Service ใน Request เดียวกันได้อย่างไร?
* **วิธีแก้:** ใช้ **Request-Scoped Providers** ของ NestJS (เช่น AuthContextService) เพื่อเก็บข้อมูล User ปัจจุบันที่ได้จาก AuthGuard และให้ Service อื่น Inject ไปใช้
* **Application-Scoped State (การ Caching):**
* **ปัญหา:** ข้อมูล Master (เช่น roles, permissions, organizations) ถูกเรียกใช้บ่อย
* **วิธีแก้:** ใช้ **Caching** (เช่น @nestjs/cache-manager) เพื่อ Caching ข้อมูลเหล่านี้ และลดภาระ Database
# **🖥️ ฟรอนต์เอนด์ (NextJS / React / UI) (Frontend (NextJS / React / UI))**
### **โปรไฟล์นักพัฒนา (Developer Profile)**
วิศวกร TypeScript + React/NextJS ระดับ Senior
เชี่ยวชาญ TailwindCSS, Shadcn/UI, และ Radix สำหรับการพัฒนา UI
### **แนวทางการพัฒนาโค้ด (Code Implementation Guidelines)**
* ใช้ **early returns** เพื่อความชัดเจน
* ใช้คลาสของ **TailwindCSS** ในการกำหนดสไตล์เสมอ
* ควรใช้ class: syntax แบบมีเงื่อนไข (หรือ utility clsx) มากกว่าการใช้ ternary operators ใน class strings
* ใช้ **const arrow functions** สำหรับ components และ handlers
* Event handlers ให้ขึ้นต้นด้วย handle... (เช่น handleClick, handleSubmit)
* รวมแอตทริบิวต์สำหรับการเข้าถึง (accessibility) ด้วย:
tabIndex="0", aria-label, onKeyDown, ฯลฯ
* ตรวจสอบให้แน่ใจว่าโค้ดทั้งหมด **สมบูรณ์**, **ผ่านการทดสอบ**, และ **ไม่ซ้ำซ้อน (DRY)**
* ต้อง import โมดูลที่จำเป็นต้องใช้อย่างชัดเจนเสมอ
### **UI/UX ด้วย React**
* ใช้ **semantic HTML**
* ใช้คลาสของ **Tailwind** ที่รองรับ responsive (sm:, md:, lg:)
* รักษาลำดับชั้นของการมองเห็น (visual hierarchy) ด้วยการใช้ typography และ spacing
* ใช้ **Shadcn** components (Button, Input, Card, ฯลฯ) เพื่อ UI ที่สอดคล้องกัน
* ทำให้ components มีขนาดเล็กและมุ่งเน้นการทำงานเฉพาะอย่าง
* ใช้ utility classes สำหรับการจัดสไตล์อย่างรวดเร็ว (spacing, colors, text, ฯลฯ)
* ตรวจสอบให้แน่ใจว่าสอดคล้องกับ **ARIA** และใช้ semantic markup
### **การตรวจสอบฟอร์มและข้อผิดพลาด (Form Validation & Errors)**
* ใช้ไลบรารีฝั่ง client เช่น zod และ react-hook-form
* แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline
* ต้องมี labels, placeholders, และข้อความ feedback
### **🧪 Frontend Testing**
เราจะใช้ **React Testing Library (RTL)** สำหรับการทดสอบ Component และ **Playwright** สำหรับ E2E:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เครื่องมือ:** Vitest + RTL
* **เป้าหมาย:** ทดสอบ Component ขนาดเล็ก (เช่น Buttons, Inputs) หรือ Utility functions
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เครื่องมือ:** RTL + **Mock Service Worker (MSW)**
* **เป้าหมาย:** ทดสอบว่า Component หรือ Page ทำงานกับ API (ที่จำลองขึ้น) ได้ถูกต้อง
* **เทคนิค:** ใช้ MSW เพื่อจำลอง NestJS API และทดสอบว่า Component แสดงผลข้อมูลจำลองได้ถูกต้องหรือไม่ (เช่น ทดสอบหน้า Dashboard [cite: 5.3] ที่ดึงข้อมูลจาก v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เครื่องมือ:** **Playwright**
* **เป้าหมาย:** ทดสอบ User Flow ทั้งระบบโดยอัตโนมัติ (เช่น ล็อกอิน -> สร้าง RFA -> ตรวจสอบ Workflow Visualization [cite: 5.6])
### **🗄️ Frontend State Management**
สำหรับ Next.js App Router เราจะแบ่ง State เป็น 4 ระดับ:
1. **Local UI State (สถานะ UI ชั่วคราว):**
* **เครื่องมือ:** useState, useReducer
* **ใช้เมื่อ:** จัดการสถานะเล็กๆ ที่จบใน Component เดียว (เช่น Modal เปิด/ปิด, ค่าใน Input)
2. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์):**
* **เครื่องมือ:** **React Query (TanStack Query)** หรือ SWR
* **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API (เช่น รายการ correspondences, rfas, drawings)
* **ทำไม:** React Query เป็น "Cache" ที่จัดการ Caching, Re-fetching, และ Invalidation ให้โดยอัตโนมัติ
3. **Global Client State (สถานะส่วนกลางฝั่ง Client):**
* **เครื่องมือ:** **Zustand** (แนะนำ) หรือ Context API
* **ใช้เมื่อ:** จัดการข้อมูลที่ต้องใช้ร่วมกันทั่วทั้งแอป และ *ไม่ใช่* ข้อมูลจากเซิร์ฟเวอร์ (เช่น ข้อมูล User ที่ล็อกอิน, สิทธิ์ Permissions)
4. **Form State (สถานะของฟอร์ม):**
* **เครื่องมือ:** **React Hook Form** + **Zod**
* **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อน (เช่น ฟอร์มสร้าง RFA, ฟอร์ม Circulation [cite: 3.7])
# **🔗 แนวทางการบูรณาการ Full Stack (Full Stack Integration Guidelines)**
| Aspect (แง่มุม) | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
| :---- | :---- | :---- | :---- |
| API | REST / GraphQL Controllers | API hooks ผ่าน fetch/axios/SWR | Components ที่รับข้อมูล |
| Validation (การตรวจสอบ) | class-validator DTOs | zod / react-hook-form | สถานะของฟอร์ม/input ใน Shadcn |
| Auth (การยืนยันตัวตน) | Guards, JWT | NextAuth / cookies | สถานะ UI ของ Auth (loading, signed in) |
| Errors (ข้อผิดพลาด) | Global filters | Toasts / modals | Alerts / ข้อความ feedback |
| Testing (การทดสอบ) | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles (สไตล์) | Scoped modules (ถ้าจำเป็น) | Tailwind / Shadcn | Tailwind utilities |
| Accessibility (การเข้าถึง) | Guards + filters | ARIA attributes | Semantic HTML |
# **🗂️ ข้อตกลงเฉพาะสำหรับ DMS (LCBP3-DMS)**
ส่วนนี้ขยายแนวทาง FullStackJS ทั่วไปสำหรับโปรเจกต์ **LCBP3-DMS** โดยมุ่งเน้นไปที่เวิร์กโฟลว์การอนุมัติเอกสาร (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation)
## **🧩 RBAC และการควบคุมสิทธิ์ (RBAC & Permission Control)**
ใช้ Decorators เพื่อบังคับใช้สิทธิ์การเข้าถึง โดยอ้างอิงสิทธิ์จากตาราง permissions
@RequirePermission('rfas.respond') // ต้องตรงกับ 'permission\code'
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
### **Roles (บทบาท)**
* **Superadmin**: ไม่มีข้อจำกัดใดๆ [cite: 4.3]
* **Admin**: มีสิทธิ์เต็มที่ในองค์กร [cite: 4.3]
* **Document Control**: เพิ่ม/แก้ไข/ลบ เอกสารในองค์กร [cite: 4.3]
* **Editor**: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนด [cite: 4.3]
* **Viewer**: สามารถดู เอกสาร [cite: 4.3]
### **ตัวอย่าง Permissions (จากตาราง permissions)**
* rfas.view, rfas.create, rfas.respond, rfas.delete
* drawings.view, drawings.upload, drawings.delete
* corr.view, corr.manage
* transmittals.manage
* cirs.manage
* project\parties.manage
การจับคู่ระหว่าง roles และ permissions **เริ่มต้น** จะถูก seed ผ่านสคริปต์ (ดังที่เห็นในไฟล์ SQL)**อย่างไรก็ตาม AuthModule/UserModule ต้องมี API สำหรับ Admin เพื่อสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลัง** [cite: 4.3]
## **🧾 มาตรฐาน AuditLog (AuditLog Standard)**
บันทึกการดำเนินการ CRUD และการจับคู่ทั้งหมดลงในตาราง audit_logs
| Field (ฟิลด์) | Type (จาก SQL) | Description (คำอธิบาย) |
| :---- | :---- | :---- |
| audit_id | BIGINT | Primary Key |
| user_id | INT | ผู้ใช้ที่ดำเนินการ (FK -> users) |
| action | VARCHAR(100) | rfa.create, correspondence.update, login.success |
| entity_type | VARCHAR(50) | ชื่อตาราง/โมดูล เช่น 'rfa', 'correspondence' |
| entity_id | VARCHAR(50) | Primary ID ของระเบียนที่ได้รับผลกระทบ |
| details_json | JSON | ข้อมูลบริบท (เช่น ฟิลด์ที่มีการเปลี่ยนแปลง) |
| ip_address | VARCHAR(45) | IP address ของผู้ดำเนินการ |
| user_agent | VARCHAR(255) | User Agent ของผู้ดำเนินการ |
| created_at | TIMESTAMP | Timestamp (UTC) |
## **📂 การจัดการไฟล์ (File Handling) (ปรับปรุงใหม่)**
### **มาตรฐานการอัปโหลดไฟล์ (File Upload Standard)**
* **ตรรกะใหม่:** การอัปโหลดไฟล์ทั้งหมดจะถูกจัดการโดย FileStorageService และบันทึกข้อมูลไฟล์ลงในตาราง attachments (ตารางกลาง)
* ไฟล์จะถูกเชื่อมโยงไปยัง Entity ที่ถูกต้องผ่าน **ตารางเชื่อม (Junction Tables)** เท่านั้น:
* correspondence_attachments (เชื่อม Correspondence กับ Attachments)
* circulation_attachments (เชื่อม Circulation กับ Attachments)
* shop_drawing_revision_attachments (เชื่อม Shop Drawing Revision กับ Attachments)
* contract_drawing_attachments (เชื่อม Contract Drawing กับ Attachments)
* เส้นทางจัดเก็บไฟล์ (Upload path): อ้างอิงจาก Requirement 2.1 คือ /share/dms-data [cite: 2.1] โดย FileStorageService จะสร้างโฟลเดอร์ย่อยแบบรวมศูนย์ (เช่น /share/dms-data/uploads/{YYYY}/{MM}/[stored\filename])
* ประเภทไฟล์ที่อนุญาต: pdf, dwg, docx, xlsx, zip
* ขนาดสูงสุด: **50 MB**
* จัดเก็บนอก webroot
* ให้บริการไฟล์ผ่าน endpoint ที่ปลอดภัย /files/:attachment_id/download
### **การควบคุมการเข้าถึง (Access Control)**
การเข้าถึงไฟล์ไม่ใช่การเข้าถึงโดยตรง endpoint /files/:attachment_id/download จะต้อง:
1. ค้นหาระเบียน attachment
2. ตรวจสอบว่า attachment_id นี้ เชื่อมโยงกับ Entity ใด (เช่น correspondence, circulation, shop_drawing_revision, contract_drawing) ผ่านตารางเชื่อม
3. ตรวจสอบว่าผู้ใช้มีสิทธิ์ (permission) ในการดู Entity ต้นทางนั้นๆ หรือไม่
## **🔟 การจัดการเลขที่เอกสาร (Document Numbering) [cite: 3.10]**
* **เป้าหมาย:** สร้างเลขที่เอกสาร (เช่น correspondence\number) โดยอัตโนมัติ ตามรูปแบบที่กำหนด
* **ตรรกะการนับ:** การนับ Running number (SEQ) จะนับแยกตาม Key: **Project + Originator Organization + Document Type + Year**
* **ตาราง SQL:**
* document_number_formats: Admin ใช้กำหนด "รูปแบบ" (Template) ของเลขที่ (เช่น {ORG\CODE}-{TYPE\CODE}-{YEAR\SHORT}-{SEQ:4}) โดยกำหนดตาม **Project** และ **Document Type** [cite: 4.5]
* document_number_counters: ระบบใช้เก็บ "ตัวนับ" ล่าสุดของ Key (Project+Org+Type+Year)
* **การทำงาน (Backend):**
* DocumentNumberingModule จะให้บริการ DocumentNumberingService
* เมื่อ CorrespondenceModule ต้องการสร้างเอกสารใหม่, มันจะเรียก documentNumberingService.generateNextNumber(...)
* Service นี้จะเรียกใช้ Stored Procedure **sp_get_next_document_number** [cite: 2.9.3] ซึ่ง Procedure นี้จะจัดการ Database Transaction และ Row Lock (FOR UPDATE) ภายใน DB เพื่อรับประกันการป้องกัน Race Condition
## **📊 การรายงานและการส่งออก (Reporting & Exports)**
### **วิวสำหรับการรายงาน (Reporting Views) (จาก SQL)**
การรายงานควรสร้างขึ้นจาก Views ที่กำหนดไว้ล่วงหน้าในฐานข้อมูลเป็นหลัก:
* v_current_correspondences: สำหรับ revision ปัจจุบันทั้งหมดของเอกสารที่ไม่ใช่ RFA
* v_current_rfas: สำหรับ revision ปัจจุบันทั้งหมดของ RFA และข้อมูล master
* v_contract_parties_all: สำหรับการตรวจสอบความสัมพันธ์ของ project/contract/organization
* v_user_tasks: สำหรับ Dashboard "งานของฉัน"
* v_audit_log_details: สำหรับ Activity Feed
Views เหล่านี้ทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการรายงานฝั่งเซิร์ฟเวอร์และการส่งออกข้อมูล
### **กฎการส่งออก (Export Rules)**
* Export formats: CSV, Excel, PDF.
* จัดเตรียมมุมมองสำหรับพิมพ์ (Print view).
* รวมลิงก์ไปยังต้นทาง (เช่น /rfas/:id).
## **🧮 ฟรอนต์เอนด์: รูปแบบ DataTable และฟอร์ม (Frontend: DataTable & Form Patterns)**
### **DataTable (ServerSide)**
* Endpoint: /api/{module}?page=1\&pageSize=20\&sort=...\&filter=...
* ต้องรองรับ: การแบ่งหน้า (pagination), การเรียงลำดับ (sorting), การค้นหา (search), การกรอง (filters)
* แสดง revision ล่าสุดแบบ inline เสมอ (สำหรับ RFA/Drawing)
### **มาตรฐานฟอร์ม (Form Standards)**
* ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ):
* Project → Contract Drawing Volumes
* Contract Drawing Category → Sub-Category
* RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้
* **(ใหม่)** การอัปโหลดไฟล์: ต้องรองรับ **Multi-file upload (Drag-and-Drop)** [cite: 5.7]
* **(ใหม่)** UI ต้องอนุญาตให้ผู้ใช้กำหนดว่าไฟล์ใดเป็น **"เอกสารหลัก"** หรือ "เอกสารแนบประกอบ" [cite: 5.7]
* ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast
### **ข้อกำหนด Component เฉพาะ (Specific UI Requirements)**
* **Dashboard \- My Tasks:** ต้องพัฒนา Component ตาราง "งานของฉัน" (My Tasks)ซึ่งดึงข้อมูลงานที่ผู้ใช้ล็อกอินอยู่ต้องรับผิดชอบ (Main/Action) จาก v\user\tasks [cite: 5.3]
* **Workflow Visualization:** ต้องพัฒนา Component สำหรับแสดงผล Workflow (โดยเฉพาะ RFA)ที่แสดงขั้นตอนทั้งหมดเป็นลำดับ โดยขั้นตอนปัจจุบัน (active) เท่านั้นที่ดำเนินการได้ และขั้นตอนอื่นเป็น disabled [cite: 5.6] ต้องมีตรรกะสำหรับ Admin ในการ override หรือย้อนกลับขั้นตอนได้ [cite: 5.6]
* ** Admin Panel:** ต้องมีหน้า UI สำหรับ Superadmin/Admin เพื่อจัดการข้อมูลหลัก (Master Data [cite: 4.5]), การเริ่มต้นใช้งาน (Onboarding [cite: 4.6]), และ **รูปแบบเลขที่เอกสาร (Numbering Formats [cite: 3.10])**
## **🧭 แดชบอร์ดและฟีดกิจกรรม (Dashboard & Activity Feed)**
### **การ์ดบนแดชบอร์ด (Dashboard Cards)**
* แสดง Correspondences, RFAs, Circulations, Shop Drawing Revision ล่าสุด
* รวมสรุป KPI (เช่น "RFAs ที่รอการอนุมัติ", "Shop Drawing ที่รอการอนุมัติ") [cite: 5.3]
* รวมลิงก์ด่วนไปยังโมดูลต่างๆ
### **ฟีดกิจกรรม (Activity Feed)**
* แสดงรายการ v\audit\log\details ล่าสุด (10 รายการ) ที่เกี่ยวข้องกับผู้ใช้
// ตัวอย่าง API response
[
{ user: 'editor01', action: 'Updated RFA (LCBP3-RFA-001)', time: '2025-11-04T09:30Z' }
]
## **🛡️ ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
ส่วนนี้สรุปข้อกำหนด Non-Functional จาก requirements.md เพื่อให้ทีมพัฒนาทราบ
* **Audit Log [cite: 6.1]:** ทุกการกระทำที่สำคัญ (C/U/D) ต้องถูกบันทึกใน audit_logs
* **Performance [cite: 6.4]:** ต้องใช้ Caching สำหรับข้อมูลที่เรียกบ่อย และใช้ Pagination
* **Security [cite: 6.5]:** ต้องมี Rate Limiting และจัดการ Secret ผ่าน docker-compose.yml (ไม่ใช่ .env)
* **(ใหม่) Backup & Recovery [cite: 6.6]:** ต้องมีแผนสำรองข้อมูลทั้ง Database (MariaDB) และ File Storage (/share/dms-data) อย่างน้อยวันละ 1 ครั้ง
* **(ใหม่) Notification Strategy [cite: 6.7]:** ระบบแจ้งเตือน (Email/Line) ต้องถูก Trigger เมื่อมีเอกสารใหม่ส่งถึง, มีการมอบหมายงานใหม่ (Circulation), หรือ (ทางเลือก) เมื่องานเสร็จ/ใกล้ถึงกำหนด
## **✅ มาตรฐานที่นำไปใช้แล้ว (จาก SQL v1.1.0) (Implemented Standards (from SQL v1.1.0))**
ส่วนนี้ยืนยันว่าแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เป็นส่วนหนึ่งของการออกแบบฐานข้อมูลอยู่แล้ว และควรถูกนำไปใช้ประโยชน์ ไม่ใช่สร้างขึ้นใหม่
***Soft Delete:** นำไปใช้แล้วผ่านคอลัมน์ deleted_at ในตารางสำคัญ (เช่น correspondences, rfas, project_parties) ตรรกะการดึงข้อมูลต้องกรอง deleted_at IS NULL
***Database Indexes:** สคีมาได้มีการทำ index ไว้อย่างหนักหน่วงบน foreign keys และคอลัมน์ที่ใช้ค้นหาบ่อย (เช่น idx_rr_rfa, idx_cor_project, idx_cr_is_current) เพื่อประสิทธิภาพ
***โครงสร้าง RBAC:** มีระบบ users, roles, permissions, user_roles, และ user_project_roles ที่ครอบคลุมอยู่แล้ว
***Data Seeding:** ข้อมูล Master (roles, permissions, organization_roles, initial users, project parties) ถูกรวมอยู่ในสคริปต์สคีมาแล้ว
## **🧩 การปรับปรุงที่แนะนำ (สำหรับอนาคต) (Recommended Enhancements (Future))**
* ✅ สร้าง Background job (โดยใช้ **n8n** เพื่อเชื่อมต่อกับ **Line** [cite: 2.7] และ/หรือใช้สำหรับการแจ้งเตือน RFA ที่ใกล้ถึงกำหนด due_date [cite: 6.7])
* ✅ เพิ่ม job ล้างข้อมูลเป็นระยะสำหรับ attachments ที่ไม่ถูกเชื่อมโยงกับ Entity ใดๆ เลย (ไฟล์กำพร้า)

View File

@@ -0,0 +1,210 @@
# **📝 Documents Management Sytem Version 1.2.1: Application Requirements Specification**
## **📌 1. วัตถุประสงค์**
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System)ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
* มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
* ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
* เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
## **🛠️ 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)**
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
* 2.1. Infrastructure & Environment:
* Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
* Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
* Development Environment: VS Code on Windows 11
* Domain: np-dms.work, www.np-dms.work
* ip: 159.192.126.103
* Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
* Data Storage: /share/dms-data บน QNAP
* ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
* 2.2. Code Hosting:
* Application name: git
* Service: Gitea (Self-hosted on QNAP)
* Service name: gitea
* Domain: git.np-dms.work
* หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
* 2.3. Backend / Data Platform:
* Application name: lcbp3-backend
* Service: NestJS
* Service name: backend
* Domain: backend.np-dms.work
* Framework: NestJS (Node.js, TypeScript, ESM)
* หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
* 2.4. Database:
* Application name: lcbp3-db
* Service: mariadb:10.11
* Service name: mariadb
* Domain: db.np-dms.work
* หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
* Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
* 2.5. Database management:
* Application name: lcbp3-db
* Service: phpmyadmin:5-apache
* Service name: pma
* Domain: pma.np-dms.work
* หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
* 2.6. Frontend:
* Application name: lcbp3-frontend
* Service: next.js
* Service name: frontend
* Domain: lcbp3.np-dms.work
* Framework: Next.js (App Router, React, TypeScript, ESM)
* Styling: Tailwind CSS + PostCSS
* Component Library: shadcn/ui
* หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
* 2.7. Workflow automation:
* Application name: lcbp3-n8n
* Service: n8nio/n8n:latest
* Service name: n8n
* Domain: n8n.np-dms.work
* หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
* 2.8. Reverse Proxy:
* Application name: lcbp3-npm
* Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
* Service name: npm
* Domain: npm.np-dms.work
* หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
* **2.9. การจัดการตรรกะทางธุรกิจ (Business Logic Implementation):**
* 2.9.1. ตรรกะทางธุรกิจที่ซับซ้อนทั้งหมด (เช่น การเปลี่ยนสถานะ Workflow [cite: 3.5.4, 3.6.5], การบังคับใช้สิทธิ์ [cite: 4.4], การตรวจสอบ Deadline [cite: 3.2.5]) **จะถูกจัดการในฝั่ง Backend (NestJS)** [cite: 2.3] เพื่อให้สามารถบำรุงรักษาและทดสอบได้ง่าย (Testability)
* 2.9.2. **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก
* 2.9.3. **ข้อยกเว้น:** ตรรกะเดียวที่จะอยู่ในฐานข้อมูลคือ **Stored Procedure** สำหรับการสร้างเลขที่เอกสาร (Document Numbering) [cite: 3.10] เพื่อป้องกันการซ้ำซ้อนของข้อมูล (Race Condition)
## **📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)**
* 3.1. การจัดการโครงสร้างโครงการและองค์กร
* 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
* 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
* 3.1.3. องค์กร (Organizations):
* มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
* Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
* 3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)
* 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects), รองรับ To (ผู้รับหลัก) และ CC (ผู้รับสำเนา) หลายองค์กร
* 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
* 3.2.3. การสร้างเอกสาร (Correspondence):
* ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
* เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
* 3.2.4. การอ้างอิงและจัดกลุ่ม:
* เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
* สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
* 3.2.5. การจัดการ: มีการจัดการอย่างน้อยดังนี้
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่เป็นผู้รับได้
* มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
* 3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)
* 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
* 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
* 3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)
* 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
* 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
* 3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)
* 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
* 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
* Request for Drawing Approval (RFA_DWG)
* Request for Document Approval (RFA_DOC)
* Request for Method statement Approval (RFA_MES)
* Request for Material Approval (RFA_MAT)
* 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.5.4. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA_DWG):
* เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
* Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
* ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
* 3.6.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
* ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
* 3.6.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
* มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
* 3.6.การจัดการเอกสารนำส่ง (Transmittals)
* 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
* 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
* 3.7. ใบเวียนเอกสารภายใน (Internal Circulation Sheet)
* 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
* 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
* 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
* ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
* ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
* ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
* 3.7.5. การติดตามงาน:
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
* มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
* สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
* 3.8. ประวัติการแก้ไข (Revisions): ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
* 3.9. การจัดเก็บ: (ปรับปรุงตามสถาปัตยกรรมใหม่)
* เอกสารและไฟล์แนบทั้งหมดจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) [cite: 2.1]
* ข้อมูล Metadata ของไฟล์ (เช่น ชื่อไฟล์, ขนาด, path) จะถูกเก็บในตาราง attachments (ตารางกลาง)
* ไฟล์จะถูกเชื่อมโยงกับเอกสารประเภทต่างๆ ผ่านตารางเชื่อม (Junction tables) เช่น correspondence_attachments, circulation_attachments, shop_drawing_revision_attachments ,และ contracy_drawing_attachments
* สถาปัตยกรรมแบบรวมศูนย์นี้ *แทนที่* แนวคิดเดิมที่จะแยกโฟลเดอร์ตามประเภทเอกสาร เพื่อรองรับการขยายระบบที่ดีกว่า
* 3.10. การจัดการเลขที่เอกสาร (Document Numbering):
* 3.10.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (เช่น correspondence_number) ได้โดยอัตโนมัติ
* 3.10.2. การนับเลข Running Number (SEQ) จะต้องนับแยกตาม Key ดังนี้: **โครงการ (Project)**, **องค์กรผู้ส่ง (Originator Organization)**, **ประเภทเอกสาร (Document Type)** และ **ปีปัจจุบัน (Year)**
* 3.10.3. ผู้ดูแลระบบ (Admin) ต้องสามารถกำหนด "รูปแบบ" (Format Template) ของเลขที่เอกสารได้ (เช่น {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}) โดยกำหนดแยกตามโครงการและประเภทเอกสาร
## **🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)**
* 4.1. ภาพรวม: ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
* 4.2. ระดับของสิทธิ์:
* Global Roles: สิทธิ์ในภาพรวมของระบบ
* Project-Specific Roles: สิทธิ์ที่ถูกกำหนดให้ผู้ใช้สำหรับโครงการนั้นๆ โดยเฉพาะ (เช่น เป็น Editor ในโครงการ A แต่เป็น Viewer ในโครงการ B)
* 4.3. บทบาท (Roles) พื้นฐาน:
* Superadmin: ไม่มีข้อจำกัดใดๆ สามารถจัดการได้ทุกอย่างข้ามองค์กรณ์
* Admin: มีสิทธิ์เต็มที่ แต่จำกัดเฉพาะในองค์กรที่ตัวเองสังกัด สามารถจัดการผู้ใช้ในองค์กรณ์ได้ สามารถสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลังผ่านหน้า Admin
* Document Control สามารถ เพิ่ม/แก้ไข/ลบ เอกสาร เฉพาะในองค์กรณ์ที่ตัวเองสังกัด ไม่สามารถจัดการผู้ใช้ได้
* Editor: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนดไว้ เฉพาะในองค์กรณ์ที่ตัวเองสังกัด
* Viewer: สามารถดู เอกสาร เฉพาะในองค์กรณ์ที่ตัวเองสังกัด
* 4.4. การบังคับใช้สิทธิ์: สิทธิ์ขององค์กรจะครอบคลุมสิทธิ์ของผู้ใช้ และการเข้าถึงข้อมูลที่เกี่ยวข้องกับโครงการ (เช่น การแก้ไขเอกสาร) จะถูกตรวจสอบเทียบกับสิทธิ์ที่ผู้ใช้มีในโครงการนั้นๆ โดยเฉพาะ
* 4.5. (ใหม่) การจัดการข้อมูลหลัก (Master Data Management):
* ระบบจะต้องมีส่วน "Admin Panel" (สำหรับ Superadmin และ Admin) เพื่อใช้จัดการข้อมูลหลัก (Master Data) ของระบบ
* ข้อมูลหลักที่ต้องจัดการได้เป็นอย่างน้อย:
* ประเภทเอกสาร (เช่น correspondence_types, rfa_types)
* หมวดหมู่แบบ (เช่น shop_drawing_categories)
* Tags ที่ใช้ในระบบ
* สถานะเอกสาร (หากจำเป็นต้องเพิ่มในอนาคต)
* 4.6. (ใหม่) การเริ่มต้นใช้งาน (User & Organization Onboarding):
* การเพิ่มองค์กรณ์ใหม่ (Organizations) เข้าสู่ระบบ จะต้องดำเนินการโดย Superadmin เท่านั้น
* เมื่อ Superadmin สร้างองค์กรณ์ใหม่ จะต้องสามารถกำหนดผู้ใช้ (User) อย่างน้อย 1 คน ให้เป็น "Admin" ประจำองค์กรณ์นั้นๆ
* Admin ประจำองค์กณ์รจึงจะสามารถเพิ่มผู้ใช้ (Editor, Viewer, Document Control) คนอื่นๆ เข้าสู่องค์กรของตนเองได้
## **👥 5\. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)**
* 5.1. Layout หลัก: หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
* Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
* Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
* Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
* 5.2. หน้า Landing Page: เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
* 5.3. หน้า Dashboard: เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
* การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
* ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
* 5.4. การติดตามสถานะ: องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
* 5.5. การจัดการข้อมูลส่วนตัว (Profile Page): ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
* 5.6. การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow): ผู้ใช้สามารถดู Technical Document ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ admin ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ admin ขึ้นไป
* 5.7. ข้อกำหนด UI/UX การแนบไฟล์ (File Attachment UX):
* ระบบต้องรองรับการอัปโหลดไฟล์หลายไฟล์พร้อมกัน (Multi-file upload) เช่น การลากและวาง (Drag-and-Drop)
* ในหน้าอัปโหลด (เช่น สร้าง RFA หรือ Correspondence) ผู้ใช้ต้องสามารถกำหนดได้ว่าไฟล์ใดเป็น "เอกสารหลัก" (Main Document เช่น PDF) และไฟล์ใดเป็น "เอกสารแนบประกอบ" (Supporting Attachments เช่น .dwg, .docx, .zip)
## **6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
* 6.1. การบันทึกการกระทำ (Audit Log): ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
* 6.2. การค้นหา (Search): ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
* 6.3. การทำรายงาน (Reporting): สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
* 6.4. ประสิทธิภาพ (Performance): มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
* 6.5. ความปลอดภัย (Security):
* มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
* การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
* 6.6. (ใหม่) การสำรองข้อมูลและการกู้คืน (Backup & Recovery):
* ระบบจะต้องมีกลไกการสำรองข้อมูลอัตโนมัติสำหรับฐานข้อมูล MariaDB [cite: 2.4] และไฟล์เอกสารทั้งหมดใน /share/dms-data [cite: 2.1] (เช่น ใช้ HBS 3 ของ QNAP หรือสคริปต์สำรองข้อมูล) อย่างน้อยวันละ 1 ครั้ง
* ต้องมีแผนการกู้คืนระบบ (Disaster Recovery Plan) ในกรณีที่ Server หลัก (QNAP) ใช้งานไม่ได้
* 6.7. (ใหม่) กลยุทธ์การแจ้งเตือน (Notification Strategy):
* ระบบจะส่งการแจ้งเตือน (ผ่าน Email หรือ Line [cite: 2.7]) เมื่อมีการกระทำที่สำคัญ ดังนี้:
1. เมื่อมีเอกสารใหม่ (Correspondence, RFA) ถูกส่งมาถึงองค์กรณ์ของเรา
2. เมื่อมีใบเวียน (Circulation) ใหม่ มอบหมายงานมาที่เรา
3. (ทางเลือก) เมื่อเอกสารที่เราส่งไป ถูกดำเนินการ (เช่น อนุมัติ/ปฏิเสธ)
4. (ทางเลือก) เมื่อใกล้ถึงวันครบกำหนด (Deadline) [cite: 3.2.5, 3.6.6, 3.7.5]

View File

@@ -0,0 +1,775 @@
---
# **สรุปตารางฐานข้อมูล (Data Dictionary) - LCBP3-DMS (V1.3.00**
เอกสารนี้สรุปโครงสร้างตาราง, Foreign Keys (FK), และ Constraints ที่สำคัญทั้งหมดในฐานข้อมูล LCBP3-DMS (v1.3.0) เพื่อใช้เป็นเอกสารอ้างอิงสำหรับทีมพัฒนา Backend (NestJS) และ Frontend (Next.js)
## **1\. 🏢 Core & Master Data (องค์กร, โครงการ, สัญญา)**
#### **1.1. organization\_roles**
ตาราง Master เก็บประเภทบทบาทขององค์กร (เช่น OWNER, CONTRACTOR)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| role\_name | VARCHAR(20) | UK | ชื่อบทบาท (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD PARTY) |
* **Unique Keys (UK):** ux\_roles\_name (role\_name)
#### **1.2. organizations**
ตาราง Master เก็บข้อมูลองค์กรทั้งหมดที่เกี่ยวข้องในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| organization\_code | VARCHAR(20) | UK | รหัสองค์กร |
| organization\_name | VARCHAR(255) | | ชื่อองค์กร |
| role\_id | INT | FK | บทบาทขององค์กร (FK \-> organization\_roles(id)) |
| is\_active | BOOLEAN | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* role\_id \-> organization\_roles(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_organizations\_code (organization\_code)
#### **1.3. projects**
ตาราง Master เก็บข้อมูลโครงการ (เช่น LCBP3C1, LCBP3C2)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_code | VARCHAR(50) | UK | รหัสโครงการ |
| project\_name | VARCHAR(255) | | ชื่อโครงการ |
| parent\_project\_id | INT | FK | รหัสโครงการหลัก (ถ้ามี) (FK \-> projects(id)) |
| contractor\_organization\_id | INT | FK | รหัสองค์กรผู้รับเหมา (ถ้ามี) (FK \-> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* parent\_project\_id \-> projects(id) (ON DELETE SET NULL)
* contractor\_organization\_id \-> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_pro\_code (project\_code)
#### **1.4. contracts**
ตาราง Master เก็บข้อมูลสัญญา
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| contract\_code | VARCHAR(50) | UK | รหัสสัญญา |
| contract\_name | VARCHAR(255) | | ชื่อสัญญา |
| description | TEXT | | คำอธิบายสัญญา |
* **Unique Keys (UK):** ux\_contracts\_code (contract\_code)
#### **1.5. project\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง โครงการ, องค์กร, และบทบาท (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-> organizations(id)) |
| role | ENUM(...) | **PK** | บทบาทในโครงการ (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD\_PARTY) |
| is\_contractor | TINYINT(1) | UK | (Generated) \= 1 ถ้า role \= 'CONTRACTOR' |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* project\_id \-> projects(id) (ON DELETE CASCADE)
* organization\_id \-> organizations(id) (ON DELETE RESTRICT)
* **Unique Keys (UK):**
* uq\_project\_parties\_contractor (project\_id, is\_contractor) \- **(Constraint สำคัญ)** บังคับว่า 1 โครงการมี CONTRACTOR ได้เพียง 1 องค์กร
#### **1.6. contract\_parties (ตารางเชื่อม)**
ตารางเชื่อมความสัมพันธ์ระหว่าง สัญญา, โครงการ, และองค์กร (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| contract\_id | INT | **PK**, FK | ID ของสัญญา (FK \-> contracts(id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| organization\_id | INT | **PK**, FK | ID ขององค์กร (FK \-> organizations(id)) |
* **Foreign Keys (FK):**
* contract\_id \-> contracts(id) (ON DELETE CASCADE)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* organization\_id \-> organizations(id) (ON DELETE CASCADE)
---
## **2. 👥 Users & RBAC (ผู้ใช้, สิทธิ์, บทบาท)**
### **2.1. users**
ตาราง Master เก็บข้อมูลผู้ใช้งาน (User)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK** | ID ของตาราง |
| username | VARCHAR(50) | UK | ชื่อผู้ใช้งาน |
| password\_hash | VARCHAR(255) | | รหัสผ่าน (Hashed) |
| first\_name | VARCHAR(50) | | ชื่อจริง |
| last\_name | VARCHAR(50) | | นามสกุล |
| email | VARCHAR(100) | UK | อีเมล |
| organization\_id | INT | FK | สังกัดองค์กร (FK \-> organizations(id)) |
| is\_active | TINYINT(1) | | สถานะการใช้งาน |
* **Foreign Keys (FK):**
* organization\_id \-> organizations(id) (ON DELETE SET NULL)
* **Unique Keys (UK):** ux\_users\_username (username), ux\_users\_email (email)
#### **2.2. roles**
ตาราง Master เก็บ "บทบาท" ของผู้ใช้ในระบบ (เช่น SUPER\_ADMIN, ADMIN, EDITOR)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| role\_id | INT | **PK** | ID ของตาราง |
| role\_code | VARCHAR(50) | UK | รหัสบทบาท (เช่น SUPER\_ADMIN, ADMIN, EDITOR, VIEWER) |
| role\_name | VARCHAR(100) | | ชื่อบทบาท |
| is\_system | BOOLEAN | | (1 \= บทบาทของระบบ ลบไม่ได้) |
* **Unique Keys (UK):** role\_code
#### **2.3. permissions**
ตาราง Master เก็บ "สิทธิ์" (Permission) หรือ "การกระทำ" ทั้งหมดในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| permission\_id | INT | **PK** | ID ของตาราง |
| permission\_code | VARCHAR(100) | UK | รหัสสิทธิ์ (เช่น rfas.create, rfas.view) |
| module | VARCHAR(50) | | โมดูลที่เกี่ยวข้อง |
| scope\_level | ENUM(...) | | ระดับของสิทธิ์ (GLOBAL, ORG, PROJECT) |
* **Unique Keys (UK):** ux\_permissions\_code (permission\_code)
#### **2.4. role\_permissions (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง roles และ permissions (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
| permission\_id | INT | **PK**, FK | ID ของสิทธิ์ (FK \-> permissions(permission\_id)) |
* **Foreign Keys (FK):**
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
* permission\_id \-> permissions(permission\_id) (ON DELETE CASCADE)
#### **2.5. user\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Global** (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user\_id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-> users(user\_id) (ON DELETE CASCADE)
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
#### **2.6. user\_project\_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Project-Specific** (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| user\_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user\_id)) |
| project\_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| role\_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role\_id)) |
* **Foreign Keys (FK):**
* user\_id \-> users(user\_id) (ON DELETE CASCADE)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* role\_id \-> roles(role\_id) (ON DELETE CASCADE)
---
## **3\. ✉️ Correspondences (เอกสารหลัก, Revisions)**
#### **3.1. correspondence\_types**
ตาราง Master เก็บประเภทเอกสารโต้ตอบ (เช่น RFA, RFI, LETTER, MOM)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| type\_code | VARCHAR(50) | UK | รหัสประเภท (เช่น RFA, RFI) |
| type\_name | VARCHAR(255) | | ชื่อประเภท |
* **Unique Keys (UK):** type\_code
#### **3.2. correspondence\_status**
ตาราง Master เก็บสถานะของเอกสาร (เช่น DRAFT, SUBMITTED, CLOSED)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| status\_code | VARCHAR(50) | UK | รหัสสถานะ (เช่น DRAFT, SUBOWN) |
| status\_name | VARCHAR(255) | | ชื่อสถานะ |
* **Unique Keys (UK):** status\_code
#### **3.3. correspondences (Master)**
ตาราง "แม่" ของเอกสารโต้ตอบ เก็บข้อมูลที่ไม่เปลี่ยนแปลงตาม Revision (เช่น เลขที่เอกสาร)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง (นี่คือ "Master ID" ที่ใช้เชื่อมโยง) |
| correspondence\_number | VARCHAR(100) | UK | เลขที่เอกสาร (สร้างจาก DocumentNumberingModule) |
| correspondence\_type\_id | INT | FK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| is\_internal\_communication | TINYINT(1) | | (1 \= ภายใน, 0 \= ภายนอก) |
| project\_id | INT | FK | อยู่ในโครงการ (FK \-> projects(id)) |
| originator\_id | INT | FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| recipient\_id | INT | FK | องค์กรผู้รับ (FK \-> organizations(id)) |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* correspondence\_type\_id \-> correspondence\_types(id) (ON DELETE RESTRICT)
* project\_id \-> projects(id) (ON DELETE CASCADE)
* originator\_id \-> organizations(id) (ON DELETE SET NULL)
* recipient\_id \-> organizations(id) (ON DELETE SET NULL)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **Unique Keys (UK):** uq\_corr\_no\_per\_project (project\_id, correspondence\_number)
#### **3.4. correspondence\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติการแก้ไข (Revisions) ของ correspondences (1:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK, UK | Master ID (FK \-> correspondences(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| **revision\_label** | **VARCHAR(10)** | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| correspondence\_status\_id | INT | FK | สถานะของ Revision นี้ (FK \-> correspondence\_status(id)) |
| title | VARCHAR(255) | | เรื่อง |
| document\_date | DATE | | วันที่ในเอกสาร |
| issued\_date | DATETIME | | วันที่ออกเอกสาร |
| received\_date | DATETIME | | วันที่ลงรับ |
| **description** | **TEXT** | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| details | JSON | | ข้อมูลเฉพาะ (เช่น RFI details) |
| **created\_at** | **DATETIME** | | **(ใหม่)** วันที่สร้างเอกสาร |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| **updated\_by** | **INT** | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* correspondence\_status\_id \-> correspondence\_status(id) (ON DELETE RESTRICT)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **updated\_by \-> users(user\_id) (ON DELETE SET NULL)**
* **Unique Keys (UK):**
* uq\_master\_revision\_number (correspondence\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_master\_current (correspondence\_id, is\_current) (ป้องกันการมี is\_current \= TRUE ซ้ำใน Master เดียว)
* **Check Constraints (CHK):** chk\_rev\_format (ตรวจสอบรูปแบบ revision\_label)
#### **3.5. correspondence\_recipients (ตารางเชื่อม)**
ตารางเชื่อมผู้รับ (TO/CC) สำหรับเอกสารแต่ละฉบับ (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondence\_revisions(correspondence\_id)) |
| recipient\_organization\_id | INT | **PK**, FK | ID องค์กรผู้รับ (FK \-> organizations(id)) |
| recipient\_type | ENUM('TO', 'CC') | **PK** | ประเภทผู้รับ (TO หรือ CC) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondence\_revisions(correspondence\_id) (ON DELETE CASCADE)
* recipient\_organization\_id \-> organizations(id) (ON DELETE RESTRICT)
#### **3.6. correspondence\_references (ตารางเชื่อม)**
ตารางเชื่อมการอ้างอิงระหว่างเอกสาร (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| src\_correspondence\_id | INT | **PK**, FK | ID เอกสารต้นทาง (FK \-> correspondences(id)) |
| tgt\_correspondence\_id | INT | **PK**, FK | ID เอกสารเป้าหมาย (FK \-> correspondences(id)) |
* **Foreign Keys (FK):**
* src\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* tgt\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
#### **3.7. correspondence\_routing\_templates / ...\_steps / ...\_routings**
ตารางที่เกี่ยวข้องกับ Workflow การส่งต่อเอกสาร (Req 3.5.4)
* **correspondence\_routing\_templates:** ตาราง Master เก็บแม่แบบสายงาน (เช่น "ส่งให้ CSC ตรวจสอบ")
* **correspondence\_routing\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: ส่งไป Org A, Step 2: ส่งไป Org B)
* **correspondence\_routings:** ตารางประวัติ (Log) การส่งต่อของเอกสารจริงตาม Workflow
---
## **4\. approval: RFA (เอกสารขออนุมัติ, Workflows)**
#### **4.1. rfa\_types / ...\_status\_codes / ...\_approve\_codes**
ตาราง Master สำหรับ RFA
* **rfa\_types:** ประเภท RFA (เช่น DWG, DOC, MAT)
* **rfa\_status\_codes:** สถานะ RFA (เช่น DFT \- Draft, FAP \- For Approve)
* **rfa\_approve\_codes:** รหัสผลการอนุมัติ (เช่น 1A \- Approved, 3R \- Revise and Resubmit)
#### **4.2. rfas (Master)**
ตาราง "แม่" ของ RFA (มีความสัมพันธ์ 1:N กับ rfa\_revisions)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง (RFA Master ID) |
| rfa\_type\_id | INT | FK | ประเภท RFA (FK \-> rfa\_types(id)) |
| revision\_number | INT | | หมายเลข Revision ล่าสุด (ข้อมูลนี้ถูกย้ายไป rfa\_revisions) |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| deleted\_at | DATETIME | | สำหรับ Soft Delete |
* **Foreign Keys (FK):**
* rfa\_type\_id \-> rfa\_types(id)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
#### **4.3. rfa\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ rfas (1:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence\_id | INT | FK | Master ID ของ Correspondence (FK \-> correspondences(id)) |
| rfa\_id | INT | FK, UK | Master ID ของ RFA (FK \-> rfas(id)) |
| revision\_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| **revision\_label** | **VARCHAR(10)** | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is\_current | BOOLEAN | UK | (1 \= Revision ปัจจุบัน) |
| rfa\_status\_code\_id | INT | FK | สถานะ RFA (FK \-> rfa\_status\_codes(id)) |
| rfa\_approve\_code\_id | INT | FK | ผลการอนุมัติ (FK \-> rfa\_approve\_codes(id)) |
| title | VARCHAR(255) | | เรื่อง |
| **document\_date** | **DATE** | | **(ใหม่)** วันที่ในเอกสาร |
| **issued\_date** | **DATE** | | **(ใหม่)** วันที่ส่งขออนุมัติ |
| **received\_date** | **DATETIME** | | **(ใหม่)** วันที่ลงรับเอกสาร |
| **approved\_date** | **DATE** | | **(ใหม่)** วันที่อนุมัติ |
| **description** | **TEXT** | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| **created\_at** | **DATETIME** | | **(ใหม่)** วันที่สร้างเอกสาร |
| created\_by | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
| **updated\_by** | **INT** | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):**
* correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
* rfa\_id \-> rfas(id) (ON DELETE CASCADE)
* rfa\_status\_code\_id \-> rfa\_status\_codes(id)
* rfa\_approve\_code\_id \-> rfa\_approve\_codes(id) (ON DELETE SET NULL)
* created\_by \-> users(user\_id) (ON DELETE SET NULL)
* **updated\_by \-> users(user\_id) (ON DELETE SET NULL)**
* **Unique Keys (UK):**
* uq\_rr\_rev\_number (rfa\_id, revision\_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
* uq\_rr\_current (rfa\_id, is\_current) (ป้องกัน is\_current=TRUE ซ้ำใน Master เดียว)
#### **4.4. rfa\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง rfa\_revisions (ที่เป็นประเภท DWG) กับ shop\_drawing\_revisions (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| rfarev\_correspondence\_id | INT | **PK**, FK | ID ของ RFA Revision (FK \-> rfa\_revisions(correspondence\_id)) |
| shop\_drawing\_revision\_id | INT | **PK**, UK, FK | ID ของ Shop Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
* **Foreign Keys (FK):**
* rfarev\_correspondence\_id \-> rfa\_revisions(correspondence\_id) (ON DELETE CASCADE)
* shop\_drawing\_revision\_id \-> shop\_drawing\_revisions(id) (ON DELETE CASCADE)
#### **4.5. rfa\_workflow\_templates / ...\_steps / ...\_workflows**
ตารางที่เกี่ยวข้องกับ Workflow การอนุมัติ RFA
* **rfa\_workflow\_templates:** ตาราง Master เก็บแม่แบบสายอนุมัติ (เช่น "สายอนุมัติ 3 ขั้นตอน")
* **rfa\_workflow\_template\_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: Org A (Review), Step 2: Org B (Approve))
* **rfa\_workflows:** ตารางประวัติ (Log) การอนุมัติของ RFA จริงตามสายงาน
---
## **5\. 📐 Drawings (แบบ, หมวดหมู่)**
#### **5.1. contract\_drawing\_volumes / ...\_cats / ...\_sub\_cats**
ตาราง Master สำหรับ "แบบคู่สัญญา" (Contract Drawings)
* **contract\_drawing\_volumes:** เก็บ "เล่ม" ของแบบ
* **contract\_drawing\_cats:** เก็บ "หมวดหมู่หลัก" ของแบบ
* **contract\_drawing\_sub\_cats:** เก็บ "หมวดหมู่ย่อย" ของแบบ
#### **5.2. contract\_drawing\_subcat\_cat\_maps (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อมระหว่าง หมวดหมู่หลัก-ย่อย (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | ID ของโครงการ |
| sub\_cat\_id | INT | **PK**, FK | ID ของหมวดหมู่ย่อย |
| cat\_id | INT | **PK**, FK | ID ของหมวดหมู่หลัก |
* **Foreign Keys (FK) (ตามเจตนา):**
* (project\_id, sub\_cat\_id) \-> contract\_drawing\_sub\_cats(project\_id, id)
* (project\_id, cat\_id) \-> contract\_drawing\_cats(project\_id, id)
* **Unique Keys (UK):**
* ux\_map\_unique (project\_id, sub\_cat\_id, cat\_id)
* ***ข้อสังเกตจาก DBA:*** *สคริปต์ SQL (1.3.6) มีการอ้างอิง FK ไปยังตารางและคอลัมน์ (`contract_dwg_sub_cat(project_id, sub_cat_id)`) ที่ไม่มีอยู่จริง ตารางนี้แสดงตามเจตนาที่ถูกต้อง*
#### **5.3. contract\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบคู่สัญญา"
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| condwg\_no | VARCHAR(255) | UK | เลขที่แบบสัญญา |
| title | VARCHAR(255) | | ชื่อแบบ |
| sub\_cat\_id | INT | FK | หมวดหมู่ย่อย (FK \-> contract\_drawing\_sub\_cats(id)) |
| volume\_id | INT | FK | เล่ม (FK \-> contract\_drawing\_volumes(id)) |
* **Foreign Keys (FK):**
* fk\_condwg\_project (project\_id) \-> projects(id) (ON DELETE CASCADE)
* fk\_condwg\_subcat\_same\_project (project\_id, sub\_cat\_id) \-> contract\_drawing\_sub\_cats(project\_id, id)
* fk\_condwg\_volume\_same\_project (project\_id, volume\_id) \-> contract\_drawing\_volumes(project\_id, id)
* **Unique Keys (UK):** ux\_condwg\_no\_project (project\_id, condwg\_no)
#### **5.4. shop\_drawing\_main\_categories / ...\_sub\_categories**
ตาราง Master สำหรับ "แบบก่อสร้าง" (Shop Drawings)
* **shop\_drawing\_main\_categories:** เก็บ "หมวดหมู่หลัก" (เช่น ARCH, STR)
* **shop\_drawing\_sub\_categories:** เก็บ "หมวดหมู่ย่อย" (เช่น STR-COLUMN)
#### **5.5. shop\_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบก่อสร้าง"
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK | โครงการ (FK \-> projects(id)) |
| drawing\_number | VARCHAR(100) | UK | เลขที่ Shop Drawing |
| title | VARCHAR(500) | | ชื่อแบบ |
| main\_category\_id | INT | FK | หมวดหมู่หลัก (FK \-> shop\_drawing\_main\_categories(id)) |
| sub\_category\_id | INT | FK | หมวดหมู่ย่อย (FK \-> shop\_drawing\_sub\_categories(id)) |
* **Foreign Keys (FK):** project\_id, main\_category\_id, sub\_category\_id
* **Unique Keys (UK):** ux\_sd\_drawing\_number (drawing\_number)
#### **5.6. shop\_drawing\_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ shop\_drawings (1:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของ Revision |
| shop\_drawing\_id | INT | FK, UK | Master ID (FK \-> shop\_drawings(id)) |
| revision\_number | VARCHAR(10) | UK | หมายเลข Revision (เช่น A, B, 0, 1) |
| revision\_date | DATE | | วันที่ของ Revision |
| description | TEXT | | คำอธิบายการแก้ไข |
* **Foreign Keys (FK):**
* shop\_drawing\_id \-> shop\_drawings(id) (ON DELETE CASCADE)
* **Unique Keys (UK):** ux\_sd\_rev\_drawing\_revision (shop\_drawing\_id, revision\_number)
#### **5.7. shop\_drawing\_revision\_contract\_refs (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง shop\_drawing\_revisions กับ contract\_drawings (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| shop\_drawing\_revision\_id | INT | FK | ID ของ Shop Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
| contract\_drawing\_id | INT | FK | ID ของ Contract Drawing (FK \-> contract\_drawings(id)) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, contract\_drawing\_id
---
## **6\. 🔄 Circulations (ใบเวียนภายใน)**
#### **6.1. circulation\_status\_codes**
ตาราง Master เก็บสถานะใบเวียน (เช่น OPEN, IN\_REVIEW, COMPLETED)
#### **6.2. circulations (Master)**
ตาราง "แม่" ของใบเวียนเอกสารภายใน
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| correspondence\_id | INT | UK, FK | เอกสารที่ใช้อ้างอิง (FK \-> correspondences(id)) |
| organization\_id | INT | FK, UK | องค์กรเจ้าของใบเวียน (FK \-> organizations(id)) |
| circulation\_no | VARCHAR(100) | UK | เลขที่ใบเวียน |
| circulation\_subject | VARCHAR(500) | | เรื่อง |
| circulation\_status\_code | VARCHAR(20) | FK | สถานะใบเวียน (FK \-> circulation\_status\_codes(code)) |
| created\_by\_user\_id | INT | FK | ผู้สร้าง (FK \-> users(user\_id)) |
* **Foreign Keys (FK):** correspondence\_id, organization\_id, circulation\_status\_code, created\_by\_user\_id
* **Unique Keys (UK):**
* correspondence\_id (1 ใบเวียน ต่อ 1 เอกสาร)
* uq\_cir\_org\_no (organization\_id, circulation\_no) (เลขที่ใบเวียนห้ามซ้ำในองค์กร)
#### **6.3. circulation\_recipients / ...\_assignees / ...\_actions**
ตาราง "ลูก" ของ circulations
* **circulation\_recipients:** รายชื่อผู้รับ (TO/CC) ภายในองค์กร
* **circulation\_assignees:** รายชื่อผู้รับผิดชอบ (MAIN, ACTION, INFO) และเก็บ deadline
* **circulation\_actions:** ประวัติการดำเนินการ (เช่น Comment, Forward, Close)
* **circulation\_action\_documents:** ตารางเชื่อม circulation\_actions กับ attachments (ไฟล์แนบระหว่างดำเนินการ)
#### **6.4. circulation\_templates / ...\_assignees**
ตารางสำหรับแม่แบบใบเวียน (Templates)
* **circulation\_templates:** ตาราง Master เก็บแม่แบบใบเวียน
* **circulation\_template\_assignees:** ตารางลูก เก็บผู้รับผิดชอบที่กำหนดไว้ล่วงหน้าในแม่แบบ
---
## **7\. 📤 Transmittals (เอกสารนำส่ง)**
#### **7.1. transmittals**
ตารางข้อมูลเฉพาะของเอกสารนำส่ง (เป็นตารางลูก 1:1 ของ correspondences)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| purpose | ENUM(...) | | วัตถุประสงค์ (FOR\_APPROVAL, FOR\_INFORMATION, ...) |
| remarks | TEXT | | หมายเหตุ |
* **Foreign Keys (FK):** correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)
#### **7.2. transmittal\_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง transmittals และเอกสารที่นำส่ง (M:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| **id** | **INT** | **PK** | **(ใหม่)** ID ของรายการ |
| transmittal\_id | INT | **FK**, UK | ID ของ Transmittal (FK \-> transmittals(correspondence\_id)) |
| **item\_correspondence\_id** | **INT** | **FK**, UK | **(เปลี่ยน)** ID ของเอกสารที่แนบไป (FK \-> correspondences(id)) |
| **quantity** | **INT** | | **(ใหม่)** จำนวน |
| **remarks** | **VARCHAR(255)** | | **(ใหม่)** หมายเหตุสำหรับรายการนี้ |
* **Foreign Keys (FK):**
* transmittal\_id \-> transmittals(correspondence\_id) (ON DELETE CASCADE)
* **item\_correspondence\_id \-> correspondences(id) (ON DELETE CASCADE)**
* **Unique Keys (UK):** ux\_transmittal\_item (transmittal\_id, item\_correspondence\_id)
---
## **8\. 📎 File Management (ไฟล์แนบ)**
#### **8.1. attachments (Master)**
ตาราง "กลาง" เก็บไฟล์แนบทั้งหมดของระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของไฟล์แนบ |
| original\_filename | VARCHAR(255) | | ชื่อไฟล์ดั้งเดิม |
| stored\_filename | VARCHAR(255) | | ชื่อไฟล์ที่เก็บจริง (ป้องกันซ้ำ) |
| file\_path | VARCHAR(500) | | Path ที่เก็บไฟล์ (บน QNAP /share/dms-data/) |
| mime\_type | VARCHAR(100) | | ประเภทไฟล์ (เช่น application/pdf) |
| file\_size | INT | | ขนาดไฟล์ (bytes) |
| uploaded\_by\_user\_id | INT | FK | ผู้อัปโหลด (FK \-> users(user\_id)) |
* **Foreign Keys (FK):** uploaded\_by\_user\_id \-> users(user\_id) (ON DELETE CASCADE)
#### **8.2. correspondence\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม correspondences กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** correspondence\_id, attachment\_id
#### **8.3. circulation\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม circulations กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| circulation\_id | INT | **PK**, FK | ID ของใบเวียน (FK \-> circulations(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** circulation\_id, attachment\_id
#### **8.4. shop\_drawing\_revision\_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม shop\_drawing\_revisions กับ attachments (M:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| shop\_drawing\_revision\_id | INT | **PK**, FK | ID ของ Drawing Revision (FK \-> shop\_drawing\_revisions(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file\_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| **is\_main\_document** | **BOOLEAN** | | **(ใหม่)** (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):** shop\_drawing\_revision\_id, attachment\_id
#### **8.5. contract\_drawing\_attachments (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อม contract\_drawings กับ attachments (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| contract\_drawing\_id | INT | **PK**, FK | ID ของ Contract Drawing (FK \-> contract\_drawings(id)) |
| attachment\_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file\_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| is\_main\_document | BOOLEAN | | (1 \= ไฟล์หลัก) |
* **Foreign Keys (FK):**
* contract\_drawing\_id \-> contract\_drawings(id) (ON DELETE CASCADE)
* attachment\_id \-> attachments(id) (ON DELETE CASCADE)
---
## **9\. 🔢 Document Numbering (การสร้างเลขที่เอกสาร)**
#### **9.1. document\_number\_formats (ตารางตั้งค่า - ใหม่)**
ตาราง Master เก็บ "รูปแบบ" Template ของเลขที่เอกสาร
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| project\_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| correspondence\_type\_id | INT | FK, UK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| format\_template | VARCHAR(255) | | รูปแบบ Template (เช่น {ORG\_CODE}-{TYPE\_CODE}-{SEQ:4}) |
* **Foreign Keys (FK):** project\_id, correspondence\_type\_id
* **Unique Keys (UK):** uk\_project\_type (project\_id, correspondence\_type\_id)
#### **9.2. document\_number\_counters (ตารางตัวนับ - ใหม่)**
ตารางเก็บ "ตัวนับ" (Running Number) ล่าสุด
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| project\_id | INT | **PK**, FK | โครงการ (FK \-> projects(id)) |
| originator\_organization\_id | INT | **PK**, FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| correspondence\_type\_id | INT | **PK**, FK | ประเภทเอกสาร (FK \-> correspondence\_types(id)) |
| current\_year | INT | **PK** | ปี ค.ศ. ของตัวนับ |
| last\_number | INT | | เลขที่ล่าสุดที่ใช้ไป |
* **Foreign Keys (FK):** project\_id, originator\_organization\_id, correspondence\_type\_id
---
## **10\. ⚙️ System & Logs (ระบบและ Log)**
#### **10.1. tags**
ตาราง Master เก็บ Tags ทั้งหมดที่ใช้ในระบบ
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | INT | **PK** | ID ของตาราง |
| tag\_name | VARCHAR(100) | UK | ชื่อ Tag |
* **Unique Keys (UK):** ux\_tag\_name (tag\_name)
#### **10.2. correspondence\_tags (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง correspondences และ tags (M:N)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| correspondence\_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| tag\_id | INT | **PK**, FK | ID ของ Tag (FK \-> tags(id)) |
* **Foreign Keys (FK):** correspondence\_id, tag\_id
#### **10.3. audit\_logs**
ตารางเก็บบันทึกการกระทำของผู้ใช้
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| audit\_id | BIGINT | **PK** | ID ของ Log |
| user\_id | INT | FK | ผู้กระทำ (FK \-> users(user\_id)) |
| action | VARCHAR(100) | | การกระทำ (เช่น rfa.create) |
| entity\_type | VARCHAR(50) | | ตาราง/โมดูล (เช่น rfas) |
| entity\_id | VARCHAR(50) | | ID ของสิ่งที่ถูกกระทำ |
| details\_json | JSON | | ข้อมูลเพิ่มเติม |
| ip\_address | VARCHAR(45) | | IP Address |
| created\_at | TIMESTAMP | | เวลาที่กระทำ |
* **Foreign Keys (FK):** user\_id \-> users(user\_id) (ON DELETE SET NULL)
#### **10.4. global\_default\_roles (ใหม่)**
ตารางเก็บค่าเริ่มต้นของบทบาทองค์กร (เช่น OWNER, DESIGNER)
| Column | Type | Key | Description |
| :--- | :--- | :--- | :--- |
| id | TINYINT | **PK** | ID คงที่ ( \= 1) |
| role | ENUM(...) | **PK** | บทบาท (OWNER, DESIGNER, CONSULTANT) |
| position | TINYINT | **PK** | ลำดับที่ในบทบาท (1..n) |
| organization\_id | INT | FK, UK | ID องค์กร (FK \-> organizations(id)) |
* **Foreign Keys (FK):** organization\_id \-> organizations(id) (ON DELETE RESTRICT)
* **Unique Keys (UK):** ux\_gdr\_unique\_org\_per\_role (id, role, organization\_id)
#### **10.5. Workflow Transition Rules (ใหม่)**
ตารางกำหนด Business Rules สำหรับการเปลี่ยนสถานะ
* **correspondence\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ Correspondences (ทั่วไป)
* **rfa\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ RFA
* **circulation\_status\_transitions:** (ใหม่) กฎการเปลี่ยนสถานะของ Circulations (ใบเวียน)
---
## **11\. 📋 Views & Procedures (วิว และ โปรซีเดอร์)**
#### **11.1. sp\_get\_next\_document\_number (Procedure)**
**(ใหม่)** Stored Procedure เดียวที่ใช้ในระบบ
* **หน้าที่:** ดึงเลขที่เอกสารถัดไป (Next Running Number) จากตาราง document\_number\_counters
* **ตรรกะ:** ใช้ `SELECT ... FOR UPDATE` เพื่อ "ล็อก" แถว ป้องกัน Race Condition (การที่ผู้ใช้ 2 คนได้เลขที่ซ้ำกัน)
#### **11.2. v\_current\_correspondences (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ correspondences ทั้งหมด (ที่ไม่ใช่ RFA)
#### **11.3. v\_current\_rfas (View)**
* **หน้าที่:** แสดง Revision "ปัจจุบัน" (is\_current \= TRUE) ของ rfa\_revisions ทั้งหมด
#### **11.4. v\_contract\_parties\_all (View)**
* **หน้าที่:** แสดงความสัมพันธ์ทั้งหมดระหว่าง Contract, Project, และ Organization
#### **11.5. v\_user\_tasks (View)**
**(ใหม่)**
* **หน้าที่:** แสดงรายการ "งานของฉัน" (My Tasks) ที่ยังไม่เสร็จ
* **ตรรกะ:** JOIN ตาราง circulations กับ circulation\_assignees (ที่ is\_completed \= FALSE)
#### **11.6. v\_audit\_log\_details (View)**
**(ใหม่)**
* **หน้าที่:** แสดง audit\_logs พร้อมข้อมูล username และ email ของผู้กระทำ
#### **11.7. v\_user\_all\_permissions (View)**
**(ใหม่)**
* **หน้าที่:** รวมสิทธิ์ทั้งหมด (Global \+ Project) ของผู้ใช้ทุกคน เพื่อให้ Backend ตรวจสอบสิทธิ์ได้ง่าย
* **ตรรกะ:** UNION ข้อมูลจาก user\_roles และ user\_project\_roles

View File

@@ -0,0 +1,478 @@
# **Documents Management Sytem Version 1.3.0: แนวทางการพัฒนา FullStackJS**
## **🧠 ปรัชญาทั่วไป**
แนวทางปฏิบัติที่ดีที่สุดแบบครบวงจรสำหรับการพัฒนา NestJS Backend, NextJS Frontend และ Tailwind-based UI/UX ในสภาพแวดล้อม TypeScript มุ่งเน้นที่ ความชัดเจน (clarity), ความง่ายในการบำรุงรักษา (maintainability), ความสอดคล้องกัน (consistency) และ การเข้าถึงได้ (accessibility) ตลอดทั้งสแต็ก
## **⚙️ แนวทางทั่วไปสำหรับ TypeScript**
### **หลักการพื้นฐาน**
* ใช้ **ภาษาอังกฤษ** สำหรับโค้ด
* ใช้ **ภาษาไทย** สำหรับ comment และเอกสารทั้งหมด
* กำหนดไทป์ (type) อย่างชัดเจนสำหรับตัวแปร, พารามิเตอร์ และค่าที่ส่งกลับ (return values) ทั้งหมด
* หลีกเลี่ยงการใช้ any; ให้สร้างไทป์ (types) หรืออินเทอร์เฟซ (interfaces) ที่กำหนดเอง
* ใช้ **JSDoc** สำหรับคลาส (classes) และเมธอด (methods) ที่เป็น public
* ส่งออก (Export) **สัญลักษณ์หลัก (main symbol) เพียงหนึ่งเดียว** ต่อไฟล์
* หลีกเลี่ยงบรรทัดว่างภายในฟังก์ชัน
* ระบุ // File: path/filename ในบรรทัดแรกของทุกไฟล์
* ระบุ // บันทึกการแก้ไข, หากมีการแก้ไขเพิ่มในอนาคต ให้เพิ่มบันทึก
### **ข้อตกลงในการตั้งชื่อ (Naming Conventions)**
| Entity (สิ่งที่ตั้งชื่อ) | Convention (รูปแบบ) | Example (ตัวอย่าง) |
| :---- | :---- | :---- |
| Classes | PascalCase | UserService |
| Property | snake_sase | user_id |
| Variables & Functions | camelCase | getUserInfo |
| Files & Folders | kebab-case | user-service.ts |
| Environment Variables | UPPERCASE | DATABASE\URL |
| Booleans | Verb \+ Noun | isActive, canDelete, hasPermission |
ใช้คำเต็ม — ไม่ใช้อักษรย่อ — ยกเว้นคำมาตรฐาน (เช่น API, URL, req, res, err, ctx)
## **🧩 ฟังก์ชัน (Functions)**
* เขียนฟังก์ชันให้สั้น และทำ **หน้าที่เพียงอย่างเดียว** (single-purpose) (\< 20 บรรทัด)
* ใช้ **early returns** เพื่อลดการซ้อน (nesting) ของโค้ด
* ใช้ **map**, **filter**, **reduce** แทนการใช้ loops เมื่อเหมาะสม
* ควรใช้ **arrow functions** สำหรับตรรกะสั้นๆ, และใช้ **named functions** ในกรณีอื่น
* ใช้ **default parameters** แทนการตรวจสอบค่า null
* จัดกลุ่มพารามิเตอร์หลายตัวให้เป็นอ็อบเจกต์เดียว (RO-RO pattern)
* ส่งค่ากลับ (Return) เป็นอ็อบเจกต์ที่มีไทป์กำหนด (typed objects) ไม่ใช่ค่าพื้นฐาน (primitives)
* รักษาระดับของสิ่งที่เป็นนามธรรม (abstraction level) ให้เป็นระดับเดียวในแต่ละฟังก์ชัน
## **🧱 การจัดการข้อมูล (Data Handling)**
* ห่อหุ้มข้อมูล (Encapsulate) ในไทป์แบบผสม (composite types)
* ใช้ **immutability** (การไม่เปลี่ยนแปลงค่า) ด้วย readonly และ as const
* ทำการตรวจสอบความถูกต้องของข้อมูล (Validations) ในคลาสหรือ DTOs ไม่ใช่ภายในฟังก์ชันทางธุรกิจ
* ตรวจสอบความถูกต้องของข้อมูลโดยใช้ DTOs ที่มีไทป์กำหนดเสมอ
## **🧰 คลาส (Classes)**
* ปฏิบัติตามหลักการ **SOLID**
* ควรใช้ **composition มากกว่า inheritance** (Prefer composition over inheritance)
* กำหนด **interfaces** สำหรับสัญญา (contracts)
* ให้คลาสมุ่งเน้นการทำงานเฉพาะอย่างและมีขนาดเล็ก (\< 200 บรรทัด, \< 10 เมธอด, \< 10 properties)
## **🚨 การจัดการข้อผิดพลาด (Error Handling)**
* ใช้ Exceptions สำหรับข้อผิดพลาดที่ไม่คาดคิด
* ดักจับ (Catch) ข้อผิดพลาดเพื่อแก้ไขหรือเพิ่มบริบท (context) เท่านั้น; หากไม่เช่นนั้น ให้ใช้ global error handlers
* ระบุข้อความข้อผิดพลาด (error messages) ที่มีความหมายเสมอ
## **🧪 การทดสอบ (ทั่วไป) (Testing (General))**
* ใช้รูปแบบ **ArrangeActAssert**
* ใช้ชื่อตัวแปรในการทดสอบที่สื่อความหมาย (inputData, expectedOutput)
* เขียน **unit tests** สำหรับ public methods ทั้งหมด
* จำลอง (Mock) การพึ่งพาภายนอก (external dependencies)
* เพิ่ม **acceptance tests** ต่อโมดูลโดยใช้รูปแบบ GivenWhen-Then
## **🏗️ แบ็กเอนด์ (NestJS) (Backend (NestJS))**
### **หลักการ**
* **สถาปัตยกรรมแบบโมดูลาร์ (Modular architecture)**:
* หนึ่งโมดูลต่อหนึ่งโดเมน
* โครงสร้างแบบ Controller → Service → Repository (Model)
* API-First: มุ่งเน้นการสร้าง API ที่มีคุณภาพสูง มีเอกสารประกอบ (Swagger) ที่ชัดเจนสำหรับ Frontend Team
* DTOs ที่ตรวจสอบความถูกต้องด้วย **class-validator**
* ใช้ **MikroORM** (หรือ TypeORM/Prisma) สำหรับการคงอยู่ของข้อมูล (persistence) ซึ่งสอดคล้องกับสคีมา MariaDB
* ห่อหุ้มโค้ดที่ใช้ซ้ำได้ไว้ใน **common module** (@app/common):
* Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators
### **ฟังก์ชันหลัก (Core Functionalities)**
* Global **filters** สำหรับการจัดการ exception
* **Middlewares** สำหรับการจัดการ request
* **Guards** สำหรับการอนุญาต (permissions) และ RBAC
* **Interceptors** สำหรับการแปลงข้อมูล response และการบันทึก log
### **ข้อจำกัดในการ Deploy (QNAP Container Station)**
* **ห้ามใช้ไฟล์ .env** ในการตั้งค่า Environment Variables [cite: 2.1]
* การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน docker-compose.yml โดยตรง** [cite: 6.5] ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station [cite: 2.1]
### **โครงสร้างโมดูลตามโดเมน (Domain-Driven Module Structure)**
เพื่อให้สอดคล้องกับสคีมา SQL (LCBP3-DMS) เราจะใช้โครงสร้างโมดูลแบบ **Domain-Driven (แบ่งตามขอบเขตธุรกิจ)** แทนการแบ่งตามฟังก์ชัน:
1. **CommonModule:**
* เก็บ Services ที่ใช้ร่วมกัน เช่น DatabaseModule, FileStorageService (จัดการไฟล์ใน QNAP), AuditLogService, NotificationService
* จัดการ audit_logs
* NotificationService ต้องรองรับ Triggers ที่ระบุใน Requirement 6.7 [cite: 6.7]
2. **AuthModule:**
* จัดการะการยืนยันตัวตน (JWT, Guards)
* **(สำคัญ)** ต้องรับผิดชอบการตรวจสอบสิทธิ์ **3 ระดับ** [cite: 4.2]: สิทธิ์ระดับระบบ (Global Role), สิทธิ์ระดับโปรเจกต์ (Project Role), และ **สิทธิ์ระดับสัญญา (Contract Role)**
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
* ให้ Superadmin สร้าง Organizations และกำหนด Org Admin ได้ [cite: 4.6]
* ให้ Superadmin/Admin จัดการ document_number_formats (รูปแบบเลขที่เอกสาร), document_number_counters (Running Number) [cite: 3.10]
3. **UserModule:**
* จัดการ users, roles, permissions, global_default_roles, role_permissions, user_roles, user_project_roles
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
4. **ProjectModule:**
* จัดการ projects, organizations, contracts, project_parties, contract_parties
5. **MasterModule:**
* จัดการ master data (correspondence_types, rfa_types, rfa_status_codes, rfa_approve_codes, circulation_status_codes, correspondence_types, correspondence_status, tags) [cite: 4.5]
6. **CorrespondenceModule (โมดูลศูนย์กลาง):**
* จัดการ correspondences, correspondence_revisions, correspondence_tags
* **(สำคัญ)** Service นี้ต้อง Inject DocumentNumberingService เพื่อขอเลขที่เอกสารใหม่ก่อนการสร้าง
* **(สำคัญ)** ตรรกะการสร้าง/อัปเดต Revision จะอยู่ใน Service นี้
* จัดการ correspondence_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Correspondence Routings"** (correspondence_routings, correspondence_routing_templates) สำหรับการส่งต่อเอกสารทั่วไประหว่างองค์กร
7. **RfaModule:**
* จัดการ rfas, rfa_revisions, rfa_items
* รับผิดชอบเวิร์กโฟลว์ **"RFA Workflows"** (rfa_workflows, rfa_workflow_templates, rfa_workflow_template_steps, rfa_status_transitions) สำหรับการอนุมัติเอกสารทางเทคนิค
8. **DrawingModule:**
* จัดการ shop_drawings, shop_drawing_revisions, contract_drawings, contract_drawing_volumes, contract_drawing_cats, contract_drawing_sub_cats, shop_drawing_main_categories, shop_drawing_sub_categories, contract_drawing_subcat_cat_maps, shop_drawing_revision_contract_refs
* จัดการ shop_drawing_revision_attachments และ contract_drawing_attachments(ตารางเชื่อมไฟล์แนบ)
9. **CirculationModule:**
* จัดการ circulations, circulation_templates, circulation_assignees
* จัดการ circulation_attachments (ตารางเชื่อมไฟล์แนบ)
* รับผิดชอบเวิร์กโฟลว์ **"Circulations"** (circulation_status_transitions, circulation_template_assignees, circulation_assignees, circulation_recipients, circulation_actions, circulation_action_documents)สำหรับการเวียนเอกสาร **ภายในองค์กร**
10. **TransmittalModule:**
* จัดการ transmittals และ transmittal_items
11. **SearchModule:**
* ให้บริการค้นหาขั้นสูง (Advanced Search) [cite: 6.2] โดยใช้ **Elasticsearch** เพื่อรองรับการค้นหาแบบ Full-text จากชื่อเรื่อง, รายละเอียด, เลขที่เอกสาร, ประเภท, วันที่, และ Tags
12. **DocumentNumberingModule:**
* **สถานะ:** เป็น Module ภายใน (Internal Module) ไม่เปิด API สู่ภายนอก
* **หน้าที่:** ให้บริการ DocumentNumberingService ที่ Module อื่น (เช่น CorrespondenceModule) จะ Inject ไปใช้งาน
* **ตรรกะ:** รับผิดชอบการสร้างเลขที่เอกสาร โดยการเรียกใช้ Stored Procedure *sp_get_next_document_number** เพื่อป้องกัน Race Condition
### **สถาปัตยกรรมระบบ (System Architecture)**
โครงสร้างโมดูล (Module Structure)
```bash
📁 src
├── 📄 app.module.ts
├── 📄 main.ts
├── 📁 common # @app/common (โมดูลส่วนกลาง)
│ ├── 📁 auth # AuthModule (JWT, Guards)
│ ├── 📁 config # Configuration
│ ├── 📁 decorators # Custom Decorators (เช่น @RequirePermission)
│ ├── 📁 entities # Shared Entities (User, Role, Permission)
│ ├── 📁 exceptions # Global Exception Filters
│ ├── 📁 file-storage # FileStorageService
│ ├── 📁 guards # Custom Guards (RBAC Guard)
│ ├── 📁 interceptors # Interceptors (Audit Log, Transform)
│ └── 📁 services # Shared Services (NotificationService)
├── 📁 modules
│ ├── 📁 user # UserModule (จัดการ Users, Roles, Permissions)
│ ├── 📁 project # ProjectModule (จัดการ Projects, Organizations, Contracts)
│ ├── 📁 correspondence # CorrespondenceModule (จัดการเอกสารโต้ตอบ)
│ ├── 📁 rfa # RfaModule (จัดการเอกสารขออนุมัติ)
│ ├── 📁 drawing # DrawingModule (จัดการแบบแปลน)
│ ├── 📁 circulation # CirculationModule (จัดการใบเวียน)
│ ├── 📁 transmittal # TransmittalModule (จัดการเอกสารนำส่ง)
│ ├── 📁 search # SearchModule (ค้นหาขั้นสูงด้วย Elasticsearch)
│ └── 📁 document-numbering # DocumentNumberingModule (Internal Module)
└── 📁 database # Database Migration & Seeding Scripts
```
### **เเทคโนโลยีที่ใช้ (Technology Stack)**
| ส่วน | Library/Tool | หมายเหตุ |
|---|---|---|
| **Framework** | `@nestjs/core`, `@nestjs/common` | Core Framework |
| **Language** | `TypeScript` | ใช้ TypeScript ทั้งระบบ |
| **Database** | `MariaDB 10.11` | ฐานข้อมูลหลัก |
| **ORM** | `@nestjs/typeorm`, `typeorm` | 🗃️จัดการการเชื่อมต่อและ Query ฐานข้อมูล |
| **Validation** | `class-validator`, `class-transformer` | 📦ตรวจสอบและแปลงข้อมูลใน DTO |
| **Auth** | `@nestjs/jwt`, `@nestjs/passport`, `passport-jwt` | 🔐การยืนยันตัวตนด้วย JWT |
|**Authorization** | `casl` | 🔐จัดการสิทธิ์แบบ RBAC |
| **File Upload** | `multer` | 📁จัดการการอัปโหลดไฟล์ |
| **Search** | `@nestjs/elasticsearch` | 🔍สำหรับการค้นหาขั้นสูง |
| **Notification** | `nodemailer` | 📬ส่งอีเมลแจ้งเตือน |
| **Scheduling** | `@nestjs/schedule` | 📬สำหรับ Cron Jobs (เช่น แจ้งเตือน Deadline) |
| **Logging** | `winston` | 📊บันทึก Log ที่มีประสิทธิภาพ |
| **Testing** | `@nestjs/testing`, `jest`, `supertest` | 🧪ทดสอบ Unit, Integration และ E2E |
| **Documentation** | `@nestjs/swagger` | 🌐สร้าง API Documentation อัตโนมัติ |
| **Security** | `helmet`, `rate-limiter-flexible` | 🛡️เพิ่มความปลอดภัยให้ API |
เราจะแบ่งการทดสอบเป็น 3 ระดับ โดยใช้ **Jest** และ @nestjs/testing:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เป้าหมาย:** ทดสอบ Logic ภายใน Service, Guard, หรือ Pipe โดยจำลอง (Mock) Dependencies ทั้งหมด
* **สิ่งที่ต้องทดสอบ:** Business Logic (เช่น การเปลี่ยนสถานะ Workflow, การตรวจสอบ Deadline) [cite: 2.9.1], ตรรกะการตรวจสอบสิทธิ์ (Auth Guard) ทั้ง 3 ระดับ
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เป้าหมาย:** ทดสอบการทำงานร่วมกันของ Controller -> Service -> Repository (Database)
* **เทคนิค:** ใช้ **Test Database แยกต่างหาก** (ห้ามใช้ Dev DB) และใช้ supertest เพื่อยิง HTTP Request จริงไปยัง App
* **สิ่งที่ต้องทดสอบ:** การเรียก sp\get\next\document\number [cite: 2.9.3] และการทำงานของ Views (เช่น v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เป้าหมาย:** ทดสอบ API Contract ว่า Response Body Shape ตรงตามเอกสาร Swagger เพื่อรับประกันทีม Frontend
### **🗄️ Backend State Management**
Backend (NestJS) ควรเป็น **Stateless** (ไม่เก็บสถานะ) "State" ทั้งหมดจะถูกจัดเก็บใน MariaDB
* **Request-Scoped State (สถานะภายใน Request เดียว):**
* **ปัญหา:** จะส่งต่อข้อมูล (เช่น User ที่ล็อกอิน) ระหว่าง Guard และ Service ใน Request เดียวกันได้อย่างไร?
* **วิธีแก้:** ใช้ **Request-Scoped Providers** ของ NestJS (เช่น AuthContextService) เพื่อเก็บข้อมูล User ปัจจุบันที่ได้จาก AuthGuard และให้ Service อื่น Inject ไปใช้
* **Application-Scoped State (การ Caching):**
* **ปัญหา:** ข้อมูล Master (เช่น roles, permissions, organizations) ถูกเรียกใช้บ่อย
* **วิธีแก้:** ใช้ **Caching** (เช่น @nestjs/cache-manager) เพื่อ Caching ข้อมูลเหล่านี้ และลดภาระ Database
### **การไหลของข้อมูล (Data Flow)**
1. Request: ผ่าน Nginx Proxy Manager -> NestJS Controller
2. Authentication: JWT Guard ตรวจสอบ Token และดึงข้อมูล User
3. Authorization: RBAC Guard (ใช้ CASL) ตรวจสอบสิทธิ์จาก Decorators (@RequirePermission)
4. Validation: Validation Pipe (ใช้ class-validator) ตรวจสอบ DTO
5. Business Logic: Service Layer ประมวลผลตรรกะทางธุรกิจ
6. Data Access: Repository Layer (ใช้ TypeORM) ติดต่อกับฐานข้อมูล MariaDB
7. Response: ส่งกลับไปยัง Frontend พร้อมสถานะและข้อมูลที่เหมาะสม
# **🖥️ ฟรอนต์เอนด์ (NextJS / React / UI) (Frontend (NextJS / React / UI))**
### **โปรไฟล์นักพัฒนา (Developer Profile)**
วิศวกร TypeScript + React/NextJS ระดับ Senior
เชี่ยวชาญ TailwindCSS, Shadcn/UI, และ Radix สำหรับการพัฒนา UI
### **แนวทางการพัฒนาโค้ด (Code Implementation Guidelines)**
* ใช้ **early returns** เพื่อความชัดเจน
* ใช้คลาสของ **TailwindCSS** ในการกำหนดสไตล์เสมอ
* ควรใช้ class: syntax แบบมีเงื่อนไข (หรือ utility clsx) มากกว่าการใช้ ternary operators ใน class strings
* ใช้ **const arrow functions** สำหรับ components และ handlers
* Event handlers ให้ขึ้นต้นด้วย handle... (เช่น handleClick, handleSubmit)
* รวมแอตทริบิวต์สำหรับการเข้าถึง (accessibility) ด้วย:
tabIndex="0", aria-label, onKeyDown, ฯลฯ
* ตรวจสอบให้แน่ใจว่าโค้ดทั้งหมด **สมบูรณ์**, **ผ่านการทดสอบ**, และ **ไม่ซ้ำซ้อน (DRY)**
* ต้อง import โมดูลที่จำเป็นต้องใช้อย่างชัดเจนเสมอ
### **UI/UX ด้วย React**
* ใช้ **semantic HTML**
* ใช้คลาสของ **Tailwind** ที่รองรับ responsive (sm:, md:, lg:)
* รักษาลำดับชั้นของการมองเห็น (visual hierarchy) ด้วยการใช้ typography และ spacing
* ใช้ **Shadcn** components (Button, Input, Card, ฯลฯ) เพื่อ UI ที่สอดคล้องกัน
* ทำให้ components มีขนาดเล็กและมุ่งเน้นการทำงานเฉพาะอย่าง
* ใช้ utility classes สำหรับการจัดสไตล์อย่างรวดเร็ว (spacing, colors, text, ฯลฯ)
* ตรวจสอบให้แน่ใจว่าสอดคล้องกับ **ARIA** และใช้ semantic markup
### **การตรวจสอบฟอร์มและข้อผิดพลาด (Form Validation & Errors)**
* ใช้ไลบรารีฝั่ง client เช่น zod และ react-hook-form
* แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline
* ต้องมี labels, placeholders, และข้อความ feedback
### **🧪 Frontend Testing**
เราจะใช้ **React Testing Library (RTL)** สำหรับการทดสอบ Component และ **Playwright** สำหรับ E2E:
* **Unit Tests (การทดสอบหน่วยย่อย):**
* **เครื่องมือ:** Vitest + RTL
* **เป้าหมาย:** ทดสอบ Component ขนาดเล็ก (เช่น Buttons, Inputs) หรือ Utility functions
* **Integration Tests (การทดสอบการบูรณาการ):**
* **เครื่องมือ:** RTL + **Mock Service Worker (MSW)**
* **เป้าหมาย:** ทดสอบว่า Component หรือ Page ทำงานกับ API (ที่จำลองขึ้น) ได้ถูกต้อง
* **เทคนิค:** ใช้ MSW เพื่อจำลอง NestJS API และทดสอบว่า Component แสดงผลข้อมูลจำลองได้ถูกต้องหรือไม่ (เช่น ทดสอบหน้า Dashboard [cite: 5.3] ที่ดึงข้อมูลจาก v_user_tasks)
* **E2E (End-to-End) Tests:**
* **เครื่องมือ:** **Playwright**
* **เป้าหมาย:** ทดสอบ User Flow ทั้งระบบโดยอัตโนมัติ (เช่น ล็อกอิน -> สร้าง RFA -> ตรวจสอบ Workflow Visualization [cite: 5.6])
### **🗄️ Frontend State Management**
สำหรับ Next.js App Router เราจะแบ่ง State เป็น 4 ระดับ:
1. **Local UI State (สถานะ UI ชั่วคราว):**
* **เครื่องมือ:** useState, useReducer
* **ใช้เมื่อ:** จัดการสถานะเล็กๆ ที่จบใน Component เดียว (เช่น Modal เปิด/ปิด, ค่าใน Input)
2. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์):**
* **เครื่องมือ:** **React Query (TanStack Query)** หรือ SWR
* **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API (เช่น รายการ correspondences, rfas, drawings)
* **ทำไม:** React Query เป็น "Cache" ที่จัดการ Caching, Re-fetching, และ Invalidation ให้โดยอัตโนมัติ
3. **Global Client State (สถานะส่วนกลางฝั่ง Client):**
* **เครื่องมือ:** **Zustand** (แนะนำ) หรือ Context API
* **ใช้เมื่อ:** จัดการข้อมูลที่ต้องใช้ร่วมกันทั่วทั้งแอป และ *ไม่ใช่* ข้อมูลจากเซิร์ฟเวอร์ (เช่น ข้อมูล User ที่ล็อกอิน, สิทธิ์ Permissions)
4. **Form State (สถานะของฟอร์ม):**
* **เครื่องมือ:** **React Hook Form** + **Zod**
* **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อน (เช่น ฟอร์มสร้าง RFA, ฟอร์ม Circulation [cite: 3.7])
# **🔗 แนวทางการบูรณาการ Full Stack (Full Stack Integration Guidelines)**
| Aspect (แง่มุม) | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
| :---- | :---- | :---- | :---- |
| API | REST / GraphQL Controllers | API hooks ผ่าน fetch/axios/SWR | Components ที่รับข้อมูล |
| Validation (การตรวจสอบ) | class-validator DTOs | zod / react-hook-form | สถานะของฟอร์ม/input ใน Shadcn |
| Auth (การยืนยันตัวตน) | Guards, JWT | NextAuth / cookies | สถานะ UI ของ Auth (loading, signed in) |
| Errors (ข้อผิดพลาด) | Global filters | Toasts / modals | Alerts / ข้อความ feedback |
| Testing (การทดสอบ) | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
| Styles (สไตล์) | Scoped modules (ถ้าจำเป็น) | Tailwind / Shadcn | Tailwind utilities |
| Accessibility (การเข้าถึง) | Guards + filters | ARIA attributes | Semantic HTML |
## **🗂️ ข้อตกลงเฉพาะสำหรับ DMS (LCBP3-DMS)**
ส่วนนี้ขยายแนวทาง FullStackJS ทั่วไปสำหรับโปรเจกต์ **LCBP3-DMS** โดยมุ่งเน้นไปที่เวิร์กโฟลว์การอนุมัติเอกสาร (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation)
### **🧩 RBAC และการควบคุมสิทธิ์ (RBAC & Permission Control)**
ใช้ Decorators เพื่อบังคับใช้สิทธิ์การเข้าถึง โดยอ้างอิงสิทธิ์จากตาราง permissions
@RequirePermission('rfas.respond') // ต้องตรงกับ 'permission\code'
@Put(':id')
updateRFA(@Param('id') id: string) {
return this.rfaService.update(id);
}
### **Roles (บทบาท)**
* **Superadmin**: ไม่มีข้อจำกัดใดๆ [cite: 4.3]
* **Admin**: มีสิทธิ์เต็มที่ในองค์กร [cite: 4.3]
* **Document Control**: เพิ่ม/แก้ไข/ลบ เอกสารในองค์กร [cite: 4.3]
* **Editor**: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนด [cite: 4.3]
* **Viewer**: สามารถดู เอกสาร [cite: 4.3]
### **ตัวอย่าง Permissions (จากตาราง permissions)**
* rfas.view, rfas.create, rfas.respond, rfas.delete
* drawings.view, drawings.upload, drawings.delete
* corr.view, corr.manage
* transmittals.manage
* cirs.manage
* project\parties.manage
การจับคู่ระหว่าง roles และ permissions **เริ่มต้น** จะถูก seed ผ่านสคริปต์ (ดังที่เห็นในไฟล์ SQL)**อย่างไรก็ตาม AuthModule/UserModule ต้องมี API สำหรับ Admin เพื่อสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลัง** [cite: 4.3]
## **🧾 มาตรฐาน AuditLog (AuditLog Standard)**
บันทึกการดำเนินการ CRUD และการจับคู่ทั้งหมดลงในตาราง audit_logs
| Field (ฟิลด์) | Type (จาก SQL) | Description (คำอธิบาย) |
| :---- | :---- | :---- |
| audit_id | BIGINT | Primary Key |
| user_id | INT | ผู้ใช้ที่ดำเนินการ (FK -> users) |
| action | VARCHAR(100) | rfa.create, correspondence.update, login.success |
| entity_type | VARCHAR(50) | ชื่อตาราง/โมดูล เช่น 'rfa', 'correspondence' |
| entity_id | VARCHAR(50) | Primary ID ของระเบียนที่ได้รับผลกระทบ |
| details_json | JSON | ข้อมูลบริบท (เช่น ฟิลด์ที่มีการเปลี่ยนแปลง) |
| ip_address | VARCHAR(45) | IP address ของผู้ดำเนินการ |
| user_agent | VARCHAR(255) | User Agent ของผู้ดำเนินการ |
| created_at | TIMESTAMP | Timestamp (UTC) |
## **📂 การจัดการไฟล์ (File Handling) (ปรับปรุงใหม่)**
### **มาตรฐานการอัปโหลดไฟล์ (File Upload Standard)**
* **ตรรกะใหม่:** การอัปโหลดไฟล์ทั้งหมดจะถูกจัดการโดย FileStorageService และบันทึกข้อมูลไฟล์ลงในตาราง attachments (ตารางกลาง)
* ไฟล์จะถูกเชื่อมโยงไปยัง Entity ที่ถูกต้องผ่าน **ตารางเชื่อม (Junction Tables)** เท่านั้น:
* correspondence_attachments (เชื่อม Correspondence กับ Attachments)
* circulation_attachments (เชื่อม Circulation กับ Attachments)
* shop_drawing_revision_attachments (เชื่อม Shop Drawing Revision กับ Attachments)
* contract_drawing_attachments (เชื่อม Contract Drawing กับ Attachments)
* เส้นทางจัดเก็บไฟล์ (Upload path): อ้างอิงจาก Requirement 2.1 คือ /share/dms-data [cite: 2.1] โดย FileStorageService จะสร้างโฟลเดอร์ย่อยแบบรวมศูนย์ (เช่น /share/dms-data/uploads/{YYYY}/{MM}/[stored\filename])
* ประเภทไฟล์ที่อนุญาต: pdf, dwg, docx, xlsx, zip
* ขนาดสูงสุด: **50 MB**
* จัดเก็บนอก webroot
* ให้บริการไฟล์ผ่าน endpoint ที่ปลอดภัย /files/:attachment_id/download
### **การควบคุมการเข้าถึง (Access Control)**
การเข้าถึงไฟล์ไม่ใช่การเข้าถึงโดยตรง endpoint /files/:attachment_id/download จะต้อง:
1. ค้นหาระเบียน attachment
2. ตรวจสอบว่า attachment_id นี้ เชื่อมโยงกับ Entity ใด (เช่น correspondence, circulation, shop_drawing_revision, contract_drawing) ผ่านตารางเชื่อม
3. ตรวจสอบว่าผู้ใช้มีสิทธิ์ (permission) ในการดู Entity ต้นทางนั้นๆ หรือไม่
## **🔟 การจัดการเลขที่เอกสาร (Document Numbering) [cite: 3.10]**
* **เป้าหมาย:** สร้างเลขที่เอกสาร (เช่น correspondence\number) โดยอัตโนมัติ ตามรูปแบบที่กำหนด
* **ตรรกะการนับ:** การนับ Running number (SEQ) จะนับแยกตาม Key: **Project + Originator Organization + Document Type + Year**
* **ตาราง SQL:**
* document_number_formats: Admin ใช้กำหนด "รูปแบบ" (Template) ของเลขที่ (เช่น {ORG\CODE}-{TYPE\CODE}-{YEAR\SHORT}-{SEQ:4}) โดยกำหนดตาม **Project** และ **Document Type** [cite: 4.5]
* document_number_counters: ระบบใช้เก็บ "ตัวนับ" ล่าสุดของ Key (Project+Org+Type+Year)
* **การทำงาน (Backend):**
* DocumentNumberingModule จะให้บริการ DocumentNumberingService
* เมื่อ CorrespondenceModule ต้องการสร้างเอกสารใหม่, มันจะเรียก documentNumberingService.generateNextNumber(...)
* Service นี้จะเรียกใช้ Stored Procedure **sp_get_next_document_number** [cite: 2.9.3] ซึ่ง Procedure นี้จะจัดการ Database Transaction และ Row Lock (FOR UPDATE) ภายใน DB เพื่อรับประกันการป้องกัน Race Condition
## **📊 การรายงานและการส่งออก (Reporting & Exports)**
### **วิวสำหรับการรายงาน (Reporting Views) (จาก SQL)**
การรายงานควรสร้างขึ้นจาก Views ที่กำหนดไว้ล่วงหน้าในฐานข้อมูลเป็นหลัก:
* v_current_correspondences: สำหรับ revision ปัจจุบันทั้งหมดของเอกสารที่ไม่ใช่ RFA
* v_current_rfas: สำหรับ revision ปัจจุบันทั้งหมดของ RFA และข้อมูล master
* v_contract_parties_all: สำหรับการตรวจสอบความสัมพันธ์ของ project/contract/organization
* v_user_tasks: สำหรับ Dashboard "งานของฉัน"
* v_audit_log_details: สำหรับ Activity Feed
Views เหล่านี้ทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการรายงานฝั่งเซิร์ฟเวอร์และการส่งออกข้อมูล
### **กฎการส่งออก (Export Rules)**
* Export formats: CSV, Excel, PDF.
* จัดเตรียมมุมมองสำหรับพิมพ์ (Print view).
* รวมลิงก์ไปยังต้นทาง (เช่น /rfas/:id).
## **🧮 ฟรอนต์เอนด์: รูปแบบ DataTable และฟอร์ม (Frontend: DataTable & Form Patterns)**
### **DataTable (ServerSide)**
* Endpoint: /api/{module}?page=1\&pageSize=20\&sort=...\&filter=...
* ต้องรองรับ: การแบ่งหน้า (pagination), การเรียงลำดับ (sorting), การค้นหา (search), การกรอง (filters)
* แสดง revision ล่าสุดแบบ inline เสมอ (สำหรับ RFA/Drawing)
### **มาตรฐานฟอร์ม (Form Standards)**
* ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ):
* Project → Contract Drawing Volumes
* Contract Drawing Category → Sub-Category
* RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้
* **(ใหม่)** การอัปโหลดไฟล์: ต้องรองรับ **Multi-file upload (Drag-and-Drop)** [cite: 5.7]
* **(ใหม่)** UI ต้องอนุญาตให้ผู้ใช้กำหนดว่าไฟล์ใดเป็น **"เอกสารหลัก"** หรือ "เอกสารแนบประกอบ" [cite: 5.7]
* ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast
### **ข้อกำหนด Component เฉพาะ (Specific UI Requirements)**
* **Dashboard \- My Tasks:** ต้องพัฒนา Component ตาราง "งานของฉัน" (My Tasks)ซึ่งดึงข้อมูลงานที่ผู้ใช้ล็อกอินอยู่ต้องรับผิดชอบ (Main/Action) จาก v\user\tasks [cite: 5.3]
* **Workflow Visualization:** ต้องพัฒนา Component สำหรับแสดงผล Workflow (โดยเฉพาะ RFA)ที่แสดงขั้นตอนทั้งหมดเป็นลำดับ โดยขั้นตอนปัจจุบัน (active) เท่านั้นที่ดำเนินการได้ และขั้นตอนอื่นเป็น disabled [cite: 5.6] ต้องมีตรรกะสำหรับ Admin ในการ override หรือย้อนกลับขั้นตอนได้ [cite: 5.6]
* ** Admin Panel:** ต้องมีหน้า UI สำหรับ Superadmin/Admin เพื่อจัดการข้อมูลหลัก (Master Data [cite: 4.5]), การเริ่มต้นใช้งาน (Onboarding [cite: 4.6]), และ **รูปแบบเลขที่เอกสาร (Numbering Formats [cite: 3.10])**
## **🧭 แดชบอร์ดและฟีดกิจกรรม (Dashboard & Activity Feed)**
### **การ์ดบนแดชบอร์ด (Dashboard Cards)**
* แสดง Correspondences, RFAs, Circulations, Shop Drawing Revision ล่าสุด
* รวมสรุป KPI (เช่น "RFAs ที่รอการอนุมัติ", "Shop Drawing ที่รอการอนุมัติ") [cite: 5.3]
* รวมลิงก์ด่วนไปยังโมดูลต่างๆ
### **ฟีดกิจกรรม (Activity Feed)**
* แสดงรายการ v\audit\log\details ล่าสุด (10 รายการ) ที่เกี่ยวข้องกับผู้ใช้
// ตัวอย่าง API response
[
{ user: 'editor01', action: 'Updated RFA (LCBP3-RFA-001)', time: '2025-11-04T09:30Z' }
]
## **🛡️ ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
ส่วนนี้สรุปข้อกำหนด Non-Functional จาก requirements.md เพื่อให้ทีมพัฒนาทราบ
* **Audit Log [cite: 6.1]:** ทุกการกระทำที่สำคัญ (C/U/D) ต้องถูกบันทึกใน audit_logs
* **Performance [cite: 6.4]:** ต้องใช้ Caching สำหรับข้อมูลที่เรียกบ่อย และใช้ Pagination
* **Security [cite: 6.5]:** ต้องมี Rate Limiting และจัดการ Secret ผ่าน docker-compose.yml (ไม่ใช่ .env)
* **(ใหม่) Backup & Recovery [cite: 6.6]:** ต้องมีแผนสำรองข้อมูลทั้ง Database (MariaDB) และ File Storage (/share/dms-data) อย่างน้อยวันละ 1 ครั้ง
* **(ใหม่) Notification Strategy [cite: 6.7]:** ระบบแจ้งเตือน (Email/Line) ต้องถูก Trigger เมื่อมีเอกสารใหม่ส่งถึง, มีการมอบหมายงานใหม่ (Circulation), หรือ (ทางเลือก) เมื่องานเสร็จ/ใกล้ถึงกำหนด
## **✅ มาตรฐานที่นำไปใช้แล้ว (จาก SQL v1.1.0) (Implemented Standards (from SQL v1.1.0))**
ส่วนนี้ยืนยันว่าแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เป็นส่วนหนึ่งของการออกแบบฐานข้อมูลอยู่แล้ว และควรถูกนำไปใช้ประโยชน์ ไม่ใช่สร้างขึ้นใหม่
***Soft Delete:** นำไปใช้แล้วผ่านคอลัมน์ deleted_at ในตารางสำคัญ (เช่น correspondences, rfas, project_parties) ตรรกะการดึงข้อมูลต้องกรอง deleted_at IS NULL
***Database Indexes:** สคีมาได้มีการทำ index ไว้อย่างหนักหน่วงบน foreign keys และคอลัมน์ที่ใช้ค้นหาบ่อย (เช่น idx_rr_rfa, idx_cor_project, idx_cr_is_current) เพื่อประสิทธิภาพ
***โครงสร้าง RBAC:** มีระบบ users, roles, permissions, user_roles, และ user_project_roles ที่ครอบคลุมอยู่แล้ว
***Data Seeding:** ข้อมูล Master (roles, permissions, organization_roles, initial users, project parties) ถูกรวมอยู่ในสคริปต์สคีมาแล้ว
## **🧩 การปรับปรุงที่แนะนำ (สำหรับอนาคต) (Recommended Enhancements (Future))**
* ✅ สร้าง Background job (โดยใช้ **n8n** เพื่อเชื่อมต่อกับ **Line** [cite: 2.7] และ/หรือใช้สำหรับการแจ้งเตือน RFA ที่ใกล้ถึงกำหนด due_date [cite: 6.7])
* ✅ เพิ่ม job ล้างข้อมูลเป็นระยะสำหรับ attachments ที่ไม่ถูกเชื่อมโยงกับ Entity ใดๆ เลย (ไฟล์กำพร้า)

View File

@@ -0,0 +1,79 @@
# **🧪 แผนการทดสอบระบบ (Test Plan) \- DMS v1.3.0 Backend**
เอกสารนี้สรุปแผนการทดสอบ, ขั้นตอน, และเครื่องมือที่ใช้ในการตรวจสอบความถูกต้องของ NestJS Backend API (DMS v1.3.0) ก่อนการ Deploy ใช้งานจริงร่วมกับ Frontend
## **1\. วัตถุประสงค์ (Objectives)**
* เพื่อให้มั่นใจว่า API ทั้งหมดทำงานตรงตาม requirements.md
* เพื่อตรวจสอบว่าระบบรักษาความปลอดภัย (RBAC และ Security) ทำงานได้ถูกต้อง 100%
* เพื่อค้นหาและแก้ไขข้อบกพร่อง (Bugs) ที่เกี่ยวข้องกับการเชื่อมต่อฐานข้อมูลและ Business Logic
* เพื่อยืนยันว่าระบบทนทานต่อการใช้งานพร้อมกัน (Concurrency) และมีประสิทธิภาพ (Performance)
* เพื่อส่งมอบ API ที่เสถียรและมีเอกสาร (Swagger) ครบถ้วนให้แก่ทีม Frontend
## **2\. ขอบเขตการทดสอบ (Scope)**
### **สิ่งที่อยู่ในขอบเขต (In-Scope)**
* **API Functionality:** การทดสอบ Endpoints ทั้งหมด (CRUD, Search, Upload)
* **Business Logic:** ตรรกะการสร้างเอกสาร (RFA, Correspondence), การสร้างเลขที่, และ Workflow
* **Security:** การยืนยันตัวตน (JWT), การจัดการสิทธิ์ (RBAC Guard), การป้องกัน (Helmet, Rate Limiter)
* **Data Integrity:** การตรวจสอบความถูกต้องของข้อมูลที่บันทึกลง MariaDB
* **Performance:** การทดสอบ Concurrency (การสร้างเลขที่) และการตอบสนองของ API
* **Error Handling:** การตรวจสอบว่า Global Exception Filter ทำงานได้ถูกต้อง
### **สิ่งที่อยู่นอกขอบเขต (Out-of-Scope)**
* การทดสอบ Next.js Frontend (UI/UX)
* การทดสอบตรรกะภายในของ N8N (เราทดสอบแค่ว่า Backend *ยิง* Webhook ไปหรือไม่)
* การทดสอบ Penetration Test ขั้นสูง (เน้น Functional & Security พื้นฐาน)
## **3\. สภาพแวดล้อมและเครื่องมือ (Environment & Tools)**
| ประเภท | เครื่องมือ/สภาพแวดล้อม | วัตถุประสงค์ |
| :---- | :---- | :---- |
| **สภาพแวดล้อม** | **Staging (QNAP)** | สภาพแวดล้อมจำลอง (บน Docker) ที่เหมือน Production ที่สุด ประกอบด้วย backend, mariadb, elasticsearch, n8n (Mock Receiver) |
| **ฐานข้อมูล** | **DBeaver** | ใช้สำหรับเชื่อมต่อ MariaDB (Staging) เพื่อตรวจสอบผลลัพธ์ (Data Verification) |
| **API (Manual)** | **Postman / Insomnia** | ใช้สำหรับการทดสอบ API ด้วยตนเอง, สำรวจ Endpoints, และสร้าง Test Case |
| **API (Automation)** | **Postman (Newman) / Supertest** | (E2E) ใช้รัน Test Case อัตโนมัติเพื่อตรวจสอบ API Contract |
| **Unit/Integration** | **Jest / @nestjs/testing** | (Developer) ใช้สำหรับทดสอบ Logic ภายใน Service และ Guard (ตามตัวอย่าง spec.ts ที่สร้างไว้) |
| **Concurrency** | **k6 (แนะนำ) / Node.js Script** | ใช้สำหรับทดสอบ Stress Test และ Concurrency (โดยเฉพาะ TC-CON-01) |
| **Webhook** | **N8N (Webhook Node)** | ใช้ N8N จริง (Staging) ตั้งค่า Webhook Node เพื่อรับ Event จาก NotificationService |
## **4\. รายละเอียดสถานการณ์ทดสอบ (Detailed Test Scenarios)**
นี่คือ Test Case ที่สำคัญที่สุด โดยแบ่งตามความเสี่ยงและ Function
### **T1: การรักษาความปลอดภัย (Security & RBAC) \- (ความเสี่ยงสูงมาก)**
| ID | สถานการณ์ | ขั้นตอนการทดสอบ (Steps) | ผลลัพธ์ที่คาดหวัง (Expected) | เครื่องมือ |
| :---- | :---- | :---- | :---- | :---- |
| **TC-SEC-01** | **(RBAC) ห้าม Viewer สร้างเอกสาร** | 1\. (Postman) เรียก POST /api/v1/auth/login ด้วย User "Viewer" 2\. คัดลอก access\_token 3\. เรียก POST /api/v1/correspondence (ใน Auth Header) พร้อม Body ที่ถูกต้อง | 403 Forbidden (RBACGuard ทำงาน) | Postman |
| **TC-SEC-02** | **(RBAC) Editor ข้าม Project** | 1\. (Postman) Login User "Editor" ที่มีสิทธิ์เฉพาะ Project A 2\. (DBeaver) หา ID เอกสาร (เช่น corr\_id: 99\) ที่อยู่ใน Project B 3\. (Postman) เรียก GET /api/v1/correspondence/99 ด้วย Token ของ Editor | 403 Forbidden หรือ 404 Not Found | Postman, DBeaver |
| **TC-SEC-03** | **(RBAC) Super Admin** | 1\. (Postman) Login User "Super Admin" 2\. เรียก Endpoint ที่จำกัดสิทธิ์สูง (เช่น POST /api/v1/admin/users) | 201 Created (Super Admin ต้องผ่านทุกการตรวจสอบ) | Postman |
| **TC-SEC-04** | **(Rate Limit) Brute-force** | 1\. (Postman Runner หรือ k6) ตั้งค่าให้เรียก POST /api/v1/auth/login (ด้วยรหัสผ่านผิด) 110 ครั้ง (Limit คือ 100\) 2\. สังเกตผลลัพธ์ | Request ที่ 1-100: 401 Unauthorized Request ที่ 101+: 429 Too Many Requests | k6, Postman |
| **TC-SEC-05** | **(Security) Helmet** | 1\. (Postman) เรียก Endpoint ใดก็ได้ (เช่น GET /api/v1/health) 2\. ตรวจสอบ Response Headers | ต้องมี Headers เช่น X-Content-Type-Options: nosniff, Strict-Transport-Security, X-Frame-Options: SAMEORIGIN | Postman |
### **T2: ตรรกะหลัก (Core Logic & Concurrency) \- (ความเสี่ยงสูง)**
| ID | สถานการณ์ | ขั้นตอนการทดสอบ (Steps) | ผลลัพธ์ที่คาดหวัง (Expected) | เครื่องมือ |
| :---- | :---- | :---- | :---- | :---- |
| **TC-CON-01** | **(Concurrency) สร้างเลขที่เอกสาร** | 1\. (k6/Script) สร้าง Script ที่เรียก POST /api/v1/correspondence (สร้างเอกสารใหม่) 50 ครั้ง *พร้อมกัน* (Simultaneously) 2\. (Postman) Login Admin 3\. (DBeaver) ตรวจสอบตาราง correspondences และ document\_number\_counters | 1\. Script ทั้ง 50 ครั้งสำเร็จ (201 Created) 2\. (DBeaver) document\_number\_counters มี last\_number: 50 3\. correspondences มีเอกสาร 50 ฉบับ โดย *ไม่มี* correspondence\_number ซ้ำกันเลย | k6, DBeaver |
| **TC-FUNC-01** | **(Data) สร้าง RFA (Complex)** | 1\. (Postman) Login User (เช่น "Editor") 2\. เรียก POST /api/v1/rfa พร้อม DTO ที่ซับซ้อน (มี rfa\_type\_id, title, attachments, shop\_drawings) | 1\. 201 Created 2\. (DBeaver) ตรวจสอบว่ามีข้อมูลถูกสร้างขึ้นใน 3 ตารางหลัก: \- correspondences (ตารางแม่) \- rfas (ตารางแม่ RFA) \- rfa\_revisions (ตารางลูก Revision 0\) | Postman, DBeaver |
### **T3: การทำงานของโมดูล (Module Functionality)**
| ID | สถานการณ์ | ขั้นตอนการทดสอบ (Steps) | ผลลัพธ์ที่คาดหวัง (Expected) | เครื่องมือ |
| :---- | :---- | :---- | :---- | :---- |
| **TC-FUNC-02** | **(File) อัปโหลดไฟล์** | 1\. (Postman) Login User 2\. เรียก POST /api/v1/files/upload (ประเภท form-data, key file) 3\. (DBeaver) ตรวจสอบตาราง attachments | 1\. 201 Created คืนค่าข้อมูล Attachment (เช่น ID, stored\_filename) 2\. (DBeaver) มีแถวใหม่ในตาราง attachments 3\. (ถ้าทำได้) ตรวจสอบ QNAP /share/dms-data/... ว่ามีไฟล์จริง | Postman, DBeaver |
| **TC-FUNC-03** | **(File) ดาวน์โหลด (ผ่าน Auth)** | 1\. (Postman) ทำ TC-FUNC-02 เพื่ออัปโหลดไฟล์ (สมมติได้ attachment\_id: 123\) 2\. เรียก GET /api/v1/files/download/123 (ต้องใส่ Auth Header) | 200 OK และได้ข้อมูลไฟล์กลับมา | Postman |
| **TC-FUNC-04** | **(Search) Elasticsearch** | 1\. (Postman) สร้างเอกสารใหม่ POST /api/v1/correspondence (จดจำ Title ไว้) 2\. (รอ 10 วินาที ให้ Elastic Index) 3\. เรียก GET /api/v1/search?query=\[Title ที่จดไว้\] | 200 OK และผลลัพธ์การค้นหาต้องมีเอกสารที่เพิ่งสร้าง | Postman |
| **TC-FUNC-05** | **(Notification) N8N Webhook** | 1\. (N8N) สร้าง Workflow ใหม่, ใช้ "Webhook" Node (เปิด Test Mode) 2\. (Postman) Login User 3\. เรียก POST /api/v1/circulation (สร้างใบเวียนใหม่) | 1\. (Postman) 201 Created 2\. (N8N) Webhook Node ได้รับข้อมูล Payload ({ event: 'NEW\_CIRCULATION\_TASK', ... }) | Postman, N8N |
| **TC-FUNC-06** | **(Audit) Audit Log** | 1\. (Postman) Login Admin 2\. เรียก DELETE /api/v1/admin/roles/10 (ลบ Role สมมติ) 3\. (DBeaver) ตรวจสอบ audit\_logs | 1\. (DBeaver) มีแถวใหม่ใน audit\_logs 2\. ข้อมูลถูกต้อง: action: 'role.delete', entity\_type: 'role', entity\_id: '10', user\_id: \[Admin ID\] | Postman, DBeaver |
### **T4: การ Deploy (NFR)**
| ID | สถานการณ์ | ขั้นตอนการทดสอบ (Steps) | ผลลัพธ์ที่คาดหวัง (Expected) | เครื่องมือ |
| :---- | :---- | :---- | :---- | :---- |
| **TC-NFR-01** | **(Health) Health Check** | 1\. (Browser/Postman) เรียก GET /api/v1/health (จาก Staging URL) | 200 OK และ JSON Response แสดง status: "ok" และสถานะ DB | Postman, Browser |
| **TC-NFR-02** | **(Error) Global Filter** | 1\. (Postman) เรียก Endpoint ที่ไม่มีอยู่จริง (เช่น GET /api/v1/invalid\_path) | 404 Not Found Response Body ต้องมีโครงสร้าง JSON ที่กำหนดไว้ (เช่น { "statusCode": 404, "message": "Cannot GET /api/v1/invalid\_path", ... }) | Postman |

View File

@@ -0,0 +1,117 @@
# แผนการพัฒนา Backend NestJS สำหรับ DMS v1.3.0
## การเตรียมความพร้อมและการติดตั้ง (Prerequisites & Setup)
- [ ] สร้าง NestJS Project ใหม่ (backend/src)
- [✅] ติดตั้ง Dependencies หลักๆ ตาม Technology Stack
- [✅] `@nestjs/core`, `@nestjs/common`
- [✅] `@nestjs/typeorm`, `typeorm`
- [✅] `@nestjs/jwt`, `@nestjs/passport`, `passport-jwt`
- [✅] `casl`
- [✅] `class-validator`, `class-transformer`
- [✅] `@nestjs/swagger`
- [✅] `winston`, `helmet`, `rate-limiter-flexible`
- [✅] ตั้งค่า `tsconfig.json`, `nest-cli.json` และไฟล์ config อื่นๆ
- [ ] ตั้งค่าการเชื่อมต่อ MariaDB ผ่าน TypeORM
- [ ] **(สำคัญ)** กำหนดค่าตัวแปรสภาพแวดล้อม (DATABASE_URL, JWT_SECRET) ผ่าน `docker-compose.yml`
---
## Phase 1: การสร้างรากฐาน (Foundation) - สัปดาห์ที่ 1-2
- [ ] พัฒนา Core Auth Module (`AuthModule`)
- [✅] สร้าง Entities: `Users`, `Roles`, `Permissions`
- [✅] สร้าง `AuthService` สำหรับ Login, Register, JWT Generation
- [✅] สร้าง `JwtStrategy` สำหรับ Passport
- [✅] สร้าง `RBACGuard` โดยใช้ CASL
- [✅] สร้าง API Endpoints: `/auth/login`, `/auth/me`
- [✅] พัฒนา Common Module (`@app/common`)
- [✅] สร้าง `FileStorageService` สำหรับจัดการไฟล์ (อัปโหลด/ดาวน์โหลด)
- [✅] สร้าง `AuditLogInterceptor` สำหรับบันทึกการกระทำโดยอัตโนมัติ
- [✅] สร้าง Global Exception Filter
- [✅] สร้าง DTOs และ Interfaces พื้นฐาน
---
## Phase 2: พัฒนาเอนทิตีหลัก (Core Entities) - สัปดาห์ที่ 3-4
- [✅] พัฒนา Project Module (`ProjectModule`)
- [✅] สร้าง Entities: `Project`, `Organization`, `Contract`, `ProjectParty`
- [✅] สร้าง Services สำหรับ CRUD และจัดการความสัมพันธ์
- [✅] สร้าง Controller พร้อม Swagger Decorators
- [ ] พัฒนา Correspondence Module (`CorrespondenceModule`)
- [ ] สร้าง Entities: `Correspondence`, `CorrespondenceRevision`, `CorrespondenceAttachment`
- [ ] สร้าง Services สำหรับจัดการเอกสาร การสร้าง Revision
- [ ] เชื่อมโยงกับ `FileStorageService` และ `DocumentNumberingService`
- [ ] พัฒนา Attachment Management
- [ ] พัฒนา API อัปโหลดไฟล์ (`POST /correspondences/:id/attachments`)
- [ ] พัฒนา API ดาวน์โหลดไฟล์ (`GET /attachments/:id/download`)
- [ ] ใช้ Junction Tables (`correspondence_attachments`) ในการเชื่อมโยง
---
## Phase 3: พัฒนาเวิร์กโฟลว์เฉพาะทาง (Specialized Workflows) - สัปดาห์ที่ 5-7
- [ ] พัฒนา RFA Module (`RfaModule`)
- [ ] สร้าง Entities: `Rfa`, `RfaRevision`, `RfaWorkflow`, `RfaItem`
- [ ] สร้าง Service สำหรับจัดการ Workflow การอนุมัติ (ส่ง -> อนุมัติ/ปฏิเสธ -> ส่งกลับ)
- [ ] จัดการ State Transitions ตาม `rfa_status_transitions`
- [ ] พัฒนา Drawing Module (`DrawingModule`)
- [ ] สร้าง Entities: `ShopDrawing`, `ShopDrawingRevision`, `ContractDrawing`
- [ ] สร้าง Services สำหรับจัดการแบบแปลนและการอ้างอิงระหว่าง Shop และ Contract Drawing
- [ ] พัฒนา Circulation Module (`CirculationModule`)
- [ ] สร้าง Entities: `Circulation`, `CirculationAssignee`
- [ ] สร้าง Service สำหรับการสร้างใบเวียน มอบหมายงาน และติดตามสถานะ
- [ ] พัฒนา Transmittal Module (`TransmittalModule`)
- [ ] สร้าง Entities: `Transmittal`, `TransmittalItem`
- [ ] สร้าง Service สำหรับการสร้างเอกสารนำส่ง
---
## Phase 4: คุณสมบัติขั้นสูงและการเชื่อมโยง (Advanced Features) - สัปดาห์ที่ 8-9
- [ ] พัฒนา Document Numbering Module (`DocumentNumberingModule`)
- [ ] สร้าง `DocumentNumberingService` (Internal Module)
- [ ] Implement การเรียกใช้ Stored Procedure `sp_get_next_document_number`
- [ ] ให้บริการแก่ `CorrespondenceModule` และโมดูลอื่นๆ
- [ ] พัฒนา Search Module (`SearchModule`)
- [ ] ตั้งค่า Elasticsearch
- [ ] สร้าง Service สำหรับ Index ข้อมูลจาก Views (`v_current_correspondences`, `v_current_rfas`)
- [ ] สร้าง API ค้นหาขั้นสูง (`/search`)
- [ ] พัฒนา Notification Service
- [ ] สร้าง `NotificationService` ใน `CommonModule`
- [ ] Implement การส่ง Email ผ่าน `nodemailer`
- [ ] สร้าง Trigger สำหรับส่งการแจ้งเตือน (เอกสารใหม่, เปลี่ยนสถานะ, ใกล้ถึง Deadline)
- [ ] เตรียมพร้อมสำหรับการเชื่อมต่อกับ N8N สำหรับ Line Notification
---
## Phase 5: การทดสอบและเพิ่มประสิทธิภาพ (Testing & Optimization) - สัปดาห์ที่ 10
- [ ] ดำเนินการทดสอบ (Testing)
- [ ] เขียน Unit Tests สำหรับ Business Logic ใน Services และ Guards
- [ ] เขียน Integration Tests สำหรับ Controller -> Service -> Repository (โดยใช้ Test Database)
- [ ] เขียน E2E Tests สำหรับตรวจสอบ API Contract ว่าตรงตาม Swagger
- [ ] ปรับปรุงประสิทธิภาพ (Performance)
- [ ] ใช้ Caching (`@nestjs/cache-manager`) สำหรับข้อมูลที่ถูกเรียกบ่อย (Roles, Permissions)
- [ ] ตรวจสอบ Query และใช้ Database Indexes ให้เป็นประโยชน์ (มีอยู่แล้วใน SQL)
- [ ] ใช้ Pagination สำหรับข้อมูลจำนวนมาก
- [ ] เพิ่มความปลอดภัย (Security)
- [ ] ติดตั้ง `helmet` สำหรับตั้งค่า HTTP Headers
- [ ] ติดตั้ง `rate-limiter-flexible` สำหรับป้องกัน Brute-force
- [ ] จัดเตรียมเอกสาร (Documentation)
- [ ] ตรวจสอบความสมบูรณ์ของ Swagger Documentation
- [ ] เพิ่ม JSDoc Comments สำหรับ Methods และ Classes ที่สำคัญ
---
## การ Deploy บน QNAP Container Station
- [ ] เตรียมการ Deploy บน QNAP Container Station
- [ ] สร้าง `Dockerfile` สำหรับ NestJS App
- [ ] สร้างไฟล์ `docker-compose.yml` สำหรับ `backend` service
- [ ] กำหนด `environment` สำหรับ `DATABASE_HOST`, `DATABASE_USER`, `DATABASE_PASSWORD`, `JWT_SECRET`
- [ ] เชื่อมต่อกับ `lcbp3` network
- [ ] ทดสอบ Build และ Run บน Container Station UI
- [ ] ตั้งค่า Health Check endpoint (`/health`) โดยใช้ `@nestjs/terminus`

View File

@@ -0,0 +1,169 @@
# แผนการพัฒนา Frontend Next.js สำหรับ DMS v1.3.0
## การเตรียมความพร้อมและการติดตั้ง (Prerequisites & Setup)
- [ ] สร้าง Next.js Project ใหม่ (App Router)
```bash
npx create-next-app@latest frontend --typescript --tailwind --eslint --app
```
- [ ] ติดตั้ง Dependencies หลักๆ ตามเอกสาร FullStackJS
- [ ] UI Library: `@shadcn/ui` และ dependencies ที่เกี่ยวข้อง
- [ ] State Management: `zustand`
- [ ] Server State: `@tanstack/react-query`
- [ ] Form Handling: `react-hook-form`, `zod`, `@hookform/resolvers`
- [ ] File Upload: `react-dropzone`
- [ ] Icons: `lucide-react`
- [ ] Testing: `vitest`, `@testing-library/react`, `@testing-library/jest-dom`, `@playwright/test`
- [ ] ตั้งค่าโครงสร้างโปรเจกต์
```
src/
├── app/ # App Router
│ ├── (dashboard)/ # Route Groups
│ ├── api/ # API Routes (ถ้าจำเป็น)
│ ├── globals.css
│ ├── layout.tsx
│ └── page.tsx
├── components/ # Reusable UI Components
│ ├── ui/ # shadcn/ui components
│ ├── forms/ # Form Components
│ └── features/ # Feature-specific Components
├── lib/ # Utility functions
│ ├── api.ts # Axios/Fetch wrapper
│ ├── auth.ts # Auth helpers
│ └── utils.ts
├── hooks/ # Custom React Hooks
├── store/ # Zustand stores
└── types/ # TypeScript type definitions
```
- [ ] ตั้งค่า Tailwind CSS และ shadcn/ui
- [ ] ตั้งค่า React Query ใน `app/providers.tsx` และครอบใน `layout.tsx`
- [ ] ตั้งค่า Zustand store สำหรับ Global State (เช่น User, Auth)
---
## Phase 1: การสร้างรากฐานและการยืนยันตัวตน (Foundation & Authentication) - สัปดาห์ที่ 1-2
- [ ] พัฒนา Layout หลัก (App Shell - Req 5.1)
- [ ] สร้าง `Navbar` Component (ชื่อระบบ, เมนูผู้ใช้, ปุ่ม Logout)
- [ ] สร้าง `Sidebar` Component (เมนูการนำทางหลัก)
- [ ] สร้าง `MainContent` Component สำหรับแสดงผลหน้าต่างๆ
- [ ] ประกอบ Component ทั้งหมดใน `layout.tsx`
- [ ] พัฒนาระบบ Authentication
- [ ] สร้าง `LoginPage` Component (ใช้ `react-hook-form` + `zod`)
- [ ] สร้าง Auth Store ด้วย Zustand (เก็บ User, Token, สถานะการล็อกอิน)
- [ ] สร้าง `useAuth` Hook สำหรับเข้าถึง Auth State
- [ ] สร้าง API functions สำหรับ Login, Logout, Get Profile
- [ ] สร้าง Middleware สำหรับป้องกัน Route ที่ต้องการ Login
- [ ] สร้าง `ProfilePage` (Req 5.5)
- [ ] แสดงข้อมูลผู้ใช้
- [ ] ฟอร์มแก้ไขข้อมูลส่วนตัว
- [ ] ฟอร์มเปลี่ยนรหัสผ่าน
---
## Phase 2: พัฒนาคอมโพเนนต์หลักและหน้า Dashboard (Core Components & Dashboard) - สัปดาห์ที่ 3-4
- [ ] พัฒนา Reusable Components พื้นฐาน
- [ ] `DataTable` Component (รองรับ Server-side Pagination, Sorting, Filtering)
- [ ] `FormSelect`, `FormInput`, `FormTextarea` (ครอบด้วย `react-hook-form`)
- [ ] `LoadingSpinner`, `ErrorAlert` Components
- [ ] `ConfirmDialog` Component
- [ ] พัฒนา `FileUpload` Component (Req 5.7)
- [ ] ใช้ `react-dropzone` สำหรับ Drag-and-Drop
- [ ] รองรับการอัปโหลดหลายไฟล์
- [ ] มี Checkbox ให้เลือก "เอกสารหลัก" (Main Document)
- [ ] แสดงรายการไฟล์ที่เลือกพร้อมตัวเลือกลบ
- [ ] พัฒนา `AttachmentList` Component
- [ ] แสดงรายการไฟล์แนบที่เชื่อมโยงกับเอกสาร
- [ ] แสดง Badge "เอกสารหลัก"
- [ ] ปุ่มดาวน์โหลดแต่ละไฟล์
- [ ] พัฒนา `DashboardPage` (Req 5.3)
- [ ] สร้าง `KpiCard` Component สำหรับแสดงข้อมูลสรุป
- [ ] สร้าง `MyTasksTable` Component
- [ ] ดึงข้อมูลจาก API endpoint ที่เชื่อมต่อกับ View `v_user_tasks`
- [ ] แสดงคอลัมน์: ชื่อเอกสาร, ประเภท, วันครบกำหนด, สถานะ
- [ ] ปุ่ม "ดำเนินการ" ที่นำไปยังหน้าที่เกี่ยวข้อง
---
## Phase 3: พัฒนาโมดูลเอกสารโต้ตอบและเวิร์กโฟลว์ (Correspondence & Workflow Modules) - สัปดาห์ที่ 5-7
- [ ] พัฒนา `CorrespondenceModule` (Req 3.2)
- [ ] หน้ารายการเอกสาร (`/correspondences`)
- [ ] `DataTable` พร้อม Filter: โครงการ, ประเภทเอกสาร, ช่วงวันที่, ผู้ส่ง/ผู้รับ
- [ ] ปุ่ม "สร้างใหม่", "ดู", "แก้ไข" (ตามสิทธิ์)
- [ ] หน้าสร้าง/แก้ไขเอกสาร (`/correspondences/new`, `/correspondences/[id]/edit`)
- [ ] ฟอร์มสร้างเอกสาร (ใช้ `react-hook-form`)
- [ ] Dropdowns ที่เชื่อมโยงกัน (Project -> Contract)
- [ ] การเลือกผู้รับ (To/CC) หลายองค์กร
- [ ] การใส่ Tag
- [ ] การเชื่อมโยงเอกสารอ้างอิง
- [ ] ใช้ `FileUpload` และ `AttachmentList` Components
- [ ] หน้ารายละเอียดเอกสาร (`/correspondences/[id]`)
- [ ] แสดงข้อมูลทั้งหมดของเอกสาร
- [ ] แสดงประวัติการแก้ไข (Revisions)
- [ ] แสดงสถานะการส่งต่อ (Routings)
- [ ] พัฒนา `RfaModule` (Req 3.5, 5.6)
- [ ] ฟังก์ชันพื้นฐานคล้ายกับ CorrespondenceModule
- [ ] พัฒนา `WorkflowVisualization` Component **(สำคัญ)**
- [ ] ดึงข้อมูลจาก `rfa_workflows` table
- [ ] แสดงขั้นตอนทั้งหมดเป็นลำดับ (เช่น การ์ดหรือไลน์)
- [ ] ขั้นตอนปัจจุบัน (Active) สามารถดำเนินการได้
- [ ] ขั้นตอนอื่นๆ แสดงเป็น Disabled
- [ ] มีปุ่มสำหรับ Action: "อนุมัติ", "ปฏิเสธ", "ขอแก้ไข"
- [ ] สำหรับ Admin: ปุ่ม "บังคับไปขั้นตอนถัดไป", "ย้อนกลับ"
- [ ] แสดงความคิดเห็นในแต่ละขั้นตอน
---
## Phase 4: พัฒนาโมดูลแบบแปลนและคุณสมบัติขั้นสูง (Drawings & Advanced Features) - สัปดาห์ที่ 8-9
- [ ] พัฒนา `DrawingModule` (Req 3.3, 3.4)
- [ ] แยกระหว่าง `ContractDrawingPage` และ `ShopDrawingPage`
- [ ] ฟอร์มสร้าง/แก้ไขแบบแปลน
- [ ] การจัดการ Revision (เช่น การสร้าง Revision ใหม่จาก Revision ปัจจุบัน)
- [ ] การเชื่อมโยง Shop Drawing Revision กับ Contract Drawing
- [ ] พัฒนา `CirculationModule` (Req 3.7)
- [ ] หน้ารายการใบเวียนภายใน
- [ ] ฟอร์มสร้างใบเวียน
- [ ] การมอบหมายงานให้ผู้รับผิดชอบ (Main, Action, Info)
- [ ] หน้ารายละเอียดสำหรับผู้รับผิดชอบกระทำ (แสดงความคิดเห็น, ปุ่มปิดงาน)
- [ ] พัฒนา `AdminPanel` (Req 4.5, 4.6)
- [ ] หน้าจัดการผู้ใช้ (Create/Edit/Delete Users ในองค์กร)
- [ ] หน้าจัดการ Roles และ Permissions
- [ ] หน้าจัดการ Master Data (Tags, Document Types, Categories)
- [ ] หน้าจัดการรูปแบบเลขที่เอกสาร (Document Numbering Formats)
- [ ] พัฒนา `AdvancedSearchPage` (Req 6.2)
- [ ] ฟอร์มค้นหาขั้นสูงพร้อมฟิลด์ต่างๆ
- [ ] ส่งคำขอไปยัง Search API (Elasticsearch)
- [ ] แสดงผลลัพธ์ใน `DataTable`
---
## Phase 5: การทดสอบ ปรับปรุงประสิทธิภาพ และเตรียม Deploy (Testing, Optimization & Deployment) - สัปดาห์ที่ 10
- [ ] ดำเนินการทดสอบ (Testing)
- [ ] **Unit/Integration Tests:**
- [ ] เขียนทดสอบสำหรับ `FileUpload` Component (Vitest + RTL)
- [ ] เขียนทดสอบสำหรับ `DataTable` Component
- [ ] เขียนทดสอบสำหรับ Custom Hooks (เช่น `useAuth`)
- [ ] **E2E Tests:**
- [ ] เขียนทดสอบ User Flow: Login -> สร้าง RFA -> อนุมัติ (Playwright)
- [ ] เขียนทดสอบ User Flow: สร้างใบเวียน -> มอบหมายงาน -> ตอบกลับ
- [ ] ปรับปรุงประสิทธิภาพ (Performance)
- [ ] ใช้ `next/dynamic` สำหรับ lazy loading ของ Components ที่ใหญ่
- [ ] ตรวจสอบการใช้ React Query เพื่อให้แน่ใจว่ามีการ Caching และ Re-fetching ที่เหมาะสม
- [ ] ใช้ Image Optimization ของ Next.js
- [ ] การเตรียม Deploy
- [ ] สร้าง `Dockerfile` สำหรับ Frontend (Multi-stage build)
- [ ] สร้างไฟล์ `docker-compose.yml` สำหรับ `frontend` service
- [ ] กำหนด `build` จาก `Dockerfile`
- [ ] กำหนด `environment` สำหรับ `NEXT_PUBLIC_API_URL`
- [ ] เชื่อมต่อกับ `lcbp3` network
- [ ] ทดสอบ Build และ Run บน Container Station UI
- [ ] ตั้งค่า Nginx Proxy Manager ให้ชี้ `lcbp3.np-dms.work` มายัง Frontend Container

View File

@@ -0,0 +1,210 @@
# **📝 Documents Management Sytem Version 1.2.1: Application Requirements Specification**
## **📌 1. วัตถุประสงค์**
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System)ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
* มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
* ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
* เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
## **🛠️ 2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)**
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
* 2.1. Infrastructure & Environment:
* Server: QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
* Containerization: Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
* Development Environment: VS Code on Windows 11
* Domain: np-dms.work, www.np-dms.work
* ip: 159.192.126.103
* Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
* Data Storage: /share/dms-data บน QNAP
* ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
* 2.2. Code Hosting:
* Application name: git
* Service: Gitea (Self-hosted on QNAP)
* Service name: gitea
* Domain: git.np-dms.work
* หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
* 2.3. Backend / Data Platform:
* Application name: lcbp3-backend
* Service: NestJS
* Service name: backend
* Domain: backend.np-dms.work
* Framework: NestJS (Node.js, TypeScript, ESM)
* หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
* 2.4. Database:
* Application name: lcbp3-db
* Service: mariadb:10.11
* Service name: mariadb
* Domain: db.np-dms.work
* หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
* Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
* 2.5. Database management:
* Application name: lcbp3-db
* Service: phpmyadmin:5-apache
* Service name: pma
* Domain: pma.np-dms.work
* หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
* 2.6. Frontend:
* Application name: lcbp3-frontend
* Service: next.js
* Service name: frontend
* Domain: lcbp3.np-dms.work
* Framework: Next.js (App Router, React, TypeScript, ESM)
* Styling: Tailwind CSS + PostCSS
* Component Library: shadcn/ui
* หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
* 2.7. Workflow automation:
* Application name: lcbp3-n8n
* Service: n8nio/n8n:latest
* Service name: n8n
* Domain: n8n.np-dms.work
* หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
* 2.8. Reverse Proxy:
* Application name: lcbp3-npm
* Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
* Service name: npm
* Domain: npm.np-dms.work
* หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
* **2.9. การจัดการตรรกะทางธุรกิจ (Business Logic Implementation):**
* 2.9.1. ตรรกะทางธุรกิจที่ซับซ้อนทั้งหมด (เช่น การเปลี่ยนสถานะ Workflow [cite: 3.5.4, 3.6.5], การบังคับใช้สิทธิ์ [cite: 4.4], การตรวจสอบ Deadline [cite: 3.2.5]) **จะถูกจัดการในฝั่ง Backend (NestJS)** [cite: 2.3] เพื่อให้สามารถบำรุงรักษาและทดสอบได้ง่าย (Testability)
* 2.9.2. **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก
* 2.9.3. **ข้อยกเว้น:** ตรรกะเดียวที่จะอยู่ในฐานข้อมูลคือ **Stored Procedure** สำหรับการสร้างเลขที่เอกสาร (Document Numbering) [cite: 3.10] เพื่อป้องกันการซ้ำซ้อนของข้อมูล (Race Condition)
## **📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)**
* 3.1. การจัดการโครงสร้างโครงการและองค์กร
* 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
* 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
* 3.1.3. องค์กร (Organizations):
* มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
* Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
* 3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)
* 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects), รองรับ To (ผู้รับหลัก) และ CC (ผู้รับสำเนา) หลายองค์กร
* 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
* 3.2.3. การสร้างเอกสาร (Correspondence):
* ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
* เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
* 3.2.4. การอ้างอิงและจัดกลุ่ม:
* เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
* สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
* 3.2.5. การจัดการ: มีการจัดการอย่างน้อยดังนี้
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่เป็นผู้รับได้
* มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
* 3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)
* 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
* 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
* 3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)
* 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
* 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
* 3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)
* 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
* 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
* Request for Drawing Approval (RFA_DWG)
* Request for Document Approval (RFA_DOC)
* Request for Method statement Approval (RFA_MES)
* Request for Material Approval (RFA_MAT)
* 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.5.4. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA_DWG):
* เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
* Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
* ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
* 3.6.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
* ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
* 3.6.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
* มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
* 3.6.การจัดการเอกสารนำส่ง (Transmittals)
* 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
* 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
* 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
* 3.7. ใบเวียนเอกสารภายใน (Internal Circulation Sheet)
* 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
* 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
* 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
* 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
* ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
* ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
* ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
* 3.7.5. การติดตามงาน:
* สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
* มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
* สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
* 3.8. ประวัติการแก้ไข (Revisions): ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
* 3.9. การจัดเก็บ: (ปรับปรุงตามสถาปัตยกรรมใหม่)
* เอกสารและไฟล์แนบทั้งหมดจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) [cite: 2.1]
* ข้อมูล Metadata ของไฟล์ (เช่น ชื่อไฟล์, ขนาด, path) จะถูกเก็บในตาราง attachments (ตารางกลาง)
* ไฟล์จะถูกเชื่อมโยงกับเอกสารประเภทต่างๆ ผ่านตารางเชื่อม (Junction tables) เช่น correspondence_attachments, circulation_attachments, shop_drawing_revision_attachments ,และ contracy_drawing_attachments
* สถาปัตยกรรมแบบรวมศูนย์นี้ *แทนที่* แนวคิดเดิมที่จะแยกโฟลเดอร์ตามประเภทเอกสาร เพื่อรองรับการขยายระบบที่ดีกว่า
* 3.10. การจัดการเลขที่เอกสาร (Document Numbering):
* 3.10.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (เช่น correspondence_number) ได้โดยอัตโนมัติ
* 3.10.2. การนับเลข Running Number (SEQ) จะต้องนับแยกตาม Key ดังนี้: **โครงการ (Project)**, **องค์กรผู้ส่ง (Originator Organization)**, **ประเภทเอกสาร (Document Type)** และ **ปีปัจจุบัน (Year)**
* 3.10.3. ผู้ดูแลระบบ (Admin) ต้องสามารถกำหนด "รูปแบบ" (Format Template) ของเลขที่เอกสารได้ (เช่น {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}) โดยกำหนดแยกตามโครงการและประเภทเอกสาร
## **🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)**
* 4.1. ภาพรวม: ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
* 4.2. ระดับของสิทธิ์:
* Global Roles: สิทธิ์ในภาพรวมของระบบ
* Project-Specific Roles: สิทธิ์ที่ถูกกำหนดให้ผู้ใช้สำหรับโครงการนั้นๆ โดยเฉพาะ (เช่น เป็น Editor ในโครงการ A แต่เป็น Viewer ในโครงการ B)
* 4.3. บทบาท (Roles) พื้นฐาน:
* Superadmin: ไม่มีข้อจำกัดใดๆ สามารถจัดการได้ทุกอย่างข้ามองค์กรณ์
* Admin: มีสิทธิ์เต็มที่ แต่จำกัดเฉพาะในองค์กรที่ตัวเองสังกัด สามารถจัดการผู้ใช้ในองค์กรณ์ได้ สามารถสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลังผ่านหน้า Admin
* Document Control สามารถ เพิ่ม/แก้ไข/ลบ เอกสาร เฉพาะในองค์กรณ์ที่ตัวเองสังกัด ไม่สามารถจัดการผู้ใช้ได้
* Editor: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนดไว้ เฉพาะในองค์กรณ์ที่ตัวเองสังกัด
* Viewer: สามารถดู เอกสาร เฉพาะในองค์กรณ์ที่ตัวเองสังกัด
* 4.4. การบังคับใช้สิทธิ์: สิทธิ์ขององค์กรจะครอบคลุมสิทธิ์ของผู้ใช้ และการเข้าถึงข้อมูลที่เกี่ยวข้องกับโครงการ (เช่น การแก้ไขเอกสาร) จะถูกตรวจสอบเทียบกับสิทธิ์ที่ผู้ใช้มีในโครงการนั้นๆ โดยเฉพาะ
* 4.5. (ใหม่) การจัดการข้อมูลหลัก (Master Data Management):
* ระบบจะต้องมีส่วน "Admin Panel" (สำหรับ Superadmin และ Admin) เพื่อใช้จัดการข้อมูลหลัก (Master Data) ของระบบ
* ข้อมูลหลักที่ต้องจัดการได้เป็นอย่างน้อย:
* ประเภทเอกสาร (เช่น correspondence_types, rfa_types)
* หมวดหมู่แบบ (เช่น shop_drawing_categories)
* Tags ที่ใช้ในระบบ
* สถานะเอกสาร (หากจำเป็นต้องเพิ่มในอนาคต)
* 4.6. (ใหม่) การเริ่มต้นใช้งาน (User & Organization Onboarding):
* การเพิ่มองค์กรณ์ใหม่ (Organizations) เข้าสู่ระบบ จะต้องดำเนินการโดย Superadmin เท่านั้น
* เมื่อ Superadmin สร้างองค์กรณ์ใหม่ จะต้องสามารถกำหนดผู้ใช้ (User) อย่างน้อย 1 คน ให้เป็น "Admin" ประจำองค์กรณ์นั้นๆ
* Admin ประจำองค์กณ์รจึงจะสามารถเพิ่มผู้ใช้ (Editor, Viewer, Document Control) คนอื่นๆ เข้าสู่องค์กรของตนเองได้
## **👥 5\. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)**
* 5.1. Layout หลัก: หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย:
* Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
* Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
* Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
* 5.2. หน้า Landing Page: เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
* 5.3. หน้า Dashboard: เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย:
* การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
* ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
* 5.4. การติดตามสถานะ: องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
* 5.5. การจัดการข้อมูลส่วนตัว (Profile Page): ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
* 5.6. การจัดการเอกสารทางเทคนิค (Technical Documents & Workflow): ผู้ใช้สามารถดู Technical Document ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ admin ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ admin ขึ้นไป
* 5.7. ข้อกำหนด UI/UX การแนบไฟล์ (File Attachment UX):
* ระบบต้องรองรับการอัปโหลดไฟล์หลายไฟล์พร้อมกัน (Multi-file upload) เช่น การลากและวาง (Drag-and-Drop)
* ในหน้าอัปโหลด (เช่น สร้าง RFA หรือ Correspondence) ผู้ใช้ต้องสามารถกำหนดได้ว่าไฟล์ใดเป็น "เอกสารหลัก" (Main Document เช่น PDF) และไฟล์ใดเป็น "เอกสารแนบประกอบ" (Supporting Attachments เช่น .dwg, .docx, .zip)
## **6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
* 6.1. การบันทึกการกระทำ (Audit Log): ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
* 6.2. การค้นหา (Search): ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
* 6.3. การทำรายงาน (Reporting): สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
* 6.4. ประสิทธิภาพ (Performance): มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
* 6.5. ความปลอดภัย (Security):
* มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
* การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
* 6.6. (ใหม่) การสำรองข้อมูลและการกู้คืน (Backup & Recovery):
* ระบบจะต้องมีกลไกการสำรองข้อมูลอัตโนมัติสำหรับฐานข้อมูล MariaDB [cite: 2.4] และไฟล์เอกสารทั้งหมดใน /share/dms-data [cite: 2.1] (เช่น ใช้ HBS 3 ของ QNAP หรือสคริปต์สำรองข้อมูล) อย่างน้อยวันละ 1 ครั้ง
* ต้องมีแผนการกู้คืนระบบ (Disaster Recovery Plan) ในกรณีที่ Server หลัก (QNAP) ใช้งานไม่ได้
* 6.7. (ใหม่) กลยุทธ์การแจ้งเตือน (Notification Strategy):
* ระบบจะส่งการแจ้งเตือน (ผ่าน Email หรือ Line [cite: 2.7]) เมื่อมีการกระทำที่สำคัญ ดังนี้:
1. เมื่อมีเอกสารใหม่ (Correspondence, RFA) ถูกส่งมาถึงองค์กรณ์ของเรา
2. เมื่อมีใบเวียน (Circulation) ใหม่ มอบหมายงานมาที่เรา
3. (ทางเลือก) เมื่อเอกสารที่เราส่งไป ถูกดำเนินการ (เช่น อนุมัติ/ปฏิเสธ)
4. (ทางเลือก) เมื่อใกล้ถึงวันครบกำหนด (Deadline) [cite: 3.2.5, 3.6.6, 3.7.5]

View File

@@ -0,0 +1,900 @@
# **สรุปตารางฐานข้อมูล (Data Dictionary) - LCBP3-DMS (V1.4.0)**
เอกสารนี้สรุปโครงสร้างตาราง, Foreign Keys (FK), และ Constraints ที่สำคัญทั้งหมดในฐานข้อมูล LCBP3-DMS (v1.4.0) เพื่อใช้เป็นเอกสารอ้างอิงสำหรับทีมพัฒนา Backend (NestJS) และ Frontend (Next.js) โดยอิงจาก Requirements และ SQL Script ล่าสุด
## **1. 🏢 Core & Master Data (องค์กร, โครงการ, สัญญา)**
#### **1.1. organization_roles**
ตาราง Master เก็บประเภทบทบาทขององค์กร (เช่น OWNER, CONTRACTOR)
| Column | Type | Key | Description |
| :-------- | :---------- | :----- | :--------------------------------------------------------------- |
| id | INT | **PK** | ID ของตาราง |
| role_name | VARCHAR(20) | UK | ชื่อบทบาท (OWNER, DESIGNER, CONSULTANT, CONTRACTOR, THIRD PARTY) |
- **Unique Keys (UK):** ux_roles_name (role_name)
---
#### **1.2. organizations**
ตาราง Master เก็บข้อมูลองค์กรทั้งหมดที่เกี่ยวข้องในระบบ
| Column | Type | Key | Description |
| :---------------- | :----------- | :----- | :--------------------------------------------- |
| id | INT | **PK** | ID ของตาราง |
| organization_code | VARCHAR(20) | UK | รหัสองค์กร |
| organization_name | VARCHAR(255) | | ชื่อองค์กร |
| role_id | INT | FK | บทบาทขององค์กร (FK \-> organization_roles(id)) |
| is_active | BOOLEAN | | สถานะการใช้งาน |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
- **Foreign Keys (FK):**
- role_id -> organization_roles(id) (ON DELETE SET NULL)
- **Unique Keys (UK):** ux_organizations_code (organization_code)
---
#### **1.3. projects**
ตาราง Master เก็บข้อมูลโครงการ (เช่น LCBP3C1, LCBP3C2)
| Column | Type | Key | Description |
| :------------------------- | :----------- | :----- | :------------------------------------------------------ |
| id | INT | **PK** | ID ของตาราง |
| project_code | VARCHAR(50) | UK | รหัสโครงการ |
| project_name | VARCHAR(255) | | ชื่อโครงการ |
| parent_project_id | INT | FK | รหัสโครงการหลัก (ถ้ามี) (FK \-> projects(id)) |
| contractor_organization_id | INT | FK | รหัสองค์กรผู้รับเหมา (ถ้ามี) (FK \-> organizations(id)) |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
- **Foreign Keys (FK):**
- parent_project_id -> projects(id) (ON DELETE SET NULL)
- contractor_organization_id -> organizations(id) (ON DELETE SET NULL)
- **Unique Keys (UK):** uq_pro_code (project_code)
---
#### **1.4. contracts**
ตาราง Master เก็บข้อมูลสัญญา
| Column | Type | Key | Description |
| :------------ | :----------- | :----- | :----------------- |
| id | INT | **PK** | ID ของตาราง |
| contract_code | VARCHAR(50) | UK | รหัสสัญญา |
| contract_name | VARCHAR(255) | | ชื่อสัญญา |
| description | TEXT | | คำอธิบายสัญญา |
| start_date | DATE | | วันที่เริ่มสัญญา |
| end_date | DATE | | วันที่สิ้นสุดสัญญา |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
- **Unique Keys (UK):** ux_contracts_code (contract_code)
---
## **2. 👥 Users & RBAC (ผู้ใช้, สิทธิ์, บทบาท)**
#### **2.1. users**
ตาราง Master เก็บข้อมูลผู้ใช้งาน (User)
| Column | Type | Key | Description |
| :-------------- | :----------- | :----- | :-------------------------------------- |
| user_id | INT | **PK** | ID ของตาราง |
| username | VARCHAR(50) | UK | ชื่อผู้ใช้งาน |
| password_hash | VARCHAR(255) | | รหัสผ่าน (Hashed) |
| first_name | VARCHAR(50) | | ชื่อจริง |
| last_name | VARCHAR(50) | | นามสกุล |
| email | VARCHAR(100) | UK | อีเมล |
| line_id | VARCHAR(100) | | LINE ID |
| organization_id | INT | FK | สังกัดองค์กร (FK \-> organizations(id)) |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
| failed_attempts | INT | | จำนวนครั้งที่ล็อกอินล้มเหลว |
| locked_until | DATETIME | | ล็อกอินไม่ได้จนถึงเวลา |
| last_login_at | TIMESTAMP | | วันที่และเวลาที่ล็อกอินล่าสุด |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
- **Foreign Keys (FK):**
- organization_id -> organizations(id) (ON DELETE SET NULL)
- **Unique Keys (UK):** ux_users_username (username), ux_users_email (email)
---
#### **2.2. roles**
ตาราง Master เก็บ "บทบาท" ของผู้ใช้ในระบบ (เช่น SUPER_ADMIN, ADMIN, EDITOR)
| Column | Type | Key | Description |
| :---------- | :----------- | :----- | :-------------------------------------------------- |
| role_id | INT | **PK** | ID ของตาราง |
| role_code | VARCHAR(50) | UK | รหัสบทบาท (เช่น SUPER_ADMIN, ADMIN, EDITOR, VIEWER) |
| role_name | VARCHAR(100) | | ชื่อบทบาท |
| description | TEXT | | คำอธิบายบทบาท |
| is_system | BOOLEAN | | (1 = บทบาทของระบบ ลบไม่ได้) |
- **Unique Keys (UK):** role_code
---
#### **2.3. permissions**
ตาราง Master เก็บ "สิทธิ์" (Permission) หรือ "การกระทำ" ทั้งหมดในระบบ
| Column | Type | Key | Description |
| :-------------- | :----------- | :----- | :------------------------------------------ |
| permission_id | INT | **PK** | ID ของตาราง |
| permission_code | VARCHAR(100) | UK | รหัสสิทธิ์ (เช่น rfas.create, rfas.view) |
| description | TEXT | | คำอธิบายสิทธิ์ |
| module | VARCHAR(50) | | โมดูลที่เกี่ยวข้อง |
| scope_level | ENUM(...) | | ระดับขอบเขตของสิทธิ์ (GLOBAL, ORG, PROJECT) |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
- **Unique Keys (UK):** ux_permissions_code (permission_code)
---
#### **2.4. role_permissions (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง roles และ permissions (M:N)
| Column | Type | Key | Description |
| :------------ | :--- | :--------- | :----------------------------------------------- |
| role_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role_id)) |
| permission_id | INT | **PK**, FK | ID ของสิทธิ์ (FK \-> permissions(permission_id)) |
- **Foreign Keys (FK):**
- role_id -> roles(role_id) (ON DELETE CASCADE)
- permission_id -> permissions(permission_id) (ON DELETE CASCADE)
---
#### **2.5. user_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Global** (M:N)
| Column | Type | Key | Description |
| :------ | :--- | :--------- | :----------------------------------- |
| user_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user_id)) |
| role_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role_id)) |
- **Foreign Keys (FK):**
- user_id -> users(user_id) (ON DELETE CASCADE)
- role_id -> roles(role_id) (ON DELETE CASCADE)
---
#### **2.6. user_project_roles (ตารางเชื่อม)**
ตารางเชื่อมผู้ใช้ (users) กับบทบาท (roles) ในระดับ **Project-Specific** (M:N)
| Column | Type | Key | Description |
| :--------- | :--- | :--------- | :----------------------------------- |
| user_id | INT | **PK**, FK | ID ของผู้ใช้ (FK \-> users(user_id)) |
| project_id | INT | **PK**, FK | ID ของโครงการ (FK \-> projects(id)) |
| role_id | INT | **PK**, FK | ID ของบทบาท (FK \-> roles(role_id)) |
- **Foreign Keys (FK):**
- user_id -> users(user_id) (ON DELETE CASCADE)
- project_id -> projects(id) (ON DELETE CASCADE)
- role_id -> roles(role_id) (ON DELETE CASCADE)
---
## **3. ✉️ Correspondences (เอกสารหลัก, Revisions)**
#### **3.1. correspondence_types**
ตาราง Master เก็บประเภทเอกสารโต้ตอบ (เช่น RFA, RFI, LETTER, MOM)
| Column | Type | Key | Description |
| :--------- | :----------- | :----- | :------------------------- |
| id | INT | **PK** | ID ของตาราง |
| type_code | VARCHAR(50) | UK | รหัสประเภท (เช่น RFA, RFI) |
| type_name | VARCHAR(255) | | ชื่อประเภท |
| sort_order | INT | | ลำดับการแสดงผล |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
- **Unique Keys (UK):** type_code
---
#### **3.2. correspondence_status**
ตาราง Master เก็บสถานะของเอกสาร (เช่น DRAFT, SUBMITTED, CLOSED)
| Column | Type | Key | Description |
| :---------- | :----------- | :----- | :------------------------------------ |
| id | INT | **PK** | ID ของตาราง |
| status_code | VARCHAR(50) | UK | รหัสสถานะหนังสือ (เช่น DRAFT, SUBOWN) |
| status_name | VARCHAR(255) | | ชื่อสถานะหนังสือ |
| sort_order | INT | | ลำดับการแสดงผล |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
- **Unique Keys (UK):** status_code
---
#### **3.3. correspondences (Master)**
ตาราง "แม่" ของเอกสารโต้ตอบ เก็บข้อมูลที่ไม่เปลี่ยนตาม Revision (เช่น เลขที่เอกสาร)
| Column | Type | Key | Description |
| :------------------------ | :----------- | :----- | :----------------------------------------------- |
| id | INT | **PK** | ID ของตาราง (นี่คือ "Master ID" ที่ใช้เชื่อมโยง) |
| correspondence_number | VARCHAR(100) | UK | เลขที่เอกสาร (สร้างจาก DocumentNumberingModule) |
| correspondence_type_id | INT | FK | ประเภทเอกสาร (FK \-> correspondence_types(id)) |
| is_internal_communication | TINYINT(1) | | (1 = ภายใน, 0 = ภายนอก) |
| project_id | INT | FK | อยู่ในโครงการ (FK \-> projects(id)) |
| originator_id | INT | FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| created_at | DATETIME | | วันที่สร้าง |
| created_by | INT | FK | ผู้สร้าง (FK \-> users(user_id)) |
| deleted_at | DATETIME | | สำหรับ Soft Delete |
- **Foreign Keys (FK):**
- correspondence_type_id -> correspondence_types(id) (ON DELETE RESTRICT)
- project_id -> projects(id) (ON DELETE CASCADE)
- originator_id -> organizations(id) (ON DELETE SET NULL)
- created_by -> users(user_id) (ON DELETE SET NULL)
- **Unique Keys (UK):** uq_corr_no_per_project (project_id, correspondence_number)
---
#### **3.4. correspondence_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติการแก้ไข (Revisions) ของ correspondences (1:N) **(ปรับปรุง V1.4.0)**
| Column | Type | Key | Description |
| :----------------------- | :----------- | :----- | :------------------------------------------------------- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence_id | INT | FK, UK | Master ID (FK \-> correspondences(id)) |
| revision_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| revision_label | VARCHAR(10) | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is_current | BOOLEAN | UK | (1 = Revision ปัจจุบัน) |
| correspondence_status_id | INT | FK | สถานะของ Revision นี้ (FK \-> correspondence_status(id)) |
| title | VARCHAR(255) | | เรื่อง |
| document_date | DATE | | วันที่ในเอกสาร |
| issued_date | DATETIME | | วันที่ออกเอกสาร |
| received_date | DATETIME | | วันที่ลงรับเอกสาร |
| due_date | DATETIME | | **(ใหม่)** วันที่ครบกำหนด (ตาม Requirements 3.2.5) |
| description | TEXT | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| details | JSON | | ข้อมูลเฉพาะ (เช่น RFI details) |
| created_at | DATETIME | | **(ใหม่)** วันที่สร้างเอกสาร |
| created_by | INT | FK | ผู้สร้าง (FK \-> users(user_id)) |
| updated_by | INT | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user_id)) |
- **Foreign Keys (FK):**
- correspondence_id -> correspondences(id) (ON DELETE CASCADE)
- correspondence_status_id -> correspondence_status(id) (ON DELETE RESTRICT)
- created_by -> users(user_id) (ON DELETE SET NULL)
- updated_by -> users(user_id) (ON DELETE SET NULL)
- **Unique Keys (UK):**
- uq_master_revision_number (correspondence_id, revision_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
- uq_master_current (correspondence_id, is_current) (ป้องกัน is_current = TRUE ซ้ำใน Master เดียว)
- **Check Constraints (CHK):** chk_rev_format (ตรวจสอบรูปแบบ revision_label)
---
#### **3.5. correspondence_recipients (ตารางเชื่อม)**
ตารางเชื่อมผู้รับ (TO/CC) สำหรับเอกสารแต่ละฉบับ (M:N)
| Column | Type | Key | Description |
| :------------------------ | :--------------- | :--------- | :---------------------------------------------------------------- |
| correspondence_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondence_revisions(correspondence_id)) |
| recipient_organization_id | INT | **PK**, FK | ID องค์กรผู้รับ (FK \-> organizations(id)) |
| recipient_type | ENUM('TO', 'CC') | **PK** | ประเภทผู้รับ (TO หรือ CC) |
- **Foreign Keys (FK):**
- correspondence_id -> correspondence_revisions(correspondence_id) (ON DELETE CASCADE)
- recipient_organization_id -> organizations(id) (ON DELETE RESTRICT)
---
#### **3.6. correspondence_tags (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง correspondences และ tags (M:N)
| Column | Type | Key | Description |
| :---------------- | :--- | :--------- | :---------------------------------------- |
| correspondence_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| tag_id | INT | **PK**, FK | ID ของ Tag (FK \-> tags(id)) |
- **Foreign Keys (FK):**
- correspondence_id -> correspondences(id) (ON DELETE CASCADE)
- tag_id -> tags(id) (ON DELETE CASCADE)
---
#### **3.7. correspondence_references (ตารางเชื่อม)**
ตารางเชื่อมการอ้างอิงระหว่างเอกสาร (M:N)
| Column | Type | Key | Description |
| :-------------------- | :--- | :--------- | :--------------------------------------------- |
| src_correspondence_id | INT | **PK**, FK | ID เอกสารต้นทาง (FK \-> correspondences(id)) |
| tgt_correspondence_id | INT | **PK**, FK | ID เอกสารเป้าหมาย (FK \-> correspondences(id)) |
- **Foreign Keys (FK):**
- src_correspondence_id -> correspondences(id) (ON DELETE CASCADE)
- tgt_correspondence_id -> correspondences(id) (ON DELETE CASCADE)
---
## **4. 📐 approval: RFA (เอกสารขออนุมัติ, Workflows)**
#### **4.1. rfa_types / ...\_status_codes / ...\_approve_codes**
ตาราง Master สำหรับ RFA
- **rfa_types:** ประเภท RFA (เช่น DWG, DOC, MAT)
- **rfa_status_codes:** สถานะ RFA (เช่น DFT \- Draft, FAP \- For Approve)
- **rfa_approve_codes:** รหัสผลการอนุมัติ (เช่น 1A \- Approved, 3R \- Revise and Resubmit)
---
#### **4.2. rfas (Master)**
ตาราง "แม่" ของ RFA (มีความสัมพันธ์ 1:N กับ rfa_revisions)
| Column | Type | Key | Description |
| :---------- | :------- | :----- | :-------------------------------- |
| id | INT | **PK** | ID ของตาราง (RFA Master ID) |
| rfa_type_id | INT | FK | ประเภท RFA (FK \-> rfa_types(id)) |
| created_at | DATETIME | | วันที่สร้าง |
| created_by | INT | FK | ผู้สร้าง (FK \-> users(user_id)) |
| deleted_at | DATETIME | | สำหรับ Soft Delete |
- **Foreign Keys (FK):**
- rfa_type_id -> rfa_types(id)
- created_by -> users(user_id) (ON DELETE SET NULL)
---
#### **4.3. rfa_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ rfas (1:N) **(ปรับปรุง V1.4.0)**
| Column | Type | Key | Description |
| :------------------ | :----------- | :----- | :-------------------------------------------------------- |
| id | INT | **PK** | **ID ของ Revision** |
| correspondence_id | INT | FK | Master ID ของ Correspondence (FK \-> correspondences(id)) |
| rfa_id | INT | FK, UK | Master ID ของ RFA (FK \-> rfas(id)) |
| revision_number | INT | UK | หมายเลข Revision (0, 1, 2...) |
| revision_label | VARCHAR(10) | | **(ใหม่)** Revision ที่แสดง (เช่น A, B, 1.1) |
| is_current | BOOLEAN | UK | (1 = Revision ปัจจุบัน) |
| rfa_status_code_id | INT | FK | สถานะ RFA (FK \-> rfa_status_codes(id)) |
| rfa_approve_code_id | INT | FK | ผลการอนุมัติ (FK \-> rfa_approve_codes(id)) |
| title | VARCHAR(255) | | เรื่อง |
| document_date | DATE | | **(ใหม่)** วันที่ในเอกสาร |
| issued_date | DATE | | **(ใหม่)** วันที่ส่งขออนุมัติ |
| received_date | DATETIME | | **(ใหม่)** วันที่ลงรับเอกสาร |
| approved_date | DATE | | **(ใหม่)** วันที่อนุมัติ |
| description | TEXT | | **(ใหม่)** คำอธิบายการแก้ไขใน Revision นี้ |
| created_at | DATETIME | | **(ใหม่)** วันที่สร้างเอกสาร |
| created_by | INT | FK | ผู้สร้าง (FK \-> users(user_id)) |
| updated_by | INT | **FK** | **(ใหม่)** ผู้แก้ไขล่าสุด (FK \-> users(user_id)) |
- **Foreign Keys (FK):**
- correspondence_id -> correspondences(id) (ON DELETE CASCADE)
- rfa_id -> rfas(id) (ON DELETE CASCADE)
- rfa_status_code_id -> rfa_status_codes(id)
- rfa_approve_code_id -> rfa_approve_codes(id) (ON DELETE SET NULL)
- created_by -> users(user_id) (ON DELETE SET NULL)
- updated_by -> users(user_id) (ON DELETE SET NULL)
- **Unique Keys (UK):**
- uq_rr_rev_number (rfa_id, revision_number) (ป้องกัน Rev ซ้ำใน Master เดียว)
- uq_rr_current (rfa_id, is_current) (ป้องกัน is_current=TRUE ซ้ำใน Master เดียว)
---
#### **4.4. rfa_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง rfa_revisions (ที่เป็นประเภท DWG) กับ shop_drawing_revisions (M:N)
| Column | Type | Key | Description |
| :----------------------- | :--- | :------------- | :--------------------------------------------------------------- |
| rfarev_correspondence_id | INT | **PK**, FK | ID ของ RFA Revision (FK \-> rfa_revisions(correspondence_id)) |
| shop_drawing_revision_id | INT | **PK**, UK, FK | ID ของ Shop Drawing Revision (FK \-> shop_drawing_revisions(id)) |
- **Foreign Keys (FK):**
- rfarev_correspondence_id -> rfa_revisions(correspondence_id) (ON DELETE CASCADE)
- shop_drawing_revision_id -> shop_drawing_revisions(id) (ON DELETE CASCADE)
---
#### **4.5. rfa_workflow_templates / ...\_steps / ...\_workflows**
ตารางที่เกี่ยวข้องกับ Workflow การอนุมัติ RFA
- **rfa_workflow_templates:** ตาราง Master เก็บแม่แบบสายอนุมัติ (เช่น "สายอนุมัติ 3 ขั้นตอน")
- **rfa_workflow_template_steps:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: Org A (Review), Step 2: Org B (Approve))
- **rfa_workflows:** ตารางประวัติ (Log) การอนุมัติของ RFA จริงตามสายงงาน
---
## **5. 📐 Drawings (แบบ, หมวดหมู่)**
#### **5.1. contract_drawing_volumes / ...\_cats / ...\_sub_cats**
ตาราง Master สำหรับ "แบบคู่สัญญา" (Contract Drawings)
- **contract_drawing_volumes:** เก็บ "เล่ม" ของแบบ
- **contract_drawing_cats:** เก็บ "หมวดหมู่หลัก" ของแบบ
- **contract_drawing_sub_cats:** เก็บ "หมวดหมู่ย่อย" ของแบบ
---
#### **5.2. contract_drawing_subcat_cat_maps (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อมระหว่าง หมวดหมู่หลัก-ย่อย (M:N)
| Column | Type | Key | Description |
| :--------- | :--- | :--------- | :----------------- |
| project_id | INT | **PK**, FK | ID ของโครงการ |
| sub_cat_id | INT | **PK**, FK | ID ของหมวดหมู่ย่อย |
| cat_id | INT | **PK**, FK | ID ของหมวดหมู่หลัก |
- **Foreign Keys (FK) (ตามเจตนา):**
- (project_id, sub_cat_id) -> contract_drawing_sub_cats(project_id, id)
- (project_id, cat_id) -> contract_drawing_cats(project_id, id)
- **Unique Keys (UK):**
- ux_map_unique (project_id, sub_cat_id, cat_id)
---
#### **5.3. contract_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบคู่สัญญา"
| Column | Type | Key | Description |
| :--------- | :----------- | :----- | :-------------------------------------------------- |
| id | INT | **PK** | ID ของตาราง |
| project_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| condwg_no | VARCHAR(255) | UK | เลขที่แบบสัญญา |
| title | VARCHAR(255) | | ชื่อแบบสัญญา |
| sub_cat_id | INT | FK | หมวดหมู่ย่อย (FK \-> contract_drawing_sub_cats(id)) |
| volume_id | INT | FK | เล่ม (FK \-> contract_drawing_volumes(id)) |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
| deleted_at | DATETIME | | **(ใหม่)** วันที่ลบ |
| updated_by | INT | FK | **(ใหม่)** ผู้แก้ไขล่าสุด |
- **Foreign Keys (FK):**
- fk_condwg_project (project_id) -> projects(id) (ON DELETE CASCADE)
- fk_condwg_subcat_same_project (project_id, sub_cat_id) -> contract_drawing_sub_cats(project_id, id) (ON DELETE RESTRICT)
- fk_condwg_volume_same_project (project_id, volume_id) -> contract_drawing_volumes(project_id, id) (ON DELETE RESTRICT)
- **Unique Keys (UK):** ux_condwg_no_project (project_id, condwg_no)
---
#### **5.4. shop_drawing_main_categories / ...\_sub_categories**
ตาราง Master สำหรับ "แบบก่อสร้าง" (Shop Drawings)
- **shop_drawing_main_categories:** เก็บ "หมวดหมู่หลัก" (เช่น ARCH, STR)
- **shop_drawing_sub_categories:** เก็บ "หมวดหมู่ย่อย" (เช่น STR-COLUMN)
---
#### **5.5. shop_drawings (Master)**
ตาราง Master เก็บข้อมูล "แบบก่อสร้าง"
| Column | Type | Key | Description |
| :--------------- | :----------- | :----- | :----------------------------------------------------- |
| id | INT | **PK** | ID ของตาราง |
| project_id | INT | FK | โครงการ (FK \-> projects(id)) |
| drawing_number | VARCHAR(100) | UK | เลขที่ Shop Drawing |
| title | VARCHAR(500) | | ชื่อแบบ |
| main_category_id | INT | FK | หมวดหมู่หลัก (FK \-> shop_drawing_main_categories(id)) |
| sub_category_id | INT | FK | หมวดหมู่ย่อย (FK \-> shop_drawing_sub_categories(id)) |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
| deleted_at | DATETIME | | **(ใหม่)** วันที่ลบ |
| updated_by | INT | FK | **(ใหม่)** ผู้แก้ไขล่าสุด |
- **Foreign Keys (FK):** project_id, main_category_id, sub_category_id
- **Unique Keys (UK):** ux_sd_drawing_number (drawing_number)
---
#### **5.6. shop_drawing_revisions (Revisions)**
ตาราง "ลูก" เก็บประวัติ (Revisions) ของ shop_drawings (1:N)
| Column | Type | Key | Description |
| :-------------- | :---------- | :----- | :------------------------------------------------ |
| id | INT | **PK** | ID ของ Revision |
| shop_drawing_id | INT | FK, UK | Master ID (FK \-> shop_drawings(id)) |
| revision_number | INT | UK | **(ปรับปรุง)** หมายเลข Revision (เช่น 0, 1, 2...) |
| revision_label | VARCHAR(10) | | **(ปรับปรุง)** Revision ที่แสดง (เช่น A, B, 1.1) |
| revision_date | DATE | | วันที่ของ Revision |
| description | TEXT | | คำอธิบายการแก้ไข |
| created_at | TIMESTAMP | | วันที่สร้าง |
- **Foreign Keys (FK):**
- shop_drawing_id -> shop_drawings(id) (ON DELETE CASCADE)
- **Unique Keys (UK):** ux_sd_rev_drawing_revision (shop_drawing_id, revision_number)
---
#### **5.7. shop_drawing_revision_contract_refs (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง shop_drawing_revisions กับ contract_drawings (M:N)
| Column | Type | Key | Description |
| :----------------------- | :--- | :--------- | :--------------------------------------------------------------- |
| shop_drawing_revision_id | INT | **PK**, FK | ID ของ Shop Drawing Revision (FK \-> shop_drawing_revisions(id)) |
| contract_drawing_id | INT | **PK**, FK | ID ของ Contract Drawing (FK \-> contract_drawings(id)) |
- **Foreign Keys (FK):**
- shop_drawing_revision_id -> shop_drawing_revisions(id) (ON DELETE CASCADE)
- contract_drawing_id -> contract_drawings(id) (ON DELETE CASCADE)
---
## **6. 🔄 Circulations (ใบเวียนภายใน)**
#### **6.1. circulation_status_codes**
ตาราง Master เก็บสถานะใบเวียน (เช่น OPEN, IN_REVIEW, COMPLETED)
| Column | Type | Key | Description |
| :---------- | :---------- | :----- | :------------------------ |
| id | INT | **PK** | ID ของตาราง |
| code | VARCHAR(20) | UK | รหัสสถานะการดำเนินงาน |
| description | VARCHAR(50) | | คำอธิบายสถานะการดำเนินงาน |
| sort_order | INT | | ลำดับการแสดงผล |
| is_active | TINYINT(1) | | สถานะการใช้งาน |
---
#### **6.2. circulations (Master)**
ตาราง "แม่" ของใบเวียนเอกสารภายใน
| Column | Type | Key | Description |
| :---------------------- | :----------- | :----- | :---------------------------------------------------------------- |
| id | INT | **PK** | ID ของตารางใบเวียน |
| correspondence_id | INT | UNIQUE | ID ของเอกสาร (จากตาราง correspondences) |
| organization_id | INT | FK | ID ขององค์กรณ์ที่เป็นเจ้าของใบเวียนนี้ (FK \-> organizations(id)) |
| circulation_no | VARCHAR(100) | | เลขที่ใบเวียน |
| circulation_subject | VARCHAR(500) | | เรื่องใบเวียน |
| circulation_status_code | VARCHAR(20) | FK | รหัสสถานะใบเวียน (FK \-> circulation_status_codes(code)) |
| created_by_user_id | INT | FK | ID ของผู้สร้างใบเวียน (FK \-> users(user_id)) |
| submitted_at | TIMESTAMP | | วันที่ส่งใบเวียน |
| closed_at | TIMESTAMP | | วันที่ปิดใบเวียน |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
- **Foreign Keys (FK):**
- correspondence_id -> correspondences(id)
- organization_id -> organizations(id)
- circulation_status_code -> circulation_status_codes(code)
- created_by_user_id -> users(user_id)
---
#### **6.3. circulation_templates / ...\_assignees / ...\_routings**
ตารางที่เกี่ยวข้องกับ Workflow การส่งต่อเอกสาร (Req 3.5.4)
- **circulation_templates:** ตาราง Master เก็บแม่แบบสายงาน (เช่น "ส่งให้ CSC ตรวจสอบ")
- **circulation_template_assignees:** ตารางลูก เก็บขั้นตอนในแม่แบบ (เช่น Step 1: ส่งไป Org A, Step 2: ส่งไป Org B)
- **circulation_routings:** ตารางประวัติ (Log) การส่งต่อของเอกสารจริงตาม Workflow
---
## **7. 📤 Transmittals (เอกสารนำส่ง)**
#### **7.1. transmittals**
ตารางข้อมูลเฉพาะของเอกสารนำส่ง (เป็นตารางลูก 1:1 ของ correspondences)
| Column | Type | Key | Description |
| :---------------- | :-------- | :--------- | :------------------------------------------------ |
| correspondence_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| purpose | ENUM(...) | | วัตถุประสงค์ (FOR_APPROVAL, FOR_INFORMATION, ...) |
| remarks | TEXT | | หมายเหตุ |
- **Foreign Keys (FK):** correspondence_id -> correspondences(id) (ON DELETE CASCADE)
---
#### **7.2. transmittal_items (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง transmittals และเอกสารที่นำส่ง (M:N) **(ปรับปรุง V1.4.0)**
| Column | Type | Key | Description |
| :------------------------- | :--------------- | :--------- | :-------------------------------------------------------------- |
| **id** | **INT** | **PK** | **(ใหม่)** ID ของรายการ |
| transmittal_id | INT | **FK**, UK | ID ของ Transmittal (FK \-> transmittals(correspondence_id)) |
| **item_correspondence_id** | INT | **FK**, UK | **(เปลี่ยน)** ID ของเอกสารที่แนบไป (FK \-> correspondences(id)) |
| **quantity** | **INT** | | **(ใหม่)** จำนวน |
| **remarks** | **VARCHAR(255)** | | **(ใหม่)** หมายเหตุสำหรับรายการนี้ |
- **Foreign Keys (FK):**
- transmittal_id -> transmittals(correspondence_id) (ON DELETE CASCADE)
- item_correspondence_id -> correspondences(id) (ON DELETE CASCADE)
- **Unique Keys (UK):** ux_transmittal_item (transmittal_id, item_correspondence_id)
---
## **8. 📎 File Management (ไฟล์แนบ)**
#### **8.1. attachments (Master)**
ตาราง "กลาง" เก็บไฟล์แนบทั้งหมดของระบบ (ตาม Requirements 3.9)
| Column | Type | Key | Description |
| :------------------ | :----------- | :----- | :-------------------------------------------- |
| id | INT | **PK** | ID ของไฟล์แนบ |
| original_filename | VARCHAR(255) | | ชื่อไฟล์ดั้งเดิมตอนอัปโหลด |
| stored_filename | VARCHAR(255) | | ชื่อไฟล์ที่เก็บจริงบน Server (ป้องกันชื่อซ้ำ) |
| file_path | VARCHAR(500) | | Path ที่เก็บไฟล์ (บน QNAP /share/dms-data/) |
| mime_type | VARCHAR(100) | | ประเภทไฟล์ (เช่น application/pdf) |
| file_size | INT | | ขนาดไฟล์ (bytes) |
| uploaded_by_user_id | INT | FK | ผู้อัปโหลดไฟล์ (FK \-> users(user_id)) |
- **Foreign Keys (FK):** uploaded_by_user_id -> users(user_id) (ON DELETE CASCADE)
---
#### **8.2. correspondence_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม correspondences กับ attachments (M:N)
| Column | Type | Key | Description |
| :---------------- | :------ | :--------- | :---------------------------------------- |
| correspondence_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| attachment_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is_main_document | BOOLEAN | | (1 = ไฟล์หลัก) |
- **Foreign Keys (FK):** correspondence_id, attachment_id
---
#### **8.3. circulation_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม circulations กับ attachments (M:N)
| Column | Type | Key | Description |
| :--------------- | :------ | :--------- | :-------------------------------------- |
| circulation_id | INT | **PK**, FK | ID ของใบเวียน (FK \-> circulations(id)) |
| attachment_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| is_main_document | BOOLEAN | | (1 = ไฟล์หลักของใบเวียน) |
- **Foreign Keys (FK):** circulation_id, attachment_id
---
#### **8.4. shop_drawing_revision_attachments (ตารางเชื่อม - ใหม่)**
ตารางเชื่อม shop_drawing_revisions กับ attachments (M:N) **(ปรับปรุง V1.2.0)**
| Column | Type | Key | Description |
| :----------------------- | :---------- | :--------- | :--------------------------------------------------------------- |
| shop_drawing_revision_id | INT | **PK**, FK | ID ของ Shop Drawing Revision (FK \-> shop_drawing_revisions(id)) |
| attachment_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| **is_main_document** | **BOOLEAN** | | **(ใหม่)** (1 = ไฟล์หลัก) |
- **Foreign Keys (FK):** shop_drawing_revision_id, attachment_id
---
#### **8.5. contract_drawing_attachments (ตารางเชื่อม - ใหม่)**
**(ใหม่)** ตารางเชื่อม contract_drawings กับ attachments (M:N)
| Column | Type | Key | Description |
| :------------------ | :-------- | :--------- | :----------------------------------------------------- |
| contract_drawing_id | INT | **PK**, FK | ID ของ Contract Drawing (FK \-> contract_drawings(id)) |
| attachment_id | INT | **PK**, FK | ID ของไฟล์แนบ (FK \-> attachments(id)) |
| file_type | ENUM(...) | | ประเภทไฟล์ (PDF, DWG, SOURCE, OTHER) |
| is_main_document | BOOLEAN | | (1 = ไฟล์หลัก) |
- **Foreign Keys (FK):**
- contract_drawing_id -> contract_drawings(id) (ON DELETE CASCADE)
- attachment_id -> attachments(id) (ON DELETE CASCADE)
---
## **9. 🔢 Document Numbering (การสร้างเลขที่เอกสาร)**
#### **9.1. document_number_formats (ตารางตั้งค่า - ใหม่)**
ตาราง Master เก็บ "รูปแบบ" Template ของเลขที่เอกสาร (ตาม Requirements 3.10.3)
| Column | Type | Key | Description |
| :--------------------- | :----------- | :----- | :---------------------------------------------------- |
| id | INT | **PK** | ID ของตาราง |
| project_id | INT | FK, UK | โครงการ (FK \-> projects(id)) |
| correspondence_type_id | INT | FK, UK | ประเภทเอกสาร (FK \-> correspondence_types(id)) |
| format_template | VARCHAR(255) | | รูปแบบ Template (เช่น {ORG_CODE}-{TYPE_CODE}-{SEQ:4}) |
| description | TEXT | | คำอธิบายรูปแบบนี้ |
- **Foreign Keys (FK):** project_id, correspondence_type_id
- **Unique Keys (UK):** uk_project_type (project_id, correspondence_type_id)
---
#### **9.2. document_number_counters (ตารางตัวนับ - ใหม่)**
ตารางเก็บ "ตัวนับ" (Running Number) ล่าสุด (ตาม Requirements 3.10.2)
| Column | Type | Key | Description |
| :------------------------- | :--- | :--------- | :--------------------------------------------- |
| project_id | INT | **PK**, FK | โครงการ (FK \-> projects(id)) |
| originator_organization_id | INT | **PK**, FK | องค์กรผู้ส่ง (FK \-> organizations(id)) |
| correspondence_type_id | INT | **PK**, FK | ประเภทเอกสาร (FK \-> correspondence_types(id)) |
| current_year | INT | **PK** | ปี ค.ศ. ของตัวนับ |
| last_number | INT | | เลขที่ล่าสุดที่ใช้ไปแล้ว |
- **Foreign Keys (FK):** project_id, originator_organization_id, correspondence_type_id
---
## **10. ⚙️ System & Logs (ระบบและ Log)**
#### **10.1. tags**
ตาราง Master เก็บ Tags ทั้งหมดที่ใช้ในระบบ
| Column | Type | Key | Description |
| :---------- | :----------- | :----- | :---------------- |
| id | INT | **PK** | ID ของตาราง |
| tag_name | VARCHAR(100) | UK | ชื่อ Tag |
| description | TEXT | | คำอธิบายแท็ก |
| created_at | TIMESTAMP | | วันที่สร้าง |
| updated_at | TIMESTAMP | | วันที่แก้ไขล่าสุด |
- **Unique Keys (UK):** ux_tag_name (tag_name)
---
#### **10.2. correspondence_tags (ตารางเชื่อม)**
ตารางเชื่อมระหว่าง correspondences และ tags (M:N)
| Column | Type | Key | Description |
| :---------------- | :--- | :--------- | :---------------------------------------- |
| correspondence_id | INT | **PK**, FK | ID ของเอกสาร (FK \-> correspondences(id)) |
| tag_id | INT | **PK**, FK | ID ของ Tag (FK \-> tags(id)) |
- **Foreign Keys (FK):** correspondence_id, tag_id
---
#### **10.3. audit_logs**
ตารางเก็บบันทึกการกระทำของผู้ใช้ (ตาม Requirements 6.1)
| Column | Type | Key | Description |
| :----------- | :----------- | :----- | :--------------------------------------------------------------- |
| audit_id | BIGINT | **PK** | ID ของ Log |
| user_id | INT | FK | ผู้กระทำ (FK \-> users(user_id)) |
| action | VARCHAR(100) | | การกระทำ (เช่น rfa.create, correspondence.update, login.success) |
| entity_type | VARCHAR(50) | | ตาราง/โมดูล (เช่น 'rfa', 'correspondence') |
| entity_id | VARCHAR(50) | | Primary ID ของระเบียนที่ได้รับผลกระทำ |
| details_json | JSON | | ข้อมูลบริบที่ |
| ip_address | VARCHAR(45) | | IP Address |
| user_agent | VARCHAR(255) | | User Agent |
| created_at | TIMESTAMP | | เวลาที่กระทำ |
- **Foreign Keys (FK):** user_id -> users(user_id) (ON DELETE SET NULL)
---
#### **10.4. notifications (ตารางใหม่ - ตาม Requirements 6.7)**
ตารางสำหรับจัดการการแจ้งเตือน (Email/Line/System)
| Column | Type | Key | Description |
| :---------------- | :------------------------------ | :----- | :-------------------------------- |
| id | INT | **PK** | ID ของการแจ้งเตือน |
| user_id | INT | FK | ID ผู้ใช้ (FK \-> users(user_id)) |
| title | VARCHAR(255) | | หัวข้อการแจ้งเตือน |
| message | TEXT | | รายละเอียดการแจ้งเตือน |
| notification_type | ENUM('EMAIL', 'LINE', 'SYSTEM') | | ประเภท (EMAIL, LINE, SYSTEM) |
| is_read | BOOLEAN | | สถานะการอ่าน |
| entity_type | VARCHAR(50) | | เช่น 'rfa', 'circulation' |
| entity_id | INT | | ID ของเอนทิตีที่เกี่ยวข้อง |
| created_at | TIMESTAMP | | วันที่สร้าง |
- **Foreign Keys (FK):** user_id -> users(user_id)
---
#### **10.5. search_indices (ตารางใหม่ - ตาม Requirements 6.2)**
ตารางสำหรับจัดการดัชนีการค้นหาขั้นสูง (Full-text Search)
| Column | Type | Key | Description |
| :---------- | :---------- | :----- | :----------------------------------------- |
| id | INT | **PK** | ID ของดัชนี |
| entity_type | VARCHAR(50) | | ชนิดเอนทิตี (เช่น 'correspondence', 'rfa') |
| entity_id | INT | | ID ของเอนทิตี |
| content | TEXT | | เนื้อหาที่จะค้นหา |
| indexed_at | TIMESTAMP | | วันที่สร้าง/อัปเดตัชนี |
- **Indexes:** `idx_entity (entity_type, entity_id)`, `FULLTEXT INDEX idx_content (content)`
---
#### **10.6. backup_logs (ตารางใหม่ - ตาม Requirements 6.6)**
ตารางสำหรับบันทึกประวัติการสำรองข้อมูล
| Column | Type | Key | Description |
| :------------ | :------------------------------------- | :----- | :----------------------------- |
| id | INT | **PK** | ID ของการสำรอง |
| backup_type | ENUM('DATABASE', 'FILES', 'FULL') | | ประเภท (DATABASE, FILES, FULL) |
| backup_path | VARCHAR(500) | | ตำแหน่งไฟล์สำรอง |
| file_size | BIGINT | | ขนาดไฟล์ |
| status | ENUM('STARTED', 'COMPLETED', 'FAILED') | | สถานะ |
| started_at | TIMESTAMP | | เวลาเริ่มต้น |
| completed_at | TIMESTAMP | | เวลาเสร็จสิ้น |
| error_message | TEXT | | ข้อความผิดพลาด (ถ้ามี) |
---
## **11. 📊 Views & Procedures (วิว และ โปรซีเดอร์)**
#### **11.1. sp_get_next_document_number (Procedure)**
**(ใหม่)** Stored Procedure ดึงเดียวที่ใช้ในระบบ
- **หน้าที่:** ดึงเลขที่เอกสารถัดไป (Next Running Number) จากตาราง document_number_counters
- **ตรรกะ:** ใช้ `SELECT ... FOR UPDATE` เพื่อ "ล็อก" แถว ป้องกัน Race Condition (การที่ผู้ใช้ 2 คนได้เลขที่ซ้ำกัน) ตาม Requirement 3.10.2
---
#### **11.2. v_current_correspondences (View)**
- **หน้าที่:** แสดง Revision "ปัจจุบัน" (is_current \= TRUE) ของ correspondences ทั้งหมด (ที่ไม่ใช่ RFA)
---
#### **11.3. v_current_rfas (View)**
- **หน้าที่:** แสดง Revision "ปัจจุบัน" (is_current \= TRUE) ของ rfa_revisions ทั้งหมด
---
#### **11.4. v_contract_parties_all (View)**
- **หน้าที่:** แสดงความสัมพันธ์ทั้งหมดระหว่าง Contract, Project, และ Organization
---
#### **11.5. v_user_tasks (View - ใหม่)**
**(ใหม่)**
- **หน้าที่:** แสดงรายการ "งานของฉัน" (My Tasks) ที่ยังไม่เสร็จ (ตาม Requirement 5.3)
- **ตรรกะ:** JOIN ตาราง circulations กับ circulation_assignees (ที่ is_completed \= FALSE)
---
#### **11.6. v_audit_log_details (View - ใหม่)**
**(ใหม่)**
- **หน้าที่:** แสดง audit_logs พร้อมข้อมูล username และ email ของผู้กระทำ
---
#### **11.7. v_user_all_permissions (View - ใหม่)**
**(ใหม่)**
- **หน้าที่:** รวมสิทธิ์ทั้งหมด (Global \+ Project) ของผู้ใช้ทุกคน เพื่อให้ Backend ตรวจสอบสิทธิ์ได้ง่าย
- **ตรรกะ:** UNION ข้อมูลจาก user_roles และ user_project_roles
---

110
docs/Markdown/icon.md Normal file
View File

@@ -0,0 +1,110 @@
```Icon
📂
🔐
⚙️
📦
🐞
🖥️
📊
💡
📄
💬
# 🎯 Icon Showcase for Documentation & Presentations
This document presents a curated set of emoji and image-based icons across multiple categories for use in Markdown files, presentations, and documentation.
---
## 📌 UI Icons
**Description:** Icons used for user interface elements such as settings, navigation, and interaction.
| Icon | Meaning |
|------|---------|
| ⚙️ | Settings |
| 🖱️ | Mouse Click |
| 📁 | Folder Navigation |
| 🔍 | Search |
| 📂 | Open Folder |
---
## 📌 Communication Icons
**Description:** Icons representing communication methods and tools.
| Icon | Meaning |
|------|---------|
| 📞 | Phone Call |
| ✉️ | Email |
| 💬 | Chat |
| 📢 | Announcement |
| 📡 | Signal |
---
## 📌 Technology Icons
**Description:** Icons related to devices, cloud services, and digital infrastructure.
| Icon | Meaning |
|------|---------|
| 💻 | Laptop |
| 🖥️ | Desktop |
| ☁️ | Cloud |
| 🔌 | Plug |
| 🧠 | AI / Intelligence |
---
## 📌 Productivity Icons
**Description:** Icons used to represent tasks, schedules, and progress.
| Icon | Meaning |
|------|---------|
| 📅 | Calendar |
| ✅ | Completed Task |
| ⏰ | Alarm / Reminder |
| 📊 | Statistics |
| 📝 | Notes |
---
## 📌 Creative Icons
**Description:** Icons representing artistic and creative activities.
| Icon | Meaning |
|------|---------|
| 🎨 | Art / Design |
| 🎬 | Video / Film |
| 🎵 | Music |
| ✏️ | Drawing / Writing |
| 📸 | Photography |
---
## 📌 Business Icons
**Description:** Icons used in business contexts such as finance, strategy, and management.
| Icon | Meaning |
|------|---------|
| 💼 | Briefcase |
| 📈 | Growth Chart |
| 📉 | Decline Chart |
| 🧾 | Invoice |
| 🏢 | Office Building |
---
## 📌 Education Icons
**Description:** Icons representing learning, teaching, and academic activities.
| Icon | Meaning |
|------|---------|
| 🎓 | Graduation |
| 📚 | Books |
| 🧑‍🏫 | Teacher |
| 📝 | Exam / Assignment |
| 🏫 | School |
---
```

134
docs/NestJS01.bak Normal file
View File

@@ -0,0 +1,134 @@
You are a senior TypeScript programmer with experience in the NestJS framework and a preference for clean programming and design patterns.
Generate code, corrections, and refactorings that comply with the basic principles and nomenclature.
## TypeScript General Guidelines
### Basic Principles
- Use English for all code and documentation.
- Always declare the type of each variable and function (parameters and return value).
- Avoid using any.
- Create necessary types.
- Use JSDoc to document public classes and methods.
- Don't leave blank lines within a function.
- One export per file.
### Nomenclature
- Use PascalCase for classes.
- Use camelCase for variables, functions, and methods.
- Use kebab-case for file and directory names.
- Use UPPERCASE for environment variables.
- Avoid magic numbers and define constants.
- Start each function with a verb.
- Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
- Use complete words instead of abbreviations and correct spelling.
- Except for standard abbreviations like API, URL, etc.
- Except for well-known abbreviations:
- i, j for loops
- err for errors
- ctx for contexts
- req, res, next for middleware function parameters
### Functions
- In this context, what is understood as a function will also apply to a method.
- Write short functions with a single purpose. Less than 20 instructions.
- Name functions with a verb and something else.
- If it returns a boolean, use isX or hasX, canX, etc.
- If it doesn't return anything, use executeX or saveX, etc.
- Avoid nesting blocks by:
- Early checks and returns.
- Extraction to utility functions.
- Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting.
- Use arrow functions for simple functions (less than 3 instructions).
- Use named functions for non-simple functions.
- Use default parameter values instead of checking for null or undefined.
- Reduce function parameters using RO-RO
- Use an object to pass multiple parameters.
- Use an object to return results.
- Declare necessary types for input arguments and output.
- Use a single level of abstraction.
### Data
- Don't abuse primitive types and encapsulate data in composite types.
- Avoid data validations in functions and use classes with internal validation.
- Prefer immutability for data.
- Use readonly for data that doesn't change.
- Use as const for literals that don't change.
### Classes
- Follow SOLID principles.
- Prefer composition over inheritance.
- Declare interfaces to define contracts.
- Write small classes with a single purpose.
- Less than 200 instructions.
- Less than 10 public methods.
- Less than 10 properties.
### Exceptions
- Use exceptions to handle errors you don't expect.
- If you catch an exception, it should be to:
- Fix an expected problem.
- Add context.
- Otherwise, use a global handler.
### Testing
- Follow the Arrange-Act-Assert convention for tests.
- Name test variables clearly.
- Follow the convention: inputX, mockX, actualX, expectedX, etc.
- Write unit tests for each public function.
- Use test doubles to simulate dependencies.
- Except for third-party dependencies that are not expensive to execute.
- Write acceptance tests for each module.
- Follow the Given-When-Then convention.
## Specific to NestJS
### Basic Principles
- Use modular architecture.
- Encapsulate the API in modules.
- One module per main domain/route.
- One controller for its route.
- And other controllers for secondary routes.
- A models folder with data types.
- DTOs validated with class-validator for inputs.
- Declare simple types for outputs.
- A services module with business logic and persistence.
- Entities with MikroORM for data persistence.
- One service per entity.
- Common Module: Create a common module (e.g., @app/common) for shared, reusable code across the application.
- This module should include:
- Configs: Global configuration settings.
- Decorators: Custom decorators for reusability.
- DTOs: Common data transfer objects.
- Guards: Guards for role-based or permission-based access control.
- Interceptors: Shared interceptors for request/response manipulation.
- Notifications: Modules for handling app-wide notifications.
- Services: Services that are reusable across modules.
- Types: Common TypeScript types or interfaces.
- Utils: Helper functions and utilities.
- Validators: Custom validators for consistent input validation.
- Core module functionalities:
- Global filters for exception handling.
- Global middlewares for request management.
- Guards for permission management.
- Interceptors for request processing.
### Testing
- Use the standard Jest framework for testing.
- Write tests for each controller and service.
- Write end to end tests for each api module.
- Add a admin/test method to each controller as a smoke test.

33
docs/NextJS01.bak Normal file
View File

@@ -0,0 +1,33 @@
You are a Senior Front-End Developer and an Expert in ReactJS, NextJS, JavaScript, TypeScript, HTML, CSS and modern UI/UX frameworks (e.g., TailwindCSS, Shadcn, Radix). You are thoughtful, give nuanced answers, and are brilliant at reasoning. You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning.
- Follow the users requirements carefully & to the letter.
- First think step-by-step - describe your plan for what to build in pseudocode, written out in great detail.
- Confirm, then write code!
- Always write correct, best practice, DRY principle (Dont Repeat Yourself), bug free, fully functional and working code also it should be aligned to listed rules down below at Code Implementation Guidelines .
- Focus on easy and readability code, over being performant.
- Fully implement all requested functionality.
- Leave NO todos, placeholders or missing pieces.
- Ensure code is complete! Verify thoroughly finalised.
- Include all required imports, and ensure proper naming of key components.
- Be concise Minimize any other prose.
- If you think there might not be a correct answer, you say so.
- If you do not know the answer, say so, instead of guessing.
### Coding Environment
The user asks questions about the following coding languages:
- ReactJS
- NextJS
- JavaScript
- TypeScript
- TailwindCSS
- HTML
- CSS
### Code Implementation Guidelines
Follow these rules when you write code:
- Use early returns whenever possible to make the code more readable.
- Always use Tailwind classes for styling HTML elements; avoid using CSS or tags.
- Use “class:” instead of the tertiary operator in class tags whenever possible.
- Use descriptive variable and function/const names. Also, event functions should be named with a “handle” prefix, like “handleClick” for onClick and “handleKeyDown” for onKeyDown.
- Implement accessibility features on elements. For example, a tag should have a tabindex=“0”, aria-label, on:click, and on:keydown, and similar attributes.
- Use consts instead of functions, for example, “const toggle = () =>”. Also, define a type if possible.

View File

@@ -0,0 +1,162 @@
# **🌳 โครงสร้างไฟล์และโฟลเดอร์ทั้งหมด \- DMS v1.3.0 Backend**
DMS\_Backend\_Project/
├── Dockerfile
├── docker-compose.yml
├── nest-cli.json
├── package.json
├── tsconfig.json
└── src/
├── app.module.ts
├── main.ts
├── common/
│ ├── common.module.ts
│ ├── audit-log/
│ │ ├── audit-log.interceptor.ts
│ │ └── audit-log.service.ts
│ ├── auth/
│ │ ├── auth.controller.ts
│ │ ├── auth.module.ts
│ │ ├── auth.service.spec.ts
│ │ ├── auth.service.ts
│ │ ├── decorators/
│ │ │ ├── current-user.decorator.ts
│ │ │ └── require-permission.decorator.ts
│ │ ├── dto/
│ │ │ └── login.dto.ts
│ │ ├── guards/
│ │ │ ├── rbac.guard.spec.ts
│ │ │ └── rbac.guard.ts
│ │ └── strategies/
│ │ └── jwt.strategy.ts
│ ├── config/
│ │ └── typeorm.config.ts (ตามที่ระบุใน app.module)
│ ├── entities/
│ │ ├── attachment.entity.ts
│ │ ├── audit-log.entity.ts
│ │ ├── circulation-action.entity.ts
│ │ ├── circulation-assignee.entity.ts
│ │ ├── circulation-attachment.entity.ts
│ │ ├── circulation-recipient.entity.ts
│ │ ├── circulation-status-code.entity.ts
│ │ ├── circulation.entity.ts
│ │ ├── contract-drawing-attachment.entity.ts
│ │ ├── contract-drawing-category.entity.ts
│ │ ├── contract-drawing-sub-category.entity.ts
│ │ ├── contract-drawing-volume.entity.ts
│ │ ├── contract-drawing.entity.ts
│ │ ├── correspondence-attachment.entity.ts
│ │ ├── correspondence-recipient.entity.ts
│ │ ├── correspondence-revision.entity.ts
│ │ ├── correspondence-status.entity.ts
│ │ ├── correspondence-type.entity.ts
│ │ ├── correspondence.entity.ts
│ │ ├── document-number-counter.entity.ts
│ │ ├── document-number-format.entity.ts
│ │ ├── permission.entity.ts
│ │ ├── rfa-approve-code.entity.ts
│ │ ├── rfa-item.entity.ts
│ │ ├── rfa-revision.entity.ts
│ │ ├── rfa-status-code.entity.ts
│ │ ├── rfa-type.entity.ts
│ │ ├── rfa.entity.ts
│ │ ├── role.entity.ts
│ │ ├── shop-drawing-main-category.entity.ts
│ │ ├── shop-drawing-revision-attachment.entity.ts
│ │ ├── shop-drawing-revision-contract-ref.entity.ts
│ │ ├── shop-drawing-revision.entity.ts
│ │ ├── shop-drawing-sub-category.entity.ts
│ │ ├── shop-drawing.entity.ts
│ │ ├── tag.entity.ts
│ │ ├── transmittal-item.entity.ts
│ │ ├── transmittal.entity.ts
│ │ ├── user.entity.ts
│ │ └── views/
│ │ ├── view-current-correspondence.entity.ts
│ │ └── view-current-rfa.entity.ts
│ ├── exceptions/
│ │ └── http-exception.filter.ts
│ ├── file-storage/
│ │ ├── file-storage.service.ts
│ │ └── file.controller.ts
│ └── security/
│ └── rate-limiter.module.ts
└── modules/
├── caching/
│ └── caching.module.ts
├── circulation/
│ ├── circulation.controller.ts
│ ├── circulation.module.ts
│ ├── circulation.service.ts
│ └── dto/
│ ├── add-action.dto.ts
│ ├── assignee.dto.ts
│ ├── attachment.dto.ts
│ ├── create-circulation.dto.ts
│ └── recipient.dto.ts
├── correspondence/
│ ├── correspondence.controller.ts
│ ├── correspondence.module.ts
│ ├── correspondence.service.ts
│ └── dto/
│ ├── create-correspondence.dto.ts
│ └── query-correspondence.dto.ts
├── document-numbering/
│ ├── admin-numbering.controller.ts
│ ├── document-numbering.module.ts
│ ├── document-numbering.service.ts
│ └── dto/
│ ├── admin-create-number-format.dto.ts
│ └── admin-update-number-format.dto.ts
├── drawing/
│ ├── drawing.controller.ts
│ ├── drawing.module.ts
│ ├── drawing.service.ts
│ └── dto/
│ ├── attachment.dto.ts
│ ├── create-contract-drawing.dto.ts
│ ├── create-shop-drawing-revision.dto.ts
│ └── create-shop-drawing.dto.ts
├── health/
│ ├── health.controller.ts
│ └── health.module.ts
├── master-data/
│ ├── admin-master-data.controller.ts
│ ├── master-data.module.ts
│ ├── master-data.service.ts
│ └── dto/
│ └── create-tag.dto.ts
├── notification/
│ ├── notification.module.ts
│ └── notification.service.ts
├── project/
│ └── (ยังไม่ได้สร้างไฟล์)
├── rfa/
│ ├── rfa.controller.ts
│ ├── rfa.module.ts
│ ├── rfa.service.ts
│ └── dto/
│ └── create-rfa.dto.ts
├── search/
│ ├── search.controller.ts
│ ├── search.module.ts
│ ├── search.service.ts
│ └── dto/
│ └── advanced-search.dto.ts
├── transmittal/
│ ├── transmittal.controller.ts
│ ├── transmittal.module.ts
│ ├── transmittal.service.ts
│ └── dto/
│ ├── create-transmittal-item.dto.ts
│ └── create-transmittal.dto.ts
└── user/
├── admin-roles.controller.ts
├── admin-users.controller.ts
├── roles.service.ts
├── user.module.ts
├── user.service.ts
└── dto/
├── admin-assign-permissions.dto.ts
├── admin-create-role.dto.ts
└── admin-create-user.dto.ts

View File

@@ -0,0 +1,100 @@
# **🗂️ สรุปโครงสร้างไฟล์และโฟลเดอร์ (Backend NestJS) \- DMS v1.3.0**
นี่คือภาพรวมสถาปัตยกรรมโฟลเดอร์ทั้งหมดของโปรเจกต์ NestJS API ที่เราได้พัฒนาขึ้น โดยแบ่งตามหลักการ Separation of Concerns
## **📂 (Root) โฟลเดอร์หลักของโปรเจกต์**
ไฟล์เหล่านี้จะอยู่ที่ระดับบนสุดของโปรเจกต์ (นอก src/)
* Dockerfile
* **หน้าที่:** คำสั่งสำหรับ Build Docker Image (Multi-stage build) เพื่อนำไป Deploy
* docker-compose.yml
* **หน้าที่:** ไฟล์ตั้งค่าสำหรับ QNAP Container Station ใช้กำหนด Services, Networks, และ (สำคัญที่สุด) Environment Variables (เช่น DATABASE\_HOST, JWT\_SECRET)
* package.json
* **หน้าที่:** เก็บรายการ Dependencies ทั้งหมด (เช่น @nestjs/core, typeorm, bcrypt, @nestjs/elasticsearch)
* .gitignore, tsconfig.json, nest-cli.json
* **หน้าที่:** ไฟล์ตั้งค่าพื้นฐานของโปรเจกต์ TypeScript และ NestJS
## **📂 src/ (Source Code)**
นี่คือหัวใจหลักของแอปพลิเคชัน
### **1\. src/ (Root Files)**
* main.ts
* **หน้าที่:** จุดเริ่มต้น (Entry Point) ของแอปพลิเคชัน
* **การตั้งค่า:**
* ใช้ helmet() (Security)
* ใช้ RateLimiterGuard (Security)
* ใช้ ValidationPipe (Global Pipe สำหรับ DTO)
* ใช้ HttpExceptionFilter (Global Filter สำหรับ Error Handling)
* ตั้งค่า SwaggerModule (สำหรับสร้าง API Docs)
* ตั้งค่า Global Prefix (/api/v1)
* app.module.ts
* **หน้าที่:** โมดูลหลัก (Root Module)
* **การตั้งค่า:**
* Import ConfigModule (สำหรับ .env)
* Import TypeOrmModule (เชื่อมต่อฐานข้อมูล)
* **Import โมดูลหลักและโมดูล Feature ทั้งหมด** (เช่น CommonModule, UserModule, CorrespondenceModule, SearchModule ฯลฯ)
### **2\. src/common/ (The Foundation)**
โฟลเดอร์นี้คือ "รากฐาน" เก็บโค้ดที่โมดูลอื่นต้องใช้ร่วมกัน (Shared Logic)
* common.module.ts
* **หน้าที่:** ไฟล์ที่รวบรวมและ export Service/Module ทั้งหมดใน common/ ให้โมดูลอื่นเรียกใช้ง่ายๆ
* auth/
* **หน้าที่:** จัดการการยืนยันตัวตน (Authentication) และสิทธิ์ (RBAC)
* auth.module.ts, auth.service.ts, auth.controller.ts (สำหรับ /login, /me)
* strategies/jwt.strategy.ts (ตรรกะการถอดรหัส JWT)
* guards/rbac.guard.ts (ตัวตรวจสอบสิทธิ์ RBACGuard)
* decorators/require-permission.decorator.ts (@RequirePermission)
* decorators/current-user.decorator.ts (@CurrentUser)
* entities/
* **หน้าที่:** **ศูนย์รวม Entities ทั้งหมด (44+ ไฟล์)** ที่ Map กับตารางใน MariaDB
* เช่น user.entity.ts, role.entity.ts, correspondence.entity.ts, rfa.entity.ts, shop-drawing.entity.ts, circulation.entity.ts, attachment.entity.ts, audit-log.entity.ts ฯลฯ
* views/: โฟลเดอร์ย่อยสำหรับ View Entities (เช่น view-current-correspondence.entity.ts)
* config/
* **หน้าที่:** เก็บ Config ที่ซับซ้อน เช่น typeorm.config.ts (ตั้งค่าการเชื่อมต่อ TypeORM)
* exceptions/
* http-exception.filter.ts (Global Error Handler)
* file-storage/
* file-storage.service.ts (Logic การบันทึกไฟล์ลง Disk)
* file.controller.ts (API Endpoint /files/upload)
* audit-log/
* audit-log.service.ts (Service บันทึก Log)
* audit-log.interceptor.ts (Interceptor ดักจับการกระทำ)
* security/
* rate-limiter.module.ts (ตั้งค่า Rate Limiting)
### **3\. src/modules/ (The Features)**
โฟลเดอร์นี้เก็บ "Business Logic" โดยแยกเป็น Feature Modules อย่างชัดเจน
* user/ (Phase 1\)
* **หน้าที่:** API สำหรับ Admin Panel (จัดการ Users, Roles, Permissions)
* admin-users.controller.ts, admin-roles.controller.ts, user.service.ts, roles.service.ts
* project/ (Phase 2\)
* **หน้าที่:** API สำหรับจัดการโปรเจกต์ (ยังไม่ได้สร้างไฟล์ แต่มีในแผน)
* document-numbering/ (Phase 2\)
* **หน้าที่:** API สำหรับ Admin (ตั้งค่า Format เลขที่) และ Service (generateNextDocumentNumber)
* master-data/ (Phase 2\)
* **หน้าที่:** API สำหรับ Admin (จัดการ Master Data เช่น Tags, RFA Types, Corr. Types)
* correspondence/ (Phase 2\)
* **หน้าที่:** Logic หลักในการสร้าง/ค้นหา เอกสารโต้ตอบ
* rfa/ (Phase 3\)
* **หน้าที่:** Logic หลักในการสร้าง/ค้นหา เอกสารขออนุมัติ (RFA)
* drawing/ (Phase 3\)
* **หน้าที่:** Logic หลักในการสร้าง/ค้นหา แบบแปลน (Contract & Shop Drawing)
* circulation/ (Phase 3\)
* **หน้าที่:** Logic หลักในการสร้าง/ค้นหา ใบเวียนภายใน
* transmittal/ (Phase 3\)
* **หน้าที่:** Logic หลักในการสร้าง/ค้นหา เอกสารนำส่ง
* search/ (Phase 4\)
* **หน้าที่:** API (/search) และ Service ที่เชื่อมต่อกับ Elasticsearch
* notification/ (Phase 4\)
* **หน้าที่:** Service สำหรับยิง Webhook ไปยัง N8N
* caching/ (Phase 4\)
* **หน้าที่:** โมดูลตั้งค่า Caching (Global)
* health/ (Phase 5 \- Deploy)
* **หน้าที่:** API (/health) สำหรับ Health Check

File diff suppressed because it is too large Load Diff

1565
docs/SQL/01_dms_v1_0_0.sql Normal file

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,40 @@
-- ==========================================================
-- DMS v1.0.1 Patch
-- Reason: Add missing relationship for Req 2.5.3
-- Update: Changed link to revision-level instead of master-level based on clarification.
-- ==========================================================
SET NAMES utf8mb4;
SET time_zone = '+07:00';
SET FOREIGN_KEY_CHECKS=1;
-- สร้างตารางเชื่อมระหว่าง shop_drawing_revisions (ตารางลูก) กับ contract_drawings (Master)
-- เพื่อรองรับ Requirement 2.5.3 ที่ระบุว่า Shop Drawing "แต่ละ revision" สามารถอ้างอิง Contract Drawing ที่แตกต่างกันได้
CREATE TABLE shop_drawing_revision_contract_refs (
shop_drawing_revision_id INT NOT NULL COMMENT 'ID ของ Shop Drawing Revision (FK -> shop_drawing_revisions.id)',
contract_drawing_id INT NOT NULL COMMENT 'ID ของ Contract Drawing ที่อ้างอิง (FK -> contract_drawings.condwg_id)',
-- PRIMARY KEY (shop_drawing_revision_id, contract_drawing_id),
-- เพิ่ม KEY เพื่อประสิทธิภาพในการค้นหา
KEY idx_sdrcr_rev (shop_drawing_revision_id),
KEY idx_sdrcr_cd (contract_drawing_id),
-- Foreign Keys
CONSTRAINT fk_sdrcr_revision
FOREIGN KEY (shop_drawing_revision_id)
REFERENCES shop_drawing_revisions(id) -- เชื่อมโยงกับตาราง Revision
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT fk_sdrcr_contract_drawing
FOREIGN KEY (contract_drawing_id)
REFERENCES contract_drawings(condwg_id)
ON DELETE CASCADE
ON UPDATE CASCADE
)
ENGINE=InnoDB
DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_general_ci
COMMENT='ตารางเชื่อมโยง Shop Drawing Revisions กับ Contract Drawings (Req 2.5.3)';

1537
docs/SQL/01_dms_v1_0_1.sql Normal file

File diff suppressed because it is too large Load Diff

1603
docs/SQL/01_lcbp3_v1_1_0.sql Normal file

File diff suppressed because it is too large Load Diff

1660
docs/SQL/01_lcbp3_v1_1_1.sql Normal file

File diff suppressed because it is too large Load Diff

1877
docs/SQL/01_lcbp3_v1_2_0.sql Normal file

File diff suppressed because it is too large Load Diff

1870
docs/SQL/01_lcbp3_v1_3_0.sql Normal file

File diff suppressed because it is too large Load Diff

1870
docs/SQL/01_lcbp3_v1_3_0.txt Normal file

File diff suppressed because it is too large Load Diff

1923
docs/SQL/01_lcbp3_v1_4_0.sql Normal file

File diff suppressed because it is too large Load Diff

1923
docs/SQL/01_lcbp3_v1_4_0.txt Normal file

File diff suppressed because it is too large Load Diff

385
docs/SQL/Cluad.sql Normal file
View File

@@ -0,0 +1,385 @@
-- ปรับปรุงโครงสร้าง Correspondence เพื่อจัดการ Revisions ได้ดีขึ้น
-- 1. แยก Master และ Revision ชัดเจน
CREATE TABLE correspondence_master (
master_id INT AUTO_INCREMENT PRIMARY KEY,
correspondence_number VARCHAR(100) NOT NULL,
project_id INT NOT NULL,
correspondence_type_id INT NOT NULL,
-- Metadata ที่ไม่เปลี่ยนแปลงตาม Revision
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
created_by INT NULL,
deleted_at DATETIME NULL,
-- Track current/latest revision
current_revision_id INT NULL,
latest_revision_number INT NOT NULL DEFAULT 0,
CONSTRAINT uq_corr_no_per_project UNIQUE (project_id, correspondence_number),
CONSTRAINT fk_cm_project FOREIGN KEY (project_id)
REFERENCES projects(project_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_cm_type FOREIGN KEY (correspondence_type_id)
REFERENCES correspondence_types(type_id) ON UPDATE CASCADE ON DELETE RESTRICT,
CONSTRAINT fk_cm_created_by FOREIGN KEY (created_by)
REFERENCES users(user_id) ON UPDATE CASCADE ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 2. Revision ที่เก็บข้อมูลที่เปลี่ยนแปลงได้
CREATE TABLE correspondence_revisions_new (
revision_id INT AUTO_INCREMENT PRIMARY KEY,
master_id INT NOT NULL,
revision_number INT NOT NULL, -- เปลี่ยนเป็น INT เพื่อง่ายต่อการเรียงลำดับ
revision_label VARCHAR(10) NULL, -- A, B, C สำหรับแสดงผล
-- สถานะเฉพาะของ Revision นี้
correspondence_status_id INT NOT NULL,
is_current BOOLEAN NOT NULL DEFAULT FALSE,
-- ข้อมูลที่เปลี่ยนแปลงตาม Revision
originator_id INT NULL,
recipient_id INT NULL,
title VARCHAR(255) NOT NULL,
keywords VARCHAR(255) NULL,
issued_date DATETIME NULL,
pdf_path VARCHAR(500) NULL,
details JSON NULL,
-- Audit
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
created_by INT NULL,
change_reason TEXT NULL,
CONSTRAINT uq_master_revision_number UNIQUE (master_id, revision_number),
CONSTRAINT uq_master_current UNIQUE (master_id, is_current), -- ใช้ partial unique index ได้ดีกว่า
CONSTRAINT fk_cr_master FOREIGN KEY (master_id)
REFERENCES correspondence_master(master_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_cr_status FOREIGN KEY (correspondence_status_id)
REFERENCES correspondence_status(status_id) ON UPDATE CASCADE ON DELETE RESTRICT,
CONSTRAINT fk_cr_originator FOREIGN KEY (originator_id)
REFERENCES organizations(org_id) ON UPDATE CASCADE ON DELETE SET NULL,
CONSTRAINT fk_cr_recipient FOREIGN KEY (recipient_id)
REFERENCES organizations(org_id) ON UPDATE CASCADE ON DELETE SET NULL,
CONSTRAINT fk_cr_created_by FOREIGN KEY (created_by)
REFERENCES users(user_id) ON UPDATE CASCADE ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 3. Update current_revision_id FK
ALTER TABLE correspondence_master
ADD CONSTRAINT fk_cm_current_revision
FOREIGN KEY (current_revision_id)
REFERENCES correspondence_revisions_new(revision_id)
ON UPDATE CASCADE ON DELETE SET NULL;
-- 4. View สำหรับ Query ง่าย (รวม Master + Current Revision)
CREATE OR REPLACE VIEW v_current_correspondences AS
SELECT
cm.master_id,
cm.correspondence_number,
cm.project_id,
cm.correspondence_type_id,
cr.revision_id,
cr.revision_number,
cr.revision_label,
cr.correspondence_status_id,
cr.title,
cr.keywords,
cr.originator_id,
cr.recipient_id,
cr.issued_date,
cr.pdf_path,
cr.details,
cm.created_at AS master_created_at,
cr.created_at AS revision_created_at,
cm.latest_revision_number
FROM correspondence_master cm
INNER JOIN correspondence_revisions_new cr
ON cm.current_revision_id = cr.revision_id
WHERE cm.deleted_at IS NULL;
-- 5. Stored Procedure สำหรับสร้าง Revision ใหม่
DELIMITER $$
CREATE PROCEDURE sp_create_correspondence_revision(
IN p_master_id INT,
IN p_title VARCHAR(255),
IN p_originator_id INT,
IN p_recipient_id INT,
IN p_status_id INT,
IN p_created_by INT,
IN p_change_reason TEXT,
OUT p_revision_id INT
)
BEGIN
DECLARE v_next_revision_number INT;
DECLARE v_revision_label VARCHAR(10);
-- Get next revision number
SELECT COALESCE(MAX(revision_number), 0) + 1
INTO v_next_revision_number
FROM correspondence_revisions_new
WHERE master_id = p_master_id;
-- Generate label (0->Original, 1->A, 2->B, etc.)
IF v_next_revision_number = 0 THEN
SET v_revision_label = 'Original';
ELSE
SET v_revision_label = CHAR(64 + v_next_revision_number); -- A, B, C...
END IF;
-- Mark all previous revisions as not current
UPDATE correspondence_revisions_new
SET is_current = FALSE
WHERE master_id = p_master_id;
-- Insert new revision
INSERT INTO correspondence_revisions_new (
master_id, revision_number, revision_label,
correspondence_status_id, is_current,
title, originator_id, recipient_id,
created_by, change_reason
) VALUES (
p_master_id, v_next_revision_number, v_revision_label,
p_status_id, TRUE,
p_title, p_originator_id, p_recipient_id,
p_created_by, p_change_reason
);
SET p_revision_id = LAST_INSERT_ID();
-- Update master
UPDATE correspondence_master
SET
current_revision_id = p_revision_id,
latest_revision_number = v_next_revision_number
WHERE master_id = p_master_id;
END$$
DELIMITER ;
-- *****************************************************
-- *****************************************************
-- *****************************************************
-- *****************************************************
-- *****************************************************
-- *****************************************************
-- ปรับปรุง Technical Documents เพื่อความชัดเจนและเชื่อมโยงกับ Correspondence
-- 1. Technical Document Master
CREATE TABLE technical_document_master (
master_id INT AUTO_INCREMENT PRIMARY KEY,
document_number VARCHAR(100) NOT NULL,
document_type_id INT NOT NULL,
project_id INT NOT NULL,
title VARCHAR(255) NOT NULL,
-- Link to RFA Correspondence (optional - เพราะอาจยังไม่ได้ส่ง RFA)
rfa_correspondence_id INT NULL,
-- Tracking
current_revision_id INT NULL,
latest_revision_number INT NOT NULL DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
created_by INT NULL,
deleted_at DATETIME NULL,
CONSTRAINT uq_techdoc_no_project UNIQUE (project_id, document_number),
CONSTRAINT fk_tdm_type FOREIGN KEY (document_type_id)
REFERENCES technicaldoc_types(document_types_id),
CONSTRAINT fk_tdm_project FOREIGN KEY (project_id)
REFERENCES projects(project_id) ON DELETE CASCADE,
CONSTRAINT fk_tdm_rfa_corr FOREIGN KEY (rfa_correspondence_id)
REFERENCES correspondences(corr_id) ON DELETE SET NULL,
CONSTRAINT fk_tdm_created_by FOREIGN KEY (created_by)
REFERENCES users(user_id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 2. Technical Document Revisions
CREATE TABLE technical_document_revisions (
revision_id INT AUTO_INCREMENT PRIMARY KEY,
master_id INT NOT NULL,
revision_number INT NOT NULL,
revision_label VARCHAR(10) NULL, -- A, B, C
status_code_id INT NOT NULL,
approve_code_id INT NULL,
is_current BOOLEAN NOT NULL DEFAULT FALSE,
-- File references
pdf_path VARCHAR(500) NULL,
dwg_path VARCHAR(500) NULL, -- สำหรับ DWG type
-- Metadata
revision_description TEXT NULL,
submitted_date DATE NULL,
approved_date DATE NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
created_by INT NULL,
updated_by INT NULL,
CONSTRAINT uq_master_rev_number UNIQUE (master_id, revision_number),
CONSTRAINT fk_tdr_master FOREIGN KEY (master_id)
REFERENCES technical_document_master(master_id) ON DELETE CASCADE,
CONSTRAINT fk_tdr_status FOREIGN KEY (status_code_id)
REFERENCES technicaldoc_status_codes(status_code_id),
CONSTRAINT fk_tdr_approve FOREIGN KEY (approve_code_id)
REFERENCES technicaldoc_approve_codes(approve_code_id) ON DELETE SET NULL,
CONSTRAINT fk_tdr_created_by FOREIGN KEY (created_by)
REFERENCES users(user_id) ON DELETE SET NULL,
CONSTRAINT fk_tdr_updated_by FOREIGN KEY (updated_by)
REFERENCES users(user_id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 3. Shop Drawing References (Many-to-Many with Revisions)
CREATE TABLE technical_document_shop_drawing_refs (
tech_doc_revision_id INT NOT NULL,
shop_drawing_rev_id INT NOT NULL,
reference_type ENUM('SUPERSEDES', 'RELATED', 'AS_PER') DEFAULT 'RELATED',
PRIMARY KEY (tech_doc_revision_id, shop_drawing_rev_id),
CONSTRAINT fk_tdsdr_tech_doc FOREIGN KEY (tech_doc_revision_id)
REFERENCES technical_document_revisions(revision_id) ON DELETE CASCADE,
CONSTRAINT fk_tdsdr_shop_dwg FOREIGN KEY (shop_drawing_rev_id)
REFERENCES shop_drawing_revisions(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 4. Contract Drawing References (Many-to-Many)
CREATE TABLE technical_document_contract_drawing_refs (
tech_doc_revision_id INT NOT NULL,
contract_drawing_id INT NOT NULL,
reference_type ENUM('AS_PER', 'RELATED') DEFAULT 'AS_PER',
sheet_numbers VARCHAR(255) NULL, -- "Sheet 1-5, 10" เก็บเป็น text
PRIMARY KEY (tech_doc_revision_id, contract_drawing_id),
CONSTRAINT fk_tdcdr_tech_doc FOREIGN KEY (tech_doc_revision_id)
REFERENCES technical_document_revisions(revision_id) ON DELETE CASCADE,
CONSTRAINT fk_tdcdr_contract_dwg FOREIGN KEY (contract_drawing_id)
REFERENCES contract_drawings(condwg_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 5. ปรับปรุง RFA Workflow ให้ชัดเจนขึ้น
CREATE TABLE rfa_workflow_instances (
workflow_id INT AUTO_INCREMENT PRIMARY KEY,
rfa_correspondence_id INT NOT NULL UNIQUE,
template_id INT NULL, -- อ้างอิงถึงแม่แบบที่ใช้
current_step_sequence INT NOT NULL DEFAULT 1,
overall_status ENUM('DRAFT', 'IN_PROGRESS', 'APPROVED', 'REJECTED', 'RETURNED', 'CANCELLED')
NOT NULL DEFAULT 'DRAFT',
started_at DATETIME NULL,
completed_at DATETIME NULL,
CONSTRAINT fk_rwi_corr FOREIGN KEY (rfa_correspondence_id)
REFERENCES correspondences(corr_id) ON DELETE CASCADE,
CONSTRAINT fk_rwi_template FOREIGN KEY (template_id)
REFERENCES technicaldoc_workflow_templates(template_id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 6. RFA Workflow Steps (แยกจาก technicaldoc_workflows เดิม)
CREATE TABLE rfa_workflow_steps (
step_id INT AUTO_INCREMENT PRIMARY KEY,
workflow_id INT NOT NULL,
sequence INT NOT NULL,
org_id INT NOT NULL,
step_purpose ENUM('FOR_APPROVAL', 'FOR_REVIEW', 'FOR_INFORMATION')
NOT NULL DEFAULT 'FOR_APPROVAL',
status ENUM('PENDING', 'ACTIVE', 'APPROVED', 'REJECTED',
'APPROVED_WITH_COMMENTS', 'SKIPPED', 'RETURNED')
NOT NULL DEFAULT 'PENDING',
approve_code_id INT NULL, -- Link to approve codes
comments TEXT NULL,
activated_at DATETIME NULL,
processed_at DATETIME NULL,
processed_by_user_id INT NULL,
deadline_date DATE NULL,
CONSTRAINT uq_workflow_sequence UNIQUE (workflow_id, sequence),
CONSTRAINT fk_rws_workflow FOREIGN KEY (workflow_id)
REFERENCES rfa_workflow_instances(workflow_id) ON DELETE CASCADE,
CONSTRAINT fk_rws_org FOREIGN KEY (org_id)
REFERENCES organizations(org_id),
CONSTRAINT fk_rws_approve_code FOREIGN KEY (approve_code_id)
REFERENCES technicaldoc_approve_codes(approve_code_id),
CONSTRAINT fk_rws_user FOREIGN KEY (processed_by_user_id)
REFERENCES users(user_id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- 7. View: Current Technical Documents with Latest Revision
CREATE OR REPLACE VIEW v_current_technical_documents AS
SELECT
tdm.master_id,
tdm.document_number,
tdm.document_type_id,
dt.code AS document_type_code,
dt.name AS document_type_name,
tdm.project_id,
tdm.title,
tdm.rfa_correspondence_id,
tdr.revision_id,
tdr.revision_number,
tdr.revision_label,
tdr.status_code_id,
sc.code AS status_code,
sc.description AS status_description,
tdr.approve_code_id,
ac.code AS approve_code,
ac.description AS approve_description,
tdr.pdf_path,
tdr.dwg_path,
tdr.submitted_date,
tdr.approved_date,
tdm.created_at,
tdr.created_at AS revision_created_at
FROM technical_document_master tdm
INNER JOIN technical_document_revisions tdr
ON tdm.current_revision_id = tdr.revision_id
INNER JOIN technicaldoc_types dt
ON tdm.document_type_id = dt.document_types_id
LEFT JOIN technicaldoc_status_codes sc
ON tdr.status_code_id = sc.status_code_id
LEFT JOIN technicaldoc_approve_codes ac
ON tdr.approve_code_id = ac.approve_code_id
WHERE tdm.deleted_at IS NULL;
-- 8. View: RFA Workflow Status
CREATE OR REPLACE VIEW v_rfa_workflow_status AS
SELECT
rwi.workflow_id,
rwi.rfa_correspondence_id,
c.correspondence_number AS rfa_number,
rwi.overall_status,
rwi.current_step_sequence,
rws.step_id AS current_step_id,
rws.org_id AS current_org_id,
o.org_name AS current_org_name,
rws.status AS current_step_status,
rws.deadline_date,
rwi.started_at,
DATEDIFF(CURDATE(), rwi.started_at) AS days_in_progress,
(SELECT COUNT(*) FROM rfa_workflow_steps WHERE workflow_id = rwi.workflow_id) AS total_steps,
(SELECT COUNT(*) FROM rfa_workflow_steps WHERE workflow_id = rwi.workflow_id AND status IN ('APPROVED','APPROVED_WITH_COMMENTS')) AS completed_steps
FROM rfa_workflow_instances rwi
INNER JOIN correspondences c ON rwi.rfa_correspondence_id = c.corr_id
LEFT JOIN rfa_workflow_steps rws
ON rwi.workflow_id = rws.workflow_id
AND rwi.current_step_sequence = rws.sequence
LEFT JOIN organizations o ON rws.org_id = o.org_id
WHERE rwi.overall_status NOT IN ('CANCELLED', 'APPROVED');

215
docs/SQL/seed01.sql Normal file
View File

@@ -0,0 +1,215 @@
-- ==========================================================
-- DMS v0.5.0
-- Database v5.1 - Deploy Script Schema (Revised)
-- Server: Container Station on QNAP TS-473A
-- Database service: MariaDB 10.11
-- Notes:
-- - Removed 'rfas' table.
-- - Added 'contracts' and 'contract_parties' tables.
-- ==========================================================
SET NAMES utf8mb4;
SET time_zone = '+07:00';
SET FOREIGN_KEY_CHECKS=0;
-- Drop tables in reverse order of creation due to dependencies
DROP TABLE IF EXISTS audit_logs;
DROP TABLE IF EXISTS user_project_roles;
DROP TABLE IF EXISTS user_roles;
DROP TABLE IF EXISTS role_permissions;
DROP TABLE IF EXISTS permissions;
DROP TABLE IF EXISTS roles;
DROP TABLE IF EXISTS users;
DROP TABLE IF EXISTS project_parties;
DROP TABLE IF EXISTS contract_parties; -- New
DROP TABLE IF EXISTS contracts; -- New
DROP TABLE IF EXISTS projects;
DROP TABLE IF EXISTS organizations;
DROP TABLE IF EXISTS correspondence_references;
DROP TABLE IF EXISTS correspondence_cc_recipients;
DROP TABLE IF EXISTS correspondences;
DROP TABLE IF EXISTS email_details;
DROP TABLE IF EXISTS instruction_details;
DROP TABLE IF EXISTS letter_details;
DROP TABLE IF EXISTS memorandum_details;
DROP TABLE IF EXISTS minutes_of_meeting_details;
DROP TABLE IF EXISTS rfi_details;
DROP TABLE IF EXISTS rfa_items;
DROP TABLE IF EXISTS transmittal_items;
DROP TABLE IF EXISTS transmittals;
DROP TABLE IF EXISTS technicaldocs;
DROP TABLE IF EXISTS shop_drawing_revisions;
DROP TABLE IF EXISTS shop_drawings;
DROP TABLE IF EXISTS shop_drawing_sub_categories;
DROP TABLE IF EXISTS shop_drawing_main_categories;
DROP TABLE IF EXISTS contract_dwg_subcat_cat_map;
DROP TABLE IF EXISTS contract_dwg_sub_cat;
DROP TABLE IF EXISTS contract_dwg_cat;
DROP TABLE IF EXISTS contract_drawings;
DROP TABLE IF EXISTS cir_action_documents;
DROP TABLE IF EXISTS cir_actions;
DROP TABLE IF EXISTS cir_recipients;
DROP TABLE IF EXISTS circulations;
DROP TABLE IF EXISTS cir_status_codes;
DROP TABLE IF EXISTS correspondence_status_transitions;
DROP TABLE IF EXISTS correspondence_statuses;
DROP TABLE IF EXISTS correspondence_types;
DROP TABLE IF EXISTS correspondence_tags;
DROP TABLE IF EXISTS tags;
DROP TABLE IF EXISTS global_default_roles;
SET FOREIGN_KEY_CHECKS=1;
-- ==========================================================
-- Table Creation
-- ==========================================================
-- Organizations Table
CREATE TABLE organizations (
org_id INT NOT NULL AUTO_INCREMENT,
org_code VARCHAR(20) NOT NULL,
org_name VARCHAR(255) NOT NULL,
primary_role ENUM('OWNER','DESIGNER','CONSULTANT','CONTRACTOR') NULL,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (org_id),
UNIQUE KEY ux_organizations_code (org_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Projects Table
CREATE TABLE projects (
project_id INT NOT NULL AUTO_INCREMENT,
project_code VARCHAR(20) NOT NULL,
project_name VARCHAR(255) NOT NULL,
description TEXT,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (project_id),
UNIQUE KEY ux_projects_code (project_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- NEW: Contracts Table
-- Stores information about each contract.
CREATE TABLE contracts (
contract_id INT NOT NULL AUTO_INCREMENT,
contract_code VARCHAR(50) NOT NULL,
contract_name VARCHAR(255) NOT NULL,
description TEXT,
start_date DATE,
end_date DATE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (contract_id),
UNIQUE KEY ux_contracts_code (contract_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- NEW: Contract Parties Table
-- Links contracts, projects, and organizations together.
CREATE TABLE contract_parties (
contract_id INT NOT NULL,
project_id INT NOT NULL,
org_id INT NOT NULL,
PRIMARY KEY (contract_id, project_id, org_id),
CONSTRAINT fk_cp_contract FOREIGN KEY (contract_id) REFERENCES contracts(contract_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_cp_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_cp_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Users Table (RBAC)
CREATE TABLE users (
user_id INT NOT NULL AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
email VARCHAR(100) NOT NULL,
first_name VARCHAR(50),
last_name VARCHAR(50),
org_id INT,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
last_login TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
UNIQUE KEY ux_users_username (username),
UNIQUE KEY ux_users_email (email),
CONSTRAINT fk_users_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Roles Table (RBAC)
CREATE TABLE roles (
role_id INT NOT NULL AUTO_INCREMENT,
role_code VARCHAR(50) NOT NULL,
role_name VARCHAR(100) NOT NULL,
description TEXT,
is_system BOOLEAN NOT NULL DEFAULT FALSE,
PRIMARY KEY (role_id),
UNIQUE KEY ux_roles_code (role_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Permissions Table (RBAC)
CREATE TABLE permissions (
permission_id INT NOT NULL AUTO_INCREMENT,
permission_code VARCHAR(100) NOT NULL,
description TEXT,
PRIMARY KEY (permission_id),
UNIQUE KEY ux_permissions_code (permission_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Role Permissions Junction Table (RBAC)
CREATE TABLE role_permissions (
role_id INT NOT NULL,
permission_id INT NOT NULL,
PRIMARY KEY (role_id, permission_id),
CONSTRAINT fk_rp_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_rp_permission FOREIGN KEY (permission_id) REFERENCES permissions(permission_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- User Roles Junction Table (RBAC) - For global/system-level roles
CREATE TABLE user_roles (
user_id INT NOT NULL,
role_id INT NOT NULL,
PRIMARY KEY (user_id, role_id),
CONSTRAINT fk_ur_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_ur_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- User Project Roles Junction Table (RBAC) - For project-specific roles
CREATE TABLE user_project_roles (
user_id INT NOT NULL,
project_id INT NOT NULL,
role_id INT NOT NULL,
PRIMARY KEY (user_id, project_id, role_id),
CONSTRAINT fk_upr_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_upr_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_upr_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Project Parties Table
CREATE TABLE project_parties (
project_id INT NOT NULL,
org_id INT NOT NULL,
role ENUM('OWNER','DESIGNER','CONSULTANT','CONTRACTOR') NOT NULL,
is_contractor TINYINT(1) GENERATED ALWAYS AS (IF(role = 'CONTRACTOR', 1, NULL)) STORED,
PRIMARY KEY (project_id, org_id),
UNIQUE KEY uq_project_parties_contractor (project_id, is_contractor),
CONSTRAINT fk_pp_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_pp_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- ... (The rest of your original script for correspondences, technical docs, etc. remains here) ...
-- Global default roles (template defaults)
CREATE TABLE global_default_roles (
id TINYINT NOT NULL DEFAULT 1,
role ENUM('OWNER','DESIGNER','CONSULTANT') NOT NULL,
position TINYINT NOT NULL,
org_id INT NOT NULL,
PRIMARY KEY (id, role, position),
UNIQUE KEY ux_gdr_unique_org_per_role (id, role, org_id),
CONSTRAINT fk_gdr_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- ... (The rest of your original script continues from here) ...

316
docs/SQL/seed02.sql Normal file
View File

@@ -0,0 +1,316 @@
-- ==========================================================
-- DMS v0.5.0
-- Database v5.1 - Deploy Script Schema (Complete & Revised)
-- Server: Container Station on QNAP TS-473A
-- Database service: MariaDB 10.11
-- Notes:
-- - This is a consolidated and updated version.
-- - Removed 'rfas' table.
-- - Added tables for Contracts, detailed Circulations,
-- Technical Document Workflow, and Correspondence Revisions.
-- ==========================================================
SET NAMES utf8mb4;
SET time_zone = '+07:00';
SET FOREIGN_KEY_CHECKS=0;
-- Drop tables in reverse order of creation due to dependencies
DROP TABLE IF EXISTS audit_logs;
DROP TABLE IF EXISTS user_project_roles;
DROP TABLE IF EXISTS user_roles;
DROP TABLE IF EXISTS role_permissions;
DROP TABLE IF EXISTS permissions;
DROP TABLE IF EXISTS roles;
DROP TABLE IF EXISTS users;
DROP TABLE IF EXISTS project_parties;
DROP TABLE IF EXISTS contract_parties;
DROP TABLE IF EXISTS contracts;
DROP TABLE IF EXISTS projects;
DROP TABLE IF EXISTS organizations;
DROP TABLE IF EXISTS correspondence_references;
DROP TABLE IF EXISTS correspondence_revisions;
DROP TABLE IF EXISTS correspondence_cc_recipients;
DROP TABLE IF EXISTS technical_doc_workflows;
DROP TABLE IF EXISTS correspondences;
DROP TABLE IF EXISTS email_details;
DROP TABLE IF EXISTS instruction_details;
DROP TABLE IF EXISTS letter_details;
DROP TABLE IF EXISTS memorandum_details;
DROP TABLE IF EXISTS minutes_of_meeting_details;
DROP TABLE IF EXISTS rfi_details;
DROP TABLE IF EXISTS rfa_items;
DROP TABLE IF EXISTS transmittal_items;
DROP TABLE IF EXISTS transmittals;
DROP TABLE IF EXISTS technicaldocs;
DROP TABLE IF EXISTS shop_drawing_revisions;
DROP TABLE IF EXISTS shop_drawings;
DROP TABLE IF EXISTS shop_drawing_sub_categories;
DROP TABLE IF EXISTS shop_drawing_main_categories;
DROP TABLE IF EXISTS contract_dwg_subcat_cat_map;
DROP TABLE IF EXISTS contract_dwg_sub_cat;
DROP TABLE IF EXISTS contract_dwg_cat;
DROP TABLE IF EXISTS contract_drawings;
DROP TABLE IF EXISTS circulation_assignees;
DROP TABLE IF EXISTS circulations;
DROP TABLE IF EXISTS cir_action_documents;
DROP TABLE IF EXISTS cir_actions;
DROP TABLE IF EXISTS cir_recipients;
DROP TABLE IF EXISTS cir_status_codes;
DROP TABLE IF EXISTS correspondence_status_transitions;
DROP TABLE IF EXISTS correspondence_statuses;
DROP TABLE IF EXISTS correspondence_types;
DROP TABLE IF EXISTS correspondence_tags;
DROP TABLE IF EXISTS tags;
DROP TABLE IF EXISTS global_default_roles;
SET FOREIGN_KEY_CHECKS=1;
-- ==========================================================
-- Table Creation
-- ==========================================================
CREATE TABLE organizations (
org_id INT NOT NULL AUTO_INCREMENT,
org_code VARCHAR(20) NOT NULL,
org_name VARCHAR(255) NOT NULL,
primary_role ENUM('OWNER','DESIGNER','CONSULTANT','CONTRACTOR') NULL,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (org_id),
UNIQUE KEY ux_organizations_code (org_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE projects (
project_id INT NOT NULL AUTO_INCREMENT,
project_code VARCHAR(20) NOT NULL,
project_name VARCHAR(255) NOT NULL,
description TEXT,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (project_id),
UNIQUE KEY ux_projects_code (project_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE contracts (
contract_id INT NOT NULL AUTO_INCREMENT,
contract_code VARCHAR(50) NOT NULL,
contract_name VARCHAR(255) NOT NULL,
description TEXT,
start_date DATE,
end_date DATE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (contract_id),
UNIQUE KEY ux_contracts_code (contract_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE contract_parties (
contract_id INT NOT NULL,
project_id INT NOT NULL,
org_id INT NOT NULL,
PRIMARY KEY (contract_id, project_id, org_id),
CONSTRAINT fk_cp_contract FOREIGN KEY (contract_id) REFERENCES contracts(contract_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_cp_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_cp_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE users (
user_id INT NOT NULL AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
email VARCHAR(100) NOT NULL,
first_name VARCHAR(50),
last_name VARCHAR(50),
org_id INT,
is_active BOOLEAN NOT NULL DEFAULT TRUE,
last_login TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
UNIQUE KEY ux_users_username (username),
UNIQUE KEY ux_users_email (email),
CONSTRAINT fk_users_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE roles (
role_id INT NOT NULL AUTO_INCREMENT,
role_code VARCHAR(50) NOT NULL,
role_name VARCHAR(100) NOT NULL,
description TEXT,
is_system BOOLEAN NOT NULL DEFAULT FALSE,
PRIMARY KEY (role_id),
UNIQUE KEY ux_roles_code (role_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE permissions (
permission_id INT NOT NULL AUTO_INCREMENT,
permission_code VARCHAR(100) NOT NULL,
description TEXT,
PRIMARY KEY (permission_id),
UNIQUE KEY ux_permissions_code (permission_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE role_permissions (
role_id INT NOT NULL,
permission_id INT NOT NULL,
PRIMARY KEY (role_id, permission_id),
CONSTRAINT fk_rp_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_rp_permission FOREIGN KEY (permission_id) REFERENCES permissions(permission_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE user_roles (
user_id INT NOT NULL,
role_id INT NOT NULL,
PRIMARY KEY (user_id, role_id),
CONSTRAINT fk_ur_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_ur_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE user_project_roles (
user_id INT NOT NULL,
project_id INT NOT NULL,
role_id INT NOT NULL,
PRIMARY KEY (user_id, project_id, role_id),
CONSTRAINT fk_upr_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_upr_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_upr_role FOREIGN KEY (role_id) REFERENCES roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE project_parties (
project_id INT NOT NULL,
org_id INT NOT NULL,
role ENUM('OWNER','DESIGNER','CONSULTANT','CONTRACTOR') NOT NULL,
is_contractor TINYINT(1) GENERATED ALWAYS AS (IF(role = 'CONTRACTOR', 1, NULL)) STORED,
PRIMARY KEY (project_id, org_id),
UNIQUE KEY uq_project_parties_contractor (project_id, is_contractor),
CONSTRAINT fk_pp_project FOREIGN KEY (project_id) REFERENCES projects(project_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_pp_org FOREIGN KEY (org_id) REFERENCES organizations(org_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- Correspondence & Workflow Tables
CREATE TABLE correspondence_types (
type_id INT NOT NULL AUTO_INCREMENT,
type_code VARCHAR(20) NOT NULL,
type_name VARCHAR(100) NOT NULL,
PRIMARY KEY (type_id),
UNIQUE KEY ux_ct_code (type_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE correspondence_statuses (
status_id INT NOT NULL AUTO_INCREMENT,
status_code VARCHAR(20) NOT NULL,
status_name VARCHAR(100) NOT NULL,
PRIMARY KEY (status_id),
UNIQUE KEY ux_cs_code (status_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE correspondences (
id INT NOT NULL AUTO_INCREMENT,
project_id INT NOT NULL,
document_number VARCHAR(100) NOT NULL,
title VARCHAR(500) NOT NULL,
issue_date DATE NOT NULL,
status_id INT NOT NULL,
type_id INT NOT NULL,
originator_org_id INT NOT NULL,
created_by_user_id INT NOT NULL,
root_id INT NULL, -- for revisions
version INT NOT NULL DEFAULT 1,
submitted_at TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE KEY ux_corr_doc_num (document_number),
CONSTRAINT fk_corr_project FOREIGN KEY (project_id) REFERENCES projects(project_id),
CONSTRAINT fk_corr_status FOREIGN KEY (status_id) REFERENCES correspondence_statuses(status_id),
CONSTRAINT fk_corr_type FOREIGN KEY (type_id) REFERENCES correspondence_types(type_id),
CONSTRAINT fk_corr_org FOREIGN KEY (originator_org_id) REFERENCES organizations(org_id),
CONSTRAINT fk_corr_user FOREIGN KEY (created_by_user_id) REFERENCES users(user_id),
CONSTRAINT fk_corr_root FOREIGN KEY (root_id) REFERENCES correspondences(id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE correspondence_revisions (
revision_id INT NOT NULL AUTO_INCREMENT,
correspondence_id INT NOT NULL,
version_number INT NOT NULL,
change_reason TEXT NOT NULL,
changed_by_user_id INT NOT NULL,
changed_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
document_data_json JSON NOT NULL,
PRIMARY KEY (revision_id),
CONSTRAINT fk_cr_correspondence FOREIGN KEY (correspondence_id) REFERENCES correspondences(id) ON DELETE CASCADE,
CONSTRAINT fk_cr_user FOREIGN KEY (changed_by_user_id) REFERENCES users(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE cir_status_codes (
code VARCHAR(20) NOT NULL,
description VARCHAR(255),
sort_order INT NOT NULL,
PRIMARY KEY (code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE circulations (
cir_id INT NOT NULL AUTO_INCREMENT,
correspondence_id INT NOT NULL,
org_id INT NOT NULL,
cir_subject VARCHAR(500) NOT NULL,
cir_status_code VARCHAR(20) NOT NULL DEFAULT 'DRAFT',
created_by_user_id INT NOT NULL,
submitted_at TIMESTAMP NULL,
closed_at TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (cir_id),
CONSTRAINT fk_cir_correspondence FOREIGN KEY (correspondence_id) REFERENCES correspondences(id),
CONSTRAINT fk_cir_org FOREIGN KEY (org_id) REFERENCES organizations(org_id),
CONSTRAINT fk_cir_status FOREIGN KEY (cir_status_code) REFERENCES cir_status_codes(code),
CONSTRAINT fk_cir_user FOREIGN KEY (created_by_user_id) REFERENCES users(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE circulation_assignees (
assignee_id INT NOT NULL AUTO_INCREMENT,
cir_id INT NOT NULL,
user_id INT NOT NULL,
assignee_type ENUM('MAIN', 'ACTION', 'INFO') NOT NULL,
deadline DATE NULL,
action_taken TEXT NULL,
is_completed BOOLEAN NOT NULL DEFAULT FALSE,
completed_at TIMESTAMP NULL,
PRIMARY KEY (assignee_id),
UNIQUE KEY ux_cir_user_type (cir_id, user_id, assignee_type),
CONSTRAINT fk_ca_cir FOREIGN KEY (cir_id) REFERENCES circulations(cir_id) ON DELETE CASCADE,
CONSTRAINT fk_ca_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE technical_doc_workflows (
workflow_id INT NOT NULL AUTO_INCREMENT,
correspondence_id INT NOT NULL,
sequence INT NOT NULL,
org_id INT NOT NULL,
status ENUM('PENDING', 'APPROVED', 'REJECTED', 'APPROVED_WITH_COMMENTS', 'FORWARDED', 'RETURNED') NOT NULL DEFAULT 'PENDING',
comments TEXT,
processed_by_user_id INT NULL,
processed_at TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (workflow_id),
UNIQUE KEY ux_workflow_corr_sequence (correspondence_id, sequence),
CONSTRAINT fk_tdw_correspondence FOREIGN KEY (correspondence_id) REFERENCES correspondences(id) ON DELETE CASCADE,
CONSTRAINT fk_tdw_org FOREIGN KEY (org_id) REFERENCES organizations(org_id),
CONSTRAINT fk_tdw_user FOREIGN KEY (processed_by_user_id) REFERENCES users(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
CREATE TABLE correspondence_status_transitions(
type_id INT NOT NULL,
from_status_id INT NOT NULL,
to_status_id INT NOT NULL,
PRIMARY KEY (type_id, from_status_id, to_status_id),
CONSTRAINT fk_cst_type FOREIGN KEY (type_id) REFERENCES correspondence_types(type_id),
CONSTRAINT fk_cst_from FOREIGN KEY (from_status_id) REFERENCES correspondence_statuses(status_id),
CONSTRAINT fk_cst_to FOREIGN KEY (to_status_id) REFERENCES correspondence_statuses(status_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
-- (The rest of your original tables for technical docs, drawings, etc. would follow here)
-- For brevity, I've included the core structure. You can append the remaining tables from your original file.

143
docs/SQL/temp.sql Normal file
View File

@@ -0,0 +1,143 @@
SET NAMES utf8mb4;
SET time_zone = '+07:00';
SET FOREIGN_KEY_CHECKS=0;
-- ==========================================================
-- 1. ลบ Stored Procedure เก่า (ย้าย Logic ไป NestJS)
-- ==========================================================
-- ตรรกะนี้ (การสร้าง Revision) จะถูกย้ายไปจัดการใน
-- CorrespondenceService และ RfaService ของ NestJS
DROP PROCEDURE IF EXISTS sp_create_correspondence_revision;
-- ==========================================================
-- 2. สร้าง Stored Procedure ใหม่ (สำหรับ Document Numbering)
-- ==========================================================
-- ใช้ Procedure นี้เพื่อจัดการ Race Condition
-- ในการดึงเลขที่เอกสารล่าสุด
-- ----------------------------------------------------------
DELIMITER $$
CREATE PROCEDURE sp_get_next_document_number(
IN p_project_id INT,
IN p_organization_id INT,
IN p_type_id INT,
IN p_year INT,
OUT p_next_number INT
)
BEGIN
DECLARE v_last_number INT;
-- 1. พยายามดึงแถวปัจจุบันและ "ล็อก" (FOR UPDATE)
-- เพื่อป้องกันไม่ให้ Transaction อื่นอ่านค่านี้จนกว่าเราจะเสร็จ
SELECT last_number
INTO v_last_number
FROM document_number_counters
WHERE
project_id = p_project_id AND
originator_organization_id = p_organization_id AND
correspondence_type_id = p_type_id AND
current_year = p_year
FOR UPDATE;
-- 2. ตรวจสอบว่าพบบแถวหรือไม่
IF v_last_number IS NULL THEN
-- 2a. ไม่พบ (นี่คือเลขที่ "1" ของ Key นี้)
INSERT INTO document_number_counters
(project_id, originator_organization_id, correspondence_type_id, current_year, last_number)
VALUES
(p_project_id, p_organization_id, p_type_id, p_year, 1);
SET p_next_number = 1;
ELSE
-- 2b. พบ (บวกเลขที่เดิม)
SET p_next_number = v_last_number + 1;
UPDATE document_number_counters
SET last_number = p_next_number
WHERE
project_id = p_project_id AND
originator_organization_id = p_organization_id AND
correspondence_type_id = p_type_id AND
current_year = p_year;
END IF;
-- (Transaction จะ Commit อัตโนมัติเมื่อ Procedure จบ)
END$$
DELIMITER ;
-- ==========================================================
-- 3. สร้าง Views (สำหรับช่วย Backend/Frontend)
-- ==========================================================
-- ----------------------------------------------------------
-- View 1: v_user_tasks (สำหรับ Dashboard "งานของฉัน" Req 5.3)
-- ----------------------------------------------------------
CREATE OR REPLACE VIEW v_user_tasks AS
SELECT
ca.user_id,
c.id AS circulation_id,
c.organization_id,
c.circulation_no,
c.circulation_subject,
ca.assignee_type,
ca.deadline,
c.created_at,
c.correspondence_id
FROM circulations c
JOIN circulation_assignees ca ON c.id = ca.circulation_id
WHERE
ca.is_completed = FALSE
AND ca.assignee_type IN ('MAIN', 'ACTION');
-- ----------------------------------------------------------
-- View 2: v_audit_log_details (สำหรับ Activity Feed Req 6.1)
-- ----------------------------------------------------------
CREATE OR REPLACE VIEW v_audit_log_details AS
SELECT
al.audit_id,
al.user_id,
al.action,
al.entity_type,
al.entity_id,
al.details_json,
al.ip_address,
al.created_at,
u.username,
u.first_name,
u.last_name,
u.email
FROM audit_logs al
LEFT JOIN users u ON al.user_id = u.user_id;
-- ----------------------------------------------------------
-- View 3: v_user_all_permissions (สำหรับ RBAC 2 ระดับ Req 4.2)
-- ----------------------------------------------------------
-- View นี้จะรวมสิทธิ์ 2 ระดับ (Global และ Project)
-- (หมายเหตุ: ไม่รวม Contract-level เนื่องจากยังไม่มีตาราง)
-- ----------------------------------------------------------
CREATE OR REPLACE VIEW v_user_all_permissions AS
-- 1. สิทธิ์ระดับ Global (project_id IS NULL)
SELECT
ur.user_id,
NULL AS project_id,
p.permission_code
FROM user_roles ur
JOIN role_permissions rp ON ur.role_id = rp.role_id
JOIN permissions p ON rp.permission_id = p.permission_id
UNION
-- 2. สิทธิ์ระดับ Project
SELECT
upr.user_id,
upr.project_id,
p.permission_code
FROM user_project_roles upr
JOIN role_permissions rp ON upr.role_id = rp.role_id
JOIN permissions p ON rp.permission_id = p.permission_id;
SET FOREIGN_KEY_CHECKS=1;

47
docs/SQL/triggers.sql Normal file
View File

@@ -0,0 +1,47 @@
-- trigger
DROP TRIGGER IF EXISTS trg_rfa_revisions_is_current;
DROP TRIGGER IF EXISTS trg_rfa_revisions_is_current_upd;
DROP TRIGGER IF EXISTS trg_rfa_revisions_auto_reset;
-- ============================================================
-- ⚙️ TRIGGERS
-- ============================================================
-- ป้องกันไม่ให้มี revision ที่ is_current=TRUE ซ้ำใน rfa_id เดียวกัน
DELIMITER $$
CREATE TRIGGER trg_rfa_revisions_is_current
BEFORE INSERT ON rfa_revisions
FOR EACH ROW
BEGIN
IF NEW.is_current = TRUE THEN
IF (SELECT COUNT(*) FROM rfa_revisions WHERE rfa_id = NEW.rfa_id AND is_current = TRUE) > 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Cannot insert more than one current revision per RFA.';
END IF;
END IF;
END$$
DELIMITER ;
DELIMITER $$
CREATE TRIGGER trg_rfa_revisions_is_current_upd
BEFORE UPDATE ON rfa_revisions
FOR EACH ROW
BEGIN
IF NEW.is_current = TRUE AND (OLD.is_current IS NULL OR OLD.is_current = FALSE) THEN
IF (SELECT COUNT(*) FROM rfa_revisions WHERE rfa_id = NEW.rfa_id AND is_current = TRUE AND correspondences_id <> OLD.correspondences_id) > 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Cannot set more than one current revision per RFA.';
END IF;
END IF;
END$$
DELIMITER ;
-- ทำให้เวลาสร้าง revision ใหม่ที่ is_current=TRUE ระบบจะ set revision เดิมเป็น FALSE อัตโนมัติ
DELIMITER $$
CREATE TRIGGER trg_rfa_revisions_auto_reset
BEFORE INSERT ON rfa_revisions
FOR EACH ROW
BEGIN
IF NEW.is_current = TRUE THEN
UPDATE rfa_revisions
SET is_current = FALSE
WHERE rfa_id = NEW.rfa_id;
END IF;
END$$
DELIMITER ;

171
docs/backend_setup.bak Normal file
View File

@@ -0,0 +1,171 @@
# การติดตั้งและสร้างโปรเจกต์ (Project Initialization)
1. ข้อกำหนดเบื้องต้น (Prerequisites)
ก่อนเริ่ม, ตรวจสอบให้แน่ใจว่าคุณมีเครื่องมือเหล่านี้ติดตั้งบน Windows 11 ของคุณแล้ว:
Node.js: เวอร์ชัน 18.x หรือสูงกว่า
NPM หรือ Yarn: ตัวจัดการ Package (มักจะมาพร้อมกับ Node.js)
NestJS CLI: เครื่องมือ Command-line สำหรับ NestJS
หากยังไม่ได้ติดตั้ง NestJS CLI, ให้เปิด VS Code Terminal หรือ Command Prompt แล้วรันคำสั่ง:
bash
npm install -g @nestjs/cli
## 2.1 สร้างโปรเจกต์ NestJS ใหม่
ไปที่ Directory ที่คุณต้องการเก็บโปรเจกต์ (เช่น C:\Users\YourUser\Development\)
ใช้ NestJS CLI เพื่อสร้างโปรเจกต์ใหม่ ผมจะตั้งชื่อว่า backend-np-dms นะครับ:
Bash
nest new backend
ระบบจะถามว่าต้องการใช้ Package Manager ตัวไหน แนะนำให้เลือก npm, รอจนกว่ากระบวนการจะเสร็จสิ้น คุณจะได้โฟลเดอร์ backend ที่มีโครงสร้างพื้นฐานของ NestJS พร้อมใช้งาน
## 2.2 ติดตั้ง Dependencies ที่จำเป็น
ตอนนี้เราจะติดตั้ง Modules ทั้งหมดที่คุณวางแผนไว้ในคราวเดียว เพื่อให้โปรเจกต์พร้อมสำหรับการพัฒนา
เปิด Terminal ใน VS Code ภายในโฟลเดอร์ backend (cd backend) แล้วรันคำสั่งต่อไปนี้:
* Database & ORM (TypeORM for MariaDB/MySQL)
Bash
npm install @nestjs/typeorm typeorm mysql2
* Configuration Management (สำหรับ .env)
npm install @nestjs/config
* API Documentation
npm install @nestjs/swagger
* Validation & Transformation
npm install class-validator class-transformer
* Security
npm install helmet
* Authentication (JWT)
npm install @nestjs/passport passport passport-jwt @nestjs/jwt
npm install --save-dev @types/passport-jwt
คำอธิบาย:
@nestjs/typeorm typeorm mysql2: สำหรับเชื่อมต่อและจัดการฐานข้อมูล MariaDB
@nestjs/config: สำหรับจัดการ Environment Variables (เช่น ข้อมูลการเชื่อมต่อ DB) ผ่านไฟล์ .env
@nestjs/swagger: สำหรับสร้างหน้าเอกสาร API (Swagger/OpenAPI) โดยอัตโนมัติ
class-validator class-transformer: ใช้สำหรับตรวจสอบความถูกต้องของข้อมูลที่ส่งเข้ามาใน API (Request Body Validation)
helmet: ช่วยเพิ่มความปลอดภัยพื้นฐานโดยการตั้งค่า HTTP Headers ที่เหมาะสม
@nestjs/passport, @nestjs/jwt: เครื่องมือมาตรฐานสำหรับทำระบบ Authentication
## 2.3: ตั้งค่าพื้นฐานในโปรเจกต์ (Initial Configuration)
ตอนนี้เราจะแก้ไขไฟล์หลักๆ เพื่อเปิดใช้งาน Modules ที่ติดตั้งไป
1. สร้างไฟล์ Environment (.env)
ที่ราก (root) ของโปรเจกต์ backend-np-dms, สร้างไฟล์ใหม่ชื่อ .env และใส่ข้อมูลการเชื่อมต่อฐานข้อมูลของคุณ (ข้อมูลนี้จะไม่ถูกเก็บใน Git):
.env
Code snippet
* Database Configuration
DB_TYPE=mysql
DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=your_db_user # <-- แก้ไขเป็น user ของคุณ
DB_PASSWORD=your_db_password # <-- แก้ไขเป็น password ของคุณ
DB_DATABASE=dms_db # <-- แก้ไขเป็นชื่อ database ของคุณ
* Application
API_PORT=3001
💡 Tip: หากคุณรัน MariaDB ผ่าน Docker, DB_HOST อาจจะเป็นชื่อ Service ของ Docker container (เช่น mariadb-container) หรือ IP ของ QNAP ของคุณ
2. แก้ไข app.module.ts เพื่อเชื่อมต่อ Database และ Config
เปิดไฟล์ src/app.module.ts และแก้ไขให้เป็นตามนี้เพื่อ import ConfigModule และ TypeOrmModule:
src/app.module.ts
```TypeScript
import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';
import { AppController } from './app.controller';
import { AppService } from './app.service';
@Module({
imports: [
// 1. Config Module - สำหรับอ่าน .env (ต้องอยู่บนสุด)
ConfigModule.forRoot({
isGlobal: true, // ทำให้ ConfigService พร้อมใช้งานทั่วทั้งแอป
envFilePath: '.env',
}),
// 2. TypeORM Module - สำหรับเชื่อมต่อ Database
TypeOrmModule.forRootAsync({
imports: [ConfigModule],
inject: [ConfigService],
useFactory: (configService: ConfigService) => ({
type: 'mysql',
host: configService.get<string>('DB_HOST'),
port: configService.get<int>('DB_PORT'),
username: configService.get<string>('DB_USERNAME'),
password: configService.get<string>('DB_PASSWORD'),
database: configService.get<string>('DB_DATABASE'),
entities: [__dirname + '/../**/*.entity{.ts,.js}'],
synchronize: true, // สำหรับ Development เท่านั้น! จะสร้างตารางให้อัตโนมัติ
logging: true,
}),
}),
],
controllers: [AppController],
providers: [AppService],
})
export class AppModule {}
```
⚠️ คำเตือน: synchronize: true สะดวกมากในช่วงพัฒนาเพราะมันจะปรับโครงสร้างตารางตาม Entity ให้อัตโนมัติ ห้ามใช้ใน Production เด็ดขาด เพราะอาจทำให้ข้อมูลหายได้ ใน Production ควรใช้ระบบ Migration แทน
3. แก้ไข main.ts เพื่อเปิดใช้งาน Swagger, Validation และ Security
เปิดไฟล์ src/main.ts และเพิ่มการตั้งค่าต่างๆ เข้าไป:
src/main.ts
TypeScript
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';
import helmet from 'helmet';
async function bootstrap() {
const app = await NestFactory.create(AppModule);
// เปิดใช้งาน CORS (Cross-Origin Resource Sharing)
app.enableCors();
// เพิ่ม Helmet เพื่อความปลอดภัย
app.use(helmet());
// ตั้งค่า Global Validation Pipe
app.useGlobalPipes(new ValidationPipe({
whitelist: true, // ตัด property ที่ไม่มีใน DTO ออก
transform: true, // แปลงข้อมูลให้เป็น type ที่ระบุใน DTO
}));
// ตั้งค่า Swagger API Documentation
const config = new DocumentBuilder()
.setTitle('LCBP3-DMS API')
.setDescription('The Document Management System API for LCBP3 Project')
.setVersion('1.0')
.addBearerAuth() // สำหรับ JWT
.build();
const document = SwaggerModule.createDocument(app, config);
SwaggerModule.setup('api-docs', app, document); // เข้าถึงได้ที่ /api-docs
// เริ่มรัน Server
const port = process.env.API_PORT || 3001;
await app.listen(port);
console.log(`Application is running on: ${await app.getUrl()}`);
}
bootstrap();
curl -i -X POST \
-H "Content-Type: application/json" \
-d '{"username": "superadmin", "password": "Center#2025"}' \
https://backend.np-dms.work/api/auth/login

17
docs/features.bak Normal file
View File

@@ -0,0 +1,17 @@
ฟีเจอร์ขั้นสูง (Advanced Features)
Error Handling: ใช้ Global Exception Filter เพื่อจัดการ Error และส่ง Response ที่เป็นมาตรฐาน
Logging: ใช้ Winston สำหรับ Structured Logging และบันทึก Error ลงไฟล์
Testing: มีโครงสร้างสำหรับ Unit Test และ E2E Test ด้วย Jest และ Supertest
Performance: ใช้ CacheModule สำหรับ Caching ข้อมูลที่เรียกใช้บ่อย
Security:
Rate Limiting: ใช้ ThrottlerModule เพื่อป้องกัน Brute-force attack
Secret Management: แนะนำให้ใช้ Environment Variable ของ Docker แทนไฟล์ .env ใน Production
API Documentation: สร้างเอกสาร API อัตโนมัติด้วย @nestjs/swagger และเข้าถึงได้ที่ /api-docs

94
docs/frontend.md Normal file
View File

@@ -0,0 +1,94 @@
xxx npx shadcn@latest init
✔ npx shadcn@latest init
✔ Would you like to use TypeScript (recommended)? Yes
✔ Which style would you like to use? Default
✔ Which base color would you like to use? Slate
✔ Where is your global CSS file? src/app/globals.css
✔ Would you like to use CSS variables...? Yes
✔ Where is your tailwind.config.ts...? tailwind.config.ts
✔ Configure the import alias for components: @/components
✔ Configure the import alias for utils: @/lib/utils
✔ Are you using React Server Components? Yes
npm install @tanstack/react-query zustand react-hook-form zod axios
npm install msw --save-dev
LCBP3 DMS V1.2.0
Custom Gem
รับทราบครับ เราจะไปขั้นตอนต่อไป คือการสร้าง App Shell Layout (โครงสร้างหน้าเว็บหลัก) ตามข้อกำหนด 5.1
เราจะสร้าง 3 ส่วนหลัก:
Sidebar (เมนูด้านข้าง)
Navbar/Header (แถบด้านบน)
Main Content Area (พื้นที่เนื้อหา)
2.1 ติดตั้ง Icons
npm install lucide-react
3.1 ติดตั้ง Shadcn Components ที่จำเป็น
npx shadcn@latest add card
npx shadcn@latest add table
npx shadcn@latest add button
npx shadcn@latest
4.1 ตั้งค่า React Query (TanStack Query) Provider
npm install @tanstack/react-query-devtools
4.2 ตั้งค่า Mock Service Worker (MSW)
npx msw init public/ --save
4.4 อัปเดต MyTasksTable (ให้เรียก API จริง)
npm install axios
5.1 ติดตั้ง Shadcn Components
npx shadcn@latest add badge
5.4 (ตัวอย่าง) การนำไปใช้ในหน้า RFA
เรายังไม่ได้สร้างหน้า /rfa/[id]/page.tsx แต่เมื่อสร้างเสร็จ เราจะเรียกใช้ Component นี้โดยส่ง props ไป:
// src/app/rfa/[id]/page.tsx (ตัวอย่างในอนาคต)
// import { mockWorkflow } from "@/mocks/data/mock-workflow";
// import { WorkflowVisualizer } from "@/components/workflow/workflow-visualizer";
// export default function RfaDetailPage({ params }: { params: { id: string } }) {
// // 1. (ในอนาคต) ดึงข้อมูล RFA และ Workflow steps จาก API
// // const { data: rfaData } = useQuery(...);
// // const steps = rfaData.workflowSteps;
// // 2. (ในอนาคต) ดึงสิทธิ์ผู้ใช้จาก Zustand (Global State)
// // const { user } = useAuthStore();
// // const isAdmin = user.role === 'ADMIN' || user.role === 'SUPER_ADMIN';
// // 3. ส่ง Props ไปยัง Component
// return (
// <div>
// {/* (แสดงรายละเอียด RFA ที่นี่) */}
// <WorkflowVisualizer
// steps={mockWorkflow} // (ใช้ rfaData.workflowSteps จริง)
// isAdmin={true} // (ใช้ isAdmin จริง)
// />
// </div>
// );
// }
6.1 ติดตั้ง Shadcn Components ที่จำเป็น
npx shadcn@latest add avatar
npx shadcn@latest add dialog
npx shadcn@latest add form
npx shadcn@latest add input
npx shadcn@latest add label
npx shadcn@latest add dropdown-menu
npx shadcn@latest add checkbox
npx shadcn@latest add pagination
x 6.2 อัปเดต Mock API (MSW) x

42
docs/ux_ui.md Normal file
View File

@@ -0,0 +1,42 @@
You are an expert in Bootstrap and modern web application development.
Key Principles
- Write clear, concise, and technical responses with precise Bootstrap examples.
- Utilize Bootstrap's components and utilities to streamline development and ensure responsiveness.
- Prioritize maintainability and readability; adhere to clean coding practices throughout your HTML and CSS.
- Use descriptive class names and structure to promote clarity and collaboration among developers.
Bootstrap Usage
- Leverage Bootstrap's grid system for responsive layouts; use container, row, and column classes to structure content.
- Utilize Bootstrap components (e.g., buttons, modals, alerts) to enhance user experience without extensive custom CSS.
- Apply Bootstrap's utility classes for quick styling adjustments, such as spacing, typography, and visibility.
- Ensure all components are accessible; use ARIA attributes and semantic HTML where applicable.
Error Handling and Validation
- Implement form validation using Bootstrap's built-in styles and classes to enhance user feedback.
- Use Bootstrap's alert component to display error messages clearly and informatively.
- Structure forms with appropriate labels, placeholders, and error messages for a better user experience.
Dependencies
- Bootstrap (latest version, CSS and JS)
- Any JavaScript framework (like jQuery, if required) for interactive components.
Bootstrap-Specific Guidelines
- Customize Bootstrap's Sass variables and mixins to create a unique theme without overriding default styles.
- Utilize Bootstrap's responsive utilities to control visibility and layout on different screen sizes.
- Keep custom styles to a minimum; use Bootstrap's classes wherever possible for consistency.
- Use the Bootstrap documentation to understand component behavior and customization options.
Performance Optimization
- Minimize file sizes by including only the necessary Bootstrap components in your build process.
- Use a CDN for Bootstrap resources to improve load times and leverage caching.
- Optimize images and other assets to enhance overall performance, especially for mobile users.
Key Conventions
1. Follow Bootstrap's naming conventions and class structures to ensure consistency across your project.
2. Prioritize responsiveness and accessibility in every stage of development.
3. Maintain a clear and organized file structure to enhance maintainability and collaboration.
Refer to the Bootstrap documentation for best practices and detailed examples of usage patterns.

192
docs/workflow.bak Normal file
View File

@@ -0,0 +1,192 @@
## Workflow ระดับ Project (correspondence_routing_steps, technical_doc_workflows): คือ "การเดินทาง" ของเอกสาร ระหว่างองค์กร (เช่น จากผู้รับเหมา -> ไปยังที่ปรึกษา -> ไปยังเจ้าของโครงการ)
## Workflow ระดับ Organization (Circulation): คือ "การแจกจ่าย" เอกสาร ภายในองค์กรของคุณเอง หลังจากที่คุณได้รับเอกสารนั้นมาแล้ว (เช่น เอกสารมาถึง Document Control แล้วต้องส่งต่อให้ใครบ้างในบริษัท)
circulation_templates: ตารางหลักสำหรับเก็บชื่อแม่แบบ
circulation_template_assignees: ตารางสำหรับเก็บ "รายชื่อผู้รับผิดชอบ" ที่ถูกกำหนดไว้ในแต่ละแม่แบบ
Workflow การทำงานใน Frontend
1. หน้า Admin Panel: จะต้องมีเมนูใหม่สำหรับให้ Admin หรือผู้มีสิทธิ์ เข้าไป สร้าง/แก้ไข/ลบ แม่แบบใบเวียน (circulation_templates) สำหรับองค์กรของตนเองได้
2. หน้าที่สร้างใบเวียน (Create Circulation Dialog):
* ที่ด้านบนสุดของฟอร์ม จะมี Dropdown ใหม่ ปรากฏขึ้นมา เขียนว่า "ใช้แม่แบบ (Use Template)"
* ใน Dropdown นี้ จะแสดงรายชื่อแม่แบบทั้งหมดที่องค์กรนั้นๆ สร้างไว้
* เมื่อผู้ใช้เลือกแม่แบบ:
** ระบบจะยิง API ไปดึงรายชื่อผู้รับผิดชอบจากตาราง circulation_template_assignees
** จากนั้น JavaScript จะทำการเติมข้อมูล (Auto-populate) ลงในช่อง "Main", "Action", และ "Information" ให้โดยอัตโนมัติ
* ผู้ใช้ยังสามารถ แก้ไข/เพิ่มเติม/ลบ รายชื่อผู้รับผิดชอบได้ตามต้องการ ก่อนที่จะกดสร้างใบเวียนจริง
การจัดการข้อมูล JSON จะเกิดขึ้นใน 3 ส่วนหลักๆ คือ Backend, Frontend, และ Database ครับ
## 1. การจัดการในฝั่ง Backend (NestJS)
นี่คือส่วนที่ทำหน้าที่หลักในการสร้างและอ่านข้อมูล JSON อย่างเป็นระบบและปลอดภัย
1.1 การแก้ไข Entity
เราจะแก้ไข Correspondence entity โดยเพิ่มคอลัมน์ details เข้าไป และลบ Entity ย่อยๆ ที่ไม่ใช้ออก
src/correspondences/entities/correspondence.entity.ts
@Entity('correspondences')
export class Correspondence {
// ... (คอลัมน์เดิมทั้งหมด: id, document_number, title, etc.)
@Column({
type: 'json', // ◀️ กำหนดประเภทข้อมูลเป็น JSON
nullable: true,
comment: 'เก็บข้อมูลเฉพาะของเอกสารแต่ละประเภทในรูปแบบ JSON'
})
details: any; // ◀️ ใช้ type 'any' หรือสร้าง Interface/Type ที่ซับซ้อนขึ้น
}
1.2 การสร้าง DTOs สำหรับแต่ละประเภทเอกสาร
เพื่อรักษาความถูกต้องของข้อมูล (Validation) เราจะสร้าง DTO แยกสำหรับเอกสารแต่ละประเภท
ตัวอย่าง src/correspondences/dto/create-letter.dto.ts:
TypeScript
import { ApiProperty } from '@nestjs/swagger';
import { IsNotEmpty, IsString } from 'class-validator';
// DTO สำหรับข้อมูลใน details ของ Letter
class LetterDetailsDto {
@ApiProperty()
@IsString()
@IsNotEmpty()
attention_to: string;
@ApiProperty()
@IsString()
@IsNotEmpty()
signatory_name: string;
}
// DTO หลักสำหรับสร้าง Letter
export class CreateLetterDto {
@ApiProperty({ description: "ข้อมูลพื้นฐานของเอกสาร" })
@ValidateNested() // ◀️ บอกให้ class-validator ตรวจสอบ object ข้างในด้วย
@Type(() => CreateCorrespondenceDto) // ◀️ ใช้ DTO พื้นฐานร่วมกัน
base_data: CreateCorrespondenceDto;
@ApiProperty({ description: "ข้อมูลเฉพาะของ Letter" })
@ValidateNested()
@Type(() => LetterDetailsDto)
details: LetterDetailsDto;
}
1.3 การสร้าง API Endpoint และ Logic ใน Service
เราจะสร้าง Endpoint แยกสำหรับสร้างเอกสารแต่ละประเภทเพื่อความชัดเจน
ใน CorrespondencesController:
TypeScript
@Post('letter')
@ApiOperation({ summary: 'Create a new Letter' })
createLetter(@Body() createLetterDto: CreateLetterDto, @Req() req: Request) {
const user = req.user as any;
return this.correspondencesService.createTypedCorrespondence(
createLetterDto.base_data,
createLetterDto.details,
user
);
}
ใน CorrespondencesService:
TypeScript
async createTypedCorrespondence(baseData: CreateCorrespondenceDto, details: any, user: User): Promise<Correspondence> {
// ... (โค้ดตรวจสอบสิทธิ์เหมือนเดิม)
const newCorrespondence = this.correspondenceRepository.create({
...baseData, // ข้อมูลพื้นฐาน (เลขที่เอกสาร, ชื่อเรื่อง, etc.)
details: details, // ◀️ นำ object ของ details มาใส่ในคอลัมน์ JSON โดยตรง
created_by_user_id: user.user_id,
originator_org_id: user.org_id,
status_id: 1, // 'Draft'
});
return this.correspondenceRepository.save(newCorrespondence);
}
## 2. การจัดการในฝั่ง Frontend (Next.js / React)
Frontend จะทำหน้าที่แสดงฟอร์มที่ถูกต้องตามประเภทเอกสาร และส่งข้อมูลในรูปแบบที่ Backend ต้องการ
2.1 การแสดงฟอร์มแบบไดนามิก (Dynamic Forms)
ในหน้า "Create Correspondence" เมื่อผู้ใช้เลือกประเภทเอกสารจาก Dropdown เราจะใช้ State เพื่อแสดงฟอร์มที่ถูกต้อง
TypeScript
const [docType, setDocType] = useState('LETTER');
// ...
const renderDetailFields = () => {
switch (docType) {
case 'LETTER':
return (
<>
{/* ฟิลด์สำหรับ Attention To, Signatory */}
</>
);
case 'RFI':
return (
<>
{/* ฟิลด์สำหรับ Question, Required By Date */}
</>
);
default:
return null;
}
}
return (
<form>
{/* ฟิลด์พื้นฐาน (Document Number, Title) */}
{/* Dropdown เลือกประเภทเอกสาร */}
{renderDetailFields()} {/* ◀️ แสดงฟิลด์เฉพาะทางที่นี่ */}
</form>
);
2.2 การส่งข้อมูล
เมื่อผู้ใช้กด Submit เราจะรวบรวมข้อมูลจากฟอร์มให้เป็นโครงสร้าง JSON ที่ Backend ต้องการ
JavaScript
const handleSubmit = () => {
// รวบรวมข้อมูลพื้นฐาน
const base_data = {
document_number: '...',
title: '...',
// ...
};
// รวบรวมข้อมูลเฉพาะทาง
const details = {
attention_to: '...',
signatory_name: '...',
};
// ส่งข้อมูลไปที่ API Endpoint ที่ถูกต้อง
fetch('/api/correspondences/letter', {
method: 'POST',
body: JSON.stringify({ base_data, details }),
});
}
## 3. การจัดการในระดับฐานข้อมูล (MariaDB)
แม้ว่าเราจะไม่ค่อยได้ Query ข้อมูล JSON โดยตรงผ่าน SQL บ่อยนัก แต่ก็สามารถทำได้เมื่อจำเป็น (เช่น สำหรับการทำรายงานที่ซับซ้อน)
ตัวอย่าง: ค้นหาเอกสาร Letter ทั้งหมดที่ส่งถึง "Mr. John Doe"
SQL
SELECT
corr_id,
document_number,
details
FROM
correspondences
WHERE
type_id = (SELECT type_id FROM correspondence_types WHERE type_code = 'LETTER') -- กรองเฉพาะ Letter
AND JSON_VALUE(details, '$.attention_to') = 'Mr. John Doe'; -- ◀️ ค้นหาค่าใน JSON
การจัดการข้อมูลด้วยวิธีนี้จะทำให้ระบบของคุณมีความ

150
prompt.md Normal file
View File

@@ -0,0 +1,150 @@
# **PROMPT**
## Gemini
## VSCode Shortcut
Markdown preview Ctrl+Shift+V
## สร้างโครงสร้างโฟลเดอร์สำหรับ lcbp3-backend
```bash
# สร้างโฟลเดอร์หลัก
$rootFolder = "backend"
New-Item -ItemType Directory -Path $rootFolder -Force
Set-Location $rootFolder
# รายการโฟลเดอร์ที่ต้องการสร้างทั้งหมด
$folders = @(
"src",
"database",
"src\common",
"src\modules",
"src\modules\user",
"src\modules\project",
"src\modules\master",
"src\modules\correspondence",
"src\modules\rfa",
"src\modules\drawing",
"src\modules\circulations",
"src\modules\transmittal",
"src\modules\search",
"src\modules\document-numbering",
"src\common\auth",
"src\common\config",
"src\common\decorators",
"src\common\entities",
"src\common\exceptions",
"src\common\file-storage",
"src\common\guards",
"src\common\interceptors",
"src\common\services"
)
# วนลูปสร้างโฟลเดอร์ทั้งหมด
foreach ($folder in $folders) {
New-Item -ItemType Directory -Path $folder -Force
}
Write-Host "สร้างโครงสร้างโฟลเดอร์สำหรับ backend เรียบร้อยแล้ว" -ForegroundColor Green
```
## Git Commands
```bash
# 1⃣ ตั้งชื่อและอีเมลของคุณ (ใช้กับทุก repo)
git config --global user.name "Pean Charoen"
git config --global user.email "peancharoen.pslcp3@gmail.com"
# 2⃣ ตรวจสอบว่าเชื่อมกับ remote ถูกต้อง (แก้ URL ให้ตรง repo จริงของคุณ)
git remote set-url origin ssh://git@git.np-dms.work:2222/np-dms/lcbp3_v1.git
# 3⃣ ตรวจสอบสถานะไฟล์
git status
# 4⃣ เพิ่มไฟล์ทั้งหมด
git add .
# 5⃣ Commit พร้อมข้อความ
git commit -m "Update project files"
# 6⃣ ดึง remote ก่อนเพื่อป้องกัน conflict (ถ้ามี)
git pull --rebase origin main
# 7⃣ Push ขึ้น Gitea
git push -u origin main
```
## **สร้าง NestJS Project ใหม่**
* ขั้นตอนที่ 1: ติดตั้ง NestJS CLI (ถ้ายังไม่ได้ติดตั้ง)
* npm install -g @nestjs/cli
* ขั้นตอนที่ 2: สร้างโปรเจกต์ใหม่
* nest new backend
* nest new . /อยู่ในโฟลเดอร์ที่สร้างไว้แล้ว และต้องการสร้างโปรเจกต์ลงในโฟลเดอร์นั้นโดยตรง:
* ขั้นตอนที่ 3: ติดตั้ง Dependencies เพิ่มเติมสำหรับ DMS
```bash
# Core & Database
npm install @nestjs/typeorm typeorm mysql2
npm install @nestjs/config
# Validation & Transformation
npm install class-validator class-transformer
# Authentication & Authorization
npm install @nestjs/jwt @nestjs/passport passport passport-jwt
npm install @nestjs/passport
npm install casl
# File Upload
npm install @nestjs/platform-express multer
# Documentation
npm install @nestjs/swagger
# Security & Performance
npm install helmet rate-limiter-flexible
# Development Dependencies (สำหรับทดสอบ)
npm install --save-dev @nestjs/testing jest @types/jest @types/passport-jwt @types/multer supertest
```
## Prompt: การพัฒนา Core Auth Module (AuthModule) สำหรับ DMS v1.2.0
ช่วยตั้งค่า tsconfig.json, nest-cli.json และไฟล์ config อื่นๆ
* 1.1 สร้าง User Entity
* 1.2 สร้าง Role Entity
* 1.3 สร้าง Permission Entity
ถัดไป ช่วยสร้าง TypeORM configuration และ DatabaseModule ให้หน่อย
ช่วยสร้าง AuthService, JwtStrategy และ AuthController พื้นฐานให้หน่อย
ช่วยสร้าง UserModule, UserService, LocalAuthGuard และ LocalStrategy สำหรับจัดการข้อมูลผู้ใช้หน่อย
ช่วยสร้าง Guard สำหรับตรวจสอบสิทธิ์ตามบทบาท (RBAC) โดยใช้ CASL หน่อย
ช่วยสร้าง UserModule, UserService, และ UserController
ช่วยตั้งค่าการเชื่อมต่อ MariaDB ผ่าน TypeORM
พัฒนา Core Auth Module (`AuthModule`)
- ช่วยสร้าง API Endpoints: `/auth/login`, `/auth/me`
พัฒนา Common Module (`@app/common`)
- ช่วยสร้าง FileStorageService สำหรับจัดการไฟล์ (อัปโหลด/ดาวน์โหลด) backend/common/file-storage
- ช่วยสร้าง AuditLogInterceptor สำหรับบันทึกการกระทำโดยอัตโนมัติ
- ช่วยสร้าง Global Exception Filter
- ช่วยสร้าง DTOs และ Interfaces พื้นฐาน
---
ขอบคุณสำหรับข้อมูลที่ละเอียดครับ นี่คือการวิเคราะห์และข้อเสนอแนะเพื่อให้โครงสร้างสิทธิ์การใช้งาน (Access Control / RBAC) ชัดเจน สมบูรณ์ และสามารถนำไปพัฒนาได้จริงครับ