Requirements
- Added following requirements
- Form: 4.1.2.2., 4.1.2.4., 4.1.2.5.
- Exhibitor: 4.1.3.2. - 4.1.3.7.
- Pricing: 4.1.4.
- Exporting: 4.1.5.
- Modified following requirements:
- Form: 4.1.2.1.
- Added the modifiable user as a user alternative.
The ARKAD Nexpo system has the purpose to replace the current fair system used Jexpo.
The purpose of implementing this system is to further develop ARKAD's internal systems, withdrawing a subscription from the current expo-system, Jexpo.
The scope is to make a secure, usable and simple system that can contain all the information needed about the fair. The time scope is primarily within 2017.
- Develop a completely general system, making it possible to use many years to come without having to implement new functionality.
- Develop a usable system.
- Develop a system containing every important part within Jexpo.
- An admin user has permission to do everything within the system
- A modifiable user includes the permissions of a standard user but also write permissions are modifiable by admin.
- A standard user has permission to read.
- A configuration contains the information about the current years fair.
- 4.1.1.1. The current configuration contains information about all the exhibitors, where information is gathered from registration forms and visualized through a list.
- 4.1.1.2. The current configuration contains information about the members in ARKAD project group.
- 4.1.1.3. A new configuration can be created by admin.
- 4.1.2.1. A form can be created by admin. (A good starting point on which kinds of question types should be implemented, could be gathered from Google Forms)
- 4.1.2.2. A form can be modified by admin.
- 4.1.2.3. A form render can embed the form on a website. (Example of embedded code can be seen below)
<!-- BEGIN Podio web form -->
<script src="https://podio.com/form.js"></script>
<div class="podio-form">Webform by podio</div>
- 4.1.2.4 During creation or modification state, admin can give rw-permission to certain modifiable users on specific fields received from companies.
- 4.1.2.5. A certain sort of field can be connected with an item on the pricing list.
- 4.1.2.6. When a company fills out a form, a total cost is to be calculated, viewing the extra choices in the end of the form, but also beside the field. See figure 4.1 and 4.2 in requirements-0.2. (Prices are gathered from the pricing list)
- 4.1.3.1. An exhibitor is created when a company registers through answering a form.
- 4.1.3.2. An exhibitor can log in with given username and password.
- 4.1.3.3. When logged in, the exhibitor can view the information the exhibitor has given.
- 4.1.3.4. If any change of information is made by a modified user the exhibitor will be notified by email.
- 4.1.3.5 If any change is made the exhibitor will need to log in to attest the changes.
- 4.1.3.6. The exhibitor can make changes to the information given until a certain date.
- 4.1.3.7. After the deadline on making changes, and register to the fair, specific fields can be unlocked by admin, making it possible to make changes to the information, by either users or the exhibitor. (See figure 4.3 in requirements-0.2)
- 4.1.4.1. The pricing list contains different items, i.e. pallet, with corresponding costs.
- 4.1.4.2. Admin can modify, delete and add items and costs.
- 4.1.5.1. All the exhibitors with information can be exported to an excel document.
Develop an invoice function generating and sending all invoices at one click.
