diff --git a/docs/deployments/firebase.mdx b/docs/deployments/firebase.mdx
index edd58dec..81ff33a6 100644
--- a/docs/deployments/firebase.mdx
+++ b/docs/deployments/firebase.mdx
@@ -144,39 +144,6 @@ Firebase will update the files `firebase-hosting-pull-request.yml` and `firebase
alt="Github actions created by firebase"
/>
-## Registering Studies
-
-:::caution
-This step must be followed **exactly**. See [Security Rules](#security-rules) for more information.
-:::
-
-1. Navigate to your Firestore Database in the [Firebase console](https://console.firebase.google.com/)
-2. Click "Start collection"
-3. Enter `registered_studies` for the collection id and click "next"
-4. Enter the id of your study for the document id
-5. Add a field named `registered_participants` with the type "array"
-6. Add the id of each study participant as a string inside the array
-
-
-
-
-
-The study should look like this when you're finished:
-
-
-
-
-
-**Additional studies must be created inside the `registered_studies` collection**
-
## Managing Data
Honeycomb ships with a CLI script for managing data in Firebase. A local service account must be created in order to use it.
@@ -234,24 +201,73 @@ Firestore rules are defined in the `firestore.rules` file in the home directory.
```firestore-security-rules title="firestore.rules" showLineNumbers
rules_version = '2';
service cloud.firestore {
- //highlight-start
match /databases/{database}/documents {
- match /participant_responses/{studyID}/participants/{participantID} {
- allow create, read:
- if participantID in get(/databases/$(database)/documents/registered_studies/$(studyID)).data.registered_participants;
- //highlight-end
- // ...
+ match /participant_responses/{studyID}/participants/{participantID} {
+ allow create, read:
+ // highlight-start
+ if
+ // Allows any combination of studyID and participantID to be created in Firebase
+ true
+ // participantID must be in the registered_participants array in the registered_studies/{studyID} document
+ // participantID in get(/databases/$(database)/documents/registered_studies/$(studyID)).data.registered_participants;
+ // highlight-end
+
+ // experimentID must be in the data subcollection
+ match /data/{experimentID} {
+ allow create, read: if true
+
+ // trialID must be in the trials subcollection
+ match /trials/{trialID} {
+ allow create, read: if true
+ }
}
}
+ }
}
```
Lines 3 and 4 indicate that Honeycomb attempts to connect to a document at `/databases/{database}/documents/participant_responses/{studyID}/participants/{participantID}` where `studyID` is a given study and `participantID` is a given participant within that study.
-Line 6 defines our rule - it must pass for Honeycomb to connect to the document. `participantID` must be found in an array called `registered_participants` inside of a document at `/databases/{database}/documents/registered_studies/{studyID}`.
+Line 5 indicates how Honeycomb can interact with that document. Note that Honeycomb cannot update or delete data! You must use the [CLI script](#using-the-cli-script) to delete data.
-Line 5 indicates how Honeycomb can interact with that document. Note that Honeycomb cannot update or delete data! You must manually make these changes from the Firestore console.
+Lines 6 through 10 defines our rule for creating a document for a given participant at `participant_responses/{studyID}/participants/{participantID}`. Honeycomb ships with two possible rules:
+
+1. Line 8 specifies `true` which allows any combination of `studyID` and `participantID` to be created in Firebase.
+
+ :::info
+ This is the default rule Honeycomb ships with. It is recommended to leave this rule as is and handle the registration of studies in another tool such as [Prolific](prolific).
+ :::
+
+2. Line 10 only allows a `participantID` to be created if the value is in an array called `registered_participants` inside of a document at `registered_studies/{studyID}`. This ensures pre-registration of every study and participant - the [next section](#registering-studies) explains how to register studies.
+
+:::caution
+Firestore rules define every valid path for data in your project. Attempting to connect anywhere besides the paths in your Firestore rules will be automatically denied, even if you have manually saved data elsewhere. This is why `firestore.rules` contains the nested rules in lines 12 - 20. These should be left alone.
-:::danger
-Firestore rules must define every match pattern in your project. Attempting to connect anywhere other than `/participant_responses/{studyID}/participants/{participantID}` will be automatically denied even if you add other collections to your database. This is why `firestore.rules` contains additional nested rules - these should be left alone.
:::
+
+#### Registering Studies
+
+1. Navigate to your Firestore Database in the [Firebase console](https://console.firebase.google.com/)
+2. Click "Start collection"
+3. Enter `registered_studies` as the collection ID
+4. Enter the id of your study as the document id
+5. Click "Add Field".
+6. Enter `registered_participants` as the field name, and set the type "array"
+7. Add the id of each study participant to the array as type "string"
+
+
+
+