Rich Message Management

Overview

A Rich Message is a message set built from up to five content items and delivered to LINE users as a run of consecutive bubbles. This module is where that content is assembled, where each item is checked for completeness, and where the result is previewed as it will appear on a chat screen.

Its primary users are content and marketing teams.

An important point: Rich Messages are not sent from this page. This is a content library that other modules draw from — campaigns, auto responses, trigger rules and workflows. Scheduling and delivery statistics live in those modules, not here.

Each content item can be one of six types:

Type	Description	Completeness criteria
Text	A plain text message	Non-blank text
Image	A single image	An image file is present
Video	A video with a thumbnail	A video file has been uploaded successfully
Tappable image	An image divided into clickable regions	An image file is present (tap areas are not required)
Flex	Hand-written Flex JSON	JSON content is present
Template Message	A reference to an existing template	A template is selected and its content loaded

Tappable images differ from rich menus in that there are no ready-made layout templates — every region must be drawn by hand on the image.

A Rich Message can also carry one Quick Reply set, which appears as buttons below the last message.

Business Flow

1. List screen

1. On open, permissions are checked and the last filter is restored from sessionStorage.
2. The table shows a row number, the Rich Message name (which links to the detail view), the creation date (labelled as Bangkok time), and the action buttons.
3. Four actions are offered — view, edit, copy and delete — with no business rules disabling any of them in any state.
4. The filter has two inputs: search by name, and a creation date range. Dates entered are interpreted as Bangkok time and converted to UTC before the request is sent.
5. Deletion always requires confirmation.

Worth knowing — the clear-filter button on this page clears the cached filters for every screen in the system, not just this one. The time picker in the date-range filter also disables times already past, which does not make sense when searching historical data.

2. Assembling a message set

1. The form supports four modes: create, edit, copy and view.
2. The screen is split in two. The left side holds the inputs — the Rich Message name, the Quick Reply selector, and the content items. The right side holds a preview pinned to the top of the viewport so it stays visible while scrolling.
3. Each content item is a card with a completeness indicator in its header and buttons to move it up, move it down, or remove it. Removal is unavailable when only one item remains, and removing an item that is already complete requires confirmation.
4. The add-item button is disabled once five items exist, in view mode, or while any item is still incomplete.
5. Changing the type of an item that is already complete prompts a warning first, since the existing data for that type is cleared.
6. The order of items in the form is the order of bubbles the LINE user will see, so moving items up and down changes the real delivery order.

3. Requirements per content type

• Text — up to 500 characters, with a live character count.
• Image — accepts JPG, JPEG and PNG up to 10 MB. The file's MIME type, extension and size are all validated before it is accepted.
• Video — accepts MP4, M4V and MOV up to 200 MB.
• Tappable image — accepts JPG and PNG up to 10 MB, and must be at least 1040 pixels wide. Once uploaded, the tap-area editor opens automatically.
• Flex — JSON is entered in a text area and validated as parseable JSON.
• Template Message — chosen from the list of active templates, with a button to reload that list.

4. The video upload sequence

Video upload is a separate step from saving the form, and begins as soon as the file is selected:

1. The browser generates a thumbnail itself by capturing the frame at the one-second mark.
2. The video and thumbnail are uploaded to the server, with a progress bar shown on that item.
3. On success, the returned video and thumbnail locations are stored, so saving the form later sends URLs rather than files.
4. On failure, an error is shown and that item's values are cleared so it can be redone.
5. Videos that have not finished uploading do not appear in the preview.

5. Setting tap areas on an image

1. The tap-area editor shows the image on the left, scaled to a fixed display width with proportions derived from the image's real dimensions.
2. Users drag on the image to draw a rectangle, in any direction. The outline is a green dashed line while drawing, turning red with a warning when it overlaps an existing area.
3. To be added, an area must not overlap an existing one, must be reasonably sized, and the total must stay within 20 areas.
4. Hovering an existing area switches the editor into move mode, so it can be repositioned without drawing a new area on top. Moves are constrained to stay inside the image and away from other areas.
5. Areas are labelled A, B, C and so on, and deleting one relabels the rest automatically.
6. Each area can carry one of three actions: open a link, send a message (with autocomplete drawn from the auto-response keywords), or place a call.
7. The save button stays disabled until at least one area exists. In view mode, drawing, dragging and deleting are all disabled.

Technical note — area coordinates are stored relative to the on-screen display size, not the original image dimensions. The reference size is stored alongside them so the receiving side can scale back correctly.

6. Preview and saving

