Difference between revisions of "Velaos"
(Tag: Visual edit) |
(Tag: Visual edit) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = List of group members = | + | == List of group members == |
Lars Erik Bratlie - larsebra@ifi.uio.no | Lars Erik Bratlie - larsebra@ifi.uio.no | ||
| Line 8: | Line 8: | ||
Vetle Volden-Freberg - vetlevo@ifi.uio.no | Vetle Volden-Freberg - vetlevo@ifi.uio.no | ||
| − | = Summary of requirement = | + | == Summary of requirement == |
LMIS Light is an online system for ordering items, most probably for a local clinic. It will be used as a replacement for a similar system that is currently in use, but that is based on paper forms sent by mail or carrier. It is important that the system can function on an unstable network and that the bandwidth requirements are as small as possible. | LMIS Light is an online system for ordering items, most probably for a local clinic. It will be used as a replacement for a similar system that is currently in use, but that is based on paper forms sent by mail or carrier. It is important that the system can function on an unstable network and that the bandwidth requirements are as small as possible. | ||
# User creates order through web-app based on the needs of the given clinic. | # User creates order through web-app based on the needs of the given clinic. | ||
# A message, containing a list of the items needed, is sent to the managers of the clinic. | # A message, containing a list of the items needed, is sent to the managers of the clinic. | ||
| + | For messaging we will use elements of the REST api, specifically Messages, OrganisationUnit and Users. We will use the latter two to figure out the correct way to find the correct place for the order message to end up. | ||
== Architechture == | == Architechture == | ||
| Line 30: | Line 31: | ||
Functionality provided by the DHIS2-api we will use'':'' | Functionality provided by the DHIS2-api we will use'':'' | ||
*demo/api/messageConversations --> To notify higher management and send a confirmation to the user that submitted the form. | *demo/api/messageConversations --> To notify higher management and send a confirmation to the user that submitted the form. | ||
| + | |||
| + | === Use of DHIS2 in implementation === | ||
| + | The organisation units(OU) in DHIS2 are set up in a hierarchical system. Each clinic is a leaf node in the tree, with parent nodes upwards in the tree representing larger organisational instances such as villages, districts, provinces and so on up to country (root). As the goal of this project is to send order messages to people in higher management, this hierarchy is very useful. Using the web-API we can acquire a list of the parents of any given OU. This list will contain a direct path from the given OU to the root of the tree (the country). Our implementation will make use of this by enabling the end user (most often at a clinic) to choose which level of organisation the given order message will be sent. When an OU is chosen, the user will also get the option of choosing any person directly assigned to the given OU. If the user doesn't know which specific person to send to, the message can be sent to the entire OU. | ||
| + | |||
| + | The reasoning behind this approach, as opposed to a standardised messaging routine, becomes apparent when you understand that the way OU's are set up in any given country is not standardised. This makes it impossible to decide on a standard number of levels the message will be sent upwards in the hierarchy. Another issue is that the user-roles in any given OU, quite similarly, are not standardised. This makes it difficult to have a predetermined person/role for the order message to be sent to. Thus, we have decided to have the user choose what OU, and person within the given OU the message will be sent to. | ||
== Features == | == Features == | ||
| + | '''Order Page:''' | ||
| − | = Milestones = | + | User can add items, either write the commodity name or choose one from a default list. When a user is typing, some relevant items should displayed. User will input quantity of items to order and, optionally, current stock of given item. At any time an item can be removed or added to the form. |
| + | |||
| + | '''Messaging System:''' | ||
| + | |||
| + | When user presses the "submit" button, the process of sending the message is started. This is done by finding the correct Organisation Unit to send the message to, and the correct user in that unit. The Message api is used to send the order to the given user, and a delivery reciept is returned to the user that created the order. | ||
| + | |||
| + | == Milestones == | ||
=== Milestone 1: 8th November === | === Milestone 1: 8th November === | ||
Document features and architecture on Wiki | Document features and architecture on Wiki | ||
| Line 49: | Line 62: | ||
* '''Presentation:''' mid December | * '''Presentation:''' mid December | ||
| − | = Task management = | + | == Task management == |
All group members must: | All group members must: | ||
# Setup DHIS2 with Postgresql | # Setup DHIS2 with Postgresql | ||
# Setup git with our bitbucket repo. | # Setup git with our bitbucket repo. | ||
| − | = | + | === Responsibilities: === |
| − | + | Lars Erik Bratlie had responsibility for fetching recipients of message and for navigation between modules. | |
| + | |||
| + | Lu Liu worked on static HTML and input validation for the commodity form. | ||
| + | |||
| + | Øystein Olavsen handeled messaging and message editing. | ||
| + | |||
| + | Vetle Volden-Freberg had responsibility, together with Lu, for creating the static HTML and also handeled fetching commodities from the input form. | ||
| + | |||
| + | Everybody made hotfixes where it was needed at any time. | ||
| − | = | + | == Link to repository == |
| + | https://vetlef@bitbucket.org/vetlef/velaos.git | ||
Latest revision as of 15:04, 14 December 2015
Contents
List of group members
Lars Erik Bratlie - larsebra@ifi.uio.no
Lu Liu - lliu@ifi.uio.no
Øystein Lytskjold Olavsen - oystelol@ifi.uio.no
Vetle Volden-Freberg - vetlevo@ifi.uio.no
Summary of requirement
LMIS Light is an online system for ordering items, most probably for a local clinic. It will be used as a replacement for a similar system that is currently in use, but that is based on paper forms sent by mail or carrier. It is important that the system can function on an unstable network and that the bandwidth requirements are as small as possible.
- User creates order through web-app based on the needs of the given clinic.
- A message, containing a list of the items needed, is sent to the managers of the clinic.
For messaging we will use elements of the REST api, specifically Messages, OrganisationUnit and Users. We will use the latter two to figure out the correct way to find the correct place for the order message to end up.
Architechture
We will primarily use HTML5, CSS3, Bootstrap and jQuery in this project. We believe they will work well together and help us create the best possible solution.
To communicate with the DHIS2 RESTful API, AJAX and JSON will be applied.
List of technologies and frameworks we will use:
- JavaScript (jQuery)
- JSON
- CSS3 --> Used for design purposes to enhance the webapps look and overall usability. (Will be incorporated with the bootstrap framework).
- HTML5
- AJAX --> Utilizing the the advantages of asynchronous programming enabling the user to fill out the order form and navigate in the web app on the client side smoothly without having to wait for responses from the server.
- Bootstrap --> HTML, CSS and javascript front-end framework, very useful when creating web apps. Ease the work load in terms of design allowing for more focus on functionality.
Functionality provided by the DHIS2-api we will use:
- demo/api/messageConversations --> To notify higher management and send a confirmation to the user that submitted the form.
Use of DHIS2 in implementation
The organisation units(OU) in DHIS2 are set up in a hierarchical system. Each clinic is a leaf node in the tree, with parent nodes upwards in the tree representing larger organisational instances such as villages, districts, provinces and so on up to country (root). As the goal of this project is to send order messages to people in higher management, this hierarchy is very useful. Using the web-API we can acquire a list of the parents of any given OU. This list will contain a direct path from the given OU to the root of the tree (the country). Our implementation will make use of this by enabling the end user (most often at a clinic) to choose which level of organisation the given order message will be sent. When an OU is chosen, the user will also get the option of choosing any person directly assigned to the given OU. If the user doesn't know which specific person to send to, the message can be sent to the entire OU.
The reasoning behind this approach, as opposed to a standardised messaging routine, becomes apparent when you understand that the way OU's are set up in any given country is not standardised. This makes it impossible to decide on a standard number of levels the message will be sent upwards in the hierarchy. Another issue is that the user-roles in any given OU, quite similarly, are not standardised. This makes it difficult to have a predetermined person/role for the order message to be sent to. Thus, we have decided to have the user choose what OU, and person within the given OU the message will be sent to.
Features
Order Page:
User can add items, either write the commodity name or choose one from a default list. When a user is typing, some relevant items should displayed. User will input quantity of items to order and, optionally, current stock of given item. At any time an item can be removed or added to the form.
Messaging System:
When user presses the "submit" button, the process of sending the message is started. This is done by finding the correct Organisation Unit to send the message to, and the correct user in that unit. The Message api is used to send the order to the given user, and a delivery reciept is returned to the user that created the order.
Milestones
Milestone 1: 8th November
Document features and architecture on Wiki
Show understanding of DHIS2 web apps
Milestone 2: 22th November
First bare-bone version - static HTML
Uploadable as DHIS2 web app
Milestone 3: 4th December
- Finished, if applicable also with mobile app --> web app will be applicable with mobile web browser.
- Final delivery: 11th December
- Presentation: mid December
Task management
All group members must:
- Setup DHIS2 with Postgresql
- Setup git with our bitbucket repo.
Responsibilities:
Lars Erik Bratlie had responsibility for fetching recipients of message and for navigation between modules.
Lu Liu worked on static HTML and input validation for the commodity form.
Øystein Olavsen handeled messaging and message editing.
Vetle Volden-Freberg had responsibility, together with Lu, for creating the static HTML and also handeled fetching commodities from the input form.
Everybody made hotfixes where it was needed at any time.
