FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Unsuccsesfull attempt to implement invitation flow.

    Scheduled Pinned Locked Moved Unsolved
    Q&A
    2
    3
    1.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mou
      last edited by

      Hello, community. I want to share my recent experience in the hope that we can figure out a solution together.

      I'm trying to implement an invite flow for our application, which allows users to invite others to collaborate, even if they are not registered in the application. After reading related topics on implementing an invitation flow, I decided on the following process:

      1. The user specifies the email of the person they want to add to the team.
      2. The application creates and registers a new user, setting sendSetPasswordEmail and skipVerification in an API call.
      3. The new user receives an email with a link to set their password.
      4. The user sets their password.
      5. The user is redirected to the application UI to accept the team invitation.

      In reality, everything goes fine up until the new user sets their password. They then see an uninformative screen with no instructions on what to do next or where to go. Therefore, I decided to update the templates for several reasons:

      1. To provide guidance and explanations about what is happening ("You were invited to... after setting your password you will...")
      2. To instruct the user on the completion page about the next actions and provide a link, or possibly even initiate a redirect to the application using JavaScript.

      This seemed like an easy task until I realized that "password reset" and "password set" use the same templates, meaning any changes will affect both flows.

      So, I decided to implement conditional branching in the template to display different content for different flows. My first attempt was the simplest possible solution: using a query parameter.

      1. I added a query parameter to the URL in the "Set password" email template.
      2. Retrieved it in the template using request.getParameter.
      3. Added a hidden input to the form.

      This worked fine for displaying the form, but after successful form submission, the user is redirected to the complete template without preserving the parameter. So, this approach failed.

      Next, I decided to add an additional data field to the user object during creation. If the user does not have an account and the account was created during the invitation flow, it would contain a corresponding boolean flag in the data map/property set. My idea was to access the user object and read the property to identify the flow. If the flag is set, it indicates that the user is not yet properly registered and is definitely not resetting their password.

      But this idea was debunked because the "Password set" template does not have the user object in its context. Even though the template has the declaration:

      [#-- @ftlvariable name="currentUser" type="io.fusionauth.domain.User" --]
      

      attempting to access currentUser causes a Null Pointer Exception (NPE).

      I am out of ideas on how to implement the invitation flow while keeping the user experience less frustrating. If you have any suggestions or even propose a complete redesign of the approach, please do not hesitate to share.

      mark.robustelliM 1 Reply Last reply Reply Quote 0
      • mark.robustelliM
        mark.robustelli @mou
        last edited by

        @mou Have you thought about setting up a separate application for the "Invited" users, then the work flow could be about registering. Once they complete registration and setting of the password, you could grant them access to the main application through the APIs and redirect them. That would allow you to keep the messaging different for the invited users and existing users.

        M 1 Reply Last reply Reply Quote 0
        • M
          mou @mark.robustelli
          last edited by

          @mark-robustelli Hi, Mark. This is a great idea I didn't even think of. Thank you very much. It is a workaround anyway, but maybe it will allow me to complete PoC and wait for the proper invite flow to be implemented in FA.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post