Mission: Equipment Booking Manager

Speaker 0: Hi. Welcome back to another episode of 100 apps, 100 hours, where we build some of your favorite apps or publicly fail trying. Today we've got a really neat use case that we're gonna try to build, an equipment booking manager. This sounds really fancy. I've seen this topic come up a few times within our direct us community, and I I thought, hey, let's tackle it today.

It's perfect. So in all of the research I did, which is basically about 5 minutes before I pressed record on this, I found a comparable solution. It's called Checkroom, c h e q, Room. Looks like a pretty neat solution, but basically it's an internal app that allows you to manage all of your equipment. So equipment, in this case, it looks like they're targeting videographers, photography, you know, maybe studios, anybody who's got expensive camera equipment or video cameras, etcetera.

But basically, you know, you can check these items in and out, reserve them for a time slot, manages all your inventory, what's the the status of all those, gives you a nice friendly dashboard. So that's what we're gonna be building today. If this is your first time watching 100 Apps 100 Hours, there are 2 rules. Number 1, we have 60 minutes to plan and build, so we're on a bit of a time crunch. There's no more, no less.

And rule number 2 is, kind of, the anti rule. Use whatever we have at our disposal. So with that let's build our equipment booking manager. I'm gonna start the clock here and away we go. So I'm inside, Figma here or FigJam.

This is how I like to plan before I build, just kind of quickly whiteboard things. So let's go in and just flesh out the the actual functionality that we're looking for out of this specific app. Right? We wanna track inventory of all of our different items, of all equipment and items. This could be, like, mobile phones or Android devices if we're doing web development for testing, camera equipment, printers, what whatever.

We wanna be able to reserve equipment equipment on a schedule. We want to be able to track, details about the equipment. Let's say user can reserve the equipment on a schedule. We're gonna be able to track details of track equipment status. I mean, that's that's pretty much the the bare bones for this.

You know, when are these things scheduled? Is it available for checkout? You know, maybe we wanna account for things like maintenance. Put, like, a big question mark there. Yeah.

Okay. That that seems pretty good. Let's let's dive in and actually start planning what our data model may look like for something like this. So I'm just going to drag a nice square over here. Let's change this to red to kind of match.

Alright. So thinking about this and and just talking it through out loud, obviously we have our inventory. This could be called items, could be called equipment. Let's let's go with equipment. That that seems like a a good compromise there.

Items has a, kind of, a specific meaning inside Directus, which is just the actual individual pieces of content or data. So let's go with equipment, and then we're going to have, users. Alright. So that's gonna come actually from a Directus underscore user collection that Directus is gonna give us out of the box, which again is really nice. We got that authentication tied to that as well.

And then we're gonna have, what, bookings for each of the this piece of equipment. Right? So we have a relationship here between equipment and bookings. The user creates a booking for a specific piece of equipment. You know, we have a check-in, check out type of functionality.

It's great. Yeah. And this could be, you know, one of the other things that I saw here on the check room website, where was this? Inventory. One inventory to rule them all.

You could potentially bundle these things up. Capture the flag. So, you know, maybe some type of checklist. Right? Let's go through and and just start fleshing this out.

Right? We're about 4 minutes in. We need to actually start building something. So I'm gonna pull up my instance of Directus, so this side by side. We'll zoom in just a little bit.

And this is just a blank direct assistance that I've spun up here locally, if I can remember the actual password. I think it's real secure. It's probably just password. Great. So we've got a totally blank instance of Directus.

Let's start building something. Let's start with equipment. Right. We're going to just call this table equipment. Usually I've got a plural at the end of a lot of my tables, but equipments doesn't make a ton of sense to me.

So, what are we going to have on this? We're going to have a status, like the default status field here. These just make it easy to add some of the most common functionality you'll have. It uses, like, a draft, published, archived. So I'm just gonna leave that blank for now.

The sort field, do we really need a a sort for our equipment? Probably not. It might be good to track when it was created, so when it was added to the database, who it was created by, and the last time that information was updated. So we'll just roll with that. And let's give this, a name, right?

This is the name of this piece of equipment, it's just gonna be a string. Really simple. No need to get fancy with it. Let's require a name for it. And next, let's probably add a a serial number.

We need a unique identifier for this. You know, maybe we want, we end up printing these on labels or QR codes. Serial number would be a good way to track that. And, you know, we can choose to require that as a value, you know, maybe we don't necessarily need to, but we'll add that. What else do we wanna add here?

