You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some functionality in the BDRS may be better implemented as separate projects.
For example in the weed spotter portal, species groups are used to define different weeds of significance per local government area/state.
In the weed bio-control portal groups are used to manage the control agent -> host relationship.
This part of the functionality may be better managed by using separate projects in BioCollect rather than attempting to replicate this functionality. (e.g. Each Local Government Area has a separate project with the Weeds of Interest for that area defined in a species list. Each host could have a separate weed biocontrol project with the agents for that host defined in a species list).
To make the "separate project" approach work, we will need to be able to tag related projects (e.g. as weed watcher , biological control or water watch) to allow for a combined view of all related projects and data. The mechanism used to perform similar functionality in MERIT is the Programmes model a similar idea would make sense, as we would like to be able to include a name/ image/ description for a tag.
For each Programme, we would need a:
Name,
Description
Logo
Coordinator (probably an "admin" of the Programme).
We would also need to be able to view all projects that are part of a programme together, in a similar way to how the organisation page currently works.
The text was updated successfully, but these errors were encountered:
I agree that it will be necessary to provide some sort of binding concept page for all related projects - perhaps a "program page" which functions in the same way as the "organisation pages" do for organisations would be OK for this.
A potentially complicating factor though is how user access is managed. In some portals (eg. the Waterwatch portals) separate projects would be configured for each region area and, whilst they all share use of the same form templates, each region has a unique set of sites and users. However, for portals such as the ACT Weedspotter, in order to manage different levels of user access to the 3 surveys that they use (ie. one is fully open public access and 2 are restricted to practitioners), we would need 2 projects which would need to be clearly part of the same thing with a user experience that is not too clunky.
Some functionality in the BDRS may be better implemented as separate projects.
For example in the weed spotter portal, species groups are used to define different weeds of significance per local government area/state.
In the weed bio-control portal groups are used to manage the control agent -> host relationship.
This part of the functionality may be better managed by using separate projects in BioCollect rather than attempting to replicate this functionality. (e.g. Each Local Government Area has a separate project with the Weeds of Interest for that area defined in a species list. Each host could have a separate weed biocontrol project with the agents for that host defined in a species list).
To make the "separate project" approach work, we will need to be able to tag related projects (e.g. as weed watcher , biological control or water watch) to allow for a combined view of all related projects and data. The mechanism used to perform similar functionality in MERIT is the Programmes model a similar idea would make sense, as we would like to be able to include a name/ image/ description for a tag.
For each Programme, we would need a:
We would also need to be able to view all projects that are part of a programme together, in a similar way to how the organisation page currently works.
The text was updated successfully, but these errors were encountered: