LINE OA Management

Overview

/line-oa-management is an account-level page: it belongs to the organization rather than to any single channel. It is therefore reachable before the user has picked a channel, and renders in a restricted layout without the sidebar.

The page serves two purposes at once:

• Channel selection — it is step 2 of the login flow. Clicking an OA card exchanges the token for one scoped to that channel and takes the user to the dashboard.
• Channel administration — adding, editing, deleting and enabling/disabling channels, plus configuring every channel setting from a single form.

The channel form gathers nine configuration sections, covering Messaging API credentials, channel details and the webhook URL, LINE Login and LIFF, API keys, GA retargeting, system attributes, message handling priority, Live Agent (Mbox) and AI configuration. Most of them are only available in edit mode.

One important constraint: the number of channels an organization can create is capped by the maxChannel value carried in the user's token.

Business Flow

1. Listing and selecting a channel

1. On open, the app checks LINE OA view permission, then sets the breadcrumb and active menu entry.
2. The most recent filter is restored from sessionStorage, falling back to page one with ten items, and the list is fetched from GET /line-oa.
3. The toolbar offers a search box, a status filter (all / active / inactive), and a counter showing how many channels exist against the maximum allowed.
4. Whenever a filter changes, the list resets to page one and the filter is written back to sessionStorage so it survives navigating away and back.
5. Results are shown as a card grid. Each card carries a cover image, a status tag, an enable/disable switch, and buttons for edit, access management and delete.
6. A "create new" card appears only while the channel count is still below the quota.
7. Only channels in the active state can be opened.
8. The access management button on a card is visible only to users with the super administrator role.

2. Entering the selected channel

1. Clicking a card calls POST /auth/login-with-line-oa to exchange the token for one scoped to that channel.
2. The profile and permission data are updated from the new token.
3. Before navigating away, permissions are reloaded from GET /user/{id}/permission. This matters because the access rule set is normally compiled only on a full page load — skipping this step would leave the user stuck with the earlier, restricted rules.
4. Cached filters from every screen are cleared and the user lands on the dashboard.

3. Enabling or disabling a channel

The switch on the card calls PUT /line-oa/{id}/status directly. On success a confirmation modal appears and the list refreshes. There is no additional button-level permission check — anyone who can reach this page can use the switch.

4. Deleting a channel

The delete button always opens a warning confirmation first. Once confirmed, the app calls DELETE /line-oa/{id} and reloads the list.

5. Per-user channel access

1. The access button on a card (super administrators only) opens a modal that loads every user from GET /line-oa/{id}/user-access.
2. Each user shows whether they currently have access to this channel; those who have never been granted specific access are tagged as having access to all channels.
3. After selecting users and saving, the list is sent to PUT /line-oa/{id}/user-access.
4. If the server rejects the change, the error is shown and the modal stays open so it can be corrected. The typical case is trying to remove the last channel a given user can reach.
5. The mirror image of this setting lives in User Management, which approaches the same relationship from the user's side rather than the channel's.

6. Creating a channel with the three-step wizard

1. The user enters the OA name plus the Messaging API channel ID and secret, and optionally the LINE Login channel details — that section expands automatically in create mode.
2. On submit, a progress modal opens showing each step in turn. It cannot be dismissed until the process finishes.
   • Step 1, validate Messaging API — calls POST /line-oa/get-oa-info to read the channel name, basic ID and cover image from LINE, without changing anything.
   • Step 2, validate LINE Login — calls POST /line-oa/validate-login. This step is skipped when the LINE Login details were left incomplete.
   • Step 3, create the channel — generates a webhook id from the channel name and the current timestamp, then calls POST /line-oa. The server registers the webhook and creates the LIFF app automatically. Any warnings it returns are surfaced under this step.
3. When every step succeeds, a "Done" button returns the user to the list. On failure only a "Close" button is offered.

7. Editing a channel

1. Opening the form with a channel id loads the record from GET /line-oa/{id} and populates every section, including reconstructing the full webhook URL from the stored webhook id.
2. The Sync button pulls the latest details from LINE. If the bot's basic ID has changed, a new webhook id is generated automatically; if it is the same bot, the existing webhook URL is preserved.
3. If the sync fails and the server identifies specific invalid fields, errors are shown per field; otherwise a modal reports that the OA could not be found.
4. The Reissue button next to the webhook URL generates a new webhook id immediately in the browser, but it is not persisted until the form is saved.
5. The Sync cover button refreshes just the cover image.
6. Saving assembles the full payload, shows a confirmation dialog, and then calls PUT /line-oa/{id}.

8. Configuration sections in edit mode

Section	What it configures
API Keys	Channel API keys as cards, with status toggle, copy, edit and delete
GA Retargeting	Enable Google Analytics tracking and set the identity parameter
System Attributes	A table of system-level attributes (key, value, data type, description) that can be referenced in messages as {{system.KEY}}. Keys become read-only once created
Message Handling	Choose the reply priority: auto response only, auto response first, or AI classifier only
Live Agent (Mbox)	Connect an external live-chat system: base URL, token, account, inbox, timeout and warning intervals, four automated messages, exit and agent keywords, department routing, and a connection test — along with the callback URL to configure on the Mbox side
AI Configuration	Select the provider and model and supply an API key. These are organization-level settings, not per-channel

9. Managing API keys

1. Keys for the channel are loaded from GET /api-key.
2. The switch on each card toggles the key's status via PUT /api-key/{id}/status.
3. The copy button uses the clipboard API with a fallback for browsers that do not support it.
4. Creating or editing happens in a modal. The key value itself is generated automatically and cannot be typed by hand — a reissue button generates a replacement.
5. Saving calls POST /api-key or PUT /api-key/{id}, always attaching the channel id.
6. Note that if saving fails, the modal simply closes without showing an error message.