We want to add a description. So maybe that's gonna be a wysiwyg editor. You know, this could be a HTML description, so we'll go with that. The type is gonna be text. I could customize my toolbar if I want to limit the options that we've got, but we'll just roll with the the default selections for now.

We're probably going to have, what, some images of this or at least one image. You know, maybe we've got a gallery, but let's just call this the image. That's gonna be a relational field, Just a mini to 1 to our directus files collection. Make sure we can add an image for it. What else am I forgetting?

We've got a status field. So, let's use a drop down for this. We'll call it status. The type, we're just gonna store that as a string. And for our choices, right, when we think through the choices, the equipment is either currently available, it is unavailable, you know, maybe it could be like, hey, it's getting serviced or it's in maintenance.

I'm not sure if that's worthwhile to track or not. Alright. So let's just add a new one. We're gonna call it available. For the value, we can use lower case.

Let's give a, maybe, a check mark. Hey. This is available. We'll make it green. Then we'll have unavailable.

I'm sure there's probably a better naming convention here, but this is what we'll roll with. Maybe like a x. Okay. This is unavailable. And, yeah, maybe we do it like a status for maintenance just to differentiate.

Maintenance. Wrench, maybe. Let's look for a wrench repair. There we go. We got a toolbox.

That'll work. Okay. And I think yellow or orange is a good color for that. Great. So we've got available, meaning it's currently in inventory.

Unavailable means it's out, Not in inventory. And then we have maintenance. Don't need to allow any other values. Looks great. Trying to think of what else we actually need for this data model.

You know, we may have, like, specific details that we wanted to track, those are escaping me at this particular moment. So we've got equipment. Let's go in and add a few pieces of equipment. You know, we'll just start out and say, this is available. We have a, just looking at my desk here, I have an iPad Pro that is BG iPad Pro.

Just create a serial number. The most amazing iPad you've ever seen. And we'll just go to Google, and it's still an image. Right? IPad Pro.

Perfect. Where are you? Apple's gonna sue me, I'm sure. Please don't. Alright.

Swipe an image here. That's great. We've got an iPad Pro. I may want to adjust my view just a little bit. I can't I don't see those nice images.

I could go in and add my thumbnail for this. Looks great. Cool. We can make this a larger view. We can make it comfortable, and I can see a little more of that.

Or I could even go straight to cards view here and get, just kind of like a gallery of where we're at. So the subtitle here could be the status, it's available. Great. We could add one more piece of equipment. You know, maybe I've got a, show my age here.

The Sony a 64100. Sony a 64100. We could call this 1. Great. So we'll find a image of the Sony.

I think it's the a 64100. Yep. That's the one. Copy image address. We'll just pull that in.

Great. And, yeah, maybe I've got something like 2 of these cameras. How can I, like, achieve that really quickly? How can I duplicate these inside Directus? Well, what I could do is just go ahead and change the name a little bit, change the serial number, and I could go into the 3 dots up here at the top and click save as copy.

So now I've got 2 of those specific cameras, maybe one's available, one's not, one's currently checked out, the other isn't. Cool. Alright. So we've got some equipment. What is the next thing that we're going to build?

Let's take a look at bookings. Right? So how is this going to work? We're going to maintain a schedule of bookings. We're probably going to use our calendar view inside Directus for this, and then we'll be able to check-in and out this equipment, or actually reserve this equipment.

The check-in, check out part may be, something else a little different. So let's just call this table bookings, makes sense. For the primary key we'll just use an ID. I'll use generated UUID for that. For the status, right, Let's leave status off here.

We're just gonna check the box for all of the date created, date updated, all these system fields that auto populate when certain actions happen. And now we've got a booking, right, so when is the we we need the times for the booking. So let's do, like, a scheduled from. We use a time stamp format just so we get the time zone value. K.

Let's make that high second half width. We'll do schedule 2 for that as well. Schedule from, schedule 2. Do we have notes? You know, I'm thinking, like, hey, we may have to have some type of notes.

We'll use a text area for that. I don't need these to be formatted in a WYSIWYG or markdown. You know, could be potentially nice if you need that level of functionality. Alright. So we've got a booking, we've got schedule from, schedule to.

