pacificemis / pacific-emis-education-survey-tool Goto Github PK

The firebase project "Education Survey Tool Base" is still clearly used though not for the configuration which seem to have moved entirely to their individual country projects (i.e. FedEMIS Education Survey Tool, MIEMIS Education Survey Tool, etc.) So far so good. What is needed now.

• Clearly detail how the "Education Survey Tool Base" is still used. I see all the usage stats there and not in the own individual country projects (i.e. FedEMIS Education Survey Tool, MIEMIS Education Survey Tool, etc.) I think it might be better to have those usage analysis split into their individual country project, is that not possible?
• Can the "Education Survey Tool Base" be used to add new countries? For example, in the Remote Config could we have a setting called "countries" : ["FedEMIS Education Survey Tool", "MIEMIS Education Survey Tool"] with the ability to just add new ones to the list. Then we can simply add a new firebase project like the existing FedEMIS Education Survey Tool, MIEMIS Education Survey Tool, etc.?

Some new work will require the app to get data from the EMIS (getting list of schools, list of teachers). For this we need a flexible way to configure how to access the EMIS API. A new setting shall be added as shown below for the Pacific EMIS Education Survey Tool.

This of course will be required in all the relevant firebase projects (i.e. MIEMIS Education Survey Tool, FedEMIS Education Survey Tool)

Similarly, the Pacific Open Education project should have the same settings (refer to its own issue at PacificEMIS/pacific-open-education-data#4)

This setting is no longer required as both the production and development service account keys are loaded from the centralized configuration. Verify it is in fact no longer used and remove.

What happened to school accreditation?

I notice something not according to the specs. If you look at the below. The cloud file with the red markings is the one I loaded from partial survey and continue completing. All good so far: changes are seen, new photos added, etc. I even see the last edited date changed. However, I see repeating users in the created by and edited by. This likely comes up as a result of same user (me) testing especially the load from partially saved (on another tablet with same or different user). This is likely to be a rare use case in real life usage. But is there not a way to only include the user if and only if it is not part of the current created by and edited by list of users.

If I try to "Load partially saved Survey" of a survey that is in complete status then it will create a new duplicate of that survey. This is not ideal. It should just open it and not create a new one (like it correctly does when loading partially saved survey of a incomplete survey). This is needed because it is the only way to edit a file in the future.

To reproduce. Open a partially saved survey (a complete one or incomplete one) on a new tablet with different user. Edit the survey by adding a comment, etc. Note that the lastEditedDateTime in the file's meta data correctly gets updated. However, I would expect the lastEditedUser to be updated with the new user from this new tablet. This can be observed by users looking at the file from our EMIS online or by developers programmatically.

The meta data in question is highlighted below.

Not urgent, next work arrangement.

Edit a surveyTag (which is used for merging) [Probably Omega-R at the tablet level]. Need to carefully assess this at the tablet level to make sure there are not any repercussion to this added "feature"

In Classroom Observation sections of the survey please rename

Class Progress: Log

to

Classroom Progress: Running Record

To document the updating of libraries

We need two very minor adjustments pretty urgently. The client raised an issue with the rounding and final calculation of the Form B. This only affects the Form B final determination of the Level in FSM (not in RMI). It is not an issue, but a miscommunication of the specs. It is quick to fix and urgent however.

1. I explain, see the final determination of the Level 2 below. You have it correct. However, before the classification to Level 1, 2, 3, 4 I previously told you to "floor" the decimal (e.g. 90.2, 90.6, etc. all become 90 for final Level determination). This was based on a meeting with the client. But there was a misunderstanding and it is actually a round up of the decimal (e.g. 90.6 is 91 and 90.2 is 90; in other words 90.0 to 90.4 will be 90 and 90.5 90.9 will be 91). The Total Score everything is ok. It is just a single line of code where you do the final rounding before the Level determination.

2. While you are doing 1) please fix one small error as shown below. This is a simple label rename, change a single word in the code. See highlighted in yellow. It should be Criteria Total (and not Sub-Criteria Total). I believe this affect BOTH FSM and RMI Form B Report.

From Delihda:

For example, what does it mean when a survey is "completed"? Is it just ticking a "yes" or a "no" or does it mean there is a comment, a photo, and having all the classroom observations be filled in?

Currently when all yes/no questions have been answered this is considered completed. However, FSM indicated they might want something a little more strict such as enforcing other data (photos, comments, etc.)

