Update Firestore information in CONTRIBUTING.md #trivial #313
Conversation
Generated by 🚫 Danger |
| @@ -409,6 +421,146 @@ Filter structure is public information and should never (or very rarely) need to | |||
|
|
|||
| </details> | |||
|
|
|||
| <details> | |||
| <summary class="collection" id="forms-collection"><b>forms</b></summary> | |||
| Initially, the purpose of this collection was to gather requests from users to change their permission level to contribute with various details introduced in the application, such as <a href=#events-collection>events</a> in the timetable or information about a particular <a href=#classes-collection>class</a>, like grading, valuable links, and resources. This form can be accessed by each user from the *Settings* page of the application. | |||
There was a problem hiding this comment.
The process behind the design is not relevant for documentation. We care about what the current state is, not what it used to be. Please remove the "initially... subsequently..." stuff and focus on the current state of the system.
Think about what someone who is using the database for the first time would need to understand about the structure of filters.
| </tr> | ||
| </table> | ||
|
|
||
| The second document, `class_feedback_answers`, has a more complex structure. It is composed of multiple _subcollections, whose keys are defined by the number of the question in the feedback form. Furthermore, each _subcollection consists of a list of documents with an automatically generated key, while each document represents the answer submitted by a user to that question. As we reach the end of the hierarchy, an answer is composed of the actual value (the result or the comment provided), together with the details related to a class (its name, associated teacher, and assistant). To provide anonymity, we do not retain the ID of the user who completed a form. The structure of this document is as follows: |
There was a problem hiding this comment.
What's with the underscores?
|
|
||
| ###### Rules | ||
|
|
||
| Since forms in this collection are public information (_anyone can **read**_), altering and adding data here is a privilege and needs to be monitored. |
There was a problem hiding this comment.
Did you just copy paste this from somewhere else? We're not monitoring squat about the forms. The monitoring thing was likely something I wrote for the collections where we're actually storing who made a change, like websites.
|
|
||
| Since forms in this collection are public information (_anyone can **read**_), altering and adding data here is a privilege and needs to be monitored. | ||
|
|
||
| Users can **update** an existing form document _if their `permissionLevel` is equal to four_, more precisely they must have the role of admin. Additionally, _anyone who wants to **create** a new form document needs to be authenticated_ in the first place. |
There was a problem hiding this comment.
You wrote this but didn't provide any reasoning for it -- in the context of the feedback forms for instance, it makes no sense (why would an admin want to modify a form in the first place?). I believe we added this for the sake of edit permission forms. I'm tagging @GhiaraD in this so that he can comment/make suggestions or even add a commit here to add more info, but we may actually want to consider having separate permissions for different forms.
There was a problem hiding this comment.
Rules for forms are still a work in progress. Right now, admins can update any kind of form, but this rule is indeed intended only for permission requests. Admins can update them to mark them resolved.
|
|
||
| Since forms in this collection are public information (_anyone can **read**_), altering and adding data here is a privilege and needs to be monitored. | ||
|
|
||
| Users can **update** an existing form document _if their `permissionLevel` is equal to four_, more precisely they must have the role of admin. Additionally, _anyone who wants to **create** a new form document needs to be authenticated_ in the first place. |
There was a problem hiding this comment.
Rules for forms are still a work in progress. Right now, admins can update any kind of form, but this rule is indeed intended only for permission requests. Admins can update them to mark them resolved.
Add more details regarding the Firestore
usersandformscollections used, according to the Encouraging actionable feedback from students through a mobile application paper.