We need, obviously, a piece of equipment tied to this booking. So now we're gonna start reaching for our relationships inside Directus, because each booking could only have a single piece of equipment, or could it? You know, we could potentially book a 3 or 4 pieces of equipment, but maybe those would be individual bookings as well. You know, it gets more complicated when you have a kit. Maybe we'll try to explore that.

But for now, let's just keep it simple. We'll do a mini to 1. Or would it be, yeah, let's do mini to 1 for now. The related collection will be equipment. And we'll go into the relationship here.

I can see what this setup looks like, but I can go in and also add that inverse relationship. So, I can add equipment to my bookings or add bookings inside my equipment. So I if I pull up a piece of equipment, I can see all the bookings right inside that item detail page that that that particular piece of equipment has had. Alright. Long winded explanation there, Brian.

Alright. So we've got a schedule from, schedule 2, notes, equipment. Who is this assigned to, or who's pulling this equipment? I again, naming things is is probably the hardest challenge in development. Let's just call this assigned to or bookie.

Call here bookie. Let's call it assign to. That's fine. So now I can't see my users collection here. Directus users is actually collection.

So we're just gonna go in and expand that system drop down, pick Directus users. I could control the display template here, so what actually shows up. You know, maybe I want to show the image of the user, the first name, the last name. Great. And save it.

Alright. So we've got the schedule from, schedule to. We probably need a status on this as well. Right? So who is this booking for?

Alright. The status, when we think about that, again, let's use a drop down just because we get, like, a rich look at it, now that we have the ability to add icons and colors. But when I think about this, let's say, what's the initial state on a booking? Would be new or maybe unconfirmed is what I'm thinking here. So a new booking comes in, somebody has to verify that that booking is okay, or maybe we could do that automatically via flow.

But we'll call it unconfirmed. And let's just see if we've got, like, a there we go. We've got a new flow. Fiber new. That's an interesting name for that particular icon.

What else do we have? Scheduled. Scheduled. K. Time.

See what we got. Okay. Let's just do, like, blue. That's kind of like a neutral color as far as what's going on. You know, maybe in progress is the next one.

We'll just create some text and value for that. Settings. Maybe, like, a gear, progress bar, meter, bar. Yeah. There we go.

That'll work. Alright. We'll mark that as I guess, as green in the state of a booking. Maybe it's red. In progress.

Maybe completed is the state. Alright. So this is a completed booking. Check mark. I think that's a that'll be a nice icon for this.

Alright. Completed booking. We'll go to check mark. We'll make that green. Great.

Okay. So now we've got our status field filled out. We'll hit save, and now we can start looking at at how this is gonna come together. So we've got equipment, we've got our bookings, you know, maybe we look at this on a calendar view. Our layout options here we're gonna adjust this view.

Each one of these layouts inside Directus has, separate configuration options that are dependent on the specific view. So here maybe we display, let's see. We're gonna display the equipment name. That makes sense to me. And then let's also maybe display the user as well, so who this is assigned to.

Assign to first name. Assign to so we'll reach into that related collection, and I can display those related values. I thought I had added that. Assign to last name. Oh, I'm just not seeing it there.

First name, assign to first name. I added it, I just didn't see it. Last name. Okay. Alright.

The start date field is gonna be scheduled from, scheduled to. 1st day of the week is Sunday, and then we're good. Right? So let's go in and create our first booking. We'll just do this manually.

And I can actually do default values as well, one of the handy things about when when you're setting up your data model inside Directus. If I go into my status, I've got unconfirmed as a value. If I go to my schema, I can just set the default value to be unconfirmed, and now whenever I create a new booking, the default is unconfirmed. Alright. So we're going to pick a piece of equipment.

Let's say we want this Sony a 64100. That's gonna be assigned to me. I wanna check this out, for 2 days at near the end of this month and using for a photo shoot. Great. So now I could see that booking on my calendar, and presumably as these bookings come in, you know, I could go in and and see this schedule.

Right? This is really a bare bones functionality. You know, I I could give access to our team to this and set up some separate permissions, but now, I let's maybe add some automation to manage this booking process. Right? It seems kind of hey, the flow doesn't seem quite right to me.

So we wouldn't have somebody go in and manually adjust the status for their booking. You know, maybe we can take advantage of Directus flows and and build something to to, account for this. Right? So we'll go inside flows, and let's just let's think about how to manage the bookings. Each one of these specific bookings, has some actions that you're taking against it.

