04. User manual
User manual is required read for administrator and operators that will use BlissRADIUS admin portal with everyday tasks like:
- working with clients, payment and other records
- managing accounts and usage history
- monitoring logs, client connections and authentications
Web portal reachable at servers address at default port of 8800. Provides all administrator functionality for administrators only.
Web portal with greatly reduced functionality, reachable at port 8801. All users can login there to check their user accounts. Does not provide any administrator functionality.
BlissRADIUS uses simplified model of user that embeds both client and administrator roles of the program. Depending of access level, they become administrators and receive extra portal functions.
Operator or similar. User with extra privileges in BlissRADIUS web portal.
Package, users group or service type, is way defined set of service rules under which user can be authenticated and establish internet connection. Each user is member of single account type at given moment. As a rule, account types may require payments before they become active.
Simplified model that combines account type activation/extension record with monetary transaction involved. Simply put, record of money changing hands and users service activation. Each payment is tied to account type, so if user changes account types he needs new payment.
History records describing when, how and how much user used internet connection. Holds data as date and time, MB uploaded/downloaded, time online, Calling ID/MAC/IP address associated with that session etc.
Portal access level
Each user in BlissRADIUS has his access level set to a integer value. Lowest level is 0 (no privilege) while highest is 5 (full privilege). Access level is not in any way related to RADIUS authentication, only to Admin and User portal usage. For login in to user portal minimum of level 1 is required. For admin portal, minimum is 2.
Basic rules apply no matter what:
- All newly created users have level set to 1.
- Users are unaware of other users that have access level greater than their own (they can't list them on search pages, view or edit them in any way).
- Only level 5 is allowed to change access levels of other users.
Level 5 - Superuser
Superusers have unlimited access. Only they have access to Config section with system preferences. Only superusers can change access level for any user.
Level 4 - Admin
Admin extends privileges of Cashier/Technician and Manager. Admins have access to Admin section where they manipulate NAS-es, account types etc. Admins can't change users access level.
Level 3 - Manager
Manager extends Cashier/Technician privileges with deleting users and editing/deleting payments & reminders. That includes changing users authentication parameters.
Level 2 - Cashier/Technician
Cashier can create new users, search and edit existing. Also can search and add payments and reminders and search usage logs. Cashier can't delete users, edit or delete payments & reminders. He can't change authentication parameters or access levels for users. He has full access to Monitoring section.
Level 1 - User
User have access only to My account section. He has limited read access only to his own records. Only thing he can change is his password. This is access level used in user (not admin) portal for all (even higher privileged) users. There is one exceptions with WHMCS users logging in to BlissRADIUS client portal - they can't change their passwords or list their payment records. Those functions are accessible only by WHMCS portal.
Level 0 - Unprivileged
User can't login to admin or user portal at all.
Account types, payments and user state
Account types can be combined using multiple limiting factors:
- Hourly limit (number of hours of usage)
- MB limit (incoming, outgoing and total transfer)
- Duration limited (start and stop date)
All 3 factors can be combined. Payment will be usually required to activate users account.
These are common scenarios:
Hourly limited (eg. classic dial-up) service. Enable only hourly limit and create ad least one payment with added number of hours. Each new payment will add extra hours to total limit. Once user uses all the hours, account is disabled. Top up hours with new payments. Important distinction is that user has no expiration time for service, available hours can be used years from last payment. All hours used is a sum of all usage records from users activation time.
MB limited (some form of hotspot or pay-as-you-go setup) works exactly the same as hourly limited scenario. You can fine tune rules by specifying exact upload, download or total MB limit.
Combination of hourly and MB limit (advanced hotspot). Each payment top up hours and MB's and first limit to be reached will disable account.
Duration limited (classic flatrate, monthly service etc.) account types work by looking only at payment start and stop time. Important distinction is that accounts that are duration limited will only have one payment at given moment that define limiting factors, unlike hourly and MB limited only accounts that usually have multiple payments. Once stop time is reached, account is disabled. If there are multiple payments with overmatching start/stop intervals, payment with closest start date will be chosen when checking if account is active.
Duration limited + MB and/or hourly limited (more complex form of monthly service). Here you have a monthly service that will end on stop date, or even before that if MB or hourly limit is reached. Only way to extend prematurely terminated service (before stop time is reached) is to create new payment (not advised way) or to edit current payment and top up MB or hours (advised way). MB and hours used in duration limited account is sum of all usage records from payment start, not from users activation time.
Keep in mind that user accounts have activation time which is time of last account type change (or users creation time). Only payments and usage records created after activation date will be accounted for (and if you are using duration limited accounts, only usage between payment start and stop time will be accounted).
You can manually change activation date, but be careful that payments account type must match users current account type. This, along with incorrectly configured activation time, is most common source of problems when user has valid payment but account is disabled.
Copyright © 2014 - 2019 LightBulb Software™ All Rights Reserved.
- BlissRADIUS Embedded™ 1.7 maintenance release is out.
- BlissRADIUS Embedded™ 1.6 is out with incremental improvements and new usability features.
- BlissRADIUS Embedded™ 1.5 is released with new proxy features and advanced caching for better resilience.
- BlissRADIUS Embedded™ 1.4 maintenance release is out! No significant changes, lot of small fixes. And we finally updated documentation on custom integration.
- BlissRADIUS Embedded™ 1.3 is released. It is incremental release with more fixes and tweaks than new features.
- BlissRADIUS Embedded™ 1.2 is out! It brings many performance and stability enhancements.
- BlissRADIUS Embedded™ 1.0 is out! This is important milestone that marks more than a year of successful production use. 1.0 is backward compatible with 0.x and brings incremental improvements and bug fixes.
- BlissRADIUS Embedded™ 0.9 brings integration with Blesta billing. There is also a new "local" standalone mode to run program without third-party billing. Manual has been updated accordingly.