UI for management of organizations.

• 3.0 Organizations - User Flow
• 3.0 Organizations - Wireframes

Create and edit forms: usually only vary in the types of fields; we should build reusable templates for these pages.

Implement views and tests for:

• Create
• Update
• List (with search, filter, sort)
• Detail view
• Summary view
• Archive/unarchive
• User role assignment

In each case, tests should include:

• Successful requests;
• Unauthenticated requests;
• Unauthorized requests;
• Invalid payloads.

USER+s can list all parcels for a project (searchable, sortable, filterable list) and view parcel overview.
Parcel overview: map (if geometry exists), parcel and relationship history, resources, other parcel data. Additional per-parcel fields initially will be restricted to an address, possibly a government parcel ID number and a parcel area.

DC+s can create parcels and edit their details.

DC+s can archive parcels.

The parcel map view (for editing and viewing) should show surrounding parcels for context.

Parcel outlines can be: drawn on the map.

DC+s can upload and archive parcel resources.

• List (sortable, filter, search)
• Create
• Get Detail
• Update
• Archive/Unarchive
• Delete(?)

USER+s can view the list of parties for a project (searchable, sortable, filterable list).

DC+s can create new parties and edit and archive existing parties.

DC+s can upload and archive party resources.

Archiving a party potentially archives all associated relationship information.

There is a mechanism for assignment and de-assignment of roles to user accounts.

Searchable/sortable/filterable lists: all list views (organisations, projects, parcels, parties, relationships, resources) should be universally sortable (including a simple multi-column sort), filterable (again, by multiple columns, using quick dropdowns), free-text searchable and should support pagination for long lists (some of the lists might also require bulk operations, e.g. for adding users to an organisation or project; we should develop a pattern for these bulk operations that we use consistently across the platform).

Archive/delete flows: usually involve similar “Click ‘Delete the thing’ → modal to confirm → delete” interaction pattern.

Create and edit forms: usually only vary in the types of fields; we should build reusable templates for these pages.

Form field validation: the same for all forms, so we can define the forms in HTML5 and build one reusable validation script.

Slippy map

Editable polygons on map

Permissions system

Archiving: archiving functionality in base data model (including correct treatment of entities associated with archived entities); control of visibility of archived objects in front end; archive/unarchive UI.

History

all list views (organisations, projects, parcels, parties, relationships, resources) should be universally sortable (including a simple multi-column sort), filterable (again, by multiple columns, using quick dropdowns), free-text searchable and should support pagination for long lists (some of the lists might also require bulk operations, e.g. for adding users to an organisation or project; we should develop a pattern for these bulk operations that we use consistently across the platform).

Form field validation: the same for all forms, so we can define the forms in HTML5 and build one reusable validation script.

Adapt the current development VM setup to provide full staging/production deployment to AWS. That means:

• AWS resource configuration using CloudFormation;
• database setup;
• Django production logging and error email setup;
• Production nginx + uWSGI web serving;
• Webpack build of static assets.

As a user I want to be able to upload point data from field data instruments such as total stations and GPS

Requested by @nastynoel and moved over from trello

Archive/delete flows: usually involve similar “Click ‘Delete the thing’ → modal to confirm → delete” interaction pattern.

Behavioural design, API endpoint and permissioning for management of archival status of projects.

• Define actions for organizations (create, edit, list, archive/unarchive, role assignment)
• Write permissions policy fragments for project permissions for initial fixed roles

Roles and Permissions:

• SUs can create organisations and edit their information.
• OAs can edit the details of the organisations they administer, SUs can edit the details of all organisations.
• OA+s can archive an organisation.
• OA+s can list all organisations (searchable, sortable, filterable list).
• OA+s can manage the user membership list for an organisation, adding or removing members and assigning roles to users within the organisation (as well as user-level permissions).

History

• Behavioral design
• API endpoints
• Permission management

Need to agree on a concept of "archived"

• Who can view, access and edit archived projects.
• What happens to projects, parcels, parties and relationships when the organization is archived.

Organizations have:

• Name
• Description (optional)
• logo (optional)
• contact emails (0..n)
• telephone number
• Implicit list of organization admins (Managed by assigning roles to users)

Implement alongside:

• Test factories

As a user I want to be able to annotate resources that were converted from analogue format.

requested by @nastynoel and moved over from trello

