Sia Eu Jin

01 A status changes

First, it asks

The script only watches column H, the status column. When a status changes, a small dialog pops up with the old and new value and waits for you to hit Confirm. That way one wrong click doesn’t email ten people.

02 Two halves

Two scripts, two accounts

This part took the most figuring out. Only code running as you can see who you are, but the email had to come from the team’s account, not yours. So I split it in two: the dialog grabs your address and passes it, with a shared secret, to a separate web app that runs as the team and sends the mail.

1. Edit in column HThe on-edit trigger fires
2. Confirm dialogRuns as the editor, reads their address
3. Mailer web appRuns as the team, checks the secret
4. Every editor’s inboxSent from one address, developer inbox excluded

03 The email

An email you don’t have to open the sheet for

My first version was a plain-text email. After a review with my supervisor I redesigned it: the old status struck through, the new one in colour, then the CR, the task ID, the issue, who changed it and when, and a button that opens the sheet on the exact cell.

04 Handover

Handing it over

I was only there for a month, so I wrote a maintainer guide: how to deploy it, how to set up the trigger, how new editors authorise it, and what to check when an email doesn’t show up. The team can keep it running without me.

Built with

Google Apps Script, HTML Service, Gmail

Made at

Silverlake Innovation Partners, week 1

FSS8-35 · FSS8-38 Search and filters

Making search actually find things

The provider tabs were sending every filter as an exact match. So if you typed part of a transaction ID you got nothing, and picking a date never matched anything, because every record has a time attached. I switched the text filters to LIKE, turned a picked day into a range from 00:00:00.000 to 23:59:59.999, and added dropdowns for columns with fixed values. Once that worked, a few pagination bugs showed up, so I fixed those too, across iPay88, Giftee, Wogi and Merchants.

FSS8-43 Back end

What’s behind four cards

Wogi’s Function tab looks simple: four cards for the merchant wallet balance and the category, brand and product lists. Most of the work was behind them. I set up the back-end support in the Java services, tested every endpoint in Postman, and checked the data with SQL in pgAdmin against a backup of the Postgres database.

That’s also where you can see what those filter strings turn into: brandname:LIKE:kopi ends up as a WHERE clause.

FSS8-045 Merchants · Brand

The big one: the merchant modal

This was my biggest ticket. Every outlet got its own QR code, with buttons to copy the merchant code and download the QR as a PNG, and I rebuilt the Details modal with new Bank, Documents and Settlement tabs. One bug took a while to track down: uploaded agreements were in the database but never showed up in the modal, because the API built each brand without looking them up. I added that lookup on the Java side, so every brand now comes back with a short summary of its agreement.

Front end

React, TypeScript

Back end

Java, Spring Boot, PostgreSQL

Tools

IntelliJ IDEA, Postman, pgAdmin

Workflow

Git, GitHub, Lark Kanban