Feat/ai parser multi transaction - #114
Conversation
…ducation + more - Add 22 categories: TELEKOMUNIKASI, KESEHATAN, KECANTIKAN, PENDIDIKAN, RUMAH TANGGA, INVESTASI, ASURANSI, CICILAN, DONASI, TRAVEL, OLAHRAGA, BONUS, FREELANCE, HADIAH, PENDAPATAN LAINNYA - Rename TRANSPORT -> TRANSPORTASI (id preserved, transactions safe) - INVESTASI as type=both (expense: nabung saham, income: dividen/cuan) Closes #108
Reviewer's GuideAdds a migration-backed expansion of transaction categories and keyword metadata, preserves existing transaction relationships while renaming TRANSPORT, and documents the production migration procedure required after deployment. Flow diagram for category migration deploymentflowchart LR
A["Merge migration PR"] --> B["git pull origin main"]
B --> C["php artisan migrate --force"]
C --> D["Expanded categories and keywords available"]
C --> E["Existing transaction relationships preserved"]
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="database/migrations/2026_09_08_000001_expand_default_categories.php" line_range="40-43" />
<code_context>
+ ['name' => 'LAINNYA', 'icon' => '📌', 'type' => 'both', 'keywords' => ['lainnya', 'misc']],
+ ];
+
+ foreach ($categories as $category) {
+ Category::updateOrCreate(
+ ['name' => $category['name']],
+ $category,
+ );
+ }
+
</code_context>
<issue_to_address>
**issue (broader_impact):** Running this migration overwrites the icon, type, and keywords of every existing category with the same name. Any category edits made by an administrator or user before deployment are silently lost.
**Triggers:** When an existing default category has been customized before this migration runs.
**Suggested fix:** Only insert missing defaults, or update only fields that are explicitly intended to be migrated while preserving user-managed values.
```suggestion
Category::firstOrCreate(
['name' => $category['name']],
$category,
);
```
</issue_to_address>
### Comment 2
<location path="database/migrations/2026_09_08_000001_expand_default_categories.php" line_range="47-53" />
<code_context>
+ }
+
+ // Rename legacy TRANSPORT -> TRANSPORTASI (id stays the same, transactions safe)
+ $legacy = Category::where('name', 'TRANSPORT')->first();
+ if ($legacy) {
+ $legacy->update([
+ 'name' => 'TRANSPORTASI',
+ 'keywords' => ['goride', 'gojek', 'grab', 'bensin', 'parkir', 'tol', 'transport', 'ojek', 'ojol', 'taxi', 'taksi'],
+ ]);
+ }
+ }
+
</code_context>
<issue_to_address>
**issue (bug_risk):** The rename issues a unique-name collision if a `TRANSPORTASI` category already exists, causing the migration to fail after the earlier category upserts have run. The categories table has a unique constraint on `name`, so the legacy row cannot be renamed in that state.
**Triggers:** When `TRANSPORTASI` was created manually, by an earlier deployment, or by another seed process before this migration runs.
**Suggested fix:** Merge or explicitly handle an existing `TRANSPORTASI` row before renaming `TRANSPORT`, preserving the transaction references on the legacy row.
</issue_to_address>Sourcery assessment
Needs a human reviewer. 2 findings to address first, and the migration writes persistent category rows, overwrites matching category metadata, and renames TRANSPORT to TRANSPORTASI; a rollback does not automatically restore any overwritten values and its cleanup can delete newly created category rows. The affected data is bounded and can be repaired with a targeted database migration or manual correction.
Blocking findings: database/migrations/2026_09_08_000001_expand_default_categories.php:43, database/migrations/2026_09_08_000001_expand_default_categories.php:53
| Category::updateOrCreate( | ||
| ['name' => $category['name']], | ||
| $category, | ||
| ); |
There was a problem hiding this comment.
issue (broader_impact): Running this migration overwrites the icon, type, and keywords of every existing category with the same name. Any category edits made by an administrator or user before deployment are silently lost.
Triggers: When an existing default category has been customized before this migration runs.
Suggested fix: Only insert missing defaults, or update only fields that are explicitly intended to be migrated while preserving user-managed values.
| Category::updateOrCreate( | |
| ['name' => $category['name']], | |
| $category, | |
| ); | |
| Category::firstOrCreate( | |
| ['name' => $category['name']], | |
| $category, | |
| ); |
| $legacy = Category::where('name', 'TRANSPORT')->first(); | ||
| if ($legacy) { | ||
| $legacy->update([ | ||
| 'name' => 'TRANSPORTASI', | ||
| 'keywords' => ['goride', 'gojek', 'grab', 'bensin', 'parkir', 'tol', 'transport', 'ojek', 'ojol', 'taxi', 'taksi'], | ||
| ]); | ||
| } |
There was a problem hiding this comment.
issue (bug_risk): The rename issues a unique-name collision if a TRANSPORTASI category already exists, causing the migration to fail after the earlier category upserts have run. The categories table has a unique constraint on name, so the legacy row cannot be renamed in that state.
Triggers: When TRANSPORTASI was created manually, by an earlier deployment, or by another seed process before this migration runs.
Suggested fix: Merge or explicitly handle an existing TRANSPORTASI row before renaming TRANSPORT, preserving the transaction references on the legacy row.
1 participant
Summary by Sourcery
Expand transaction categorization defaults and document the required production migration steps.
New Features:
Bug Fixes:
Enhancements:
Deployment:
Documentation: