Project Setup

[00:00:00]
>> Kyle Cook: So this entire section is all about how we can get the code running on your computer. So you're going to want to make sure that you have Node.js installed, and specifically you're going to need version 20 or higher. You also are going to want to make sure you have Docker installed on your computer. Now if you don't want to use Docker, you just need some way to run a Postgres server, but I find Docker is the easiest way, and I already have a Docker compose style set up for you, so it should be relatively simple to set up.

[00:00:22]
You obviously need git to be able to download the code, and then some type of code editor. I recommend VS Code because it's what I use, but it really doesn't matter which one you use. Now the very first step that we're going to need to do is to clone down the repository. So if you're following along on this exact page, you can copy either one of these commands if you're doing SSH or if you're doing HTTP.

[00:00:40]
You're going to want to clone down this exact repo right here. You're going to navigate to the brand new folder that it created, and specifically you're going to want to check out the branch 1-basic permissions. We have a bunch of different branches inside of the code for every single step of our progress, and the one-basic permissions is essentially our starting point. It's our basic application with a really simple permissions that are relatively naive, but it at least gives us a good starting point to work with.

[00:01:05]
So once you get that cloned down, the next step is just to kind of set up the project. We're going to need to install our dependencies, so run npm install, that should download all of your different dependencies for you. Then we're going to want to start up our database. This is what we're using Docker for. If you prefer to use something besides Docker, you can, that's perfectly fine, but if you run Docker Compose up inside your terminal, that should start up Docker for you, which will start up our database for you.

[00:01:28]
Now we need to configure our environment variables. When you download the code, you should already have this file set up, but if you don't, you can just copy these environment variables as are into your project in a .env file, and it'll work for you. But as I said, this should come down as part of the project you installed. If you use something besides Docker for your setup, you would need to modify these to set your own variables for what your Postgres database is running towards.

[00:01:50]
Finally, we need to add data to our database. We can run npm run db:push, that'll push all of our migrations to our database and set up all of our tables. And then finally to seed our database with some starting data, we can run npm run db:seed. Then once all of those are finished running, we can run npm run dev, which should start up our project on localhost 3000, and if you open up that page, you should be presented with something that looks similar to this, where you have a login page where you can enter an email, or what we'll be doing through this course is clicking on one of these quick logins, which essentially logs in as a specific user with a specific role inside of a specific department.

[00:02:25]
Now I know that may be a lot, so let's just kind of quickly run through what the actual application looks like before we start diving into the code itself. So we'll log in as the engineering admin so we can see everything since the admins have access to everything in our project, and do that, you can just click on this button and it'll automatically log you in as that particular user. Now as you can see on the left hand side of our page, we have a list of different projects, and on the right hand side we have the documents for each of those projects.

[00:02:50]
So essentially this entire application is a list of projects and a list of documents inside those projects. So we really only have two models that we're worried about, projects and documents, and everything for our application is going to be following those. So you can see as I navigate through these different projects, you can see the different documents for them, and below each project you can see a label for what department that project is for.

[00:03:10]
So we have an engineering project, we have a marketing project, another marketing project, an all project which is available to everyone, and then finally another engineering project here as well. Now if we look at one of the documents, we can see all the data for our document. You can see it has a title, it has a status for if it's like draft, published, and so on, and then we have like the content of the document and some details about all the metadata for like who created it, when it was created, and so on.

[00:03:33]
As you can see, we also have abilities to create, update, delete all these different resources. So for documents, for example, we could edit a document, change it however we want, and we could save those changes. We also have the ability to delete a document if we want inside of our application, and we can create a brand new document as well. Right now, the admins don't have permission to do that because it's a bug in our current application on purpose, but there would be a new button right here for that.

[00:03:54]
You can also see we have the ability to edit projects and we can create a brand new project as well. So very basic create, read, update, delete access for all of our two different resources in our application. Now the top right button is allowing us to log out, and if we logged in as a different user, you could see they currently are restricted with what they could do. For example, they have less projects they have access to because they aren't in the correct departments, and you can see maybe they have less actual documents they can view as well, depending on different permissions.

[00:04:18]
That's kind of the overview of what our application looks like. We're not actually going to be changing almost anything in our UI during this, because almost everything we're going to be messing with is specifically on the backend side of things. So once we've verified that everything works, if you do have issues, you can run through these troubleshooting steps, essentially it's just a few different things related to the database to try to make sure everything's working.

[00:04:37]
And now we can kind of go over the overview of our code. There are really only three folders that we care about for 95% of the changes we're going to be making. There's an actions folder. If you're used to working inside of Next.js this is essentially when you submit a form, we're going to run an action, so every time you click submit on a form, it'll essentially run one of the functions in this actions folder for that specific form.

[00:04:59]
We have our app folder, this is just where all of our UI for our entire application lives, so anytime that we need to hide or show a button, it's going to be inside this app folder. And then finally we have a folder called DAL that stands for data access layer, and this essentially is for all of our database manipulation. Every time we query data or mutate data in our database, it's in that data access layer folder.

[00:05:19]
And like I said, 95% of all the changes we make are going to be in one of those three folders. The rest of the code you don't really have to worry about too much. It's mostly just like UI components and things like that. Now moving on a little bit further, let's go actually dive into the code itself so I can show you what those different folders look like. So here is the full application right here.

