Tom Gobich

Anytime!! 🙂

Hi german-gonzalez!

Do you also have the runToasts call within the onMounted hook? Since the ToastsManager is added via the layout, when you go from a page using the AppLayout to a page using the AuthLayout the AppLayout's ToastManager will be destroyed and a new one will be created and mounted for the AuthLayout. By having runToasts called inside the onMounted hook, we're populating that initial state for our messages when the component is first created and ready.

With how we have our layouts defined when we traverse between pages using the same layout, like going from the login page to the register page, the same layout instance will be used. Since our ToastsManager is added via the layout, that also means the same ToastManager instance will be used and that is where the watchEffect comes into play. That will watch the reactive values we're using within the hook for changes and rerun when any are detected.

onMounted(() => {
  runToasts({
    exceptions: props.messages.errorsBag,
    success: props.messages.success,
  })
})

watchEffect(() => {
  runToasts({
    exceptions: props.messages.errorsBag,
    success: props.messages.success,
  })
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Why does it work when wrapped in $nextTick? The issue is that watchEffect runs immediately to pickup which reactive values to watch for changes. When it runs immediately, its running in the setup stage of our component at which time the component hasn't been mounted, so we don't have a template yet. That results in nothing happening with our toasts. By wrapping it in $nextTick you're deferring when the watchEffect's runToasts call actually run.

Hope this helps!!

Awesome, I'm glad to hear that helped! Anytime!!

Hi iphonegeek-me!

Method spoofing with _method is documented on the request page. I also introduce it in this series in our HTTP Method Spoofing HTML Forms lesson.

Hey Tresor!

Password Reset

The differences between using signed URLs and a database-stored token for password resets mostly come down to weighing the pros and cons, and how important those are for your site's use case.

Signed URLs are reliable and quick to implement. However, since they aren't stored in the database, we need a way to attach them to a user, like adding the user's email or ID to the signed URL. Additionally, once generated, we have no way to invalidate the token until its expiry time is reached. This means we can't expire a token after it's been used. This will suffice for most basic apps and is a fine option if you're just starting out with a small user base.

Database-stored tokens have a bit more overhead to implement, and we need to manage the tokens ourselves. However, since the token is stored in the database we don't need to expose any of our users' information via the URL. Additionally, we have the ability to update the database record at any time, so it can easily be expired once used. This is a great option if protecting your users info, even from their own inbox, is a top priority. It's also a must-use if you need to invalidate a token after use (for example, say you need to use an expiry longer than you'd feel comfortable leaving lingering).

The third option here is to use both, generate a token then sign that token into the URL. This would be the most secure option. It takes away the cons of just using a Signed URL and adds an extra obfuscation layer to the database-stored token. Might be seen as a bit overkill depending on the app though.

So, none of the above are bad options unless the type of site you're building or its audience dictates a higher level of security. I actually plan on updating Adocasts password reset flow to use database-stored tokens here in the future. I almost did it with a redesign I'm working on, but opted to save it till after.

Deferred Mail Sending

If we actually dig into sendLater and poppinss/defer, both are in-memory queues using fastq under the hood to actually do the queuing. So, I'd argue there's no real difference between the two unless one has a specific feature you're looking for.

The downside to an in-memory queue is that if your server crashes or reboots (like when you deploy) then anything in that queue has been lost. If you don't send many emails and don't deploy all that often then the likelihood of a lost email is pretty slim.

If you send emails frequently or deploy frequently then your chances of a lost email increase. You might also be sending mission-critical emails that must reach their destination (think appointment confirmation or order receipt emails). That's where an alternative like BullMQ can help because it'll hold the queued item until it's processed, even if the app reboots. You can also swap sendLater's in-memory queue with BullMQ as well. So, you can start with in-memory and upgrade the queue system very easily down the road without having to rewrite your sendLater code.

I'm still using an in-memory queue for Adocasts emails, but I don't deploy all that often and Stripe takes care of our purchase-based emails.

Hope this helps!!

Sure thing! Yeah, looks promising! 🤞

Terribly sorry you lost some time on that christoxz!! I've written down a note to circle back to lesson 4.8, where we introduce the fake_seeder, and add a note about the seeder order of execution.

Terribly sorry about that adun! I'm happy to see you were able to figure it out, and your assessment is spot-on! I'll circle back and insert a heads-up into this lesson. Thank you very much for sharing, and sorry again this got past me!

Yeah, I completely agree!! Thanks again for the helpful feedback!!

Hi holodevelop! First, thank you for your feedback! I'm always looking to improve my lesson making skills, and feedback like this definitely helps, I appreciate it!

To answer your question, any Redis connection would do. You can even use a small free tiered one from Redis Cloud. However, we only use Redis in this lesson and the next within this series, so just skipping over is also a valid option.

There's many things about this series I would add, remove, or do differently now if I were to go back and do them again. A heads up blurb like the below in this lesson and our before we begin lesson would definitely be one of those things.

As a heads up, we'll only be utilizing Redis in this lesson and the next as a way to demonstrate installing, configuring, and using the package. Again, as we covered in lesson 1.1, you'll need a Redis connection to work with. If you're following along and don't see yourself using Redis for anything beyond this series, feel free to skip this and the next lesson and pick back up in lesson 2.16.

👆 I'll circle back and add that to this lesson and another blurb to lesson 1.1, I have some updates to do in module 11 as well.

Terribly sorry about that drummersi-3! This module wasn't originally a part of this series, I added it on last minute and that really shows in this lesson! I'll have to re-watch this module and think through how to appropriately correct it. Again - apologies you had difficulty here, there's definitely room for improvement on this lesson.

Hey hsn! Yeah, I'm not sure what the timetable looks like on that. If you're following along with this series, I'd recommend sticking with Radix for now. If that issue gets closed with a happy migration possible from Radix to Reka for AdonisJS apps, which it sounds like it will (just a matter of when), I'll take a look at adding a 14th module to this series to cover that migration.

Yeah, that can definitely be a major headache depending on the UI library! Anytime!! 😊

Hi Tresor! Yeah, there's some benefits to that, but also cons. The benefits are that you can easily ensure those pages where SEO is important have as small of a weight to them as possible. Many times marketing materials have a different look and feel from the internal application as well, so having them completely split between your Edge pages & Inertia app can help define that barrier.

Though Google and other search engines have been getting better about reading JavaScript, you'll also have piece of mind in knowing exactly what markup is being sent when using Edge as well.

The main con is for those instances where there isn't a visual separation between marketing materials and the internal application. For example, say we're using a UI library in the SPA app but we still want that same look on the Edge pages. We'd need to replicate that UI library's CSS for our Edge pages in order for the look and feel to remain the same. Of course, that may not be an issue if your UI library is framework agnostic or uses web components, but if you're using something like ShadCN, Nuxt UI, etc then that can be a real issue.

In those cases, or even if you just prefer to have everything reside within Inertia, you can specify which pages in Inertia should use SSR. The SSR allowlist resides within the config/inertia.ts configuration file and accepts an array of page names or a function that returns a boolean.

Below are two examples from the linked documentation for this.

import { defineConfig } from '@adonisjs/inertia'

export default defineConfig({
  ssr: {
    enabled: true,
    pages: ['home']
  }
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

import { defineConfig } from '@adonisjs/inertia'

export default defineConfig({
  ssr: {
    enabled: true,
    pages: (ctx, page) => !page.startsWith('admin')
  }
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Hi Diego! That's a great question! My approach would vary depending on just how segmented I would need to get at the data. Let's take a Post model as an example. A post might have certain types (blog, article, news, etc). If the type is the primary way I need to fetch the post, I might have a getPostsByTypeId(typeId: number) service method or action.

However, typically there are other checks needed for a post as well

• Fetching only those that are published, not published, or all

• Fetching posts tied to a specific taxonomy/topic

• Ordering by publication date, title, or something else

• Should we paginate the results or get only a specific number back

And, the list could go on from there. Our endpoints will vary from caring about none through all of these.

My approach to this is to stop and think about what most endpoints are going to need now or shortly in the future. I don't worry about issues we might have 3 or 5 years down the road, as those may or may not come to fruition and we can always refactor to appease them if they do.

I'd then create methods (service or action) to satisfy the requirements of most of the endpoints I'll need. This might result in:

• getPosts(stateId: number, typeId: number, limit?: number = 10, orderBy: PostSorts = 'latest')
  This would return the first limit number of published posts for the provided type and state ordered by sorts we have defined for our posts (like latest, alphabetical, popular, etc). Type would be whether it's a blog, article, etc and state would determine if it's published or not.

• getPostsPaginated(typeId: number, pagination: PaginatorQuery, orderBy: PostSorts = 'latest')
  This would be similar to getPosts, but would return a paginator instead of the first limit. PaginatorQuery here would contain the page, perPage, and baseUrl

That alone would satisfy most of the way we would need to get at our posts, however, a really nice part about Lucid's query builder is that the query can be built on top of further until it is either awaited, executed, or we call a method that does not return back the builder, like paginate.

Meaning, we could return the Post Query Builder from these methods giving us the ability to expand off of them as needed, which is really convenient for those outliers. We might also choose to call these queryPosts instead of get to note that they're expandable. For example:

export default class QueryPosts {
  static handle(
    stateId: number, 
    typeId: number, 
    limit?: number = 10, 
    orderBy: PostSorts = 'latest'
  ): ModelQueryBuilderContact<typeof Post, Post> {
    const query = await Post.query()
      .where({ stateId })
      .where({ typeId })
      .limit(limit)

    switch (orderBy) {
      case PostSorts.ALPHABETICAL:
        query.orderBy('title', 'asc')
        break
      default:
        query.orderBy('publishAt', 'desc')
        break
    }

    return query
  }
}

const query = QueryPosts.handle(States.PUBLISHED, typeId: PostTypes.BLOG)
const blogs = await query
  .whereHas('topics', (topic) => topic.where('topics.slug', slug))

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Now, with this in mind and also that paginate won't allow this, we could remove the limit parameter from this method, get rid of our getPostsPaginated method and instead perform those outside of these methods for additional expansiveness.

If desired, we can create additional methods that call and build off our getPosts as well. Like, the above blog query could be wrapped in a getPostsByTopic(slug: string) method. This comes in handy if this is a frequent way we're going to get at our posts. If we're only ever going to need this for a single page, we might chose to leave the query as-is from the above previous example.

I also really like giving the more complex statements in my queries names. This can be done via query scopes or you can go a step further and create a builder. A builder is essentially a query builder wrapping the Model Query Builder itself with chainable methods specific to your application. That might look like the below.

export default class PostBuilder extends BaseBuilder<typeof Post, Post> {
  whereHasTopic(slug: string) {
    this.query.whereHas((query) => query.where('topics.slug', slug)
    return this
  }

  // use ids
  whereTypeId(typeId: PostTypes) {
    this.query.where({ typeId })
    return this
  }

  // or use named methods
  wherePublished() {
    this.query.where('stateId', States.PUBLISHED)
    return this
  }

  whereNotPublished() {
    this.query.whereNot('stateId', States.PUBLISHED)
    return this
  }

  // or offer both
  whereStateId(stateId: States) {
    this.query.where({ stateId })
    return this
  }

  orderLatest() {
    this.query.orderBy('publishAt', 'desc')
    return this
  }
}

const blogs = await new PostBuilder()
  .whereHasTopic('adonisjs')
  .wherePublished()
  .whereTypeId(PostTypes.BLOG)
  .orderLatest()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

What I like about this is that it keeps our queries very easy to build and understand. It also keeps any methods we may choose to wrap this with small and easily reusable as well. Which, in turn, makes it less of a chore to have multiple different methods for getting at our posts. This is actually the approach I've used for the Adocasts site, if you'd like to see a full example.

Sorry this was a long answer, TLDR: the best approach will vary depending on how many varying ways you need to query your data. If it's only a few ways, specific methods will do just fine. If you need it a myriad of different ways, more complex or even a combination of solutions may prove fruitful.

Thanks a ton for watching, Odejayi! I'm happy to hear you're enjoying AdonisJS! 😊

Hi Jean!

You can achieve that by using Tuyua! From it's documentation, once installed & configured it'll allow template & programmatic linking using route identifiers like the below:

<script setup lang="ts">
import { Link, useRouter } from '@tuyau/inertia/vue'

const router = useRouter()

function visit() {
  router.visit('users.posts.show', { id: 1, postId: 2 })
}
</script>

<template>
  <div>
    <Link route="users.posts.show" :params="{ id: 1, postId: 2 }">Go to post</Link>
    <button type="button" @click="visit">Go to posts</button>
  </div>
</template>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
inertia
pages
Home.vue

Hi cubicalprayer712!

Vladimir kindly left steps on getting this setup in React in the next lesson's comments if you'd like more details, but something like the below should satisfy the needed typing.

const page = await resolvePageComponent(
  `../pages/${name}.tsx`,
  import.meta.glob('../pages/**/*.tsx'),
) as {
  default: ComponentType & { layout?: (page: ReactElement) => ReactElement }
}

page.default.layout = page.default.layout

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Anytime, Vladimir!

That's good to know that it does work! If it works now, I'm more than sure it'll continue to work down the road 😊

Hi cubicalprayer712! Yes, Inertia's structure is a little different from the web starter kit including the name/location of it's base EdgeJS page! Happy to hear you were able to find it!

Hi Vladimir!

That's awesome to hear, I'm happy you were able to build and get an app out to production!

As for your question, the main disadvantage comes if you're working with a team as it'll increase the possibility of merge conflicts or conflicting sorts for your migrations when merging.

Another disadvantage, though much smaller, is that you might need to constantly tweak ordering as you're working on things. For example, if you're working on commit that is adding 5 migrations (10, 11, 12, 13, 14) and you realize you need to add a new migration but it needs to run before the other 5, you'll have to reorder those existing 5. Again, that's a small issue, but using timestamps would've likely given you plenty of buffer where that wouldn't be the case.

The timestamp prefix can also be useful if you need to know when a migration was made; though you can also use the adonis_schema table to see when the migration was run which will be similar.

Apart from that, I've never tried this but I believe Lucid should handle it just fine and can't think of any other big gotchas.

Hi memsbdm! With how we have it, it should display the toast for every failed login attempt. Vue Sonner stacks the messages by default, but you can see each individually if you hover over the stack.

The key premise of it is that we're watching the effect of our messages prop. When the prop's proxy detects a mutation, our watchEffect is called, which pushes a new toast into Vue Sonner.

Try adding a console log within the watchEffect so you can see exactly when it is firing and the message(s) the mutation contains.

watchEffect(() => {
  console.log('ToastManager: messages changed', { ...props.messages })
  runToasts({
    exceptions: props.messages.errorsBag,
    success: props.messages.success,
  })
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
inertia
components
ToastManager.vue

It should look something like the below:

Exactly! It's all a balancing act. Anytime, inox!! 😊

Thank you for watching and for your feedback, jals! I hope you enjoyed!

Thank you very much for sharing, memsbdm!! 😊

Thanks so much for sharing, Vladimir!!

Sorry for the delayed response!! Yes, if you'd like, you can definitely use mixins to extract those out of your models into a reusable bit of code. That would look very similar to what we do in the next lesson with our organization!

Personally, I never bother to do this with my timestamps because when we use the Ace CLI to create our migrations & models those timestamps come with that stub automatically, so it is actually more work to extract them than it is to just leave them be. Plus, they're consistent enough to be easily updated across the board with a find/replace if needed.

Hi Martin!

Sounds like it is most likely a reactivity issue. When the redirect occurs, Inertia will use the new data to update the props of the page. If the reactivity from the props is severed, then that would cause those props and your view to become out of sync.

You should be able to use Vue Devtools to inspect and verify that the props are actually getting updated. Then, follow your usage of that prop to see exactly where the reactivity is being severed.

You could also do a simplified sanity check to ensure that the flow is indeed working.

<script setup>
defineProps({
  users: UserDto[]
})
</script>

<template>
  <ul>
    <li v-for="user in users" :key="user.id">
      {{ user.email }}
    </li>
  </ul>
</template>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
inertia
pages
Usuarios.vue

Great to hear, and thanks for confirming Aaron! I'll get that note added into lesson 12.3! Again, terribly sorry about that!

Hi inox! Yes, that's correct! You have to send the request via the useForm composable in order for that composable to be able to digest any validation errors into its state.

Hi Aaron! I had run into this as well while preparing for the Web API series, but my thinking at the time was that it was something that had changed during the package updates when updating to Inertia 2. Perhaps not though, if you're seeing it here. Terribly sorry about that! I'll have to circle back and add a note in lesson 12.3.

If you go into your inertia/css/app.css file and add the below, does that resolve this issue for you? My understanding was that TailwindCSS should be able to discern the default config when omitted, but it appears @apply might not work so well with that.

@config "../../tailwind.config.js";

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Awesome, thank so much Abdelmadjid! I was able to get it installed and working, and after an initial scan it looks great! Well done on this!! 😃

Hi swarnim! What queries have you tried? I'm not sure I'm fully following.

If your timestamp is stored as a string within the database rather than a date-like type then I'd only see one option. Query all results within the range, convert your timestamp into a date post-query and then group by the needed date frequency. I guess, alternatively, you could also try to group by the left portion of the string consisting of the date.

If it is a date-like type then you should be able to use groupByRaw to group & sum by the needed date frequency. How that looks will vary depending on your database (MySQL, PostgreSQL, etc). https://knexjs.org/guide/query-builder.html#groupbyraw

Hi Manas! Unfortunately, we don't have any content on WebSockets at this time. AdonisJS does have a first-party package for Server Sent Events (SSE) called Transmit. This sounds like it could be suitable for your use-case and may be easier to implement!

This looks great, Abdelmadjid!

Is there any trick to getting it installed within Zed? I tried dropping the repo into Zed's extensions directory but it doesn't show within Zed itself.

~/Library/Application Support/Zed/extensions/installed/zed-edge

Anytime!!

Hi virimchi-m!

Yep, you could absolutely do that! If the HX-Request header is there then HTMX sent the request, so you can use that to conditionally determine whether to render your layout or not. If needed you can also use the target, via the HX-Target header, to determine if the layout needs rerendered.

Alternatively, you could put the contents you want to render within a component, very similar to how we did it in this series with our post_list then render that component directly!

<ul>
  @each (post in posts)
    <li>{{ post.title }}</li>
  @endeach
</ul>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
resources
views
components
post
list.edge

Then, we can use this component within the page:

@layout()
  @!post.filter()
  @!post.list({ posts }) {{-- 👈 renders the list for the page --}}
@end

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
resources
views
pages
posts
index.edge

We can conditionally render it directly from our controller.

export default class PostController {
  async index({ view, request }: HttpContext) {
    const isHtmx = !!request.header('HX-Request')
    const posts = [/* ... */]
   
    return isHtmx
      ? view.render('components/post/list', { posts })
      : view.render('pages/posts/index', { posts })
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Hey Aaron!

What you're getting is a foreign key constraint error. You get this when you attempt to delete a record whose id is referenced by another record's foreign key. Foreign keys are essentially in charge of id integrity within our database, ensuring that we aren't referencing any ids that don't actually exist.

For example, if I have an organization with an id of 3 and a course with an id of 1 that contains an organization_id of 3. When I attempt to delete the organization with an id of 3 the course record, via it's foreign key constraint, will prevent the organization from being deleted because the course's organization_id wouldn't exist anymore. As such, the course with an organization_id of 3 must be deleted before we can actually delete the organization with an id of 3.

Throughout this series, we don't need to worry to much about any of this because when we setup our database, through our migrations, we added instructions to our database to cascade deletions. Meaning, if we attempt to delete the organization with an id of 3, our database will automatically cascade that deletion to also delete our courses with an organization_id of 3.

table
  .integer('organization_id')
  .unsigned()
  .references('organizations.id')
  .onDelete('CASCADE') // 👈
  .notNullable()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

It sounds like you might be missing one or more of these cascade instructions. The error you're getting should include the foreign key's name that prevented the deletion. You should be able to use the foreign key's name to determine which relationship is not cascading. I believe you should then be able to switch it to cascade using something like the below. Alternatively, you could just delete the needed records prior to deleting your organization in code (here's an example of that being done).

this.schema.alterTable(this.tableName, (table) => {
    table.dropForeign("organization_id");

    table
      .foreign("organization_id")
      .references("organizations.id")
      .onDelete("CASCADE")
});

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Hi juandiegou!

I don't have anything on multi tenancy at this time, sorry! It can definitely be done, I've seen some discussions on it, but as a heads up better built-in support is coming down the road in a future AdonisJS version!

Hi tigerwolf974!

Vue doesn't like direct mutation of prop values, which is why we're setting the organizationId into it's own ref and syncing it with the organization id from our props.

However, you're right, it is still redundant and could've been done a little more cleanly using the newer toRef Vue method. The end result in data flow would've been similar though.

Alternatively, we could've not used two-way data binding on the DropdownMenuRadioGroup, however, then our UI wouldn't have immediately updated but rather only updated after we got the response back from the organization switch. Not a huge deal, since the dropdown is auto-closed after selection, but still nice to be able to see the selection bubble change as the dropdown is closing as confirmation that the switch is occurring.

Unless there are certain endpoints you'd like to do something specific with, in terms of error handling, I would just rely on AdonisJS' exception handling. If you don't have try/catches in your controllers the exception handler will catch any exceptions that are thrown automatically for you.

You can then update the handler to your liking if you're looking to always return a specific structure for exceptions.

Sure thing, memsbdm! Thank you very much for catching this!!
Just noticed I missed the validation update in my prior comment, will get that edited in now 😊

Oh hey, haha! Seems we both found the culprit around the same time! 😄

I chose to take the overkill approach in my commit & other comment, though using flash messages instead of a cookie.

Alrighty, was able to track down the issue! So this was happening as a side-effect to the Referrer-Policy: no-referrer within reset method of the forgot password controller.

When we call response.redirect().back(), which happens on our behalf during request validation handling, it reads from the referer header and redirects the user back to that page. With our Referrer-Policy on this particular form set to no-referrer we're telling the browser not to share that referrer with anyone. This is a security step to prevent the token from being leaked via the referrer.

To properly correct this and also allow any password errors to show, we want to keep the no-referrer designation and instead update how we're handling our validation errors.

First, let's move the password reset token into a flash message, rather than passing through the form. This will allow us to keep it out of our redirect url should we get any validation errors on submit.

async reset({ params, inertia, response, session }: HttpContext) {
  // will be in the params if coming from email
  // will be in flash messages if coming from errored validation
  const token = params.value ?? session.flashMessages.get('password_reset_token')
  const { isValid, user } = await VerifyPasswordResetToken.handle({
    encryptedValue: token,
  })

  // flash it to the session store
  session.flash('password_reset_token', token)
  // keep this to keep things secure
  response.header('Referrer-Policy', 'no-referrer')

  return inertia.render('auth/forgot_password/reset', {
    email: user?.email,
    isValid,
  })
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Then, configure the update method to read the token from the flash message store instead of our form. We'll also want to manually capture and handle the validation error so we can specify where the user should be redirected to, reflashing the token so it continues to be available for us to use.

@inject()
async update({ request, response, session, auth }: HttpContext, webLogin: WebLogin) {
  let data: Infer<typeof passwordResetValidator>

  try {
    data = await request.validateUsing(passwordResetValidator)
  } catch (error) {
    // manually catch any validation errors that were thrown
    if (error.code === 'E_VALIDATION_ERROR' && 'messages' in error) {
      // reflash the user's password reset token so it is available to use again
      session.reflashOnly(['password_reset_token'])
      // flash the validation errors so they display to the user
      session.flashValidationErrors(error)
      // redirect to the correct page
      return response.redirect(`/forgot-password/reset`)
    }
    throw error
  }

  // grab the token from the flash message store to use
  const token = session.flashMessages.get('password_reset_token')
  const user = await ResetPassword.handle({ data, token })

  await auth.use('web').login(user)
  await webLogin.clearRateLimits(user.email)

  session.flash('success', 'Your password has been updated')

  return response.redirect().toRoute('courses.index')
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Next, since our token is no longer in our data, we'll update the ResetPassword action to accept it separately.

type Params = {
  data: Infer<typeof passwordResetValidator>
  token: string
}

export default class ResetPassword {
  static async handle({ data, token }: Params) {
    const { isValid, user } = await VerifyPasswordResetToken.handle({ encryptedValue: token })

    if (!isValid) {
      throw new Exception('The password reset token provided is invalid or expired', {
        status: 403,
        code: 'E_UNAUTHORIZED',
      })
    }

    await user!.merge({ password: data.password }).save()
    await ExpirePasswordResetTokens.handle({ user: user! })

    return user!
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Then, since the token will come from our flash message store on any validation redirects and not the route params, we'll make that route parameter optional.

router.get('/reset/:value?', [ForgotPasswordsController, 'reset']).as('reset')

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Lastly, since we're no longer passing the token to our page or form, we can remove it from our validator.

export const passwordResetValidator = vine.compile(
  vine.object({
    value: vine.string(),
    password: vine.string().minLength(8),
  })
)

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

With all that, things should be behaving properly! Terribly sorry I missed accounting for that. The no-referrer was something I added in after the fact and failed to recognize it'd have that kind of impact. However, it is definitely something we want to keep.

You can find the full diff of my commit for this here:
https://github.com/adocasts/building-with-adonisjs-and-inertia/commit/2f87a54cd84886e6dfffad01568153e2f8fe24a1

Anytime! Awesome, I'm happy to hear it's making sense now!! 😊

Hi memsbdm!

The mailer at plotmycourse.app is indeed still up and running, you might need to check your spam for it's email. However, I can confirm I'm having the same issue. I'm not immediately sure why this would be happening, it looks like it isn't properly returning an Inertia response from the validation handling.

I'll be able to dig into it further after work and will let you know if I find anything!

Hey Michel!

I haven't personally looked into this too deeply of late. I do know the it was once a planned feature within Inertia, but I believe it has since been dropped; though there are many workarounds out there.

InertiaUI's Modal functionality looks pretty promising though, might be worth checking out!

A user named Cory on the AdonisJS Discord also just recently shared similar functionality, you might be interested in reading his approach!

Thanks a ton, Validimir!

I actually don't have WhatsApp and am not all that familiar with it. My current understanding is that it is similar to SMS/text messaging. Please correct me if I'm wrong, but if that is indeed the case I appreciate the invite but will decline at this time. I'm actively on and can be easily reached via the AdonisJS Discord, the Adocasts site, and other social media.

Beyond that, I like to try and minimize the amount of notifications I receive. 😊

Happy to hear you enjoyed, Vladimir!! JWT & refresh tokens can definitely be complicated to implement, for sure! 😊

Hi Vladimir!

Yes, there sure is! If you open your JSON user settings:

1. Hit cmd/ctrl + shift + p to open the command palette

2. Search for and select "Preferences: Open User Settings (JSON)"

You can add the following to this file, which will map the EdgeJS file extension .edge to use HTML Emmet functionalities.

{
  "emmet.includeLanguages": {
    "edge": "html"
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Hi memsbdm!

Unless you're looking to handle these exceptions a specific way, the built in status page functionality of AdonisJS should suffice for these! These status pages work the same way in Inertia as they do in standard AdonisJS.

Any status codes within the range specified via the statusPages object, which is located within your app/exceptions/handle.ts file, will render out the designated page for that status code to alert your user of the exception.

import app from '@adonisjs/core/services/app'
import { HttpContext, ExceptionHandler } from '@adonisjs/core/http'
import type { StatusPageRange, StatusPageRenderer } from '@adonisjs/core/types/http'

export default class HttpExceptionHandler extends ExceptionHandler {
  // ...

  /**
   * Status pages are used to display a custom HTML pages for certain error
   * codes. You might want to enable them in production only, but feel
   * free to enable them in development as well.
   */
  protected renderStatusPages = app.inProduction

  /**
   * Status pages is a collection of error code range and a callback
   * to return the HTML contents to send as a response.
   */
  protected statusPages: Record<StatusPageRange, StatusPageRenderer> = {
    '404': (error, { inertia }) => inertia.render('errors/not_found', { error }),
    '500..599': (error, { inertia }) => inertia.render('errors/server_error', { error }),
  }

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

If, as shown in your example, you're looking to redirect the user back to the previous page when the exception is raised and alert them via a toast (or something similar) instead. You could create an exception with a handle method doing exactly that, then extend that exception for your ConflictException and any others you've created.

I believe that'd look something like the below!

// app/exceptions/exception_redirect_handler
export default class ExceptionRedirectHandler extends Exception {
  async handle(error: unknown, ctx: HttpContext) {
    ctx.session.flashErrors({ [error.code!]: error.message }) // to access it using errors.E_CONFLICT
    return ctx.response.redirect().back()
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

export default class ConflictException extends ExceptionRedirectHandler {
  static status = 409
  static code = 'E_CONFLICT'
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
app
exceptions
conflect_exception.ts

Hi memsbdm! I don't have any plans to do so at this point in time, but if there is enough desire for that I'd be happy to circle back. Updating to Inertia v2 was planned and accounted for in the planning of this series, as we knew ahead of time the breaking changes would be next to none and it'd mostly be feature additions. So the additions to the series there wouldn't be overly confusing.

It does look like Shadcn-Vue now supports TailwindCSS 4, however, that does require updating to their new major version which switches from Radix Vue to Reka UI. They also seem to have dropped support for specifying a tsconfig location in that update.

Awesome, glad to hear all is working now!

Yep, that'll do it! You'll want to either use:

• The auth middleware (requires an authenticated user)

• The silent auth middleware (checks for user, but does not require auth)

• Or, call await auth.check() to check for an authenticated user without one of the two middleware.

Anytime!!

I'm guessing you're probably using v3 or later of the AdonisJS Inertia adapter and errors is already being shared automatically for you.

Since you're sharing to a custom errors key in your flash messages, that won't be included within those.

Try writing to the errorsBag instead. This is how the invalid credentials exception does it itself, and this is automatically checked and populated by the AdonisJS Inertia adapter (v3+).

if (error instanceof errors.E_INVALID_CREDENTIALS) {
  session.flashErrors({ form: 'Invalid credentials' })
  return response.redirect().back()
}

// Handle other errors
session.flashErrors({ form: 'An error occurred during login' })
return response.redirect().back()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Then, so long as my assumption is correct and you're using v3 or later of the adapter package, you can remove errors from your sharedData

AdonisJS uses Opaque Access Tokens (OAT), sometimes referred to as a by-reference token. Unlike JWTs, with opaque tokens the source of truth is the database and the only thing meant to read the token is the issuing server.

Since the source of truth is the database, in order for a token to be verified it must go through the server via an introspection endpoint. This also means tokens can be readily revoked at any time. This makes opaque tokens more secure than JWTs, as it follows the never trust, always verified methodology. Since the token can be revoked at any time and doesn't contain any user information they can have a longer expiry than JWT access tokens. However, since it needs to verify the token with the server, it can be less scalable at high user levels.

Here's more on the matter from AdonisJS' creator.

That said, if you would like to use JWTs with AdonisJS, you can give MaximeMRF's JWT package a go! That should get you all set up!

Hi Michel,

Are you sure you have an authenticated user and/or errors? Try giving them a console log inside the sharedData just to make sure you actually have a value there. This has been the reason for a few others in the past.

sharedData: {
  greetings: 'bonjour',

  user: (ctx) => {
    const user = ctx.auth?.user
    console.log({ user })
    return user
  },

  errors: (ctx) => {
    const errors = ctx.session?.flashMessages.get('errors')
    console.log({ errors })
    return errors
  },
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Also, if you're using v3 of the AdonisJS Inertia adapter or later, you don't need to manually pass the errors via sharedData, the package will now do that automatically.

Thanks so much, codthing!! I greatly appreciate that! I'm really happy to hear everything was easy to follow even with using a translator!

Anytime! Thank you, again, for the great suggestion!

Ah, I'm happy to hear you were able to track down the root cause! Sorry there wasn't a warning in-video about that, codthing! Locales on the slugify didn't even occur to me.

Sounds good, Rajeeb! Hope it helps!! 😊

Anytime! Best of luck!! 😊

Hi codthing!

Thank you for the great suggestion! You can now find the database diagram within readme of the repository and the repository's public directory!

Hi ab-ab!

I don't personally use Docker, so this isn't something likely to be covered on Adocasts anytime soon. You can give AdonisJS Sail a go though, I believe this is meant to help with getting a Docker environment set up in an AdonisJS 6 app.

Hi Rajeeb!

That would definitely be something that's possible, though we don't have a lesson on that specific topic here at this time. We do, however, have an introductory lesson on how to make an AdonisJS package that may help get you started.

With Inertia reaching both the front & back end, though, the scope of what your package would look like will depend on whether it is intended for the front end, back end, or both.

Hi n2zb! You can preload pivot table data two ways.

First option is to define them directly in the relationship definition, as shown in this lesson at 6:50. This will always include them when the relationship is preloaded. So, this is a great option is you'll frequently need that pivot data.

export default class Movie extends BaseModel {
  // ...

  @manyToMany(() => Cineast, {
    pivotTable: 'cast_movies',
    pivotTimestamps: true,
    pivotColumns: ['character_name', 'sort_order'], // 👈
  })
  declare castMembers: ManyToMany<typeof Cineast>

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

The second option is to add them on a per-query basis, as needed.

const crew = await movie
  .related('crewMembers')
  .query()
  .pivotColumns(['title', 'sort_order']) // 👈
  .orderBy('pivot_sort_order')

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

This will then add those pivot columns into the $extras object of the preloaded relationship.

const crewMember = {
  // ...

  '$extras': {
    pivot_title: 'Art Director', // 👈
    pivot_sort_order: 0, // 👈
    pivot_movie_id: 417,
    pivot_cineast_id: 40,
    pivot_created_at: DateTime { ts: 2024-03-30T11:59:58.911+00:00, zone: UTC, locale: en-US },
    pivot_updated_at: DateTime { ts: 2024-03-30T11:59:58.911+00:00, zone: UTC, locale: en-US }
  },
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Note that the column names are prefixed with pivot_ and that the ids of the relationship are always included. Also note, if you're serializing your models, you'll want to turn on extras serialization via the below on the model, and they'll be serialized as meta.

export default class Cineast extends BaseModel {
  serializeExtras = true

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

We get into all of this in various later lessons in this series as well, if you'd like a deeper dive!

Hi codthing! Everything you've shared looks right. If you're viewing your Redis database with a GUI application, those often don't reflect live data and require refreshing in order for them to reflect changes made to the database contents. Also, make sure you're viewing the Redis database actually being used by your application! This can be found within config/redis.ts

const redisConfig = defineConfig({
  connection: 'main',

  connections: {
    main: {
      host: env.get('REDIS_HOST'),
      port: env.get('REDIS_PORT'),
      password: env.get('REDIS_PASSWORD', ''),
      db: 1, // 👈 indicates I'm using Redis DB1, DB0 is typically the default
      keyPrefix: '',
      retryStrategy(times) {
        return times > 10 ? null : times * 50
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
config
redis.ts

You might also do a sanity check, just to ensure your controller methods are actually being hit correctly, by adding a console log to each.

//redis controller
export default class RedisController {
    public async destroy({ response, params }: HttpContext) {
        console.log('destroy', params.slug)
        await cache.delete(params.slug)
        return response.redirect().back()
    }

    public async flush({ response }: HttpContext) {
        console.log('flushing redis')
        await cache.flushDb()
        return response.redirect().back()
    }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

If neither of those help, please feel free to share a link to your repository and I can take a deeper look to see if anything stands out!

Anytime! Okay cool, yeah updating the logger destination and logging the queries, as shown in the last two code blocks in my comment above, should get that working for ya!

Hi Rajeeb!

Console logging a call to toSQL() as you have should work, you should be seeing something like the below in your console.

However, there is a nicer way to do this, using pretty printed query logging. Within your config/database.ts, set prettyPrintDebugQueries: true.

const dbConfig = defineConfig({
  prettyPrintDebugQueries: true, // 👈
  connection: 'postgres',
  connections: {
    postgres: {
      client: 'pg',
      connection: {
        host: env.get('DB_HOST'),
        port: env.get('DB_PORT'),
        user: env.get('DB_USER'),
        password: env.get('DB_PASSWORD'),
        database: env.get('DB_DATABASE'),
      },
      migrations: {
        naturalSort: true,
        paths: ['database/migrations'],
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
config
database.ts

Then, you can either globally enable query logging, by adding a debug: true to your driver object.

const dbConfig = defineConfig({
  prettyPrintDebugQueries: true,
  connection: 'postgres',
  connections: {
    postgres: {
      debug: true, // 👈
      client: 'pg',
      connection: {
        host: env.get('DB_HOST'),
        port: env.get('DB_PORT'),
        user: env.get('DB_USER'),
        password: env.get('DB_PASSWORD'),
        database: env.get('DB_DATABASE'),
      },
      migrations: {
        naturalSort: true,
        paths: ['database/migrations'],
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
config
database.ts

Or, you can enable this this on a per-query basis by adding debug(true) to the query.

await Collection.query().where('slug', params.slug).debug(true).firstOrFail()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

With that set, you should see something like below in your console

Now, unfortunately, this pretty print can't be logged to a file. You can still log the query to a file though. Within your config/logger, set the non-production logger target to a file at the destination you'd like. If that's a file in storage, it'd look something like:

const loggerConfig = defineConfig({
  default: 'app',

  loggers: {
    app: {
      enabled: true,
      name: env.get('APP_NAME'),
      level: env.get('LOG_LEVEL'),
      transport: {
        targets: targets()
          // 👇
          .pushIf(!app.inProduction, targets.file({ destination: './storage/local.log' }))
          .pushIf(app.inProduction, targets.file({ destination: 1 }))
          .toArray(),
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
config
logger.ts

Then, add a global listener for the query within a preload.

node ace make:preload events

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

import emitter from '@adonisjs/core/services/emitter'
import logger from '@adonisjs/core/services/logger'

emitter.on('db:query', function (query) {
  logger.debug(query)
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  
start
events.ts

With this all your logs, including queries, will be written to the file at the location you've specified! Hope this helps!! 😊

That's awesome to hear, Vladimir! I'm really happy to hear you're finding the lessons early to follow and enjoying them, thank you for sharing!

Anytime! Awesome, I'm happy to hear that got things working for you, memsbdm!!

Hey memsbdm! Yeah, the deployed app has been expanded beyond the scope of the Building with AdonisJS & Inertia series. It's what I use to plan lessons and series, and also feeds the data shown on our schedule page. So, I've added some things since. Apologies if that caused any confusion!

I did have the repository private, but just made it public. You can find the code for the live PlotMyCourse app here.

The <Sortable> component accepts a tag prop, and I have that set as tbody so that it plays well structurally with the table itself. I think that might be all you're missing!

<Table>
  <TableHeader>
    <TableRow>
      <!-- ... -->
    </TableRow>
  </TableHeader>
  <Sortable
    v-if="courses?.length"
    v-model="courses"
    item-key="id"
    handle=".handle"
    tag="tbody" <!-- 👈 -->
    class="[&_tr:last-child]:border-0"
    @end="onOrderUpdate"
  >
    <template #item="{ element: course }">
      <TableRow class="group">
        <!-- ... -->
      </TableRow>
    </template>
  </Sortable>
</Table>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Anytime, Nidomiro!! 😊

Awesome, that's great to hear!
Anytime!!

Hi memsbdm!

It looks like this was a tiny change that occurred between InertiaJS v1 and v2! In this lesson, I'm still working with Inertia v1, which is why everything works without issue for me. We upgrade to InertiaJS v2 in module 13, though this is one change I missed!

Here's what the FormDataType looks like in InertiaJS v1:

And then here is what it is now in InertiaJS v2:

So, your solution is perfect for v2! You could probably try and use `Record<string, FormDataConvertible> if you'd prefer to be as accurate as possible! Though I don't believe what you have should cause any issues down the road! Thank you for sharing! 😊

Anytime and no worries at all! That's completely understandable!! 😊

Hi Nidomiro!

Yep, that's absolutely a valid approach with AdonisJS! I haven't done it myself, but you can check out Romain Lanz's website which uses this setup. He is one of the AdonisJS Core Members.

You'd need to move some files around to your liking manually, then update the imports within your package.json to match your feature names (if you want to use import aliases) rather than having one for controllers, models, etc.

Hi Thiago!

Sorry you're having issues! I think I found the culprit. It looks like TailwindCSS was having difficulty picking up the default configuration to use. Explicitly defining the config seems to have fixed the issue - at least on my end, but I couldn't get the error to consistently happen.

Please let me know if this remedied the issue for you!

Thanks and sorry again you're having issues!

Sure thing, Aaron!!

Hi Tigerwolf!

Lucid cascades the transaction to relationship operations for us! So, when we attach the transaction to the operation that creates the organization, the transaction reference will be kept in the organization instance.

return db.transaction(async (trx) => {
  const organization = await Organization.create(data, { client: trx })
  
  organization.$trx // 👈 holds the transaction

  // ...
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

This transaction reference is then automatically used when we perform subsequent operations with this organization, which includes related operations.

return db.transaction(async (trx) => {
  const organization = await Organization.create(data, { client: trx })
  
  // 👇 passes $trx on the organization along with the attach db operation
  return organization.related('users').attach({
    [user.id]: {
      role_id: Roles.ADMIN,
    },
  })

  // ...
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

The managed transaction, then, wraps the callback within a try/catch block. The transaction is committed if the callback completes and no errors are thrown. Otherwise, if an error is caught, the transaction is rolled back. Essentially doing the below for us in a nicer syntax.

const trx = await db.transaction()

try {
  const organization = await Organization.create(data, { client: trx })
  
  // 👇 passes $trx on the organization along with the attach db operation
  return organization.related('users').attach({
    [user.id]: {
      role_id: Roles.ADMIN,
    },
  })

  // ...

  await trx.commit()
} catch (error) {
  await trx.rollback()
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

So, as long as we don't eat the errors thrown by the operations we're performing, the managed transaction will catch it and roll back our transaction. This is regardless of how we structure our code within the managed transaction, including splitting it into additional methods.

So, to answer your question, If an issue occurs in assignAdmin or createDefaults the managed transaction will catch this and roll back our transaction for us! You can see this for yourself by trying to assign the user a role_id that doesn't exist. Since we're using a foreign key constraint here, attempting to do so will throw an error.

static async #assignAdmin(organization: Organization, user: User) {
  return organization.related('users').attach({
    [user.id]: {
      role_id: 45, //Roles.ADMIN, // 👈 replace admin with some non-existant id
    },
  })
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Anytime! Awesome, glad to hear you’re all set Oliver!

Hi Oliver!

Partial route parameters, like /fly-to-:city aren't supported by the AdonisJS Router at present. However, you can use a vague route parameter in conjunction with a route param validator to make this work.

router.get('/:flyToCity', [Controller, 'handle']).where('flyToCity', /^fly-to-/)

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

The where here is applying a validator to the route parameter, stating that the parameter should start with "fly-to-" in order for the route to match the definition.

We have a lesson where we cover this using user profiles in our Let's Learn AdonisJS 6 series if you'd like to learn more!

Awesome, I'm really happy to hear you're all set up now! Thanks a bunch, Ikeh!! 😊

Alrighty, so I took a look into it. I was also getting the error with MySQL, and it was indeed a code issue! I accidentally missed binding the organization to the transaction, which caused the decrement to run outside the confinement of the transaction - hence the lock block.

Below is the updated code that fixes this issue! Terribly sorry about the miss here! I'll get a note about this added into the lesson.

export default class DestroyLesson {
  static async handle({ organization, id }: Params) {
    const lesson = await organization.related('lessons').query().where({ id }).firstOrFail()

    await db.transaction(async (trx) => {
      lesson.useTransaction(trx)
      organization.useTransaction(trx) // 👈

      await lesson.delete()
      await organization
        .related('lessons')
        .query()
        .where('moduleId', lesson.moduleId)
        .where('order', '>', lesson.order)
        .decrement('order')
    })

    return lesson
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

Hi Deniz!

I think you've got a small typo. You're flashing to notification in your controller, but sharing notifications. You'll want those two to match 1:1.

Also, make sure you've got the flash message key notification or notifications (whichever you pick) defined as a prop on your page/layout. Otherwise Vue, for example, won't ingest it and will treat it as an attribute and not a prop.

Anytime! Awesome, I'm glad to hear you were able to get it fixed up! As a morning person, I can concur! 😄

No worries at all! It's been a long while since I've used MySQL, so my platform-specific knowledge here will be limited. But, if it works fine without the decrement then I'd imagine you most likely have a stuck lock or transaction on one of your lessons. Something not directly related to the decrement, but rather blocking the decrement from succeeding.

This may or may not be code-related. It could be a lock added by a client application or CLI using your MySQL table. It could also be another transaction touching one of the lesson rows that was never committed or rolled back. Here is a StackOverflow thread that discussed some query options to dig into what might be locking things up.

I can try and get MySQL set up and test it out this evening after work to ensure it isn't a code issue specific to MySQL.

Hi Ikeh! Redis is used for a very brief period in this series. I believe 2.14 and 2.15 are the only two lessons we use it within, just to show how to work with it. It is completely skippable if you don't feel like setting it up on your machine!

Alternatively, you can use Redis Cloud. They offer a small free tier if you click "Try for Free" and then select the "Essentials" plan option during sign-up, as shown below.

Once you've created your database, you can click on "connect" and then expand the "Redis Client" section. Here you can copy/paste the username, password, host, and port into your .env file of your project.

Note: you have to click the "copy" button to get the actual password

That's awesome! I'm happy to hear you're making progress with it! I wouldn't worry too much about doing things the best or cleanest way, especially initially! So long as it works for what you need in a way you understand, that's all that matters to keep progress going. You can always refactor down the road if need be. 😊

Awesome! I'm glad to hear you were able to get it figured out! 😊

Hi Ryan!

The authenticated user isn't populated until you tell AdonisJS to populate it. This can be done using the auth middleware, silent_auth middleware, or manually calling auth.check() as needed. You're most likely missing one of those.

Note that you also need to specify a serialized type for your Lucid Models using either casting or DTOs.

Yeah, you'll want the HttpContext here to be optional. Then, when you don't have an HttpContext, you'll want to signal to yourself that your permissions haven't been populated; leaving it null there could be a way to do that.

@afterFind()
static async attachPermissions(workspace: Workspace) {
  const ctx = HttpContext.get()

  if (!ctx) return

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

If the HttpContext isn't optional then your model would also become unusable within commands, jobs, events, and all that fun stuff. In most cases, you shouldn't need permissions on those types of requests. On the off chance you do, that's where you'd want to extract the contents of the hook into a model method, service, or action so you can also use the same logic on an as-needed basis.

Hi Aaron!

It sounds like your organization is undefined within the SortableLessons component. If it works fine within SortableModules then it should be populated on the page okay. Make sure you've got it within the props being passed into SortableLessons!

<SortableLessons
  v-model="modules[index]"
  :organization="organization" <!-- 👈 -->
  :course="course"
/>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

If it's there, then make sure it is within SortableLessons props.

const props = defineProps<{
  organization: Organization // 👈
  course: CourseDto
  modelValue: ModuleDto
}>()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

I'd reckon it's one of those two, but if it is in both of those spots, I'd recommend using the Vue DevTools to inspect the flow of this prop to see where it might be getting lost.

Hope this helps!!

Oh shoot - I recorded these updates and got the Inertia one updated but missed this one. I'll get this updated after work!

Thanks so much for watching, cortesbr!! ❤️

Hi Emilien!

No worries at all!! 😊

Yeah, things spiral here quickly depending on your approach. It's a big enough of a topic to be a series of its own, but I'll try to give an overview below.

Access Determination

So, the first thing you need to do is figure out how the more granular access will be determined. Will only the creator have permission to edit, update, and delete? Or, maybe the creator can invite others to edit, update, and delete? Essentially, how are the different roles going to be determined at those different levels?

Creator Only

If it's just the creator, then that's much easier. You'd want to capture the userId of the user who created the resource. For example, adding a ownerId onto the Course model. Then, you'd handle the logic very similarly to how we allow org members to remove themselves throughout the next two lessons (12.1 & 12.2). By giving priority to allow the action if the ownerId matches the authenticated user's id. When that's the case, you'd want to ignore whatever the role's permission says and allow the action.

Resource Specific Invitations

If you want to allow the creator to invite/share with others to collaborate, you'll need a table to track that. This table could look many different ways.

• It could be a single table per resource, ex: course_user consisting of course_id, user_id, and role_id if there are different levels and not an on/off.

• A polymorphic table, ex: permission_user consisting of something like entity , entity_id, user_id, and again role_id if needed. Here, entity would be the table/model and entity_id would be the row's id for that table/model. Now, Lucid doesn't support polymorphic relationships but that doesn't mean you couldn't specifically query for what you need. The downside is, that you can't use foreign keys for the entity_id since it'll be dynamic

• A single table with a nullable column per resource, ex: permission_user consisting of something like course_id, another_id, user_id, and again role_id if needed. This is similar to the polymorphic relationship, but you have a specific column per resource needed. Plus here, is you can keep foreign keys. Downside here, is it can be a lot of columns if a lot of resources need to use it.

There are many different ways authorization can look beyond these two, but determining what that looks like is the first step.

Populating Permissions

When it comes to populating these permissions, again, it's going to depend on just how granular you need to go. For us in this series, things were simple so our approach was simple. The approach covered here was meant mostly for a single set of roles that then trickle down as needed.

If you're going to be listing courses and each of those courses in the list is going to have varying permissions based on invites/shares, then you might be better off moving the can approach to the row level. For example, allowing something like course.can.edit to determine if the authenticated user can edit the course. This could be done using something like model hooks.

You could also always reach for a package to help achieve your implementation.

That was a lot, sorry! Hopefully, that helps at least little though.

Sorry I couldn't be of more help, Rajeeb! I hope you're able to find a solution. You might have luck reaching out on the AdonisJS Discussions or Discord.

My pleasure, tigerwolf!! Happy to be able to help! 😊

Hello, tigerwolf!

Sorry about the inconvenience!! Thankfully, the video host we're using for these videos allows specifying custom CSS within the player's iframe, and I was able to get the captions pushed up when the video toolbar is shown. I also hid the heatmap, which seems to be mostly what was going over the subtitles.

We're in the process of switching from an actual video host to Cloudflare R2 with a hand-picked player, so hopefully we'll have more improvements in this area down the road!

Thank you very much for the feedback!!

Terribly sorry about that, tigerwolf! The subtitles for this lesson have now been corrected. Thank you very much for the heads up!

Hi Rajeeb!

Do you have ts-node-maintained installed? This package is a version the AdonisJS Core team support that's a maintained fork of ts-node.

Please make sure that this package is installed and that you're attempting to run your Ace CLI command from the correct directory. If in development, that'll be the root of your project. If you're attempting to run a built application, that'll be in the build directory. I'm unfamiliar with Docker, but that may be a source of the issue as well.

As a sanity check, I just pulled down a new installation of the AdonisJS Inertia starter kit and it installed and booted successfully.

Hi emilien!! I think your linked repo is private, but I'm happy to hear you were able to find a solution! I just took a look into it and the target was email.database.unique where email is the validator field's name.

The below, within resources/lang/en/validator.json, worked for me!

{
  "shared": {
    "messages": {
      "email.database.unique": "This is from the translation"
    }
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
  

You can find the logic used to find a translated message within the I18nmessagesProvider . Also, my initial thinking was incorrect. This is actually used immediately by the validator, not inside the middleware!