Protocol Daemon

index protocol interface

What?

Every company must deal with emails and the protocols that come with them. Saving information about the emails like, sender, receiver(s), subject, …. This can take up a lot of time for employees, especially if you are a project manager. This is why the protocol daemon was requested, it could free up a lot of time and effort for employees.

My plan for this project was to make a 'Protocol Daemon' where users can send emails to, from these emails important information will get extracted. This information will be saved to a database, users can then view this information on a web interface. On this interface users can also edit this information. It is important to differentiate between protocol entries that are in or outbound, confirmed by the user or not and set to active or inactive.

How?

One requirement was that the application was built on Node.js. This is why I opted for using Express.js as a framework for the backend. To realize the frontend, I used a combination of Ejs as a view engine and Tailwind CSS for styling. As a Database Management System, I chose to use MySQL. The application is hosted on a server owned by ChemiCloud, using cPanel I can manage the application on the server. At the end of the project, I realized a 'Protocol Daemon' that saves the information extracted in a database which is then manageable through a web interface.

Incoming mails

When users need to protocol an incoming email, they forward that email to the Protocol Daemon. This Daemon then extracts the information, saves it in the database and sends a mail back to the users containing a form with the extracted information. Users can change the information here if needed, when content, they confirm the form. This makes the necessary changes to the protocol entry in the database. The protocol entry is now marked as confirmed.

Form

Outgoing mails

The flow for outgoing emails is a little different. Users first have to send a mail to the Protocol Daemon. When received, information from this mail will be saved and the Protocol Daemon returns a mail containing the 'Protocol Number' which they have to insert in their actual mail. When the user decides to send the actual mail to their client, they can opt to include the Protocol Daemon in CC. If they choose to do so, the Daemon will see the protocol number and change information according to this mail. The protocol entry will be marked as confirmed automatically.

confirm protocol mailForm

Web interface

On the web interface, users can see all protocol entries. They are divided into 2 tables, one containing unconfirmed protocol entries, and the other containing confirmed protocol entries. Users can filter on in or outbound mails. By each protocol entry a pencil can be found. If they click on this pencil, they will be sent to a page where they can see all information about his entry. They can also edit this information. Protocol entries that have not been confirmed can be confirmed through here as well.

Protocol entries cannot be deleted. If a protocol entry is no longer needed or is faulty, they can instead mark the entry as inactive. On the web interface users can navigate to the inactive page. Here they can also set the entries back to active if needed.

Conclusion

During this assignment I learned a few different things. I learned to work in a more professional setting. I had to communicate with my colleagues in a professional way. Node.js was completely new to me, I had not built an application with Node.js and had to learn about frameworks that were built for it. View engines like Ejs was also new to me. It was fun to find how to combine this with the knowledge I had gained from my previous exeriences, and combining it with technologies I had learned before.