Developing a KANBAN application with Laravel

Determining whether or not a user is allowed to perform a certain action is an important aspect of building a CMS. It provides users with ownership of their data, preventing other users from performing CRUD functionality on data that should be hidden from them. This is more commonly referred to as authorization. Laravel accomplishes this job by using gates and/or policies . This blog entry will cover how gates are used in the KANBAN application. Only one example will be covered as the process is the same for creating different gates for different actions. Workflow There are multiple steps involved when attempting to secure actions. There are shortcuts that can be taken to reduce the number of these steps however in doing so the applications logic becomes less manageable as some methods could become 'fat'. This makes the code harder to understand. Initially the developer should create a security policy, these are stored in app_route/app/Policies and follow the xPolicy.php conven...

The main aspect of a KANBAN application is for managing tasks and tracking progress on those tasks. One way that file uploads can be incorporated into the project is by providing users the ability to add their own custom avatar. Laravel makes uploading files a streamlined process however there are several intermediary steps that need to be taken before uploading and serving files is possible. Registering The Required Routes Firstly the application needs new routes that point toward a controller that handles file uploads. This can be done by creating two new lines in the routes.php file. The first listens for post requests at /file-upload and the latter listens for put requests at /file-upload Creating The Controller Once this is done the FileUploadController class needs creating which can be accomplished with an artisan command. I have covered how to do this in a previous blog so I won't include the command. In this applications users can only have one avatar, so the update route i...

Implementing Authentication In Laravel This entry to the blog will explain how I personally went about adding authentication into an existing application along with the issues I faced. I'll be covering both the good and bad, what I found intuitive and where I feel that Laravel could potentially improve and why. Database Table Structure So far the project already has a users table that were generated by default. This table is already suitable providing the appliation what it requires for authentication, the application just needs the logic for authentication. Each users table has the following general structure : The following is an example of some data that has been generated with Faker through the use of Factories( you can read more about factories in blog #6 ). You'll notice that every password is identical, at the moment as they are hardcoded. The pre-hashed version of the password is the word 'password' so that while testing functionality I don't need to rememb...

The proposed application allows users to create and use KANBAN boards. If you are reading this and are unsure what a KANBAN board is then Atlassian provides an excellent explanation that I recommend reading. The application needs to be able to provide this functionality in real time, without page refreshes that will ruin the users experience. In order to achieve this the application will make use of AJAX. The requests will be received by the server, passed through its routes to the appropriate controller which will handle any business logic that needs to be processed.  At the time of writing the application has over 800 lines of JavaScript so this blog post will not cover everything, just the parts that are important. The modification of the DOM tree by creating HTML elements will not be covered as it is repetitive code that has no interaction with the server. Despite not covering everything, this  entry is longer than the other entries in the blog series, this is because it ...

The application now has all of the tables it needs in the database that were built previously. If the application needs to move to a different machine or a developer is attempting to add new features on a monolithic development machine they'll need a database that has the same table structure and configuration to do testing on. The tables in the database can easily be created with the migrations that were previously written although the only problem is the database tables created are now empty, but they can be populated by using the application models factory methods. This entry in the blog series will cover how create, use and automate model factories in your application. Creating Factories Yet again the php artisan  command comes in handy, making it extremely easy to make a factory. For this project one of the commands I used to make a factory was the following. This creates a file named BoardFactory located at app_root / database / factories / BoardFactory.php Artisan creates bo...

Before attempting to do any development work it will be helpful to understand the requirements of the application in terms of the data it will need to function. This blog entry will provide an overview of how the data are planned to be organised. Creating The Models Now that the datas layout and relationships have been defined I can continue forward, figuring out how Eloquent ORM models work. First I have got to set my relationships in my model, to do this we use one of the built in Eloquent ORM methods. The type of relationship will dictate which function is used. All of my models boilerplate code was generated using the following Artisan command.  The -c flag at the end creates a controller for the model as well, reducing the amount of code I am required to write when it comes to managing the controllers logic. User Relationships Each user can have multiple boards Each user can have one custom avatar ( if not the default is used ) Board Relationships Each board must belong to one...