Need to review this with the team to see what change if anything is worth doing here.

New functionality/Field/data ?

@ghachey
We have a suggestion, the Menu icon (3 screens: 1) School Accreditation; 2) Water, Sanitation and Hygiene; 3)Software License), on the top left corner, change to Go back arrow icon, cause it performs the same action - returning to previous screen

[this issue ONLY affect the RMI (MIEMIS) Form B report and NOT FSM (FedEMIS)]

There is a minor but important issue with how the Form B report is produced. Refer to below screenshot comparing the Tablet report versus the online MIEMIS web app. This one is in production but can be easily reproduced in Development.

The final tally is the count of each Level (1, 2, 3 and 4) from all the school evaluation standards. Those seem to be counted correctly. However, the final result differ a little. I believe the difference is caused by how the final level for the two classroom observations are calculated. In RMI, the two classroom observations contribute to the final tally. For example, if classroom observation one is level 1 and classroom observation two is level 2 you would increment the tally of level 1 and level 2 by one to the final tally (hence the total of 26 and not 24 coming from the school evaluation standards). The tablet seems to be using the partition as shown in the legend to produce the final level of each classroom observations:

• Level 1 - 0-50%
• Level 2 - 51-75%
• Level 3 - 76-90%
• Level 4 - 91-100%

But this is incorrect. For the classroom observations you partition as follows (essentially 4 equal partitions for the 60 possible scores of a classroom observation):

• Level 1 - 0-15
• Level 2 - 16-30
• Level 3 - 31-45
• Level 4 - 46-60

So a couple of things to do here. First, in the Summary tab of the final report remove the legend as it does not apply in RMI as such.

Then add to the summary the final score for both classroom observations as shown below. The three areas highlighted in yellow are the string "Classroom Observation Final Score" the total summed correct answers of the classroom observation and the final score as defined by the partition above (the example below is a total of 35 score yes in the classroom observation which falls in Level 3 - 31-45).

Finally, fixing the above I believe will then automatically fix the final tally shown below.

The following list of grades is incorrect.

It must be urgently changed to

• Grade ECE
• Grade 1
• Grade 2
• Grade 3
• Grade 4
• Grade 5
• Grade 6
• Grade 7
• Grade 8
• Grade 9
• Grade 10
• Grade 11
• Grade 12

Note that this list will also soon have to be dynamically retrieved from the API as per the new requirement described in #15

See below bug. This should never happen. But we observe some surveys with such added script element into the survey. We need to understand why and fix.

Change "Merge" below to "Merge From".

Any work required here? Refer to email with subject: "New deadline: Target API Level"

Currently the Education Survey Tool can operate in either of the following mode:

• Production
• Development

There is a very minor issue with this. The Google Service Account keys used for the Development mode ends with _test (e.g. pacemis-education-survey-tool-test.json). To make this more clear I think the easiest is to simply rename the mode "Development" to "Testing" in the app. The other approach would be to create yet a whole new set of Google Service Accounts and rename it with _dev (e.g. pacemis-education-survey-tool-dev.json) but due to lots of files in those existing service accounts it might be more effort.

The related firebase remote configuration is currently "service_account_key_dev" which should be renamed "service_account_key_test". This way we end up with a clean naming convention:

• Firebase config: service_account_key_test
• Operating mode label: Testing
• Google Service Account Name and Key: "Pacific EMIS Education Survey Tool Test" and "pacemis-education-survey-tool-test.json"

The production remains the same with the following:

• Firebase config: service_account_key_prod
• Operating mode label: Production
• Google Service Account Name and Key: "Pacific EMIS Education Survey Tool Production" and "pacemis-education-survey-tool-prod.json"

And we now are also in the process of creating a third one called Training.

• Firebase config: service_account_key_train
• Operating mode label: Training (but not yet shown in the app)
• Google Service Account Name and Key: "Pacific EMIS Education Survey Tool Training" and "pacemis-education-survey-tool-train.json"

Of course, the exact same as above is true for all contexts (countries).

For the transition the current Firebase config: service_account_key_dev shall remain there containing the same key as the service_account_key_test so that older app versions continue operating as expected with the same Google Service Account.

A little pain with this easy work now I think will make it more clear for posterity and anybody else working on the project in the future.

Currently we have a development Google Service Account for development/testing and one production service account for all contexts. Each context (FEDEMIS, MIEMIS, etc.) shall have their own respective individual production service accounts. This will need to be well coordinated between work on the server side and the tablet side.

