SalesforceLabs / ActionPlansV4

Action Plans encapsulates best practices into reusable task templates.
https://salesforcelabs.github.io/ActionPlansV4/
BSD 3-Clause "New" or "Revised" License
21 stars 11 forks source link

"Cannot locate Apex Type for ID" #71

Open katrina-lawrence-salesfix opened 1 year ago

katrina-lawrence-salesfix commented 1 year ago

Apex Error

Steps to re-create

  1. Create a new action plan from the Action Plans tab
  2. Add a task to the action plan
  3. Associate a record with the action plan
  4. Attempt to Save
  5. An error will display "Cannot locate Apex Type for ID"

Expected behavour: action plan saves successfully

Workaround: always attach an action plan by first navigating to a record and Creating an action plan from the related list. OR attach the record as your first step when creating an action plan (before adding any tasks)

Screenshots image image

Environment (please complete the following information):

anthonygiuliano commented 1 year ago

You should be able to find a record in the "Related Object" section using that lookup field. I'm experiencing the same error, and notice that it only gets thrown when that lookup is empty, like you said.

Something doesn't sit right about how this gets thrown though. As a required field, I would expect something less jarring, the way my browser complains about missing required fields everwhere else on the internet. Instead of failing only after the controller isn't able to getSObjectType.

I glanced through the markup on the page and the component that looks like it's responsible for this input field, and it looks like it should be getting the required attribute in the rendered html. Does anyone have any clues or insight that could help me understand what I'm seeing in this behavior?

anthonygiuliano commented 1 year ago

You should be able to find a record in the "Related Object" section using that lookup field. I'm experiencing the same error, and notice that it only gets thrown when that lookup is empty, like you said.

Something doesn't sit right about how this gets thrown though. As a required field, I would expect something less jarring, the way my browser complains about missing required fields everwhere else on the internet. Instead of failing only after the controller isn't able to getSObjectType.

I glanced through the markup on the page and the component that looks like it's responsible for this input field, and it looks like it should be getting the required attribute in the rendered html. Does anyone have any clues or insight that could help me understand what I'm seeing in this behavior?

I noticed that the form element is getting a novalidate attribute. I assume this is preventing the behavior I'm expecting re field requiredness.

katrina-lawrence-qbcc commented 1 year ago

Hi @anthonygiuliano there seems to be some weird refresh behaviour every time you add a new line in the tasks. I raised another bug where if you set a time on the task, then add another task below it the time resets back to default. Perhaps thats the hint -> when Add New Task is pressed, something is being triggered and that is expecting a value in the field.

dschach commented 1 year ago

Hi all. The reminder should be fixed in the next release. The novalidate attribute was included to allow people to delete a line when editing the tasks without throwing an error if all fields weren't filled in. It's proving difficult to enforce everything.

Perhaps we can do a special custom validation that the related record field be filled, using Javascript, but that feels a little janky. Thoughts?

anthonygiuliano commented 1 year ago

What if removeTask didn't refresh the whole page? Could it just remove the object from the list in memory and rerender that part of the page?

Or, what if the related record were optional? Worst case someone accidentally creates an action plan without one and the resulting tasks are created without a WhatId. Does that present challenges elsewhere that I haven't seen or thought about?

dschach commented 1 year ago

So I don't have good news. Validating that box is next to impossible, it seems. I'm going to have to put this on hold until I can rewrite this app in LWC. Very sorry - it's really hard to catch that error from the component and surface it to the page. I can't even find where the error is fired because it doesn't show up in the Apex logs! Odd!

In better news, a new release will be coming out next week!