Key Screens & Components

List screen

The list splits into a container (src/components/line-oa-management/list/line-oa-management.container.tsx) that owns data fetching, filter caching, channel entry, deletion and status changes, and presentational components covering the card grid, the search toolbar and the access management modal.

Form screen

A single container handles both create and edit modes, distinguished by whether a channel id is present in the URL. The presentational component groups the nine configuration sections into cards and collapsible panels.

Every field that must be copied from the LINE Developers Console has a help icon beside it, backed by a guideline modal with screenshots showing where to find that value.

Note — the form page currently has no route-level permission check, so anyone who knows the URL can reach it directly.

Creation progress modal

This modal is purely presentational. It renders a vertical stepper with each step's state and cannot be dismissed by clicking outside.

Main API endpoints

Operation	Endpoint
List channels	GET /line-oa
Read one channel	GET /line-oa/{id}
Create a channel	POST /line-oa
Update a channel	PUT /line-oa/{id}
Change status	PUT /line-oa/{id}/status
Delete a channel	DELETE /line-oa/{id}
Read OA details from LINE	POST /line-oa/get-oa-info
Validate a LINE Login channel	POST /line-oa/validate-login
GA retargeting settings	GET and PUT /line-oa/{id}/ga-tracking-settings
Message handling and Mbox settings	PUT /line-oa/{id}/message-handling
Test the Mbox connection	POST /line-oa/{id}/mbox/test-connection
List Mbox departments	GET /line-oa/{id}/mbox/teams
Per-user channel access	GET and PUT /line-oa/{id}/user-access
API key management	GET, POST, PUT, DELETE under /api-key
System attribute management	GET, POST, PUT, DELETE under /system-attribute
AI configuration	GET and PUT /ai-config

Dependencies

• Login — this page is step 2 of the login flow and the only way to obtain a channel-scoped token.
• User Management — the entry point to that page sits in this page's header (visible only with the right permission), and the channel access modal is the mirror image of the OA access setting found there.
• Webhook service — the webhook id generated here is the endpoint LINE delivers events to. If it changes unintentionally, incoming user messages will silently stop reaching the system.
• Access control — the server-side line-oa module unlocks this page together with several menu and content pages.
• External systems — Mbox for live chat, Google Analytics for retargeting, and an AI provider for message classification.
• Environment configuration — the webhook base URL must include the correct path prefix; otherwise webhook deliveries fail with a silent not-found response.

Backend Details (CMS API)

A LINE OA is the tenant unit of this system: nearly every table is scoped by OA id. The backend module behind this page is therefore the hub almost every other feature depends on.

Why these endpoints work before an OA is selected

Almost all routes in this module sit behind a guard that accepts tokens without an OA id, rather than the ordinary guard, because the OA selection page must list the available OAs before the token can identify one. With the ordinary guard, users would be stuck in a loop on the selection page, unable to fetch the list at all.

The notable exceptions are GET and PUT /api/line-oa/:id/user-access, which were moved onto the ordinary route group because the super-admin check must read the role from the request context that only the ordinary guard populates.

What the backend does at each channel-creation step

• Credential check (POST /api/line-oa/get-oa-info) — the backend calls the real LINE Messaging API to confirm the channel id, secret and access token, and pulls back the OA's name and picture. Nothing is written to the database at this stage.
• Creation (POST /api/line-oa) — the organization's maxChannels quota is always checked first, so an over-quota request is rejected server-side rather than relying only on the frontend hiding the "create" card. The new row is then created with both webhook_id and line_oa_hash generated automatically.
• Reissuing the webhook id (PUT /api/line-oa/:id/regenerate-webhook) — intended for cases where the URL has leaked. Changing it means the new URL must also be set in the LINE Developer Console, or messages stop reaching the system.
• Reverse lookup from a webhook (GET /api/line-oa/webhook/:webhookId) — resolves a webhook id back to its OA, the mechanism that lets the webhook service know which tenant an incoming event belongs to.

Deletion and soft delete

• DELETE /api/line-oa/:id is a soft delete: the data remains in the database but is flagged as deleted.
• DELETE /api/line-oa/:id/hard performs a real delete and is locked behind two conditions — the caller must be a super admin, and an explicit confirmation parameter must be supplied. The current frontend exposes no button for this route.

Permissions and security notes

• Module-level permissions are not enforced yet. The module carries policy metadata for line-oa, but it is not actively enforced. The only checks that really apply are the super-admin guards on the hard-delete and user-access routes — consistent with the frontend note that the status toggle has no button-level permission check.
• GET /api/line-oa/find-all-object has no guard at all. It returns the OA list in the shape requested via query parameter (dropdown, group, or object) without requiring a token, and should be treated as a caveat when assessing the system's security posture.
• Removing OA access has a lock-out safeguard. Saving through PUT /api/line-oa/:id/user-access writes the user_line_oa table and rejects any request that would leave a user with no accessible OA at all. That is why the modal stays open when a save is refused.

Side effects and related systems

• Redis cache — the backend caches OA records and LINE access tokens, so credential edits may not take effect immediately until the cache expires or is cleared.
• RabbitMQ — triggering a follower sync publishes a job to the line_sync_follower_user queue for a worker to process asynchronously, which is why the frontend gets an immediate response even though the data is not synced yet.
• External systems — the module talks to the LINE Messaging API and the mbox system directly over HTTP. Both the mbox connection test and the team listing hit the live mbox system at that moment.
• Audience auto-refresh settings configured here determine how the cron that refreshes this OA's audiences behaves, so the effect shows up in the audience management feature rather than on this page.
• Message handling settings decide whether an inbound message is routed to auto-response, a workflow, or mbox, which affects the behaviour of the whole automated messaging stack.