wiki:BluePrint/OccupyProjects

Version 50 (modified by devin, 12 years ago) ( diff )

--

BluePrint: Occupy Sandy Phase 2 Development

The following is a list of development tasks in order of their priority.

Projects

Status: Active - Aaron needs assistance

Description

The Occupy projects team is currently using a Google Form to capture information about projects, but it would be better to use Eden for this. This means providing a public view to project data, so that potential volunteers can learn about project activities and get in touch with coordinators. Eden should also capture some additional information about projects and enable project leaders to register certain needs (like volunteers or technical help) to the people responsible for those things.

Use-Cases

A project team member would register for the Sahana site as a "Project User" role, which would allow them to register their project in the system. Once registered, Project Admin users can approve or reject them. Approved projects have their basic details publicly accessible via table and map views, but the rest of their information would only be accessible to project owners and project admins. An additional tab on project profiles only viewable to project owners and admins would be a threaded comments section where those two groups could publish notes and communicate with each other.

Project users have the ability to make requests for supplies, people (skils) and services from the network. Project Admins maintain a directory of "services" (new request type: services) that can be requested by projects. Services consist of a Title, Description and General Contact Email and can be associated with a Person Entity: individual, group/team, organization. When a project requests a service, the general contact is sent an email notification (via saved search and notification functionality). These requests would be viewable by filtering services for type: services.

New project data fields

This is how it seems the fields in the Google form map to existing database objects:

  • Project name: project name
  • Project blurb: short activity description
  • Project description: project description
  • Organization: lead implementor
  • Location: activity location
  • Services needed: tasks, assigned to service leads (tech, volunteers, grants, budget)
  • Private contact information: reference to project lead
  • Public contact info: who people should get in touch with if they're interested in helping (could just go in description)

These are fields that don't seem to have an analog in Eden's models and would be added:

  • Project (Activity?) category: new model with entries like distribution, food, etc.
    • An example of how to attach a category to project and/or activity objects can be seen here (activity type is inserted into the project_location form). The same could be done here using this link table.
  • Media link: url to Youtube site, etc.
    • Could just rename the "Attachments" tab for your site [but does this allow "attachment" of URLs?]
  • Project partners: individuals and org references
    • Use project_organisation table settings.project. multiple_organisations = True

Michael points out that many "missing" fields can be turned on via the deployment settings.

New views

Public All Projects View (Public): This is the main view for the public where they can see all "approved" projects via the following columns:

  • Project Name (link to project)
  • Activity Status
  • Description
  • Public Email
  • Categories

Admin All Projects View: view for admins should have the following columns:

  • Project Name (link to project)
  • Activity Status (Past, Present, Future)
  • Administrative Status (Pending, Accepted, Rejected) (implemented by just showing approved_by email address)
  • Project Categories
  • # of Pending Requests
  • Bottom-liner Contact
  • Support Contact

Project Map Stub View: for projects that are connected to location, add the following columns:

  • Project Name (links out to Project Page)
  • Project Blurb
  • Categories
  • Email Address
  • Location

Individual Project View: [possibly just the "/read" view for project with permissions tweaked?]

  • Basic Details (public) (bold = implemented)
    • Project Name
    • Project Blurb (max 100 characters)
    • Status (past, present, future)
    • Administrative Status (pending, accepted, rejected)
    • Project Description
    • Location (if any)
    • Categories
    • URLs (for Media Link, Fundraising Link, Website, Social Media)
    • Project Relationships (Associated entities)
    • How people can help.
    • General Contact
  • Comments (only view-able able to project admins and project owner)
    • Administrative Status (pending, approved, rejected)
    • Project Liaison
    • Last Check In (timestamp)
    • Threaded comments
  • Requests (viewable to everyone but public users)
  • Contacts (viewable to everyone but public users)
  • Attachments (viewable to everyone but public users)

Add Comments to Projects

Add threaded comments as a "comments" tab on project profiles only viewable to project owners and project admins.

Add "Services" Request Type

Services are defined as:

  • Title
  • Description
  • Contact: person entity associated with providing the service.

Services can be managed by users with the Project Admin user role - or better yet, entities can define the service they'd like to provide and then manage information about their services themselves.

Projects can request services. When they do so, the services contact receives an automated notification about the request via email (powered by the saved search & subscription functionality).

Give Projects Request Functionality

Give project owners the ability to request supplies, people and services by linking projects to requests. This can be done by creating a link table holding both project_id & req_id. It will require changing how the system makes facilities mandatory for project requests. Requests would then be added as a tab on project pages.

Status: Needs an Owner

Implementing the following top level navigation menu structure would do wonders for usability:

Inventory, Assets and Contacts Definitions

Status: Needs an Owner

Inventory

The following items have been defined in this spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AvGeaSVQPEYUdDZmbm9aWlFINGtnN3ZBcVJnYzlhb2c&usp=sharing

  • Asset
  • Asset Log
  • Contacts

Only sheets with colored columns should be implemented. The following color coding is used:

  • Green = recommended
  • Yellow = if necessary
  • Red = delete
  • red = delete
  • red = delete
  • red = delete
Note: See TracWiki for help on using the wiki.