kontenhumas-be/docs/REFACTORING_UNIFIED_APPROVAL_ACTIONS.md

Refactoring: Unified Approval Actions Implementation

🎯 Overview

Refactoring ini dilakukan untuk menyelaraskan implementasi approval actions dan menghilangkan duplikasi field message. Sekarang semua action menggunakan field yang sama dan dibedakan hanya berdasarkan statusId.

🔄 Perubahan yang Dilakukan

1. Service Layer Changes

Method yang Dihapus:

• ✅ RejectArticle(authToken string, flowId uint, rejectedById uint, reason string)
• ✅ RequestRevision(authToken string, flowId uint, requestedById uint, revisionMessage string)

Method yang Dipertahankan:

• ✅ ProcessApprovalAction(authToken string, flowId uint, action string, actionById uint, message string)
• ✅ processApproveAction() - untuk action approve
• ✅ processRequestUpdateAction() - untuk action revision
• ✅ processRejectAction() - untuk action reject

2. Controller Layer Changes

Method yang Dihapus:

• ✅ Reject(c *fiber.Ctx) error
• ✅ RequestRevision(c *fiber.Ctx) error

Method yang Dipertahankan:

• ✅ ApproveArticleByFlow(c *fiber.Ctx) error - menggunakan ProcessApprovalAction

3. Route Changes

Route yang Dihapus:

• ✅ PUT /article-approval-flows/{id}/reject
• ✅ PUT /article-approval-flows/{id}/request-revision

Route yang Dipertahankan:

• ✅ POST /article-approval-flows/articles/{articleId}/approve - dengan action parameter

📊 Field Unification

Sebelum (Duplikasi Field):

// Untuk reject
flow.RejectionReason = &message

// Untuk revision
flow.RevisionMessage = &message

Sesudah (Field Unified):

// Untuk semua action
flow.RevisionMessage = &message

// Dibedakan berdasarkan statusId
switch action {
case "approve":
    // StatusId tetap atau naik step
case "revision":
    flow.StatusId = 4 // revision_requested
case "reject":
    flow.StatusId = 3 // rejected
}

🎯 Action Types & Status Mapping

Action	StatusId	Field Used	Behavior
approve	1 atau 2	RevisionMessage	Naik ke step berikutnya
revision	4	RevisionMessage	Mundur 1 step
reject	3	RevisionMessage	Balik ke draft

🔧 Database Field Usage

Unified Field:

• revision_message: Digunakan untuk menyimpan pesan dari semua action types
• revision_requested: Boolean flag untuk revision (hanya untuk action revision)
• status_id: Pembeda utama antara approve/revision/reject

Status ID Values:

• 1: pending - Menunggu approval
• 2: approved - Disetujui
• 3: rejected - Ditolak
• 4: revision_requested - Diminta revisi

🚀 API Usage

Single Endpoint untuk Semua Actions:

POST /api/article-approval-flows/articles/{articleId}/approve

Request Body:

{
  "action": "approve|revision|reject",
  "message": "Your message here"
}

Examples:

Approve:

curl -X POST "http://localhost:8080/api/article-approval-flows/articles/123/approve" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "action": "approve",
    "message": "Content looks good, approved"
  }'

Revision:

curl -X POST "http://localhost:8080/api/article-approval-flows/articles/123/approve" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "action": "revision",
    "message": "Please fix grammar and improve conclusion"
  }'

Reject:

curl -X POST "http://localhost:8080/api/article-approval-flows/articles/123/approve" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "action": "reject",
    "message": "Content does not meet quality standards"
  }'

📈 Benefits

1. Consistency

• ✅ Semua action menggunakan field yang sama untuk message
• ✅ Tidak ada duplikasi field RejectionReason vs RevisionMessage
• ✅ Konsisten dengan naming convention

2. Simplicity

• ✅ Satu endpoint untuk semua action types
• ✅ Satu field untuk semua message types
• ✅ StatusId sebagai pembeda utama

3. Maintainability

• ✅ Code lebih mudah di-maintain
• ✅ Tidak ada duplikasi logic
• ✅ Single source of truth untuk message

4. Backward Compatibility

• ✅ Field revision_message tetap ada dan digunakan
• ✅ Field rejection_reason tetap ada tapi tidak digunakan
• ✅ Tidak ada breaking change untuk database schema

🔄 Migration Guide

Untuk Client yang Menggunakan API Lama:

Before (Multiple Endpoints):

# Reject
PUT /article-approval-flows/{id}/reject
{"reason": "Content not suitable"}

# Request Revision
PUT /article-approval-flows/{id}/request-revision
{"message": "Please fix grammar"}

After (Single Endpoint):

# Reject
POST /article-approval-flows/articles/{articleId}/approve
{"action": "reject", "message": "Content not suitable"}

# Request Revision
POST /article-approval-flows/articles/{articleId}/approve
{"action": "revision", "message": "Please fix grammar"}

🎉 Summary

Refactoring ini berhasil:

1. ✅ Menghilangkan duplikasi field message
2. ✅ Menyederhanakan API dengan single endpoint
3. ✅ Menyelaraskan implementasi dengan field yang sama
4. ✅ Mempertahankan backward compatibility
5. ✅ Meningkatkan maintainability code

Sekarang sistem approval menggunakan implementasi yang lebih konsisten dan mudah di-maintain! 🚀