Categories & Statuses
Clone this wiki locally
The goal of this page is to explain the reasons and potential use cases behind the
Category collections. To best understand these concepts see these schema files from the project:
Statuses and Categories address two very common needs. Managing state of documents (with logging) and classifying documents.
What is the
pivot field used for? This is used as a grouping mechanism. I could have use a pivot of
Account for my Account specific statuses. I could also have a
BlogPost pivot used for blog posts. This way I don't need to make multiple collections and/or schemas that are almost identical. It's very open ended, feel free to change it up.
When should I break away from these generic collections? Whenever you need to store anything besides the just a
By default, you can find statuses implemented in the Admin for Accounts (
/admin/accounts/). Statuses help us keep track of a document's current state, who changed the state and when. Documents can also be extended to use the
StatusLog schema to support logging. Logging helps us see the history of Status changes over time.
StatusLog is a just a schema definition. It doesn't reference an actual mongo collection. We store the log data on other records. You'll see this used for in the
/schema/Account.js schema where the
statusLog field is an array of nested
... statusLog: [mongoose.modelSchemas.StatusLog], ...
Note: Out of the box, nothing in Drywall uses categories, it's there for convenience and can be removed without worry.
Categories are similar to Statuses, but instead of 'state' think 'classification'. Also, Categories don't have logs.
Use the Force
I hope this was helpful. If you have questions or think this page should be expanded please contribute by opening an issue or updating this page.