Skip to content
This repository has been archived by the owner on Dec 8, 2017. It is now read-only.
Sarah Allen edited this page Dec 2, 2015 · 6 revisions

Much of the Open Opportunities platform is organized around tags.

We're currently thinking a lot about how tags should work from a user experience perspective and some wonder if we should get rid of them completely. We've collected related use cases, see Data about Tasks and People

From a technical perspective, tags can be used to store data that is not freeform, and may be used to facet data objects within the application. For example, tags used for location can be used to query all people by a specific location, or tags used for skills can query projects that require a certain skill.

Tags are designed to be very flexible. They are (mostly) managed by the frontend backbone applications.

Tag Models

Tags are organized as follows:

TagEntity

Entities are the actual values of the tags that will later be associated with a user, project, or task (opportunity). They are structured as follows:

{
    id   : 'INTEGER',  // Set automatically by Open Opportunities on create
    type : 'STRING',   // The category of the type, such as 'skill'
    name : 'STRING',   // The name of this particular tag, such as 'node.js'
    data : 'JSON',     // Additional information about the tag, such as `lat` and `long` for locations
}

The api/tagentity endpoint provides the standard GET/POST/PUT/DELETE operations.

Example 1: Create a tag

[Needs updated docs]

Example 2: Delete a tag

[Needs updated docs]

Example 3: Create a tag for a user

[Needs updated docs]

Storage in the Database

It helps to see how this is stored in the database. One way to do so is with the psql command line tool. Remember that PostgreSQL by default converts column names to lower case, which doesn't play well with the Open Opportunities schema, so put column names in quotes.

[Needs updated docs]