So to me, if you're used to building, like, inventory systems, you probably got some type of transaction against that inventory of, hey, this was checked in, this was checked out, it was reserved, or it the on hand quantity was reduced. So maybe we do something like that where we track the individual transactions against these bookings of when it was checked out, when it was checked in. Let's do that. So we'll do bookings underscore transactions, and I'll just use UUID again. Just kind of the standard for me.

Maybe the created on do we really need, alright. We're not gonna update these transactions. So, yeah, if we're created on, I'm just gonna change this to timestamp because that is the timestamp this particular transaction occurred. We'll use created by just so we have the user created that particular transaction, so if that was me checking myself in or somebody else checking in that booking. Alright.

So at that point we also are gonna have a relationship to our bookings. So let's go ahead and set that up. Here it's going to be a mini to one relationship from booking transactions to bookings, because, a a transaction only has one booking, but a booking could have many different transactions attached to it. So we'll call this the booking, and our related collection is gonna be bookings. And for the display template, let's say that is the equipment name, space, date, schedule from.

And we do schedule to. And if I wanted to, I can even go in and add the the specific user. So we'll do first name, assign to last name. Perfect. Alright.

Cool. So now we've got a booking, and I forgot to create the inverse relationship. There's when you're creating that mini to 1, there's a second tab for that, but no fear. We can just go into our bookings and and we can add that from here. So we'll do the one to many field.

So this is the inverse relationship. We'll call this our transactions. And let's do booking transactions and the foreign key we'll already have, which is the booking. So this is the foreign key for bookings inside transactions. We'll just save that, maybe show a link to it and hit save.

Alright. So now if we take a look at one of our bookings we can see this transaction table. Alright. The other thing that we're probably gonna need on our booking transactions, and honestly, like, this may be hidden behind the scenes, and I'm just gonna go in and add some icons to this before it drives me crazy. Recovering designer folks.

Bear with me. Camera. There we go. Looks great. Alright.

So on our booking transactions, and I may even just nest that, we're gonna need a action type. Alright. So it's a check-in, check out. You know, move to maintenance, maybe, as well. For this, let's try something like radio buttons.

So this will be the action. The choices that we'll have will be check-in, the value here, check underscore in, Check out. Check out. Maintenance. Move to maintenance.

Request maintenance. Let's just call it maintenance. I'm getting too fancy with it. Taking too much time when I'm actually maintenance. I'm not even sure if that's the correct spelling.

That's what we're rolling with. Alright. So now, what have we done? We've got some equipment, we've got bookings we can use to manage that, and then we can attach transactions to those. Right?

So as far as our underlying data model, this looks pretty cool. Let's work on our our flow. Right? How can we make this easier? So I can imagine, like, if I'm looking up bookings, you know, maybe I want to bookmark this.

This is the calendar view. So we'll add a calendar icon for that as well. Alright. So when I save a bookmark, that gives me the calendar here. And then maybe I can go in and maybe we just want, like, a list of all the bookings as well.

This could be a new potential bookmark. Let's go in. We don't wanna update that original bookmark. I go back to bookings. We'll just create a bookmark for this.

We'll call this list. This is a list of bookings. Great. So one of the other nice things about creating these bookmarks inside Directus is if you have certain filters applied or, you know, even a search query, you could save that search query and create these really nice slices of your data. But as far as my list view, you know, maybe I want to clean this up a little bit.

My assign to field looks kind of boring, my equipment is not showing. Let's just make this look a little nicer. So I'm going to go back inside my data model and where I have equipment I'm gonna look at my interface and display. So here we have our interface, which is gonna be how it looks inside the detail view. The display is gonna be how it presents on the layout.

So I could go in and maybe we want to show the, image, And I can expand that a little bit just to get a a thumbnail. And we'll show the name of this, and we'll do the same here. One of the little tricks I can use here is just drop this down, copy raw value, we can also paste it here and get access to the same thing. Great. As far as the assign to, maybe we want to do the same thing.

Copy for the display. Because this is a user, I could also just show the direct us user. And maybe we wanna show the user in a circle instead of a square. Totally up to you. So there we go.

This looks a little better. We'll probably have the schedule 2 on there as well. And maybe I wanted to get a little fancy with some conditional formatting for the status. Again, pretty easy to do. We'll just go to status, we'll do display, a couple of different ways I could display this.

