Customer card, fields and permissions
What the operator sees on the right side of a BILLmanager ticket, how to set up the card fields, and who is allowed to do what.
What the operator sees
- The “Service info”, “Customer info” and “Ticket info” cards. On a module channel their fields are configurable (see below). With an API connection the same cards are filled from BILLmanager's summary of the ticket, and what they show can't be changed; if the ticket isn't linked to a customer, there are no cards.
- The customer's profile and balance.
- “Services”: the customer's services except expired ones (suspended ones included), with their IP (every address, with extra ones under “+N”), host, OS, data center, expiry date and auto-renewal. Three are shown right away, the rest open with “All”.
- VPS and dedicated servers get one power button: “Stop” on an active service, “Start” on a suspended one (if permitted). There's no restart. On a module channel a service also has “Log in to VM6”; with an API connection there's a “🖥 VMs in VMmanager” block with a “Sign in to VMmanager 6 as customer” button instead. On a module channel these buttons also depend on the gateway checkboxes (see below).
- “Recent payments”: up to the last five.
- The “Open in BM” link, which opens the ticket in the BILLmanager panel.
The service password is masked with dots and revealed with the eye icon. In streamer mode it stays blurred even after you reveal it.
If the ticket isn't linked to a BILLmanager customer, the card says so (“This ticket isn't linked to a BillManager client…”). With an API connection the card also warns when the person writing in the ticket isn't the one whose BILLmanager account the customer is linked to.
Card fields (module)
On a module channel, the channel card has a “Sidebar fields” tab. It sets which BILLmanager values appear in the “Service”, “Client” and “Ticket” cards, in what order and under what labels. SupportHub sends the module only the field names, and the values are collected on the BILLmanager server; for these three cards, only the fields you show leave it. The customer profile, the services list and payments are sent regardless of this setting. By default the “Service” card includes the password — remove it if operators don't need it.
- “Choose a value…” → “Add field”. The “Move up” / “Move down” arrow buttons change the order, and “Remove” takes a field out. Changes apply after “Save”.
- You can replace the sidebar label with your own (up to 80 characters). A card holds up to 40 fields.
- A card with no fields is hidden in the ticket. “Defaults” brings back the standard set.
- A tag on each field shows where it comes from: built-in, custom or Omnidesk.
If the module is outdated, rejected the request or didn't respond, the tab says so at the top, and you can't edit the fields until the module responds.
Custom fields via SQL
Custom values are defined in a JSON file on the BILLmanager server: /usr/local/mgr5/etc/supporthub/custom_fields.json (create it yourself; the module reads it as root). In the layout these fields get custom.<name> keys. The format is the same as the Omnidesk module's: if the server already has its file /usr/local/mgr5/etc/omnidesk/custom_fields_values.json, those fields are picked up automatically (with omnidesk.<name> keys). There's an example in /usr/local/mgr5/share/supporthub/custom_fields.example.json.
{
"vip": {
"entity": "user",
"name": "VIP",
"type": "bool",
"sql": "SELECT IF(COUNT(*) > 0, 'true', 'false') FROM ... WHERE u.id = __id__"
}
}__id__ is replaced with: user is the user who owns the customer's account, case is the ticket number, and item is the ticket's service.| Field | Type | Default | Description |
|---|---|---|---|
| entity | user | case | item | — | What __id__ is replaced with: user is the user who owns the customer's account, case is the ticket number, and item is the ticket's service. |
| name | string | — | The field's default label. |
| sql | SELECT | — | A single SELECT. The value is the first column of the first row; an empty value hides the field. The query runs read-only and for no longer than 2 seconds; all custom fields of a ticket get 5 seconds in total. |
| type | string | text | text, multiline, date, datetime, bool (true/false → “Yes”/“No”), list (the option number from options, counting from 1). |
| sensitive | true | false | true | Hide the value in SupportHub streamer mode. |
Operator permissions
Permissions are set on the “Permissions” tab of the channel card; owners and admins can change it. Each permission can go to “All operators”, “All except selected” or “Only selected”. The project owner (and the platform admin) can do everything, whatever the settings; project admins follow the permissions just like operators. Without an action permission, an operator doesn't see the matching button. Without “View customer card”, the whole BILLmanager card in the ticket is replaced by a “BillManager unavailable” error, and SupportHub shows a no-access window.
| Field | Type | Default | Description |
|---|---|---|---|
| View customer card | read | everyone | The whole BILLmanager card in the ticket, including the service password and the “Open in BM” link. |
| Open in BillManager | read | everyone | The link to the ticket in the BILLmanager panel. |
| View customer VMs | read | everyone | Needed on an API connection for the “VMs in VMmanager” block and the start and stop buttons. Has no effect on a module channel. |
| Sign in to VM as customer | action | no one | “Log in to VM6” on a service (module), or signing in to VMmanager as the customer (API). Grant it explicitly. |
| Manage VM (start / stop / reboot) | action | no one | The “Start” / “Stop” buttons on VPS and dedicated servers and “Reboot” on a VPS, and the same steps in macros. Grant it explicitly. |
| Money: free prolongation and bonuses | action | no one | Running macros that prolong a service for free or add a bonus to the balance. Only the project owner can grant it. |
On a module channel, “Log in to VM6”, start and stop from the ticket are recorded in the Audit Log of the platform admin panel: who did it and on which service. For start and stop the entry also shows the result, including when the module refused or didn't answer.
Any action on a service — sign-in, start, stop, reboot — only goes ahead for a service of this ticket's customer: SupportHub checks it against the customer's services in BILLmanager first, and the module checks again on its side. Another customer's service is refused, and the attempt is recorded in the audit log. Stop and reboot ask for confirmation, and after the action the ticket gets an internal note saying who did what. Reboot is for VPS only.