Release MR132

Account

add_followme_number
add_followme_number_list
update_followme_number_list

"redirect_number", "name" and "domain" are no longer mandatory when a follow-me number is created, matching the update path which already allowed them to be empty. A follow-me number can now exist with call forwarding enabled and no destination configured. The format of a supplied "domain" is still validated, and a non-UDP transport without a domain falls back to UDP.

Account

get_account_followme

"redirect_number", "name" and "domain" are now nillable in the FollowMeNumberInfo structure - when empty they are returned as null instead of being omitted from the response, matching "period", "period_description" and "max_sim_calls".

Account

update_followme_number_list

Pushing more than one brand new entry (without "i_follow_me_number") in a single request is now rejected for the Simple forwarding and Forward to SIP URI modes, which allow only one follow-me number per account. Previously this limit was not enforced for new entries added through this method.

Add follow-me numbers one per request for these forward modes.

Template

clone_template

A reseller can now clone a rate upload template under a name that is already used by an administrator - the new name is checked only within the owner's own namespace instead of across the whole environment, and the clone is stored under the reseller's own ownership. Templates of other types keep the administrator namespace and are unchanged.

Template

update_template

Renaming a template to a name already taken within the same owner namespace is now refused with the "update_template.not_unique_name" fault instead of failing on a database constraint. Changing only the letter case of the current name is allowed.

AccessControl

generate_mfa_config
confirm_mfa_config

A user who must enroll in two-factor authentication before signing in can now complete the mandatory enrollment while holding only the Read permission on their own two-factor authentication (Auth_Parameters.mfa). Previously these methods required the Modify permission, which also let the user disable two-factor authentication for themselves. The permission check is waived only while the mandatory enrollment is still pending (two-factor authentication enabled but not yet configured); disabling it via set_mfa still requires Modify.

Notification

add_notification_preset

A notification preset of the "user" type can no longer be created with an owner ("i_customer") - such a preset could never be assigned to anyone, because only a preset without an owner can belong to an administrator. A reseller session is offered the "customer_class" type only; an administrator can still create a "user" preset without an owner.

Create user-type notification presets without an owner; use the customer class type for presets managed by a reseller.

User

get_user_info
get_user_list
add_user
update_user
delete_user
get_notification_list
get_notification_category_list
update_notification_list
get_rt_ticket_list

Administrators whose login is listed in the "Superusers" configuration option are now protected from API users that are not superusers. "get_user_info" and "get_user_list" return such a record reduced to "i_user", "login", "description", "email", "status", "class", "i_acl", "i_role", "role_name", "hide_personal_info" and "is_super_user" - the remaining fields, including "api_token", are withheld. "update_user", "delete_user", "get_notification_list", "get_notification_category_list", "update_notification_list" and "get_rt_ticket_list" return the "Access to the superuser is enabled only for superusers" fault. "add_user" and "update_user" additionally refuse a login listed in that option with the "Only a superuser can assign a login from the Superusers list" fault.

An integration that has to read or manage superuser records must authenticate as a superuser.

WebLog

get_web_log_list

The web log records about an administrator whose login is listed in the "Superusers" configuration option are no longer returned to API users that are not superusers, for any filter and for a request with no filter. What a superuser did to other entities stays visible to every administrator of the environment.

Customer

make_transaction
get_customer_invoices

Billing periods of a customer with invoicing turned off are now closed with a hidden internal invoice that records the period's charges and the total debt; such invoices are not returned by get_customer_invoices. The part of the payments that covered such a period's charges used to become non-refundable at the period closure (it was erased from the refundable amount). Now it stays refundable, and a manual refund of it is accepted.

Invoice

get_invoice_info
get_invoice_list

Billing periods of a customer with invoicing turned off are now closed with a hidden internal invoice that records the period's charges and the total debt; such invoices are not returned by these methods. The first regular invoice issued after invoicing is turned on again collects the not-invoiced debt through the "prior_balance" field.