There has been a lot of talk recently about some of the new features and the direction that osTicket is heading in. In the past I've mentioned that osTicket will have individual user accounts for clients. Today I get to share a little more about this coming feature! Jared (aka greezybacon) posted the following commit notes over on github a short time ago:
This feature adds the framework for client authentication. Now, clients can register for accounts and login with a username and password to the client portal. The feature include several sub-features
Features
- Client login (via new sign-in page)
- Client registration
- Email address verification for self-service registration
- When viewing a ticket, users are encouraged to register for an account or sign-in to view other tickets
- Registration can be disabled, which will use the legacy ticket access link page
- Registration can be closed so that only staff members can register client accounts
- Login can be required for clients to create new tickets
- New tickets via the web portal can be disabled (if registration is disabled and sign-in is required)
- Ticket links in emails now give access to exactly one ticket (show related tickets is retired)
- Clients have a time zone preference, and all times are shown in the client's preferred time zone
- System time zone is pre-selected for both new clients and new staff
- Client login supports password reset via email (with configurable template)
- Client sign-in page supports a configurable header and title
- Client registration page and email templates are translatable and configurable
- Staff login page supports a configurable banner
- New staff accounts can be accessed without a temporary password (reuses the password reset feature)
- New "Access" settings page with consolidated settings for authentication and access settings
Review Requested for
- Template and view file naming conventions
- Content phrasing, especially with respect to the new content
- Look and feel as well as workflow
- Intuitiveness
- Misleading links, pages, etc.
- Missing prompts, labels, headers, etc.
- Migration of existing data and settings after upgrade from <= 1.8.2
- Lint and code quality
(source)
This of course immediately prompted an impromptu Q&A session. Here are the questions and answers (They were re-formated to make more sense):
Q: Out of curiosity how will this new system handle existing accounts? (ie in case of upgraded installations) Since these users will obv not have a password. Will they be forced to use the "forgot password link?"
Jared: Upon upgrade, there will be no existing accounts. We’ve chosen to separate the idea of users and user accounts. For instance, anyone who sends an email into the system should not necessarily have an account created with user preference, organization information, account access email sent out, etc. User’s accessing the system via email links will have the option to register for an account in the system, once the setting is enabled in the admin panel (Settings -> Access -> Client Registration Mode (set to ‘public’). New installs will ship with the setting configured as ‘public’ and upgrades will set the setting to ‘private’ (only staff can register client accounts). Once a client registers, verifies the email address, and logs in, they will have access to all their tickets, can manage their profile, etc.
Client registration will use an email verification method similar to the forgot my password since email addresses are still required for client accounts.
Q: Will there be a staff ui for reseting the account password immediately?
Jared: Peter is working in parallel on a user directory feature which will allow staff members to create, delete and manage client accounts (including resetting passwords).
Q: Will there be the traditional "ask question:provided answer" to prove who the person is before sending password reset links? Like the ones that financial institutions use. (examples: Where was your favorite place to visit as a kid? What is your mothers maiden name? etc.)
Jared: Currently, reset is done by email address verification. I’m not opposed to the Q and A option, but I personally don’t like them and generally forget the answers to the questions before I’m able to use them. I would vote for a SMS message reset instead, if we required another form of authentication.
Please join the conversation over on the osTicket.com forums here:
Upcoming osTicket Feature: User Accounts — includes commit notes and Dev Q&A