Let's just go with a label, and I'm just going to copy the raw value from these choices. I'm gonna paste it here and then, you know, I could adjust the actual colors, like background and foreground if I need to. But let's just see how this presents. Yeah. That looks that looks definitely a lot better, and nice to have like an icon as well.

Alright. So now we've cleaned this up a bit. Let's build a flow to check-in and out. So what we'll do, we'll go into our flows. Directus Flows is a great workflow automation tool.

So I can set up, flows to run on any number of things. This one we're going to use the manual trigger for, which is one that I use often. I really like this. So let's call this the check-in. And do we have, like, an in there's an in out.

Maybe that's, like, a in out burger, maybe? I don't know. Let's, let's do, like, an arrow forward for check-in. That looks good. And then when we do a checkout flow we can move backwards.

So I move on to the trigger setup. Again, you've got lots of options here. You've got event hook, you could, so basically when an event happens inside Directus we're going to start this specific flow. I could trigger on webhook requests from other third party services, a schedule, or in this case we're going to run this manually. Alright.

So this is going to be on our bookings collection. Right? The location is going to be where this displays. So if I want to show it on the collection, like the view, the layout page, I can do collection page only or I can do item page only to show it with in a specific booking. Or if I do both, I can, get get the option to pick from the collection page or I could do it from the detail page as well.

So great. We'll go in and let's just require confirmation on this specific booking and, you know, let's add some inputs for this. Let's add some notes. Any notes about this booking? So I'm trying to think of what this would be.

You know, maybe, hey, they showed up late or, you know, something like that. But we're already gonna be picking a booking so we know who this is. Let's give this a shot. And the first time I'm, the first thing I do whenever I'm building flows is basically start with my trigger, and then I'm going to go in and actually trigger my flow. So over here on the right, I can see my flows, I can select this, right?

If I unselect, I won't be able to check this in. But we'll just say, hey, I'm going to check this in and here's some notes about this. Great. Alright. So now if I go back into my Flows, we'll see a couple things.

Right? We've got our logs that we're gonna take a look at. We've got our payload. And if I look at the body, we've got the notes, we've got our collection, and we've got our keys. So this is the actual ID of the booking that we selected.

Great. So when I think through this flow, right, what are we going to do? There's a a couple things we're probably going to want to achieve with this flow. If we go back into our data model just thinking out loud here. Alright.

We're going to this is getting in the way. Let's just do text. We're going to want to create a booking transaction. We're probably going to update the status, update the status of the booking, and then we're going to update the status of the underlying equipment. Right?

So that's gonna move from available to unavailable. Alright. We can achieve all of those inside of Flow. Let's get to it. Alright.

So we are going to create our first operation. Let's call this, create booking, create transaction. Okay. We're gonna create data. So we're going to create an item in the database that's going to be our booking transactions.

We can leave the permission set to from trigger because we're going to run this flow inside Directus. If this was triggered on a webhook event or something like that, you would probably want to use full access because you're not going to provide that accountability, that direct us user to actually run this flow. But we'll go into our payload and listening through this, we've got a booking. So let's just throw that out there. And then that is going to be coming from our trigger.

So whenever I want to access data from that trigger event, I have to use this special syntax and just add a dollar sign in front of it. That is the only time I need to use that to access data from this flow. So only in the trigger. And let me just take a look. It could be handy if you take and copy this, into Versus Code or your editor just to make it easier to remember what it was as you're building out these flows.

So we've got the trigger dot body dot keys. This is an array. We're gonna have to pick off the first value of that array. Alright. So let's run this again.

Create transaction, and we'll do booking transactions, and paste this in. Trigger dot body dot keys, and we're gonna grab the first item from that array. And again, we're using the mustache syntax here. We can close this, and we're also going to have an action. Alright.

So if you remember, that action is going to be check-in. And is that all we need? I think that's all we need. Great. Alright.

So the next thing that we're gonna do, we want to update the status of that booking. So this is a check-in. We are going to update the status of that booking to what? So if we look at our booking, we've got, we're gonna change that to in progress. Right?

Great. So we'll do update our booking, and that's gonna be update data. So we'll just call that update booking. That's gonna be our bookings collection. Again, we'll use the trigger permissions.

Okay. So 2 ways I could go about grabbing the ID of the item that we're gonna update. I could use the IDs field to specify the specific IDs, or I could run a query for this. I'm going to lean this way just because we already know what that value looks like. So it's going to be dollar sign trigger dot body dot keys, first item of that array, and I'm going to press enter to make sure we store that.

