=Paper=
{{Paper
|id=Vol-3179/Short_14.pdf
|storemode=property
|title=Information System for Meetings, Conferences and Trainings with Voting Possibility
|pdfUrl=https://ceur-ws.org/Vol-3179/Short_14.pdf
|volume=Vol-3179
|authors=Oleksii Bilyk,Iryna Vergunova
|dblpUrl=https://dblp.org/rec/conf/iti2/BilykV21
}}
==Information System for Meetings, Conferences and Trainings with Voting Possibility==
https://ceur-ws.org/Vol-3179/Short_14.pdf
Information System for Meetings, Conferences and Trainings
with Voting Possibility
Oleksii Bilyk and Iryna Vergunova
Taras Shevchenko National University of Kiev, 64/13, Volodymyrska Street, Kyiv, 01601, Ukraine
Abstract
The paper presents an automated system for conducting and documenting meetings of various
kinds. A special feature of the developed system is the possibility of voting among the partic-
ipants of the meetings and the generation of protocols based on the results of voting.
The developed system is a closed online platform. Users of this system receive some roles that
can be changed as needed. The user subscribes to the channel of the relevant meeting and can
see in real time the changes made by other users and make their own adjustments. The option
“Voting” was added to the questions and the voting process included in the life cycle of the
consideration of the issue. After the meeting, the necessary protocols are formed automatically.
The implementation of this system is presented on the example of the current work of the
Academic Council of the Faculty of Computer Science and Cybernetics.
Keywords 1
Online platform, JWT Web Token, domain object, roles of participants, protocols, voting
1. Introduction
Recently, the world got acquainted with life in quarantine, with its beginning, people had to transfer
professional activities online. The use of information systems with the ability to conduct video confer-
encing, document management and voting allows you to effectively perform work duties remotely,
increases the comfort of creating and processing documents. Today, all developed countries are working
on the development and implementation of such systems. Prominent examples are parliamentary elec-
tronic voting systems, corporate electronic document management systems, and automation systems
for meetings and sittings. In 2020, Intecracy Group [1] presented a commercial solution for video con-
ferencing with the possibility of voting. The system developed by this company is intended for use
during meetings, which should result in legally significant actions. For example, meetings of the board
of directors in business structures, discussion of regulations or decisions in the public sector, etc. Usu-
ally such meetings require a personal presence, which is a big problem in quarantine. Integration with
the Megapolis.DocNet document management system is also possible [2]. However, all these systems
are either automated voting systems or electronic document management systems. It should be noted
that after the increase in the popularity of the Zoom service, the "Poll" functionality was added, in which
you can put to the vote from one to several questions with the appropriate answer options, but the
functionality is part of the video call. For example, after the transition to the online mode, the Academic
council at the faculty of computer science and cybernetics used the Zoom video call service for meet-
ings, and Google Forms for voting. Invitations to the meeting, agenda and invitations to vote were sent
to council members by e-mail. Of course, in resolving the issue of communication and voting, the
minutes of the counting commission were further processed manually, the meeting plan and all other
documents for the work of the Academic Council were distributed as text documents, and invitations
were sent to the council members by mail. After each meeting, the secretary manually formed the
minutes of the meetings and the counting commission, as well as numerous extracts from the minutes.
Information Technology and Implementation (IT&I-2021), December 01–03, 2021, Kyiv, Ukraine
EMAIL: alexwhitecorp@gmail.com); vergunova@hotmail.com
ORCID: ; 0000-0003-3052-9143
©️ 2022 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
398
2. Problem Statement
Ensuring that employees work effectively remotely in modern conditions is important. Remote
meetings with support of various accompanying functions are also urgently needed. For this reason, the
presented system was created, which allows to automatically notifying the participants about the meet-
ings, to gradually form the minutes during the meeting, to vote with the results, etc.
Of course, some of the processes can be performed on different platforms and services (for example,
sending invitations and notifications to meeting participants, forming minutes of meetings according to
templates), which is not very convenient.
Therefore, the aim of our work was to create a system in which you can automatically perform the
following processes: meeting planning; sending invitations and notifications to participants; formation
of the agenda of meetings and submission of issues for consideration; voting of the present participants
on specific issues with processing of results; formation of protocol cases according to a template (pro-
tocol of the counting commission, minutes of the meeting); management of roles and positions of par-
ticipants; storage of general protocols and generated protocols of voting results.
The main tasks of the presented work are:
to build an online platform that allows you to efficiently, conveniently and fully perform the
preparation and conduct of meetings, to generate and to view appropriate protocols;
to demonstrate the implementation of the system on the example of the current work of the
Academic Council of the Faculty of Computer Science and Cybernetics.
Achieving the goal of the work leads to an online platform, which, unlike the existing ones, is at the
same time a system for electronic document management, a system for preparing and holding meetings
and a system for voting.
3. Technical solutions of basic problems
The first question was the selection of technologies that will be used to develop the platform. When
considering the available variants, the emphasis was on reliability and productivity on the one side, as
the meetings provide for real-time holding, and the possibility of easy expansion on the other one. As a
result, it was decided to use the Spring Framework with its components (Spring Security, Spring MVC,
Spring Data JPA, Spring WebSocket) to develop the backend side. On the frontend side it was decided
to use the Vue.js framework, because, in the subjective opinion of the author, it is more convenient than
React.js and lightweighter than Angular.js (although we are talking about platform development, An-
gular.js is too heavy in this situation). PostgreSQL is used as a database because it correspond the needs
of the project.
When developing closed online platforms, especially those that provide documentation, secret ballot
and division into different levels of access depending on the position and authority of users, the first
issue is the choice of protocol and implementation of the authentication and authorization process. To
develop the online platform "Academic Council" it was decided to abandon the standard approach with
HttpSession, when to keep the user's status authorized in the system using cookie data and use the
protocol authentication by tokens [3]. This method is most often used in the construction of distributed
systems Single Sign-On (SSO), where one microservice (service provider or relying party) delegates
the function of user authentication to another microservice (identity provider or authentication service).
Thus, we immediately design the architecture of our code so that you can easily switch to a microservice
architecture and perform horizontal scaling in case of successful project development.
The implementation of this method is that the identity provider (IP) provides reliable information
about the user in the form of a token, and the service provider (SP) application uses this token to iden-
tify, authenticate and authorize the user. There are several standards that define the protocol of interac-
tion between clients and IP/SP applications and the format of tokens. Among the most popular standards
are OAuth, OpenID Connect, SAML, and WS-Federation.
We chose the OAuth standard and the JWT Web Token format [4, 5]. The specified technology was
used to verify user authentication according to the following algorithm (Figure ):
1. The user makes the first authentication request using the "e-mail / password" pair.
2. The authentication service verifies the received data, in case of success creates a short-term
Access Token [6] and a long-term Refresh Token [7] and sends them to the user.
399
3. When a user requests a platform API, he adds the previously received Access Token to it. When
processing a request with an added access token, the server validates the received token and can author-
ize the user without additional requests to the database.
4. After the expiration time of the access token, the user requests the platform API, adding a Re-
fresh Token to it. In response, the server creates a new access token.
Figure 1: Algorithm of getting and using JWT token
To update the session with this platform, the user does not need to re-enter the pair e-mail / password.
From the server point of view, this approach reduces the load on the database in the security layer,
because you do not need to perform requests every time to verify the user and get general data about
him – just check the validity of the token, and the required data is already encrypted. The issue of
protection against compromised tokens remains open. It was solved as follows: to shorten the lifetime
for access tokens, and in case of suspicion to remove the update token from the database, so the attacker
immediately loses access to the platform. It should be noted that the platform is closed, so user can
register only by receiving an invitation. The chairman of the Academic Council and the Secretary may
invite a new participant. To do this, fill in the necessary information about the user, including his e-
mail. After filling in all the fields to the specified mail finds an invitation letter with a link to register.
Password recovery is also available. To do this, a link with a code is sent to the user's mail.
The next issue after authentication is the distribution of user roles by different levels of access and
authority. The system uses the following roles for users:
member of the Academic Council;
member of the counting commission;
member of the Academic Council;
chairman of the Academic Council;
secretary of the Academic Council;
administrator.
In the specified list, the roles are listed in ascending order of access level. In this case, the secretary
has more power, because the main function is moderation, which in a normal meeting and performs the
secretary. The level of access determines the ability to use one or another functionality of the platform.
For example, the minimum level of access to create a new meeting is the secretary of the academic
council. You can view the current roles of the members of the Academic Council on the "Participants"
page (Figure 2). You can also manage roles of users on this page using the appropriate drop-down
menu, if available. If a user has been appointed or removed from office – he will receive a notification
in the Notifications center (Figure 3).
The full list of meetings of the Academic Council is available for viewing on the “Meetings” page.
You can also get brief information about the meeting, including the date and time, a link to the video
conference and status. The meeting may have one of the statuses:
400
moderation (completion of the necessary data and preliminary formation of the agenda; avail-
able for viewing only by the chairman and the secretary);
planning;
online (meeting now);
completed.
Figure 2: Roles setting menu popup
Figure 3: User notifications center
When you go to the meeting viewing page, the communication protocol with the server on Web-
Socket is changed [8-10]. The user subscribes to the channel of the relevant meeting and can see in real
time the changes made by other users and make their own adjustments. He can edit general information
on the meeting view page. Autocompletion is implemented to simplify the editing process (Figure 4).
To do this, the minutes of meetings over the past years were analyzed and the most frequently used
words and phrases were identified. They were structured and recorded and a special dictionary.
The words search in the dictionary is performed taking into account the beginning of the text that
was entered, or through the use of abbreviations. Autocomplete information is also available from user
profiles so you can quickly specify the rank and achievement of the desired meeting participant. Since
in the Ukrainian language there is a concept of cases, all words and phrases are stored in the dictionary
in all possible forms of declension. Also on the meeting page is the formation of the agenda: sections
and issues are created for consideration. If necessary, you can add files (reports, presentations, state-
ments, etc.) to each question, which can be downloaded by all users of the system. If the consideration
of the created issue involves the voting of the members of the council, then the option “Voting” is added
to the question and the voting process will be included in the life cycle of the consideration of the issue.
This item was one of the key elements of the idea of creating this platform, as it is necessary to perform
many standard movements to organize, conduct, obtain voting results, and then create the appropriate
protocol in the desired format. It is also interesting that some votes must be secret, so it is not possible
to simply keep what one or another participant of the meeting in an explicit form answered. You need
to use a cryptographic approach.
Accordingly, the existing protocols of secret ballot were considered [11]. There were certain require-
ments for implementation. Our voting system must meet the standard requirements for secret ballot
systems [11]. Namely, it requires that no one but the voter should know his choice, only registered
participants can vote (they can vote only once) and the decision of the voter cannot be changed by
anyone. In addition: each registered participant may be sure that his vote has been counted and can
change his opinion and change his new choice over short time period; there is operator authentication;
401
we can find out who took part in the voting and who did not; the system maintenance should not require
a lot of resources and it must be fault-tolerant in case of technical malfunctions, unintentional and crim-
inal actions. As for the protocols available today, the simplest protocol of secret ballot is essentially a
correspondence with electronic signatures between the election committee and a large number of voters.
The first interesting protocol worth considering is the Two Agent Protocol. The basic idea is to replace
one election agency with two so that they control each other.
Figure 4: Create and edit agenda items using autocomplete
Let's have a validator, whose duties include preparation of lists, and also admission or non-admission
of the participant to voting. It creates a set of identification tags (exactly as many as registered partici-
pants) and sends one tag through the secure channel to each registered participant without information
about who owns the tag. There are many different options based on the protocol of two agents. But with
some complications these are:
1. Fujioka-Okamoto-Okhta protocol, slightly complicating the protocol, this solution uses mask-
ing encryption and partially solves the problem of collusion between the two agencies. It allows you to
make sure that the document is genuine and signed by an authorized user, but does not let you know
what data it contains.
2. Sensus protocol (as modification of the Fujioka-Okamoto-Ohta protocol). A characteristic fea-
ture here is that upon receipt of an encrypted message from the participant who voted, it is immediately
added to the list of published results, and the signed ballot is additionally sent back to the participant as
a receipt. This makes it possible not to wait until all other participants have voted and to end the voting
(at the same time it becomes additional proof that a particular participant took part in the voting).
3. He-Su protocol. In it the key of the registered participant is signed with the blind signature (but
the specified hash function is used and the method of blind encryption must be stipulated in advance).
It also allows voters to change their minds by the end of the vote and further eliminates the possibility
of collusion between the registrar and the agency.
The second approach is now chosen in our voting system. However, in the future, when expanding
the functions of the platform, the issue of complicating the protocol algorithm will be considered in
order to fully comply with the above requirements for secret ballot systems.
4. Results and Discussion
As already mentioned, as an example of the implementation of an online platform for meetings with
the possibility of voting, the current work of the Academic Council of the Faculty of Computer Science
and Cybernetics was considered. The developed system is closed. At the login stage, the user's authen-
tication is verified using JWT technology with the involvement of the "e-mail/password" pair.
The system uses different user roles, all roles are displayed on the "Members" page. Roles have
different levels of authority in using the functionality of the platform. For example, the minimum level
402
of access to create a meeting of the Academic Council – the secretary. On the Participants page, the
secretary can also manage the roles of the participants. If a user's role has changed, they will receive a
notification in the notification center. On the "Meetings" page, after the secretary has entered the nec-
essary information, a full list of scheduled and held meetings is available for all participants with brief
information about each meeting, including the date and time, video conference link, status.
At the time indicated as the beginning of the meeting, the secretary or chairman of the Academic
Council begins the meeting and the status changes to "online". After the change of status, the registra-
tion of council members for the meeting is activated. Registration occurs automatically when you visit
the agenda page (Figure 5). The received information about the registered participants also used during
the formation of protocols and voting.
Figure 5: List of registered participants of the meeting
From the point of view of technical implementation, each meeting is a domain object, which is stored
in the database and is a structure of three levels (the state diagram at Figure 6).
The first level is the Conference model, which contains general information about the meeting, as
well as its related sections (next level) ConferenceChapter. The latter, by analogy, includes the very
issues of the ConferenceQuestion meeting. The question model already retains all the textual infor-
mation, and may also include voting, or additionally downloading files that are needed to address the
question. It is from this model is obtained basically all the necessary information for the formation of
the protocol. When we start to consider a question, a corresponding icon appears indicating the active
question and the active section. The secretary also adds fields with autocomplete, which must be filled
in for the protocol. The issues already considered are marked with a green check mark. In matters with
the voting option, all council members have dynamic information about the voting process and its re-
sults. If the necessary information has already been heard on a specific issue and the secretary has
started the voting process, each member of the council automatically opens a voting window in which
he must vote. After the meeting, the necessary protocols are formed. It should be one file with the
meeting protocols, which contains general information on the template (as well as a list of sections and
issues discussed during the meeting). All questions in protocol are usually accompanied by textual re-
cordings of the speeches and the results approved.
If a vote was taken to consider the issue, you must add information about the results of the vote in
the specified format. When generating such a protocol, all data is automatically pulled from the agenda
of the meeting, which does not require any additional manual processing. For each question, which
provided for voting, a separate file is formed – the protocol of the counting commission with the appro-
priate serial number. All files formatted in .docx format. The received minutes can be downloaded and
viewed by each user of the platform. We have: the meeting protocol is at the bottom of the agenda; the
counting commission protocols are under the voting results of the relevant issue. If necessary, the sec-
retary can download the protocol generated by the template, correct it and upload a new version of the
file to the platform. Relevant events was recorded in the system. To form files on a template requires
the use of a specific template engine [12]. In the case of working with .doc files, this may be a solution
from Aspose [13], an example of the syntax:
<< [s.getName ()] >> says: "<< [s.getMessage ()] >>."
An important advantage of the approach is that the template is written directly to a .doc file. Because
the syntax of the template is quite simple, we can easily adjust the template if you need to change the
rules for filling out the protocol. However, this solution does not provide the necessary flexibility in
editing file-filling styles, which does not allow you to play the desired template. We can also try to first
403
generate the desired .html file using the Thymeleaf template [14]. This approach allows providing the
necessary format and stylization of protocols due to the flexibility of the specified template.
Figure 6: Domain model UML diagram
However, after conversion there are problems with stylization and the created file needs additional
processing, which is not allowed by our condition of full automation of the process. Therefore, the
404
system has its own template with the minimum required functionality. The syntax approach is borrowed
from the already known Thymeleaf [14]. As in the first case, the code of the template is written to a
.doc file, but immediately with the desired stylization, which is saved during processing by the template.
Data (which are dynamic data) written by the algorithm to obtain the necessary data in the syntax of the
created template. To do this, when processing the file through the template engine, a context is created.
This context houses the objects of the domain model. We can get the necessary information from these
objects. Thus, the created template in its syntax supports the use of variables by their names (Figure 7).
It also supports the use of objects, calling their fields and methods, and therefore has the ability to use
basic programming language classes to process data directly in the template, not in the code.
Figure 7: The syntax example
In the case of using such a system, it is possible to abandon the usual way of saving protocols in .doc
format. The protocols will be viewed immediately on the platform page, this will facilitate the work
with extracts and their creation. If we need to use the protocol as an application, it will be enough to
attach a link to the appropriate page of the platform, and not the whole file. We may also need to con-
sider a system of plug-ins, because although meetings are mostly based on a single template, there are
times that require a personal approach and implementation for each type.
All registered participants of the meeting (except, of course, the secretary) can use smartphones to
participate in the meeting and to vote. For this purpose, the mobile version of the user interface was
implemented (Figure 8). The presented platform is now configured for holding meetings of scientific
councils with automation of current work processes. Simple expansion of the system allows implement-
ing it for use by scientific and labor collectives for carrying out of planned meetings of labor collectives,
conferences with any number of working sections, training courses. For any use, the system provides a
simple solution to the problem of holding online meetings, allows each participant to participate in the
meeting only have a smartphone.
5. Conclusion
As a result of the research, we analyzed the algorithms of the current work of the academic council
of the faculty and its meetings and selected the processes to be automated. We have developed algo-
rithms for automated execution of key stages of organization and holding of meetings. Based on these
algorithms, we developed a web application, demonstrated in this paper.
The peculiarity of the developed system is the convenience of preparation and holding of meetings,
the possibility of secret ballot of registered participants with instant reflection of the voting process,
automatic formation of protocols on the results of voting and the general minutes of the meeting.
The developed platform for holding meetings of the Academic Council with automation of current
work processes and the system of secret ballot can be implemented both at other faculties and at the
level of the institution. With a slight expansion, the system can be used for meetings of the staff, con-
ferences with many sections, training courses. The resulting product solves the problem of holding
online meetings, but is also adapted for the offline version during meetings in the hall. In this case, each
board member only needs a smartphone to participate in the meeting. Also, after the implementation of
the platform, it was noticed that the character of peak loads is present. For example, most meetings of
the Academic Councils are held on Mondays, at other times it may be simple visits to common pages,
work on the agenda or documents by several people, which does not create a high workload. Based on
these observations, we consider the possibility of switching the platform to the Serverless model (in
this situation we do not have a web server instance all the time, we only register lambda functions that
work as web controllers; in this case we pay not for the time of use, but for the number of requests
made). This will require dividing the platform into two functional parts: holding a real-time meeting
(one service that requires a permanent instance); another platform functionality (working with docu-
ments, changing user roles, etc.), which is a request-response model and can be ported to Serverless.
405
Figure 8: Mobile version of platform for participants
6. References
[1] Intecracy Group presents the latest video meeting system, 2020. URL:
https://softline.org.ua/news/intecracy-group-prezentuie-novitniu-systemu-videozasidan.html.
[2] Megapolis.DotNet electronic document management system, 2021. URL: https://in-
base.com.ua/ua/soft/megapolis-docnet.html.
[3] Token Based Authentication Made Easy. Learn about token based authentication and how to easily
implement JWT in your applications, 2016. URL: https://auth0.com/learn/token-based-authentication-
made-easy/.
[4] Introduction to JSON Web Tokens, 2020. URL: https://jwt.io/introduction.
[5] S.E. Peyrott, JWT Handbook, Auth0 Inc., Version 0.14.1, 2016-2018. URL:
https://assets.ctfassets.net/2ntc334xpx65/o5J4X472PQUI4ai6cAcqg/13a2611de03b2c8edbd09c3ca14
ae86b/jwt-handbook-v0_14_1.pdf.
[6] OAuth official documentation. Access Token. 2021. URL: https://auth0.com/docs/tokens/access-tokens.
[7] OAuth official documentation. Refresh Token, 2021. URL: https://auth0.com/docs/tokens/refresh-tokens.
[8] I. Fette, A. Melnikov, The WebSocket Protocol, Internet Engineering Task Force (IETF), 2011. URL:
https://datatracker.ietf.org/doc/html/rfc6455.
[9] WebSocket, in: Sovremenny`j uchebnik JavaScript, 2020. URL: https://learn.javascript.ru/websocket.
(In Russian).
[10] WebSocket Protocol. SAP Help Portal. URL: https://help.sap.com/viewer
/05d041d3df1a4595a3c45f57c15e2325/7.40.17/en-US/bd59428a3dd9454ab789412735adcb57.html.
[11] D.R. Patel, Information security: Theory and Practice, PHI Learning, Pvt. Ltd., 2008. Link.
[12] Java Template Engines, Topstone Software Consulting, 2018. URL:
http://topstonesoftware.com/publications/java_template_engines.html.
[13] Aspose Template Engine demo, 2020. URL: blog.aspose.com/2020/01/14/generate-word-documents-
from-templates-dynamically-using-java/.
[14] Thymeleaf official documentation. URL: https://www.thymeleaf.org/documentation.html.
[15] Docx4j – Getting Started, Plutext Pty Ltd, 2021. URL:
https://raw.githubusercontent.com/plutext/docx4j/master/docs/Docx4j_GettingStarted.pdf.
406