1. The preview updates automatically with a short delay as the user types, showing only items that are complete.
2. If a Quick Reply is attached, its buttons are fetched and rendered below the last message.
3. The save button becomes available when no validation errors remain, a name has been entered, and every content item passes its completeness check.
4. Creating and copying save immediately without a confirmation dialog; editing opens a confirmation first.
5. When the server reports errors that identify a specific item and field, the message is attached to that item and it is marked incomplete. Otherwise an error dialog is shown.

Key Screens & Components

List screen

The list container (src/components/rich-message-management/list/rich-message-management.container.tsx) owns the table, filters, pagination and deletion, with the table and filter form as separate presentational components.

Form screen

The form splits into a container handling data loading and transformation, payload assembly and error mapping, and a large form component covering the rendering of every content type, file validation, and video upload.

When existing data is opened for editing, image URLs are converted back into files so they can be displayed and replaced. Videos use a placeholder file and keep their existing URLs, avoiding a download of the real video.

Tap-area editor

This modal (src/components/rich-message-management/form/modal/action-spot.tsx) brings drawing, dragging, resizing, overlap detection and per-area action configuration together in one place.

Completeness helper

The per-item completeness check lives in a single file and is reused in four places: the status indicator in each card header, the add-item button's enabled state, the save button's enabled state, and the filter that decides which items appear in the preview.

API endpoints

Operation	Endpoint
List Rich Messages	GET /rich-message
Read one Rich Message	GET /rich-message/{id}
Dropdown list for other modules	GET /rich-message/find-all-object
Create or copy	POST /rich-message
Update	PUT /rich-message/{id}
Delete	DELETE /rich-message/{id}
Upload a video with its thumbnail	POST /rich-message/gen-thumbnail-video
Template message list	GET /template-message/find-all-object
Template content	GET /template-message/{id}
Quick Reply data	GET /quick-reply/{id}

Hard-coded limits

Five content items per set, 20 tap areas per image, images up to 10 MB, videos up to 200 MB, tappable images at least 1040 pixels wide, text up to 500 characters, tap-area text up to 400 characters, and phone numbers up to 10 digits.

Dependencies

• Template Message — the template content type depends on that module for both the selectable list and the content rendered in the preview.
• Quick Reply — one set can be attached per Rich Message and is rendered in the preview.
• Auto Response — the text field on tap areas offers autocomplete drawn from auto-response keywords.
• Rich Menu — the two modules share the tap-area data model and the same letter-labelling scheme.
• Downstream consumers — campaigns, auto responses, trigger rules and workflows all pull the list of active Rich Messages to choose the content they will send.
• Access control — the list page uses the Rich Message module's permission as expected, but the form page is gated by the LINE OA Management permission instead. This inconsistency is worth keeping in mind when assigning permissions.

Backend Details (CMS API)

The backend treats this module as a library of reusable messages, consumed primarily by campaigns and auto responses — matching the frontend's note that Rich Messages are never sent from this page.

Rules the backend applies on save

• Duplicate names are rejected with error code RMS_001. Two Rich Messages cannot share a name within the same OA.
• Flex content is submitted to LINE for real validation, not merely checked for well-formed JSON. If LINE rejects it, the response carries error code RMS_002. This explains why JSON that passes the frontend check can still fail to save — the frontend validates syntax, while LINE validates the Flex Message structure.
• Attachments are uploaded to object storage through the shared storage service. What lands in the database is the file's location, not the file itself.
• Both create and update accept multipart data, since attachments travel alongside the other fields.

Video thumbnail generation

POST /api/rich-message/gen-thumbnail-video is a separate endpoint that takes a video file and returns a preview image. It exists because LINE requires every video block to carry a preview image, making this a mandatory step rather than a nicety.

Permissions and deletion

• Every route is wrapped in ModuleGate for the rich-message module, and it is genuinely enforced. If the module is disabled for an organization, neither the list nor the form works regardless of what the frontend permission check decides — which limits the impact of the form-page permission inconsistency noted above.
• Per-action permission metadata exists but is not enforced.
• GET /api/rich-message/find-all-object, used by other modules to populate dropdowns, carries no permission metadata at all, matching the previous system's behaviour.
• DELETE /api/rich-message/:id is a soft delete; hard deletion requires super admin plus an explicit confirmation parameter.

Side effects worth knowing

• Redis cache — the backend caches both the list and individual details, using the same keys and expiry as the previous system.
• Editing a Rich Message affects whatever references it. Auto response reads the Rich Message table directly, and campaigns assemble their content from this data at send time, so editing content after it has been attached to a campaign or a response rule changes what actually goes out.