It seems like it might be a good idea to have “feature toggles” where we (or PM+s?) can switch more complex features (as we develop them) on or off at a project level. This will also make life a bit easier for testing, since we can roll new features out to guinea pig projects first, rather than dropping new stuff on everyone at once.

UI tasks for #7

Pages included:

• Registration page
• Login page
• Profile page
• Password change
• Password reset

Other issues:

• Error messaging
• Password reset email?

DC+s can add relationships for a party or parcel and edit and archive existing relationships. Relationships can be created in three different ways (for all three there should be an option to replace existing a relationship for parcels if one exists):
By creating a relationship from scratch, selecting party and parcel from a list.
“Add new relationship” from a party page, and select the parcel.
“Add new relationship” from a parcel page, and select the party.

When creating and editing relationships, DC+s can select from a list of predefined right, responsibility and restriction types. This list consists of standard types.

When relationship details are edited, new relationship history entries are generated. New relationships maintain links to earlier relationships via the relationship history, so that it is possible to trace the history of transfers of tenure.

DC+s can upload and archive relationship resources.

DRF serializer for project model.

PM+s can view a full resource list for a project (searchable, sortable, filterable list). (This should have an extra filter to allow for viewing just project resources, just party resources, just parcel resources, etc.)

• Define actions for projects (create, edit, list, summary view, detail view, archive/unarchive, role assignment, others?)
  • Write permissions policy fragments for project permissions for initial fixed roles

Specifically, from earlier notes:

