Rules question: write a node if it doesn't exist, then allow conditional writes to children?

[Benjamin Mueller]

Hi,

I'm just digging in to rules for the first time, and I'll say up front that I have a bad feeling that the answer to my question here is going to be "you have to re-structure your data", but I'm going to ask it anyway.

We have an app where data is shared between teacher and students. We want a teacher to be able to create a shared classroom, add course content to that classroom, and then allow students to add responses to the classroom. So, imagine a structure like this:

"classrooms": {
  "classroom1": {
    "teacherId": "asdfg",
    "content": {
    },
    "responses": {
    }
  }
}

So imagine that I want a teacher to be able to create an empty "classroom1" node, but then I want the teacher to be able to write to "content", and teacher and students to be able to write to "responses". So for the content node, the rule would be something like (some pseudo-code below to keep things simple):

".write": "auth.uid === ${teacherId}"

...and then the responses node would be something like:

".write": "auth !== null"

That by itself seems, at least in theory, relatively simple, but then I'm stuck about what to do at the root level of "classrooms". I understand that rules cascade, with shallower ones taking precedence over deeper ones, but I have to define *some* kind of rule at the root level of "classrooms", or no data would be writeable at that node or any child nodes. What I want to say in general is something like "write a new classroom if none exists, but only if you're authenticated (assuming authenticated means you are a teacher for now), and once a classroom is written, then observe new write rules for the children". Is this even possible, or do I have to re-structure my data?

Thanks in advance for any advice!

Ben

[meme...@firebase.com]

It seems that your major source of confusion here is you need to treat ".read" and ".write" rules as if they are OR-ed together (if any rule along the path evaluates to true then the read/write succeeds) and ".validate" rules act as if they are AND-ed together (if any rule along the path evaluates to false then the write fails).  Another thing to note is that ".read" and ".write" rules work on the path that the request was made on and not the data, so if I try to write to /some/random/path with the data { a: { b: { c: 1 } } } then only the read and write rules are trigger for /some, /some/random and /some/random/path.  On the other hand the ".validate" rules work on the actual data that is written, so working from the same example the validate rules would have been triggered for each of the paths that the read/write rules were plus /some/random/path/a, /some/random/path/a/b and /some/random/path/a/b/c.

In this particular case I don't think that you have to restructure your data.  In your example you don't have to have any rules that explicitly allow any writes to the classrooms node as long as you allow access to the node lower that your end users need.  So if you let the teacher have access to all nodes in an individual classroom node and then let student only have access to the responses node inside an individual classroom then you can ignore the rules for any nodes that are above those (as nodes that do not have a ".read" or ".write" rules default to false for those).

Hope that helps,

Alex