[00:05:36]
If I look inside that actions folder, you notice we have a section for auth, that's authentication. We can ignore that because we're not touching that. But you see we have a documents project and a projects file. These two different files have all of our actions, so if we were to look, you can see we'll just minimize the actual implementation down. We have create, update, and delete for our projects, and if we look in documents, we have the exact same thing.

[00:05:58]
We have a create, we have an update and a delete, and every single time we click submit on one of our forms, so if we go back here and I were to, for example, click on submit in this form, that create document button, it's going to directly call the code inside of here, and that data right here is going to be passing along everything from our form. So we can essentially think of this as the backend for all of our form submissions.

[00:06:18]
Now if we dive into this app folder, inside this dashboards folder specifically, that's where all of the different pages that we're interacting with are. So for example, if we wanted to find the document page for the projects, we can go dashboard, projects, project ID and click on page, and that's the show page specifically for our project. I tried to make these self-explanatory as possible with the namings, but I also left comments pretty much everywhere in the code where you need to make modifications or where our permissions live.

[00:06:42]
So even if you don't know the exact structure of the code, you can just search for these different keywords. I'll show you in a little bit, and they'll bring you directly to the code where you actually need to modify or look at different things in the project. Finally, we have that data access layer folder as I said, and inside here we have a documents folder and we have a projects folder, and all we need to do is inside of here, you can see we have different functions and all they do is they interact directly with our database.

[00:07:06]
We're using Drizzle as our ORM for our database. It doesn't matter if you know Drizzle at all, it's essentially just running SQL on our database to update, delete, read data, and so on. So that's all the main folders we need to look at. Next thing that I want to actually look at is going to be what the data structure for our project is. Now in our project we have three models, but only two of them we care about.

[00:07:28]
We have users, which are handled by authentication. We never have to mess with that. Otherwise we have projects and we have documents, and documents always live within a project. If you want, you can reference this chart whenever you want. This is essentially the full ERD diagram, a little bit different than that, but it has all of our different columns and types, but I also have below listed out everything that we need to do.

[00:07:46]
And I'm going to be focusing just on the actual attributes and columns that are most important for dealing with permissions inside this project. So users, the most important things that we have to worry about are the role of the user, pretty self-explanatory, and then the department of the user. So for example, we have different projects that are like engineering and marketing, and users may have a specific department they're a part of, so they can only access things within their department.

[00:08:09]
Now projects, the only thing we care about for permissions is the department of the project, so that we can map together users to the actual project that they're a part of. This could also be in a different style application, maybe like an organization that has team members. You can think of this as a very similar relationship. I kind of wanted to show what happens when you have more than just a direct ownership relationship.

[00:08:28]
We kind of have this indirect relationship between departments and users and then the documents inside those projects. It adds an extra level of complexity that we'll see when we start to implement our system. Finally, our most complicated table is the documents table, and the things we really care about here are the status of the document that may impact our permissions. We have this is locked flag which will later impact our permissions on who's allowed to edit things.

[00:08:51]
We have the project ID that's obviously important for linking back to what projects the user has access to, and finally we have who created the actual document because that again will impact who has the ability to edit and update that particular document. Now currently in our application, our permissions are very basic, and they still have quite a few bugs in them because we're using this less than ideal permission system.

[00:09:14]
So by default for projects, everything can be done by the admin, they can create, update, delete projects all they want, but every other role, an author, an editor and a viewer, all they can do is view projects and specifically they can only view projects where the department of that project is the same as the department of that user, or if the department is null, they can also access that. So if we look at our code here, you can see this Bob author is an engineering department, so he only has access to the engineering projects or this company Wiki, which has a project or a department of null, they have access to this as well because it's a global project in the application.

[00:09:49]
So you either must match your department directly or you must have a null department inside of the project you want to access. Now admins can get around this, they can view every single project no matter what. So if we log in as for example an admin user, you can see they can access all the projects even though they don't match their department. Again, they're just an admin, they have super permissions over everyone else.

[00:10:08]
Now when it comes to permissions of the document, this is where they become a little bit more fine-grained. A viewer can view all of the documents in our application as long as it's within a project they have access to. An editor can view and edit, pretty self-explanatory, an author can view, edit and create, and finally, an admin can do all four, view, create, edit, and delete. So essentially we have different tiers here to really break down all the different permissions that we have inside of our application.

[00:10:31]
Now the thing that we're going to be focusing on next is fixing all the problems in our application, because there's actually quite a few problems. Now I've gone through and I've labeled every single thing that needs to be fixed with the comment all capital letters FIXED with a colon at the end. So if we actually go into our code and we were to specifically search for that, you can see every single location that we need to fix things.

[00:10:51]
I know it looks like a lot, but most of these fixes are very, very simple fixes, so it won't be too difficult to do. Also, you can search for PERMISSION, again all capitals with a colon at the end, and this will show you every single place in our code where we have some type of permission code. This will make it much easier for us to later go back and update this as we start to roll through different permission systems.

[00:11:03]
We can just search for PERMISSION and update every single section, so we don't make sure we accidentally forget something.