Hi,
When trying to pass this code through an on click action on a custom component, it always return true on the if-condition, even though it’s not true. The string that is returned decides which part of the action that is run. Tried detaching the component, and then it works as expected on the exact same data.
Please let me know if this is a problem that potentially affects all custom components, because then we might have a problem.
Hi Geir,
I have tried to reproduce your scenario without luck.
My set up is as follows:
Test 1 Boolean? → should return false
Test 2 Boolean? → should return true
Test 1 String → should return “Cancel ag edit”
Test 2 String → should return “Open Confirmation dialog”
As you can see, when I run this action, I get the correct result:
Would it be possible to get access to the application so I can take a closer look at the setup in your solution (my email is ulrik@appfarm.io)? If this is not possible, could you please provide me with more details on how you’ve set it up?
I have changed to logic of the function a bit now, but still encountering the same issue where the exact same code is returning different results on the same data – custom component vs “normal” (detached) component.
New code:
The data sources used:
v5TEMPAgMembers = All objects (runtime datasource where data is read into the source when selecting a access group)
v5TEMPAgFoldersNEW = All objects (runtime datasource where data is read into the source when selecting a access group)
v5TEMPAGItems = (also runtime datasource where data is read into it) Filtered selection: “Should be persisted?” is a runtime property on the data source.
allAccessGroupMembersInDR = (database connected) Filtered selection based on selected group.
My two best guesses is that the problem might have something to do with custom components not being able to properly use runtime properties on runtime sources? Or, as i can see from your attempt on recreating the issue, your code does not account for any AND or OR operators in the if condition.
Hopefully this information is sufficient 
Hi again,
Thank you for the information. I have tried to recreate the problem, but I am still not able to recreate it.
The best way to verify if the filtering works in the custom component is to use console.log to check both the objects and the lengths of the arrays.
If possible, we could set up a Google Meet session where you can walk me through the logic. I believe this would be more efficient. If that’s not possible, I recommend using console.log to check the lengths of the arrays to confirm whether the correct number of objects are being filtered.
Findings from further investigation:
Console log for custom component:
Console log for detached component:
Data sources:
What i am getting out of this, is that the custom component is not reacting properly to the filters on V5 TEMP AG items:
I have been able to reproduce the bug! It seems as you hypothesized, that the custom component is not evaluating the filters correctly.
A challenge is registered for this subject and the Devs team are looking at a fix!
I will let you know when the a fix is expected, sorry for the inconvenience this has caused.
Any updates on this? And do you know if this is something thats been broken from the start of when custom components was introduced, or if it came with the newest update? Would be nice to know in regards to deploying the new version to production.
Hi, the Devs team have investigated the problem and it seems like it has been a prevalent bug for some time. They tested in Create version 118 and it was a prevalent bug here as well.
This most likely means, that the bug has been prevalent since the introduction of custom components.
Again, any updates on this? I now have another case where i try to pass a integer through a action param on custom component, and it seems to always return “3” or less no matter how big the number is supposed to be.
This in turn makes me spend several hours trying to figure out how and why the action is not doing what it’s supposed to, only to detach the custom component in the end to reveal that the same exact action (only detached) returns the correct results. Do you know of these bugs, and if so is it possible to notify us users about them before spending hours to debug something thats not supposed to be debugged?
Hi. We are looking into this, but I don’t currently have a timeline for when this will be fixed. We apologize for the inconvenience this bug is causing.
We were not aware of the integer issue you reported here, and I was not able to reproduce it in our dev environment. Could you please provide more details about your setup, so we can hopefully reproduce and fix this issue? Either here or in a DM.
Should have provided more information, sorry about that. A bit to late in the evening to run into bugs… I guess the issue is the same as before with filters not being evaluated correctly. It was just that the filter this time around was a lot simpler than before and it made me believe that this was a different case.
This is the filter in question now. Based on this it should return a integer from a runtime property on “Folder items…”. It returned a an integer, but it always return 3 or less meaning that for all cases where the int should have been 3+ it would just return 3 anyways.
Hopefully this can help pinpoint the issue.
Hi! A fix for filter evaluation in Shareable Components is scheduled for our release at the end of October/beginning of November. Please note that this information is subject to change.
