Work & Development · Backend & Full Stack Development
Free preview
Define the private task and permission matrix
Lesson 1 of Full Stack Capstone: From Brief to Delivery. Anyone can read this lesson with no account. Every lesson after this one is for students.
Plan data and permissions
Choose a small private app, describe its user task and write rules showing who may do what.
1Begin with a private user task
A capstone is a project that brings your earlier skills together. You will connect the interface, server, database, sign-in, tests and release process. Choose a small learning or community task using invented records and test accounts. You can adapt the journal example, but explain your own choices. Do not import real student records.
A brief is a short description of the problem and the planned app. Say what the user needs, what data is stored and who may use it. Privacy is a rule you will demonstrate with tests. Keep payments, social messaging and unnecessary account roles out of this first version.
2Reference example
A Private Learning Journal lets learners River and Oak create, list, read, edit, and delete their own entries. River owns entry E001, "Practice keyboard navigation". Oak owns E002, "Review a budget formula". The application does not share entries between users. Authentication uses an established tool from your prerequisite course, not a homemade password system.
A permission matrix is a table of actions and who may perform them. Use it to make the access rule easy to check:
| Action | Signed out | Owner | Other account |
|---|---|---|---|
| List own entries | Denied | Allowed | Own list only |
| Read a particular entry | Denied | Allowed | Denied |
| Edit or delete | Denied | Allowed | Denied |
For this reference API, signed-out requests receive 401. An authenticated request for an unavailable or unowned entry receives 404 so the API does not reveal whether another user's record exists. Document this policy consistently.
3Your project steps
- Compare two possible user tasks and select one.
- Write the brief: included features, excluded features, sample data and delivery limits.
- Write at least ten acceptance criteria. Each is a condition you can check to decide whether a feature works. Include blocked requests too.
- Write the permission matrix and three user journeys.
- Create a backlog, an ordered list of work still to do. Check that the first version is small enough.
Give each acceptance criterion an input, action and expected result. For example: "Oak asks for River's entry E001. The server returns 404 and no journal text." Also cover valid creation, bad input, an expired session and a server failure the user can recover from. Plan one accessible main journey from sign-in to saving an entry.
4Judgment challenge
A request suggests administrators should read all journals "for convenience." That changes the privacy model. Unless your chosen task genuinely requires it, exclude the feature. If you introduce another role, define its purpose and tests rather than assuming a role name grants unlimited access.
5Check your work
A hidden edit button is not access control. The server must deny a forged request as well. An account identifier submitted by the browser must not choose the acting user. The verified server session does that.
Check that every stored field serves a documented purpose. Data should be enough to demonstrate both allowed and denied cases.
6Cumulative milestone
Save brief, acceptance-criteria, permission-matrix, and backlog. Your first checkpoint is a small private task with observable boundaries, ready to translate into a schema and server behavior.
Continue with the full course
This free preview is lesson 1 only. Enroll to open the rest of Full Stack Capstone: From Brief to Delivery.