It could be nice to let clients override Crop documents in the local database, but not allow them to push these changes to the server (#63). Crops with local changes should probably be marked in the UI, and there should be a possibility to revert to using the original data from the server.

The companionship algorithm calculates a score for a set of crops based on data from 1) our companion database (db/companions.js) and 2) the Practical Plants database (db/practicalplants.js).

Write a test that checks that (1) is compatible with the companionship algorithm. This should assert that if two crops are companions in (1) then the companionship algorithm also determines them compatible. If this assert fails then one of the databases is wrong and should be fixed.

Blocked by #5 #6.

After #5 and #6 are finished, data has to be fed to the components. Make sure this happens now with the new code structure.

At the moment we have no field for old binomial names but we should be able to identify also by old binomial names.

Add to the model an attribute holding an array of old binomial names.
Create an index of all binomial and common names to search in with references to the crops.

Example: if you look at https://practicalplants.org/wiki/Solanum_lycopersicum you'll see the old binomial name for it (Solanum esculentum). Literature may be referencing this name instead of the new name and people should be able to identify it also by this name.

At the moment the default values in practicalplants.js are imho wrong since they lead to wrong information and wrong match making.

I think the default values should be null or empty arrays depending on the format.

Add search field and filters for crop list. Preferably make it work so that the user has to explicitly select which filters they want to use (maybe something like the trac ticket query interface?), instead of having all the filters editable on the view all the time.

This will be later used for the bed planner (#54) so make it reusable.

Also, this is related to #55 which is for redesigning the crop list and the search interface in antd.

There is a test with a TODO item in test/shared/filter.js that has currently basic tests for the different filter types. It would be nice to complete this test by testing each elementary filtering operation (each property, each enum value, each hardiness zone, etc.) to see how many crops are returned in practice when running the filter against the database.

Create UI component that is given an array of crops and that shows what data is missing from these crops.

For example when the user is planning their beds the UI could offer a report of missing data for the chosen crops. This way the user could improve the original data in order to make the companionship algorithm more accurate.

See #27.

Data should be validated before it is written to PouchDB or Redux. There could be two layers, a PouchDB validation layer that would be used before documents are put to any PouchDB instance, and then a static layer that could be tested independently and that would be used by the PouchDB layer, in front of Redux, and also in the UI. UI should give clear warnings when there is something wrong with an edited document.

New plant/crop attributes are to be added to the practical plants database (data model).

For the accurate documentation of the expanded data model these attributes should integrated into the source codes's JSDoc knowledge base.

The attributes to be documented can be found at /server/models/crops.js where the JSDoc attributes will be clear as some already have defined descriptions and some do not

At the moment we define three groups of users:
Admin
Moderator
User

These should have different rights to manipulate data and give rights.
Admins should be able to assign Users a role.
Moderator should check User request to change or add information.
User should be able to suggest changes.

Add more information to this issue for more clarification.

Find good solution and Implement it on client and server side.

In previous git versions we had a bed planner where it was possible to select a crop for the bed from only those crops that were companion plants with all the other crops that were already in the bed. This worked well for the relatively small dataset that we had back then, but now that we've moved to using the practicalplants.org data with over 8000 crops, we also need to redesign the bed planner.

In the new bed planner there could be a search field where one could find crops by name, and it'd open a dropdown list of the crops that match a given string (if no characters are given it'd show all crops). From this list those crops that are incompatible (cannot be grown in the same environment) with the other crops that are already in the bed, would be filtered out, and the list would be ordered by how good companion a crop would be. Then the user could select additional filters to further limit the list to only those crops that have specific properties.

The filtering function should be independent from the UI and tested separately, it should also use the companionship algorithm in shared/companionship.js.

It turned out that the algorithm that was used in the previous bed planner has a serious performance problem, it doesn't scale at all to the size of the new dataset. The algorithm that's sketched here would have the time complexity NMK (plus sorting and filtering), where N is the number of crops (around 10000), M is the number of compatibility/goodness values (around 30), and K is the number of crops in the bed (around 5), so it should be usable, especially with some caching.

So far, only Model IDs are validated but we need to validate all additional data sent also.

Write validation for all Models in shared/validation/models/ for server/models use the validation in static validation functions on the models and use the validations in the middleware.js, to validate user data.

testcases: #14

Create HTTP API and CLI command for querying current weather warnings from powerplant server. Cache these warnings on the server. Alternatively make the server to periodically check for weather warnings for all garden locations.

Documentation is lacking both in structure and content since the move from MongoDB to PouchDB.

• Fix developer documentation in docs/dev_docs.js, especially setup and architecture.
• Check that the structure of the generated JSDoc documentation is correct, especially that the file and directory headers with namespace and memberof tags are used correctly.
• Remove docs/Powerplant Workflow.svg, it isn't update anymore.
• Remove docs/software_specifications.md and docs/ideas/database_structure.md, use github issues instead if there is something acute there.

Fixing #63 by #66 introduced a bug when admin tries to edit the database after the initial npm run migrate, for some reason their changes don't get synchronized to clients.