I can also go in and edit the raw value here just to see what that looks like. So again, if I'm using this mustache syntax, it's going to dynamically populate that data for me. We do not want to omit events for this. We don't want to trigger any type of, like, infinite loop using that, so always be careful when you're using that. And for our payload here, we're just going to update the status of this booking.

The status is going to be in underscore progress. And I think I think that's all we're really looking for here, right. Now, we need to update the underlying piece of equipment as well. And if you take a look at our log, though, right, we are not getting that information here. We're only getting the key for the booking.

So in that case, before we can update the actual piece of equipment this is attached to, we probably need to get the booking so we can find that, equipment that's attached to it. So let's just create a new operation. We're going to call it find booking. We're going to use the read data operation. We're going to find bookings collection.

And then, again, we're just gonna do the same one, trigger.body.keys, save that. And for our query here, I could pass any of the the standard query parameters that are available. If you're not familiar with those, check out our docs. But what I'm gonna do, I'm gonna pass a fields query, or fields property, and this is gonna be an array. I'm gonna get all the root level fields, that's what this asterisk will do, And then I'm also going to get all of the equipment fields as well.

So I am drilling through my relationships here. One of my favorite features of Directus is the ability to get and expand those relationships in a single API call. So assuming that goes well, then we are going to update that piece of equipment. Right. Before we do that, let's just stop and go test this out.

Alright. So we are gonna go here. I'm gonna hit check-in. Here's some notes, and, you know, I could also save these on that transaction. We'll maybe do that in a moment.

But we can see here the change. We've got a status of in progress. We've got a new transaction here. We can see the time stamp that was created. It was a check-in action.

Let's go into that booking transactions. We'll add that notes field as well, just so we can store those notes. Great. And let's run into our flows and just see the log. Right?

What did we get for the booking? Are we getting the data that we want? We can see the equipment dot ID. That's what we wanna update, and we're gonna change that status to available or unavailable because it it's unavailable. Alright.

So this last link in the chain here will go in and update equipment. And You can see Directus will automatically generate the key for me. If you want to change that, feel free to. Not a big deal. But these keys are how you access the data in subsequent operations.

Right. So as you can see in just a moment, we're going to go into choose our equipment collection. We'll do from trigger. But as far as the ID's that we're going to update, we're going to use, find booking_orfindbooking.equipment.id. So that is how we're gonna access this.

And for our payload, we're just gonna change the status. Unavailable. Okay. Great. Cool.

Alright. So I'm just gonna go in and manually change this. This is, let's call it a scheduled booking, for I'm gonna undo these transactions, unhide those just because I want to delete this one. Alright. So we're starting fresh.

Everything's available. We've got a booking for our specific camera. I'm gonna go in, select this. I can also go into the item detail page here and do the same thing. And, oh, also forgot to update our notes.

Right? Let's go ahead and do that as well. The perks of building on the fly. How are we looking time wise? Yeah, good.

Pretty pretty solid time wise. Alright. So for our transactions here, we're gonna pass the notes, and that will be trigger, dollar sign trigger, dot body dot notes. Okay. Just some standard JSON format there.

Great. Alright. Moment of truth. Let's see if this is actually gonna work. We'll go in, run check-in, our check-in flow.

Bryant was late showing up to pick up this camera. Great. We'll hit run flow. Now we can see this is an in progress booking. If we look at our equipment, it shows as unavailable.

You know, maybe we could potentially, show that a little nicer, maybe with a badge or something. And what else did we update? Right? We've got a transaction, we're storing our note. If we go into that detailed booking, we could see the transaction here.

Maybe we want to clean this up a little bit for our users because we don't want them to see that UUID. Alright, so again, optimizing for our users. Let's go in and we'll go to the transactions. What do we want to do? We want to do show the timestamp, what the action was, and maybe if there's any notes.

Oops. Let's do notes. See that? Cool. Okay.

So now I can see this, 1 minute ago it was a check-in event, Bryant was late showing up to pick up this camera. And I can even go a step further with this, or I should be able to, in the action here for my display, I could show a formatted value of this. So we can show a border, and if this is a check-in, you know, maybe we wanna show, what did we use for this? Maybe, yeah, green will be fine. We could show a checkbox.