Related questions, is the retrieval of the configuration from Firebase done over an encrypted channel?

For next work arrangement.

Should the below not read "Send a partial survey to another device" instead of the current "Get a survey from another device"? Also the smaller string below that reads "Waiting for initiator device" should be changed to "Waiting for primary team leader device".

All of this is not final and only here for consideration, discussion and eventually finalize into requirements specifications.

Add support for additional stricter validation to consider a survey as completed. Currently comments, photos, running record are all optional and a survey is considered completed when all sub-criteria questions have been answered. Some to consider are:

• Minimum of 2 photos per sub-criteria. Here are some things to consider when discussing this: what about sub-criteria that does not make sense to have photo evidence? what about sub-criteria answered as No, why provide evidence of non-compliance?
• Minimum of one comment.
• Running record. What is considered an acceptable running record? Just having it created with a single record?

Whatever the final validations will be, this should also be made an optional feature into the tablet identified by a setting like such in firebase and tablet local setting. The new validations to consider a survey completed will be false by default and would have to be enabled. Actually the setting would be called "enforce_stricter_school_accreditation_completed_validations" since this would only apply to the school accreditation surveys.

Creating a new survey from "upload from partial survey" feature works correctly when loading a survey in the following state.

• surveyCompleted=POSITIVE
• surveyCompleted=NEGATIVE
• surveyCompleted=MERGED

See below for example of this meta data.

It works correctly in the sense that you can open a file on another tablet and it will continue updating that same cloud file.

However, when we try to "upload from partial survey" that we have loaded into our database on the server it does not work as expected: it create a completely new cloud file. This is problematic as we find it difficult to open an old file that we already loaded on the tablet (in event we need to change something). Below is an example of a file that was loaded into the database. I believe perhaps simply the added uploaded metadata added on the server when we successfully load a survey into the database may be enough for the tablet to be thrown off normal operation?

This is an urgent bug affecting us right now.

For next piece of work.

