# 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):**
```go
// Untuk reject
flow.RejectionReason = &message

// Untuk revision
flow.RevisionMessage = &message
```

### **Sesudah (Field Unified):**
```go
// 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:**
```bash
POST /api/article-approval-flows/articles/{articleId}/approve
```

### **Request Body:**
```json
{
  "action": "approve|revision|reject",
  "message": "Your message here"
}
```

### **Examples:**

#### **Approve:**
```bash
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:**
```bash
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:**
```bash
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):**
```bash
# 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):**
```bash
# 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! 🚀