Or, actually, I think we were using, like, a arrow. Right? Arrow. Check-in. And check out of it.

So if the value equals that, we can actually, I'm getting these wrong, aren't I? We'd probably be checking out the equipment, not checking in. So maybe I need to go in and fix that as well. Arrow. Left.

Right. There we go. Check-in. Oh, let's use left for that one. Great.

Okay. Alright. Cool. So now we've got our actions. If I take a look at our transactions, we could see we got a badge for that, and I would probably actually flop these.

Right? That would be this would be like a, yeah, checkout and not check-in. So we can change this. Right? This is a checkout event.

And is there anything else we need to? I don't think we need to change any of these other ones. Alright. Cool. So let me go in and just fix this again.

Alright. I'll delete this record so we don't have any more booking transactions there. Reset this guy to scheduled, and let's try it again. Check out. Late again.

Run one flow on the selected item in progress. Now we got our checkout. Great. So I could do the same operation just in reverse for, like, a a check-in. So when we are checking this equipment back in, pretty easy to do.

What other functionality do we need out of this? You know, is there an opportunity to take this one step further? We still got, about 15 minutes here. So what if we were to send some notifications on check-in or, like, if we got a new booking, we want to send some type of alert or or notification to someone. So maybe we reach into our flows for that.

We'll go in and, you know, we could do a maybe like a a check-in flow as well. Right? So we do all this over again. We are going to do a check-in flow. Isn't that exciting?

Let's do a notification. Right? New booking notification. Alright. So whenever a new booking occurs, we want to trigger a notification.

That is going to be using our event hook, and you get 2 types of those event hooks inside Directus, whether that's a filter, which is a blocking. So this is great if I want to run some type of logic and then potentially either adjust the payload of the item that we're saving or, you know, updating, deleting, etcetera, or, you know, if I want to actually cancel that event pending some logic. In this case, we're going to do action non blocking. We don't want to block anything from occurring. Just after a new booking occurs, we are going to run a notification to a user.

Right? So our scope here is items dot create. That's gonna be on a new booking And this also could be we could condition this down if we wanted to, where we only trigger on unconfirmed bookings. Unconfirmed. Alright.

So the condition gives us, if, then, or if, else logic. So I can separate my flow into 2 separate paths, right. If the condition passes, we go this way and we run some other operations. If it fails, we do something else. So here's the syntax for this.

We're just gonna use trigger. I'm breaking my own rules here. Let's just save this as is, and let's actually go create a new booking. And let's do it for the iPad Pro. We'll do the rest of this week.

That's gonna be assigned to me. And here's some notes. Alright. So we created a new booking. I'm gonna get, a a payload here that I can take a look at, right.

So the the payload is a little different than what we get from when we manually trigger these. But we can see we've got the equipment, we've got schedule from, assigned to. Great. So only on unconfirmed, what are we going to trigger this on? Basically, the unconfirmed.

I really don't even think we need a condition here because the default value is unconfirmed. So, yeah, we could we could potentially do something like this. Like status is I think it's not equal to unconfirmed. Let's see if that runs. And then we're going to notify a certain member of the team.

Right? Let's send a notify Matt. I'm going to pick on Matt on my team. We're going to send Matt a notification. And to do that, we have to have a UUID for that user.

And I don't actually have a user in this account for Matt. Maybe we'll just use myself. Or we'll just create 1. Matt Minor. Great.

Alright. We'll pick up the UUID from that specific user. And, you know, part of this flow could be like picking that up dynamically, depending on how you decide the logic of who to notify here. But I could just hard code that value in, hit save or hit enter to record that, and then we're going to add a notification. Right.

New booking. Please review this booking and confirm. And as far as the collection here, the item, we are going to do what? Let's look at our log here. We got the payload.

We're gonna do the key. So that's the created booking. And I can link that notification to that specific item. So it looks something like this, where we have trigger dot key. And that should do the trick.

Alright. One of the other things that we may want to do, let's just check time really quick, we've got about 10 minutes. One of the other things that we may want to do is lock down some of these fields when you're actually editing this data. Right? When I am looking at a booking, I may not want anybody to be able to update the status without going through a specific, like, check-in or check out flow that handles all the logic that we want.

Or likewise, you know, I I don't want any of my non admin users to be able to change the assignment for this. So there's 2 ways I could do this. If I go through the actual data model, you know, if if the booking status is controlled almost exclusively through Flows, I could go in and I could disable editing for this value. That'll be across the board, basically. Inside the UI nobody can update this value.

