Decentralized iHRIS Data Policy: Difference between revisions

From IHRIS Wiki
(Undo revision 10598 by Litlfred (Talk))
No edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 9: Line 9:


==Data Management==
==Data Management==
We first need to decided on a data management policy that is compatible with our data structure.
We first need to decide on a data management policy that is compatible with our data structure.
 
 
===Decentralized Data Structure===
===Decentralized Data Structure===
Our decentralized data module is "vertical" in that it allows data to flow from the district to the region to the national level.  It also allows that the data flow in the reverse direction.  We do not allow data to flow "horizontally."  In other words, we do not have a mechanism for the data on a person in district A to be given to district B.   
Our decentralized data module is "vertical" in that it allows data to flow from the district to the region to the national level.  It also allows that the data flow in the reverse direction.  We do not allow data to flow "horizontally."  In other words, we do not have a mechanism for the data on a person in district A to be given to district B.   
Line 33: Line 35:
*At the district level, the facility and facility contact data is exported from the region within two modules: ''ihris-manage-taifeki-northern-region-facility''  and ''ihris-manage-taifeki-northern-region-facility_contact.''  You would choose to use (read-only) [[Form Storage -- Magic Data|magic data]] form storage mechanism in your data policy.
*At the district level, the facility and facility contact data is exported from the region within two modules: ''ihris-manage-taifeki-northern-region-facility''  and ''ihris-manage-taifeki-northern-region-facility_contact.''  You would choose to use (read-only) [[Form Storage -- Magic Data|magic data]] form storage mechanism in your data policy.


==Launchpad==
[[Category:Implementer Resources]]
===Team===
Create a launchpad team, called ''ihris-taifeki,'' which you and all members of your development team will join.
===Project===
Create a launchpad project called ''ihris-taifeki.'' Once it is created, edit the project details and:
*set it to be "Part of:" the 'ihris-suite' project
*Check ''Code for this project is published in Bazaar branches on Launchpad''
*Check ''Bugs are tracked in launchpad''
*Hit the ''Change'' button
*Returnto editing the project details, scroll down to the bottom of the page and choose the ''Edit People'' link
*Set the Mainter to be the ''ihris-taifeki'' team
 
===Series===
Within the ''ihris-taifeki'' we will create a Series for each tier of of structure. As we are working with iHRIS Manage 4.0, we will also want to indicate that in the Series name. Each series will contain all of the sites that exist on that tier.  Here are series we will create:
*national-4.0 One site, the national site which aggregates from all the regions
*region-4.0 One site for each regions, each region will aggregate from all the districts contained within it
*district-4.0 One site for each district
ce
To create the series, and do the following for each of the series above:
*Click on the 'Code' tab on the project home page
*Click on the 'Register Series' link
*Set the owner to be ''ihris-taifeki''
*Set the name to be the same name as the series (e.g. ''national-4.0'')
*Set the branch type to be 'Hosted'
*Click on the 'Register Branch' button
*Return to the project home page by clicking on the 'Overview' tab
*Select "Register a series"
*Enter in the name of the series (e.g. ''national-4.0'')
*Enter in the Bazaar branch (e.g. ''~ihris-taifeki/ihris-manage-taifeki/national-4.0'')
 
==Modules==
===Data Policy Module===
Within each of the series we will, create the modules as appropriate:
*ihris-manage-taifeki-national-data-policy
*ihris-manage-taifeki-regional-data-policy
*ihris-manage-taifeki-district-data-policy
which defines the form storage/data management policy for that tier and which requires ihris-manage.  If the data for a form is contained in a module  that it should also require that module:
*The national site would require the ''ihris-manage-taifeki-national-data-policy''
*Each site on regional level will require the ''ihris-manage-taifieki-regional-data-policy'' module. 
*Each site on the district level would require ''ihris-manage-taifieki-district-data-policy.'' Also, in the example above, for any district in the northern region,  we would have it's site module require ''ihris-manage-tafaiki-northern-region-facility'' and  ''ihris-manage-tafaiki-northern-region-facility_contact.''
 
 
 
[[Category:Tutorial]]

Latest revision as of 18:53, 1 March 2019

This decentralized implementation of iHRIS is our answer on how to manage data in any of these settings:

  • high Internet connectivity
  • low Internet connectivity
  • no Internet connectivity

It is designed to work easily, with minimal configuration, and maximal functionality.

Suppose that we are interested in setting up a decentralized implementation of iHRIS Manage in the country Taifeki. Let us assume we are going to work on a three tier implementation: national, region and district. We will show how to take advantage of [1] to maintain the various customizations needed for each of the sites.


Data Management

We first need to decide on a data management policy that is compatible with our data structure.


Decentralized Data Structure

Our decentralized data module is "vertical" in that it allows data to flow from the district to the region to the national level. It also allows that the data flow in the reverse direction. We do not allow data to flow "horizontally." In other words, we do not have a mechanism for the data on a person in district A to be given to district B.

We always that there is only one site that can write each data component. A data block consists of all the data for one form in one site. Examples of data components are:

  • all the jobs at the national level
  • all of the facilities in a specific region
  • all of the positions in a specific district


Data Management Policy

These questions need to be answered:

  • Who can see which data?
    • (Examples) Should a district be able to see the facilities in another district?
  • Who can edit which data?
    • (Examples)Who maintains the list of facilities? The jobs? The positions? Is it at the national, regional or district level?

These questions need to be answered for all the forms within iHRIS Manage and all sites (national, regional and district-level).

Example

If you decide that each facility is maintained at the regional level. This means the following:

  • At the national level, the facility data needs to be componentized by regions and the facility and facility_contact forms will use the (read-only) multi-flat storage mechanism to aggregate the cached data tables from the regional level.
  • At the regional level, the facility data is not componentized. Since the facility and facility contact information is not subject to frequent changes and you do not need to keep track of the history, you would choose to use the (read-write) magic data form storage mechanism in your data policy.
  • At the district level, the facility and facility contact data is exported from the region within two modules: ihris-manage-taifeki-northern-region-facility and ihris-manage-taifeki-northern-region-facility_contact. You would choose to use (read-only) magic data form storage mechanism in your data policy.
Retrieved from "https://wiki.ihris.org/mediawiki/index.php?title=Decentralized_iHRIS_Data_Policy&oldid=55400"