- Date: June 9, 2025
- Categories: Product Development
This is an application for a company that creates secure environments for individuals, businesses, and organizations, both public and private. They protect homes from burglars and intervene in sensitive situations when alarms are triggered. I was contracted for this project and contributed partially. Some of the work I completed includes the authentication module, the client/agent chat, the alarm alerts, and integrating several views in the billing and service payment sections for clients. I developed the authentication, client/agent chat, notifications, and alarm alerts modules as a full-stack developer.
For the authentication module, the company requested a simple way for their customers to access their accounts without the need for manual user registration. This was necessary because we couldn’t scale the alarm system to the new app due to certain limitations. The existing alarms included a user_id that corresponded to clients already registered in their system. Using this data, I developed an API to synchronize their users with our Laravel app in real-time. This allows users to log in using their mobile number instead of an email, with their password set as their phone number. To ensure security, access is only granted after completing a two-factor authentication (2FA) step that verifies a code sent to their phone.
Regarding the Alarm Alerts module, I am integrating with the company’s alarm system database, where every alarm triggered for their customers is registered. I listen to these alarms using a custom API that I developed. This allows me to receive the alarm information in real-time and store it in our MySQL database, which holds the app data. Before storing the data, the user is immediately notified within the app in real-time, even if they are not actively using the app at that moment. Below I’m listing all features that I’ve implemented in this module.
Alarm Alert Module Features
-
Ability to activate an alarm for a specific client (this was used for simulation)
-
When an alarm is activated:
The client receives a real-time notification about the alarm. -
When an alarm is activated:
If the client is currently using the app at that moment, a modal window opens asking to confirm whether it is them or not (“Am I the one?” or “No, I’m not”). -
When an alarm is activated:
The client is also notified via system notifications even if they are not actively using the app at that moment. They can access the notifications manually and respond. -
When an alarm is activated:
If the client confirms “Yes, it’s me,” the issue is considered resolved and the agent is not notified. -
When an alarm is activated:
If the client responds “No, it’s not me,” the agent is immediately notified. The alarm status is updated indicating that patrol intervention is required. -
If the agent does not manually close the case, the system automatically closes it after two hours, considering it resolved. (This applies to alarms with status “Patrol needs to be called.”)
-
When an alarm is activated:
If the client does not respond within 1 minute, the agent is immediately notified that the client did not respond for that event. The notification automatically reflects this status. -
When an alarm is activated:
If the client does not respond within 1 minute or responds “No, it’s not me,” the agent is notified via notifications. The agent also has a DataTable with live records of new alarms, which are highlighted with blinking red and black backgrounds to draw attention to new events. -
When alarms with blinking colors appear in the agent’s DataTable, the agent can change the status on the right side, for example, to call the patrol.
-
The agent’s Alerts DataTable is connected with sockets to receive real-time information for important events as described above.
-
Similarly, the client has their own DataTable with information about executed alarms. The client also has access to detailed logs for each individual alarm.
Chat Module Features
-
Integration with Notifications
-
When a client sends a message for the first time, it is sent to all agents (considered a general Offline line).
-
All agents receive a notification that client X has sent a message.
-
The client is considered ONLINE as long as their chat window is open. When the window is closed or minimized, the client is considered Offline.
-
The first agent who opens the notification establishes a chat line between the two users (communication becomes online).
-
When both users (agent and client) are online, they do not receive notifications for new messages because messages are delivered and seen in real-time within the chat window.
-
Once communication starts between one agent and client, the same notification cannot be opened by a second agent (because agent 1 and client X are already connected, considered a BUSY line).
-
If the conversation ends and no communication happens between agent 1 and client X for 2 hours, the chat line is disconnected, and all messages are deleted.
-
After the line is disconnected, if the same client X sends a message again, the same procedure applies: whichever agent (agent 1 or 2) opens the message enters the chat line, the line is marked as LIVE by that agent, and other agents cannot join the line without closing the existing one.
-
When the agent and client currently connected are offline, messages are sent offline. New incoming messages trigger notifications that can be accessed by clicking the corresponding notification.
-
One agent can chat with multiple clients simultaneously but can only be LIVE (online) with one client at a time. The client whose notification the agent clicks is considered LIVE in chat.
-
Whenever agents send messages to clients, clients receive notifications in the same way.
-
A cron job runs every 2 hours to check for inactive chat lines. If no messages have been exchanged for 2 hours, those chat lines are deleted along with their associated chat IDs and message history.
Below, I’m attaching some screenshots of the app overall:
