-
Notifications
You must be signed in to change notification settings - Fork 573
Categories & Statuses
The goal of this page is to explain the reasons and potential use cases behind the Status and Category collections. To best understand these concepts see these schema files from the project:
/schema/Category.js/schema/Status.js/schema/StatusLog.js
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 name and pivot really.
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.
Note: 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 documents.
...
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.
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.