Currently the user can enter freely the Teacher name and Subject in the step below in the Schools accreditation survey. A predefined list shall be first extracted when the app is setup (same as loading Schools from API as described in #13). From this list the fields shall now be an autocomplete. After typing for example 3 characters a short list of choices matching the characters will be display to user for selection. Typing additional characters will shorten then list dynamically. If the Teacher is not in the list the field can accept the fully typed name also. This will improve data quality by linking with known data in the system.

When recording this in the XML of the survey currently is sets teacherName as shown below. This is good, but when retrieving from the EMIS we will also get the ability to put the teacher ID there. So this can only be added if users selected a teacher from list. But if so, add below teacherName tID=IDOFTEACHER.

The same shall be done for subjects (which can also have an ID called subjCode if selected from list).

And these UI widgets shall be available in any other surveys in the tablet. Currently there is only one other example in WASH.

The REST API call to get the data will be added here soon.

Currently only logging Delete surveys. Add logging for the following operations:

• Creating new surveys
• Merging survey into another tablet (tag it "Merged To")
• Merging survey from another tablet (tag it "Merged From")
• Change Date of a Survey

Add ability to click on log for more details in a pop-up.

Upload commits with last bugfixes.
Actual branch

This is a little tricky. Changing from Production to Development or Development to Production with existing files on the tablet. Ideal the files would be "migrated" across. However, the one tricky bit is that this is a new Google service account and all UUID would be re-created and thus would need to be changed (all photos in a XML survey would have to be updated to the new photos' UUID. But I want to still assess the feasibility and repercussions of this feature. It would be useful and sometime IT staff can forget to set to Production for actual production work.

This is on a budget tablet for testing. Android 11.

I believe this used to work. We could use the feature Load partially saved survey to retrieve a survey from the cloud onto another tablet (say a tablet is lost, etc.). It works but the photos are all blank. This one I tried to retrieve an older created cloudfile from production. But this can easily be reproduced in Development (which I did and result was the same). Why?

This may or may not be required. Needs to be discussed with relevant stakeholders.

In RMI Form B report there is a small but neat distinction for the display of the standard levels. FSM combines the standard total and standard level using a number and color. In RMI these are in two distinct columns making it a bit more clear. Need to discuss if FSM would like to have this small adjustment.

The partially saved survey is loaded correct into the new tablet. Everything is there except there is no local copy of the photos uploaded and therefore the photos for that survey are not shown. Easily reproducible. Create partial survey on one tablet with a couple of photos. On another tablet load that partially saved survey from the cloud service account. This is likely true for both School Accreditation surveys and WASH surveys.

For next round of work.

With this message showing. I already gave all permissions to the app at installation. I do not see this on other tablets yet. Only on one table but they are all the same Samsung Galaxy Tab A7 Lite tablet.

I have some reports from FSM that there are at least 3 surveys that are complete but that never synced to the cloud. I can not find them in the DEBUG: Show Storage and I do not see them listed in our system that list all the files loaded in cloud. This needs more testing. Ghislain will be doing additional testing with FSM data staff and comment here with any details.

A very urgent issue users have discovered with newly purchased tablet.

The tablet details can be found below.

We have tried with version 09.06.21 and also the latest 16.11.2021.

The tablet is fully updated and has been rebooted.

In the remote config it is possible to set configuration parameters as force: True|False. I would expect that a force fetch from the app will override locally changed settings only is the force parameter is set to True. But in the case of Operating Mode it is force: False.

This is not functioning as expected. A change to Production in the local tablet settings should remain even if user does a force fetch setting.

Is this scenario feasible. When a cloudfile is deleted from the cloud service account from the EMIS web app it would also delete it from the tablet(s) where it resides.

This would make file management in the cloud easier.

There are still situations that can lead to duplicate surveys somehow. Need to identify how and eliminate this source of problem.

The EMIS Education Survey Tool currently supports two hard code surveys (School Accreditation and a comprehensive WASH survey). Adding new surveys requires the assistance of developers typically done by preparing a structured XML file of the survey form. While this approach as served the needs so far, it would be desirable to be able to design our own surveys and load them in the app preferably through the firebase configuration. The preferred approach is to build upon the work of an existing open source tool used around the world for data collection. The tool is called Kobotoolbox (https://www.kobotoolbox.org/) which builds upon the open data kit standard. Using Kobotoolbox one can design surveys for data entry using a WYSIWYG (simple what you see is what you get graphical user interface) and then provide the surveys online (and offline) for data entry. But the surveys can also be exported as an XML definition following a standard convention like ODK (Open Data Kit). Provided we follow a few specific rules such as including fields for school name/id, period, createDateTime, createUser, etc. we should be able to produce a survey in Kobotoolbox, use the resulting XML files, load it into the firebase configuration and it would then become available in the Education Survey Tool installed on the tablet without a new build.

The newly deployed XML survey would then be available for use exactly as the current surveys are supporting all the same features (cloud syncing/syncing monitoring, progress bar monitor by category/group, etc.) The advantage of this approach vs simply using the online version of the created survey in Kobotoolbox is the tight integration with the EMIS backend including the preview and approval process.

Need to load a new survey. The changes to the survey and minor, mostly small edits in some of the survey questions. Prepare the new survey into XML format which and bump it to version 2.

In anticipation of a school list that will need to change over time we need a better way to get the list of schools. The app shall add the ability to get/update the list of updated schools from the EMIS API with the configured context (e.g. FEDEMIS, MIEMIS, etc.). We keep the ability to load the list of schools has it currently does by loading the CSV file. But we add the ability to update it by getting list from the EMIS API.

The below highlighted in yellow remains untouched and continues to work as it does. Simply rename from Import schools to "Import schools from CSV". And below "Import schools from CSV" you add a new button "Update schools from $EMIS API" where $EMIS displayed is actually the context (settings just above).

This new "Update schools from $EMIS API" button simply triggers a REST API call to /api/schools (exact API URL will be provided soon). The data returned should be a JSON like this.

[
{"schNo ": "AIL100 ", "schName":"Aerok Elementary School"},
{"schNo ": "ALU101 ", "schName":"Ailuk Elementary School"},
...
]

The data returned from the "Update schools from $EMIS API" call shall always completely replace the hard coded "Import schools from CSV" list of schools.

When setting up a new tablet and selecting the context the settings are fetched from Firebug. At that point the "Update schools from $EMIS API" should be executed in the background. If it works, then it replaces the schools. Otherwise it defaults to the CSV list.

An admin user should always be able to go in the settings and also force the "Update schools from $EMIS API".

Do all updates on software dependencies, eliminate any warning/deprecation/etc and ensure a clean build that runs flawlessly on all modern phones.

We need to understand why we have repeating folder (FedEMIS, FedEMIS, etc. MIEMIS, MIEMIS, etc. photos, photos)