So this is what that looks like. Now if I go into status, it just shows me the read only field, and if I wanted to change the status I would have one of my flows or update this via the API. Right. Here's my notes. I run this flow.

My status is changed to in progress, and, potentially, I've got some type of, operation here to move this, like my check-in process. Right. But the other ways I could do this are via the Directus access control. So I could go in and create a, you know, let's call it a team member role. They will have app access, they won't have admin access, so they can't adjust the flows, they can't adjust our data model, but we do want them to be able to do certain things, like, view all of our bookings.

Right. So I can give all access to start with, maybe we start whittling down some of these permissions. There's no need to share it. I don't want them to be able to delete bookings, delete equipment. I do want them to be able to update these fields.

It could potentially mess with our flows as well, but let's address it. Right. So we're going to use the custom permissions for our bookings, the field permissions oh, I've gotta go in and do no access. Alright. So here's what we could do.

We want to allow them to update only certain fields. Right. Maybe they can change the equipment in case we need to swap that. They can't change the status. They can change they can't change the assign to.

They can't adjust the transactions, but they can see them. Sounds great. I can even configure field validation rules, or presets. Like, hey, here's the the default values for those. The only other thing that I'm concerned with here is because we're locking down that status, inside our flow for checkout we're actually using the permissions from the trigger here.

So we'll just do full access, which basically gives unlimited access to, update these things. Great. Cool. And then, you know, if we go back into access control or team member, maybe we don't want them to update the equipment status either. Alright.

So we'll give access field permissions. These are the fields that this role can update. They can update the name, serial number, description, image. I can't update the bookings. Status, no.

Okay. Obviously they can update these. Cool. Alright. So we'll save this And now let's open up an incognito window.

But first I need to give mister Matt Minor some permissions, or just a login. Matt@example.com. Give it a password. Great. Open up this incognito window.

Go local. And we'll do matt@example.com. Password. Password. Did I did I get the password wrong?

Did I even give them a role? So a couple things. I need to give Matt that team member role so he can have app access. And, you know, maybe I typed the password wrong. Password.

Let's just copy that and make sure. Hit save. Okay. There we go. Alright.

So now this is what Matt would see when he's logged in. You know, immediately you'd see he doesn't have access to the admin interface. But if he goes within the bookings, he can't update the status, he can't change the assignments, he can't do any of this stuff. But what he can do is run this flow. Here's some notes.

This is not gonna really change any of this. Let's just zoom back out. Too zoomed in. Alright. So for the iPad Pro, I'm just gonna change this did I lock that down?

I totally locked that down, didn't I? Let's go here. We'll change status. Go to the disable editing value. I'm just going to remove that just to demonstrate this capability.

Alright. So now we go to iPad Pro. You can see over here I'm logged in as admin on the right hand side over here. I can change this status to be whatever I want. Hey, this is scheduled.

I've got full permissions. Matt, when he's logged in, he can't edit any of the specific values. Right? But what he can do, he can still run these flows. And here's my notes about this booking.

Right. We run the flow. It still updates all of our data, but in a restricted manner. You know, it only runs the logic that we want to run, so we can force Matt down a particular path that we want him to go. Alright.

So as far as equipment manager, I'm calling this a win. We have got our inventory. Let's look at our list. Right? Track inventory of all of our equipment.

User reserves equipment on a schedule. We track equipment status. We've got maintenance here. You know, we could easily create a flow modeled after our checkout flow to send this to maintenance, add some notes for it, or I could even just quickly, like, add some maintenance records for this the same way I do my transactions. Right?

And I could even potentially just add those maintenance notes to this specific transaction. So as far as the equipment booking manager, in 1 hour or less, it's a win. It's good. Is it Checkroom? No, it's not.

So if you need a more robust tool, make sure you check this one out. What was it again? Check Room? Looks like a pretty cool tool. Give it a free trial.

I I like building inside Directus because, hey, bookings is is just one part of it. Right? You've got your other workflow. If you're managing your equipment, you're going to have to, plan where you're using that equipment at and things like that. So, inside Directus, in just a couple of tables, in less than an hour you can easily build an internal app to solve some of your problems.

That's it. That's it for this episode of 100 Apps, 100 Hours. Thanks for joining me. Hope to see you on the next one.