stats4sd/ccrp-soils

ccrp-soils's Issues

Sample downloads with incorrect data

For split data:

• the poxc analysis tab has the data from the aggregate stability test (empty in this case)-- and the aggregate stability tab also has it.

Setup login from front-end form

Currently, the /home/checklogin route gives a 404 - probably because it's sending a GET request instead of POST.

This should probably be moved to use some form of default Laravel / Backpack login controller for ease of maintenance.

Setup translations of web pages

Ideally, all the page text across the front end should be translatable.

Using Translation.io seems like a good call. Requires:

• Install vendor plugin
• Add project API key
• Update all blade files to use {{ t("the string") }} instead of just the string
• php artisan translation:sync sends those strings to translations

Add QR Code generator

The live platform uses a JS plugin QRCode, along with an ajax php call to actually generate the code numbers and add them to the database.

The generic codes are in 2 parts - a 4-digit random number, followed by the auto-incremented ID generated by adding the record into the 'barcodes' MySQL table. The Ajax request generates the random numbers, inserts the records into the Db, then returns the compiled strings for JS to create the QR images.

The easy way to add this feature is to basically use the same setup. The front-end JS code can be very similar. The back-end can be tidied a lot by making it a proper Laravel API controller.

Pull out template components of page into seperate blade files

Things like the HEAD, top menu, footer, login and account panels should go into a separate layout file, referenced by individual pages.

When new XLS form is uploaded, push 'test' version to Kobotools

Should automatically push a new version to the main ccrp_soils account on Kobotools whenever a form is created or updated in the platform.

This probably involves an observer for the xls_form model, then one or more jobs to do the actual Kobotools API stuff.

Setup new repository for new structure (Soils Platform Project)

Setting up a 'new' Soils platform to explore the new structure:

• setup new system with backpack laravel template;
• odk link package; team management package;
• setup database + models + crud for:
  • soil samples;
  • analyses;
  • analysis-types;
• bring in existing data into new format.

Pull out styling into .scss files

Styling should be generalised and organised sensibly into /resources/sass/ * .scss files.

Automatically link projects and forms together

Whenever a new form or project is added, it should be linked to all existing elements.

So, we need a ProjectObserver, so when a project is created, it's linked to all existing forms.
And a FormObserver, so when a form is created, it's linked to all existing projects.

Setup link between projects and xlsforms

Needs to use a custom pivot table for things to track the Kobotoolbox metadata for each form (project_xls_forms).

Example:

`

Project Model

xls_forms () {
return $this->belongsToMany(Xlsform::class)->using(Projectxlsform::class)
->withPivot([
'records',
'deployed'
]);
}

Form Model

projects() {
return $this->belongsToMany(Project::class)->using(Projectxlsform::class)
->withPivot([
'records',
'deployed'
]);
}

}

$project->xls_forms();`

Create and manage users and projects

Administrators should be able to manage users and projects via a standard CRUD interface.

A user can be a member of a project, or can be an admin for a project.

On the front end, a user should be able to create a new project (and automatically become an admin of that project), then invite other users to be members or admins of that project.

Make sample downloads more useful

For split downloads, add farmer_id and other relavent identifiers into each worksheet, to minimise the amount of merging / lookups that need to be added after the fact.

For wide downloads, investigate if we can get all samples repeated across the wide format.

Analysis Tables in db should be generalised

Currently, whenever a major change is made to an analysis form, it involves:

• updating the MySQL table structure for that analysis type;
• updating the Kobo importer;
• updating the merged samples_view for the main data download.

We should modify the table structures to use json 'extras' fields for most analysis variables.

Should users have individual Kobotools usernames or should projects?

On the live platform, a project is linked to a single Kobotoolbox username. Users join that project, then must use that same kobotools account to collect data.

This works for groups like ForrajesYDescansos (I think), but adds confusion to a lot of instances where people need to swap kobotoolbox accounts.

It would be simpler long-term if users had their own individual kobotools accounts, and all project forms were shared with every project member. Then users can collect data with different kobo accounts but the same (shared) project form.

Not sure if this would mess things up in the short term, though!

Include existing translations from Wordpress site

Probably a manual copy-pasta into the translations.io system.