Skip to main content

Black Friday 2025! Only until December 1st: coupon FRIDAY25 for 40% off Yearly/Lifetime membership!

Read more here

Setting user_id Column Automatically: Two Ways

Premium
3:04

We start our course with a simple version of multi-tenancy: records restricted by users assigned to them, so users would see only their records.

Some people don't even consider it a "multi-tenancy", meaning records should be restricted not by a user, but by company or team, using sub-domains, multi-databases, or something more complex.

But, in a broader sense, multi-tenancy means dividing your data by some tenant, however you define that tenant in your project. So, as the most simple example, we will divide the data of Project and Task Eloquent models by projects.user_id and tasks.user_id fields, in the same database.


I have made a simple demo project with two Models: Task and Project with CRUDs for both of them. Also, I added a relation: Task -> belongsTo -> Project.

In this section of the course, we will cover how to create a user_id field and filter by that so every user would see only their projects and tasks.

First, we must add a user_id column to the projects table.

php artisan make:migration "add user id to projects table"

database/migrations/xxx_add_user_id_to_projects_table.php:

Schema::table('projects', function (Blueprint $table) {
$table->foreignId('user_id')->constrained()->cascadeOnDelete();
});

We also added the user_id to the Project model in the fillable. I prefer to have all the fields fillable except for id and timestamps.

app/Models/Project.php:

class Project extends Model
{
protected $fillable = [
'name',
'user_id',
];
}

Now, our goal is to add user_id value to the projects automatically, from the logged-in user. And we have three options here.


Option 1. Controller.

In the store() method of the ProjectController, we create...

The Full Lesson is Only for Premium Members

Want to access all of our courses? (29 h 14 min)

You also get:

54 courses
Premium tutorials
Access to repositories
Private Discord
Get Premium for $129/year or $29/month

Already a member? Login here

Comments & Discussion

RV
Rick van den Bovenkamp ✓ Link copied!

Another almost identical option would be to use Eloquent Observers and create the creating() method in the Observer, instead of the Model. But it's a personal preference.

What is personal preference based on? What makes one better than the other?

PK
Pawel Kowalski ✓ Link copied!

The advantage of having it in model is it's really easy to follow the flow.

Observer it's much harder to follow the application flow but if you have a ton of code you can argue maybe observer would be better in complex apps.

I personally don't like obeaervers due to it making much harder to track the application flow. So there should be a really good reason for using it. Like maybe it's in a app that's heavily event based and lots of steps get fired when user is created.

FW
Felix Wei ✓ Link copied!

Excellent course! We need another similar course for workflow approval.

M
Modestas ✓ Link copied!

Could you expand on the workflow approval? What do you have in mind here?

FW
Felix Wei ✓ Link copied!

More like a user submits application/transaction which requires approval of Admin, Reviewer (based on multi level approval process setup) in that order with status (Pending, Approved, Rejected) and feedbacks. How to implement this with best practice in Laravel or may be combined with available Laravel package?

M
Modestas ✓ Link copied!

Honestly, there's no best practice for that, because that's a custom workflow in your application. I don't have anything to recommend here, sorry!

FW
Felix Wei ✓ Link copied!

I found this old youtube video https://www.youtube.com/watch?v=GVzsSBl5yGM&ab_channel=LaravelDaily