| 1 | What is WAeUP.Ikoba ? |
|---|
| 2 | ********************* |
|---|
| 3 | |
|---|
| 4 | Ikoba, which means 'bucket' in Bini language, is a multifunctional Application and Registration Web Portal to provide transparent and comprehensive information about application and registration processes. |
|---|
| 5 | |
|---|
| 6 | Ikoba is the second flagships of the West African eUniversity Project (WAeUP) Group. See http://www.waeup.org to learn more about WAeUP. |
|---|
| 7 | |
|---|
| 8 | Installation instructions can be found in the User Documentation (docs folder in the file system). |
|---|
| 9 | |
|---|
| 10 | |
|---|
| 11 | Ikoba and Kofa - Similarities and differences |
|---|
| 12 | --------------------------------------------- |
|---|
| 13 | |
|---|
| 14 | Ikoba could be described as a customer registration, document verification and contract conclusion portal. Customers are being registered (customer registration workflow), documents are being verified (document verification workflow) and contracts are being applied for and concluded (contract workflow). |
|---|
| 15 | |
|---|
| 16 | Ikoba's user interface and its usability is very similar to WAeUP's Student Management System Kofa. This comprises: |
|---|
| 17 | |
|---|
| 18 | - Responsive webdesign (by Bootstrap) |
|---|
| 19 | - User management |
|---|
| 20 | - Permissions and roles |
|---|
| 21 | - Authentication |
|---|
| 22 | - Portal configuration |
|---|
| 23 | - Data import (batch processing) |
|---|
| 24 | - Data export |
|---|
| 25 | - Logging |
|---|
| 26 | - Reporting |
|---|
| 27 | - Localization |
|---|
| 28 | - Mandates |
|---|
| 29 | - Notification and mailing |
|---|
| 30 | - Data tables |
|---|
| 31 | - etc. |
|---|
| 32 | |
|---|
| 33 | But in Ikoba there are completely new content components (models), views (including pdf slips) and controlling components. |
|---|
| 34 | |
|---|
| 35 | |
|---|
| 36 | Company |
|---|
| 37 | ------- |
|---|
| 38 | |
|---|
| 39 | The main web application and container class is called 'Company' which corresponds to the university container in Kofa. The company container contains sub-containers for products, public documents, customers and officers (regular users). |
|---|
| 40 | |
|---|
| 41 | |
|---|
| 42 | Products |
|---|
| 43 | -------- |
|---|
| 44 | |
|---|
| 45 | A company offers products usually for sale. A product could be a license, a visa or any purchasable merchandise/article. In the base package a product has eight attributes, unique product id, title, contract title, contract_category, options (set of product options), valid from, valid to, terms and conditions |
|---|
| 46 | |
|---|
| 47 | Products don't have a workflow. |
|---|
| 48 | |
|---|
| 49 | |
|---|
| 50 | Public Documents |
|---|
| 51 | ---------------- |
|---|
| 52 | |
|---|
| 53 | Public documents are meant for publishing content on the portal. There are three types of public documents: |
|---|
| 54 | |
|---|
| 55 | - PDF documents |
|---|
| 56 | - HTML documents |
|---|
| 57 | - REST documents |
|---|
| 58 | |
|---|
| 59 | The first can be used to provide pdf files for download. The second and third can be used to create multilingual static html pages on the portal. HTML documents expect html coded text as input, REST documents expect reStructuredText which is transformed into html. Public documents have a publication workflow with two states: created and published. Only published documents can be seen by anonymous users. |
|---|
| 60 | |
|---|
| 61 | |
|---|
| 62 | Officers |
|---|
| 63 | -------- |
|---|
| 64 | |
|---|
| 65 | Officers are regular users or principals of the system with a set of global and local roles which allows them to view or manage the various sections in Ikoba. In contrast to classical content management systems, officers do not manage their own space where they can add and edit own content. Ikoba officers can just access those parts of the portal which their roles or sets of permissions allow them to access. |
|---|
| 66 | |
|---|
| 67 | An officer has eight attributes: unique login name, title (fullname), public name, description, email address, phone number, set of roles, encrypted password |
|---|
| 68 | |
|---|
| 69 | Officers can't register themselves. They have to be added by the initial system administrator or by officers who have the permission to manage user data. |
|---|
| 70 | |
|---|
| 71 | Officers don't have a workflow. |
|---|
| 72 | |
|---|
| 73 | |
|---|
| 74 | Customers |
|---|
| 75 | --------- |
|---|
| 76 | |
|---|
| 77 | The term 'customer' has two different meanings in Ikoba. On the one hand a customer is a container object which contains all the documents and contracts owned by a prospective or registered client or contractor of the company. On the other hand a customer is an authenticated users or principal of the system with a user account adapted to each customer container object. |
|---|
| 78 | |
|---|
| 79 | The attributes of a customer in the base package are: customer id, firstname, middlename, lastname, sex, email, phone, an encrypted password and a unique registration number which can be set by the company. |
|---|
| 80 | |
|---|
| 81 | Customers have a registration workflow with four states: created, started, requested and approved. An email notification is sent after after approval or rejection of the registration. |
|---|
| 82 | |
|---|
| 83 | Customer accounts can be temporarily suspended. Although suspension is not part of the workflow it does appear in the customer's workflow history. |
|---|
| 84 | |
|---|
| 85 | Only approved customers can conclude contracts (see below). |
|---|
| 86 | |
|---|
| 87 | Customers can register themselves. They need a valid email address for self-registration. |
|---|
| 88 | |
|---|
| 89 | |
|---|
| 90 | Customer Documents |
|---|
| 91 | ------------------ |
|---|
| 92 | |
|---|
| 93 | Customers are requested to upload scanned documents and images required e.g. for the conclusion of contracts. Each uploaded file is connected with a document object which carries the metadata of the scanned document. In the base package a customer document has only a title, a unique document id and an md5 attribute. The latter contains the md5 checksum of the connected (binary) file after verification. |
|---|
| 94 | |
|---|
| 95 | Documents have a verification workflow with five states: created, submitted, verified, rejected and expired. |
|---|
| 96 | |
|---|
| 97 | Various document classes can be implemented and selected by the customer to make customization as flexible as possible. |
|---|
| 98 | |
|---|
| 99 | Once a document has been submitted, it can no longer be edited by customers. Verified documents can neither be edited by customers nor by officers. |
|---|
| 100 | |
|---|
| 101 | The md5 checksum proves the genuineness of the uploaded file. |
|---|
| 102 | |
|---|
| 103 | A pdf document slip can be downloaded. The slip is composed of a covering page and the scanned document badged by a watermark. |
|---|
| 104 | |
|---|
| 105 | |
|---|
| 106 | Contracts |
|---|
| 107 | --------- |
|---|
| 108 | |
|---|
| 109 | Contracts are being concluded between the company and the customer. The customer applies for a contract by |
|---|
| 110 | |
|---|
| 111 | 1. selecting a proper form (= contract class), |
|---|
| 112 | 2. selecting one of the products which belong to the contract class, |
|---|
| 113 | 3. filling the contract form, |
|---|
| 114 | 4. uploading required documents, |
|---|
| 115 | 5. submitting the documents for verification, |
|---|
| 116 | 6. linking the submitted documents on the contract form, |
|---|
| 117 | 7. paying the contract fees, |
|---|
| 118 | 8. submitting the contract form for approval. |
|---|
| 119 | |
|---|
| 120 | A customer has to register first but must not wait for approval before s/he can add contracts. Only after registration the customer can proceed to the contracts section and add, pay and submit contracts. If documents have to be uploaded and attached to the contract, these documents must be at least submitted for verification. Otherwise they cannot be attached. This ensures that documents can't be modified after application (= submission of contracts). Thus, a new customer can register, add and submit documents and then add, pay and submit contracts in just one single session. |
|---|
| 121 | |
|---|
| 122 | Company officers approve the customer registration request first, then verify the customer's documents and finally approve the contracts submitted by the customer. Approving a contract means that the contract is concluded. Contracts can also be rejected or expire. |
|---|
| 123 | |
|---|
| 124 | Each contract class belongs to a contract category. The contract category defines the subset of products which can be selected when configuring the contract (see Products section above). |
|---|
| 125 | |
|---|
| 126 | A contract in the base package has a title, a unique contract id, one document reference, one product reference and list of product options. A customized contract can have several document references, but it can only refer to a single product offered by the company. The product options determine the fees to be paid before a contract can be concluded. |
|---|
| 127 | |
|---|
| 128 | A contract can only be submitted if all documents attached to the contract have been at least submitted for verification. Contracts can only be approved if the customer registration request has been approved and then all attached documents have been verified by an officer. |
|---|
| 129 | |
|---|
| 130 | The contract workflow has the following states: created, submitted, approved, rejected and expired. An email notification is sent after after approval or rejection of the contract conclusion request. |
|---|
| 131 | |
|---|
| 132 | A pdf contract slip can be downloaded. |
|---|
