Skip to main content

Set a Tag for a Researcher, Study, Participant, Activity, or Sensor, or its childen.

Tags act as a hierarchical key-value store localized to each Resource. That is to say, Participant A has a completely different key-value store instance than Participant B or Activity X. Furthermore, the resource hierarchy also influences the contents of the key-value store. If a Researcher sets a Tag "hello.testing" on Participant A with the contents "hello world", then Participant A will be able to query their tags and see "hello.testing" exists, even though it was not created by Participant A. The side-effect of this feature is called "tag masking": should Participant A now attempt to create "hello.testing" with the contents "bye world", this Tag will be successfully saved, but masked during retrieval by the version created by the Researcher.

There are four target types that act as a selector for which key-value store will be manipulated.

  1. "me": Implicit self; Automatically substitute the id parameter as the target. See (2) for semantics.
  2. id: Explicit self. Manually specify the id parameter as the target. This selects the key-value store corresponding to the resource itself.
  3. {type}: Implicit child. This should be one of "Researcher", "Study", "Participant", "Activity", or "Sensor". This selects the key-value store that spans all children resources of that resource type!! For example, a Researcher may create a Tag targetting Participant (all Participant children of all Study children of the Researcher resource itself), such that the Tag applies to ANY child Participant.
  4. {id}: Explicit child. This should be a specific child resource ID, and selects the key-value store of that specific child resource ONLY.

In most cases, either (1) or (2) are what you will want to use, as these select self's specific key-value store. There are, however, a few cases for (3) and (4). For example, if a study needs to manage delivered gift card codes, using (1)/(2) would be problematic, as this inadvertently allows the Participants to modify the delivered codes.

The deprecated name for this operation is Type.set_attachment.

Path Parameters
id string REQUIRED

The id of the Resource (Researcher, Study, Participant, Activity, or Sensor) to create or update a Tag. The special case "me" parameter can also be used to implicitly refer to the Resource ID of the currently authenticated user (Credential).

key string REQUIRED

The key of the Tag in reverse-DNS format (i.e. org.digitalpsych.college_study.demographics). This must be unique per key-value combination, otherwise the corresponding value will be overwritten (if the Tag does not already exist). The prefixes "lamp." and "digital.lamp." are reserved for internal use only.

target string REQUIRED

The target selector for the specific key-value store. (See description above.)

Request Body REQUIRED
undefined
Responses
200

Success

Schema OPTIONAL
data OPTIONAL
default

Error

Schema OPTIONAL
error string OPTIONAL