• OA+s can create projects and edit their information.
• OA+s can manage the list of PMs for a project.
• PM+s can list all projects that they can access (searchable, sortable, filterable list). (Shouldn't this be possible for all users?)
• PM+s can edit the details of the projects they manage.
• PM+s can manage the archival status of a project.
• PM+s can manage the user list for a project, controlling membership and assignment of project roles to users, as well as per-user permissions within projects.

Permissions system: the reusable backend component of this is https://github.com/Cadasta/django-tutelary.

Initial use in platform: back-end system for policy-based access control (data model, policy grammar, permissions engine); fixed roles defined by developers; no user-visible reference to policies, user-level permissions, etc.

SUs can monitor platform health to ensure that the platform is available and performant.

Manage visibility of projects in list views based on user identity and their public/private flag.

Requirements

• Public projects should be visible to all users.
• Private projects should be visible only to users who are members of the organization with which they are associated.

Tasks and tests

• Add project visibility flag to project model.
• TEST Create projects with different visibility.
• TEST Visibility in serializer.
• Add project.view_private action to project actions.
• Add appropriate project.view_private permissions to policies for roles.
• Modify project detail API view to control access to private projects.
• Change user role assignment on organization membership to include project.view_private permissions.
• TEST Detail API view: private projects should only be visible to members of the owning organization.
• Modify project detail API view to handle patching of visibility flag.
• TEST API visibility flag patching (create private view, test for permission denied for non-member user, patch visibility flag to make project public, check for accessibility to non-member user).
• Modify project list API view to filter results based on user organization membership and project visibility flags: public projects should be visible to all users, private projects only to those users who are members of the organization owning the project.
• TEST Fixtures for project list visibility testing: create a number of projects, some public, some private, belonging to a number of different organizations.
• TEST Project list API view 1: all public projects should be visible to all users.
• TEST Project list API view 2: private projects should be visible to all users who are members of the organization owning the project.
• TEST Project list API view 3: no private project should be visible to any user who is not a member of the organization owning the project.
• Refactor visibility control for use in both API and template views
• TEST Detail template view: private projects should only be visible to members of the owning organization.
• Modify project list template view to filter results based on user organization membership and project visibility flags.
• TEST Project list template view 1: all public projects should be visible to all users.
• TEST Project list template view 2: private projects should be visible to all users who are members of the organization owning the project.
• TEST Project list template view 3: no private project should be visible to any user who is not a member of the organization owning the project.

Different individuals are often involved in the collection of data as part of property titling process. Current mobile collection workflows with Cadasta involve entering new records. They needs to be a workflow where a project can have existing partially completed data which can then be assigned to a data collector to then complete.

Sample use case:

In the Philippines there is a rapid assessment done at the start of a titling process. The desired process looks like this:

1. Data is gathered at the beginning of the process it is as followed: lot number, survey claimant, lot data status, lot area (from tax declaration), tax declarant (from tax declaration) and put into Cadasta. This information comes from a couple of offices that would want to enter it through a web interface.
2. Data is downloaded on a mobile survey for offline collection
3. Accessor goes and files in the remaining field: Current Claimant, Address of Current Claimant, Representative, Address of the Representative, Mode of Acquisition, Dominant Use, Remarks
4. Collector sync's data back at office

Big map showing project extents and parcel boundaries.

Selectable base map, initially using standard tile servers.

Click on parcel to show details (parcel ID, number of relationships, link to details view?) either with some sort of pop-up or a modal dialogue.

Users should provide: user name, password, email address, full name, optional avatar image.
User-selected username account ID (not email address).
Account verification, password reset, “remember me” cookies, etc.
Password reset and change from profile page.
API authentication.
Email addresses should be verified (this should be fine since we’re not requiring “public” viewers to have an account). Handling unverified emails: When a user signs up they can use their account without verified the email for some time. An information message should be displayed when their email is not verified. After some time the account is suspended, providing the user the option to resend the verification email.
Allow updates of email address (with verification), but not multiple email addresses per account.
No user should be able to edit or delete user accounts other than their own account. It should be possible for an OA to remove a user from their organisation, but not otherwise to modify the user’s account. A SU should probably be able to archive user accounts, but not an OA.

Use a translation framework from the start. Should be compatible with Transifex or a comparable service.

OA+s can list all users registered with the platform (searchable, sortable, filterable list). They should be able to bulk select from that list for further actions, such as adding permissions.
OAs can see user profiles with all permissions.

SUs can create organisations and edit their information.
Organisations have: name, optional description, optional logo, optional URL(s), optional contact email(s) or telephone.
OAs can edit the details of the organisations they administer, SUs can edit the details of all organisations.

OA+s can archive an organisation.

OA+s can list all organisations (searchable, sortable, filterable list).

OA+s can manage the user membership list for an organisation, adding or removing members and assigning roles to users within the organisation (as well as user-level permissions).

archiving functionality in base data model (including correct treatment of entities associated with archived entities); control of visibility of archived objects in front end; archive/unarchive UI.

Organisation contacts will be stored as JSON using a hcard-like format. A custom validator function is required for the field, that checks if required fields are provided, correct types and formats.

jsonschema can be used for validation.

Project overview UI: description, map, parcel and resource activity (plus UI elements for editing project resources visible to users with sufficient permissions). Also summary statistics for project; this may be all that USERs see.

Project extents (settable and editable by PM+s): draw on map.

PM+s can manage per-user permissions within projects.

DC+s can upload and archive resources for the project.

DC+s can list all resources for projects that they can access (searchable, sortable, filterable list). (This includes both project-level and entity-level resources. The view here should allow filtering by resource type.)

Editable polygons on map (existing plugins for leaflet to help with this)

As a user I want to be able to upload data represented/captured in coordinate systems other than WGS-84

requested by @nastynoel and moved from trello

Slippy Map

• Project list with search, filter, sort
  • Access project details
  • Create, update
  • Archive/unarchive

Add DRF views to:

• Create
• Update
• Delete (?)
• Get organization details
• Get organization list (including sorting, filtering, search)
• Archiving/unarchiving
• Permission management

Tests should include

• Successful requests
• Unauthorized requests
• Unauthenticated requests
• Invalid payloads

When following the directions, I get this error while running vagrant up --provision:

==> default: Running provisioner: ansible...
    default: Running ansible-playbook...
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit='default' --inventory-file=/home/pnorman/cadasta-platform/.vagrant/provisioners/ansible/inventory -vvv provision/vagrant.yml
ERROR: postgresql_ext is not a legal parameter in an Ansible task or handler
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

As a user working with resources converted from analogue format, I want to be able to perform the following functions.

• Despeckle
• Deskew
• Adjust brightness
• Adjust contrast
• Rotate (clockwise, 180degrees, counterclockwise)
• Blank selected area
• Fill selected area
• Crop
• Image info dialog box (name, size, resolution, paper size, dimensions in pixels, etc.)
• Area select tools (rectangle, oval, circle, freehand)
• Panning and zooming tools

Edits to a resource should result in the creation of a new resource so that edits can be tracked by version. On completion of editing tasks, users should be asked to commit final edits

Requested by @nastynoel and moved over from Trello

Fixed permissions policies for stereotyped user roles (“roles” have a policy assigned to them with a particular set of permissions):

• Super user (SU): An administrator of the platform. SUs should be able to to access all data and perform any actions.
• Organisation admin (OA): Works directly with organisations and communities. Can create new organisations and projects and has wide-spread permissions to access and act on objects. Appoints PM(s). Is appointed by a SU or other OA.
• Project Manager (PM): Works in-field on specific projects. Can access and act on objects assigned to a project (parcels, relationships, parties). Is appointed by OA. Appoints DC(s).
• Data Collector (DC): Works in-field with the communities mostly using their mobile phone. Can add, edit, import, or review data in a project (parcels, relationships, parties). Is appointed by PM.
• User (USER): Public users. Don’t need to sign up. Can access public information only.

• Projects and organisations have sets of active roles and policies.
• When a new organisation is created, a set of roles and policies for the organisation are copied from a platform-wide set of templates.
• When a new project is created, a set of roles and policies for the project are copied from the organisation-wide roles and policies.
• Roles and policies can be edited at the platform, organisation and project level.

This information has been moved into the wiki for further discussion and definition.

Questionnaire Creation

1. Project Manager creates XLSForm with the questions they want (likely using Excel)
2. Project Manager uploads XLSForm to Cadasta Platform
3. Cadasta Platform parses XLSForm and creates custom data model from the form.
4. Data can then be entered into Cadasta in one or two ways.

Mobile Phone Data Entry:

Data Collectors :

1. Data Collector opens mobile phone app (ODK Collect/GeoODK) and enters in the "General Settings" their Cadasta username and password and the URL to the survey download endpoint of Cadasta
2. Data Collector connects to Cadasta Platform and downloads available questionnaire
3. Data Collector then selects a questionnaire to download and downloads the questionnaire
4. Data Collector fills out questions
5. Data Collector uploads responses to Cadasta platform

Web Data Entry :

1. Data Collector logs into Cadasta web platform
2. Data Collector goes to project
3. Data Collector clicks "add new data"
4. Data collect enters responses

Data Import

1. Project Manager logs into Cadasta web platform
2. Project Manager goes to project
3. Project Manager clicks "upload data"
4. File is uploaded into the project.

Data Review

• Project Manager reviews and validates/invalidates uploaded questionnaire data (all new data is considered unvalidated).
• Project Manager can view a list of unapproved data sets (searchable, sortable, filterable list), and approve/reject data entries, either in bulk or on a per-item basis.

Editing of Data

• If a record is edited its status becomes invalidated and it needs to be approved by a project manager
• Data collectors can edit existing records

Notes:

• Needs to be a way to map between default data and questions.
• Resources are considered part of the questionnaire data. For example a photo question should be imported as a photo resource into the Cadasta platform
• Project Manager can edit questionnaire data before approval

There is a page in the UI for administrators to control the assignment of roles to users.

Wireframes and user flow: https://drive.google.com/open?id=0BzpiEtMtHC3rVy1HeEh4eVhmbEU

Wiki design documentation: https://github.com/Cadasta/cadasta-platform/wiki/4.0-Users

All labels must be translatable. Internationalisation will be based on Jed and Sprintf.js.

• Move test-framework to karma, using a webpack pre-processor to compile .po files
  • Mock HTTP requests (an alternative to Nock is required)
  • Update testing docs, replace nock with sinon.fakeServer
• Replace labels and messages with translate functions in the following components
  • account.Activate
  • account.Login
  • account.Logout
  • account.Password
  • account.PasswordReset
  • account.PasswordResetConfirm
  • account.Profile
  • account.Register
  • account.RegistrationForm
  • core.App
  • core.Header
  • core.Home
  • messages.actions
• Mark missing translations
• Add styling for translations to CSS
• Add React component handling

Building base css for site.

Includes:

• Header
• Footer
• Base fonts
• Base colors

Implement Django model for projects.

Projects have:

• Owning organisation
• Name (unique per organisation)
• Country
• Optional description
• Optional image(s)/logo(s)
• Optional URL(s)
• Optional contact email(s) or telephone
• Private/public flag (controls whether the project summary page is publicly visible)
• Project extent/boundaries
• Project manager list -- adding a user to this list gives them project manager permissions. (In fact, project-level permissions will be managed directly by assigning roles to users, so the project manager list will be implicit.)

The per-project public/private flag should really be “public with details”/”public, summary data only”/”private”, at least to begin with. More detailed permissioning of the visibility of different entities to the public can come later.

(As well as implementing the model, implement basic tests and any mocks that are needed for those tests, like mock image resources and mock spatial units for project extents.)