At the moment we rely on practical plants for plant data practicalplants.js and a small data set of companion plants companions.js. For linkin this informations, we need binomial names in companions.js.

Search for the binomial names of the crops in companions.js (in the average case it should match a binomial name in practicalplants.js) and replace the common names with the binomial names.
Also see (#24).

Currently all server integration tests are run with a common application instance. This has the obvious problem of one test affecting the other. Create new application instance for each test.

For further guidelines see https://glebbahmutov.com/blog/how-to-correctly-unit-test-express-server/

Write function that finds a list of current weather warnings (frost, rain) when given a geographic location.

Weather data is obtained from external web weather services. There are libraries available for many weather services, and generally the data is in JSON or XML format so it is fairly easy to handle manually.

Place code for example in shared/weather.js. Write also a test.

Currently the crop database is stored to both a local PouchDB instance and Redux storage. Would it be possible to make Redux use the local PouchDB instance for crops instead of duplicating the data to two places?

On Firefox the default localStorage quota seems to be about 5M and AFAIK the only way to change that is to modify dom.storage.default_quota in about:config. Other browsers also have such limits.

One solution could be to switch to using an IndexedDB-backed redux, for this localForage might work, or some other package.

Another solution could be to make redux use directly the local PouchDB instance, and continue using localStorage for smaller datasets. Currently the whole crop database is duplicated to both localStorage and the local PouchDB instance (it looked like the easiest solution).

Importing data to MongoDB is currently done in cli/cli.js, so the easiest way is probably to replace that by using the data returned by readCrops() from db/practicalplants.js.

The companionship algorithm (shared/companionship.js) calculates a score for the given set of crops in two steps: first the compatibility of the crops is determined, and if the crops are compatible, then the actual score is calculated.

The score is a sum of different goodness values. Each goodness value is defined by a goodness function and an importance factor. These goodness values represent how much of some feature is present in the input set of crops. This feature may be anything that looks useful. For example the diversity of different plant features is one class of goodness values.

Create new goodness functions.

We need page with filter and search functionality for the crops in the database:

• search field
• filter by (could be a seperate modal)
• pagination
• cards of basic information
• modal to show full list of attributes of an element
• should be editable

This whole think should be done with ant design.

Create UI component that shows current weather warnings (frost and rain).

Input data for this component will be obtained either directly from external web weather services (#2), or from powerplant server (#3), so make the interface generic enough. This component may be implemented and tested before real weather warning data is available.

This is quite clear for family and genus, but commonName and binomialName are not so clear. Add the test to test/db/practicalplants.js.

For verification of information we want to make sure to link sources to the information we provide.

Add a new model called Reference:

{
  link : String or null
  publication : String or null
}

Link or Publication has to exist.

Add a new Model called Sources:

{
  references : [Reference]
}

On Every model with information e.g. crop, companionship should have an object with all properties that are

• existent on the object
• and have a source entry

For that we need to extend the models with a property "sources". Default: {}

And a method to add sources:

objectWithInfo.addSource(property,{link : "exampleLink"})
objectWithInfo.addSource(property,{publication : "exampleString"})
objectWithInfo.removeSource(property,{link : "exampleLink"})
objectWithInfo.removeSource(property,{publication : "exampleString"})

Should add the according entry (link/publication) Reference to the Source on the property entry in sources of the object.
On the Crop object it would look like this.

Crop = {
  propertyName : "value"
  sources : {
    propertyName : Sources
  }
}

Best practice:

Write test for

• Reference does exist on object
• Reference does not exist
• Sources does not exist
• Sources exist

then implement the functions

Later the Sources and the Reference object will have more functions. For now this will be enough.

For building and testing a practicalplants wiki integration for powerplant, create instructions for setting up a local MediaWiki with practicalplants format. Note that there are dumps available that have been created with the WikiTeam tools, and it should be possible to import these to a MediaWiki instance by following this.

Leave a comment here with more fine-grained instructions for your environment, we can then think of creating a wiki page on github for documenting the process.

We want to don't double code, so we want to use in the webclient and cli the same API functions.

All API calls should be written/moved into shared/client/api.js.
At the moment they are in client/apiCalls.js and cli/api-client.js.

At the moment our crop model has no further attributes then the name and the binomial name. To utilize the data from practical plants we need to add more attributes.

We have a camel case name convention and practical plants has not. We don't want to copy there name convention:
Write a mapping of all attributes in practicalplants.js in PP_PROPERTIES to properties in the crop model:

The average Case should be renamed with this function:

function noWhiteSpaceAndCamelCase(ppName){
	return {
		[ppName] : ppName
			.replace(/( [a-zA-Z])/,(match)=>match.toUpperCase())
			.replace(' ','')
	}
}

But there are other attributes where it doesn't work, so we have to write exceptions. An example looks like this:

{
	binomial : "binomialName",
	...toCamelCase("genus"),
	...toCamelCase("family"),
	...toCamelCase("life cycle"),
	...toCamelCase("hardiness zone"),
	...toCamelCase("water"),
	...toCamelCase("drought"),
	...toCamelCase("soil texture"),
	...toCamelCase("soil ph"),
	...toCamelCase("wind"),
	...toCamelCase("maritime"),
	poornutrition : "poorNutrition",
        ...
}

Extend the model definitions, with the definitions in practical plants with enums and defined values. Null should be default for unset.

The companionship algorithm (shared/companionship.js) calculates a score for the given set of crops in two steps: first the compatibility of the crops is determined, and if the crops are compatible, then the actual score is calculated.

The score is a sum of different goodness values. Each goodness function is assigned an importance factor that specifies how important it is in relation to other goodness values.

We should decide which features are more important than others and assign the importance factors based on that. Roughly speaking the importance factors should be biased towards food production.

Dropdowns are broken when the list of options exceeds the window height, see for example the dropdowns for family and genus.

Note that we want to eventually move to antd (#55, #46) which is also based on React, so it might be possible to fix this by using some antd component and start the refactoring process.

Once #24 and #25 are done, the companionship algorithm should be enabled in production code. This means replacing the current logic of the HTTP API calls /api/get-crop-groups and /api/get-compatible-crops with logic based on the companionship algorithm (or if they are already moved to browser side then replacing the logic there).

Currently application and tests use a common database. Remove this interference by using a separate database for tests.

Expensive calculations should be done on the client side to release the server from processing.

Move/implement complex functions from server to client:

• getCompatibleCrops
• getCropGroups
• removeCropGroupsFromCombinations
• check for other complex calculations you find on the server side e. g. server/processor.js that should be moved

Since we don't want to use google as necessary dependency, we want to implement a way to do it also without Google Api request.

Add to the form of creating locations a option to use coordinates directly by picking a coordinate on the map. Use OpenLayer. (or a better OpenSource OpenStreetMap solution)

Currently all changes that any client makes get synchronized to the server and all clients by PouchDB. Restrict this by allowing only clients from localhost to modify the central server database (with npm run migrate and npm run cli). This is the first step of implementing #40.

We are currently using react-tagsinput for grouping crops with tags. It would be easier to get a common style with the rest of the application by creating a component that is based on react-bootstrap components.

The Crop property matureMeasurementUnit is used for specifying the unit of the properties matureHeight and matureWidth. The unit can currently be either meters or feet. It looks preferable to remove the unit property and convert all values to meters in the preprocessing step in db/practicalplants.js.

Currently practicalplants.json is in mongoexport JSON format, we don't use MongoDB anymore so it would be better to convert this to plain JS file that can be included with require.

Look into refactoring the UI to use Ant Design to minimize the need to build basic components from scratch (like we now do with react-bootstrap).

Currently the most specialized components that we have are:

• List view with pagination (for crops)
• Tag input (for grouping crops)

Ant Design has also some support for building advanced search features, which might be useful for searching crops with a combination of different criteria (by selecting the wanted properties, by being good companions).

Server HTTP API should be fully tested. Tests for get-crops-by-name and possibly others are still missing. Add tests for all API calls and check that all of their parameters are covered.

Note that some functions are being moved from server to client side by #6. API calls that correspond to these functions may be removed so there is no need to write tests for those.

Currently the PouchDB design document with the validate_doc_update function is created during npm run migrate with an HTTP call. It would be more robust to also check that the design document exists and is up-to-date on startup, and since it is a normal document to create it with the PouchDB methods instead of HTTP. See pouchdb-design.

The search and filtering tests that are using the crop database take a long time, it would be nice to divide tests to fast and slow. Probably add another package.json script test-also-slow that would run all tests, add a tag to the slow tests and use the --grep option of Mocha. Or is it possible to filter tests by selecting those that have timeout set to high value or infinite?

Use the validations written by #13 in shared/validation/models to validate the model on the client side and use the knowledge from server/models to do basic validation.

Write them into client/reducers before data is added to the store.

In #20 it was found that there are many properties that are missing a value for most crops. From algorithmic point of view some of these properties look useful, so it'd be interesting to analyze what sort of crops do contain values for these properties, and especially if they are mostly common food crops then these properties should be also extracted.

Currently when the server database is destroyed and created again with npm run migrate, the clients end up with duplicate Crop documents (this can be fixed by manually removing the local IndexedDB databases). There should be logic in the client to keep only the latest crop document that comes from the server.

Create companionship algorithm that calculates a score for a set of plants based on combined information from practicalplants.org wiki (db/pfaf.json) and our companion database (db/companions.js).

We need test for our server side functions in server/middleware.js

Write simple tests for the functions that should not work to test the validation of models and bad requests.

related with #13

The function readCrops() in db/practicalplants.js selects useful properties from raw practicalplants.org data and normalizes their content to a format that is easier to handle for the companionship algorithm.

There are still quite a few properties that are not selected and normalized by readCrops(). It would be useful to have more data available for the creation of new goodness functions for the companionship algorithm.

Look for "TODO" in db/practicalplants.js.