- edited description
Knowledge article version sObject not being indexed for code completion
Illuminated Cloud: 2.2.0.5
WebStorm: 2021.3.2
I have an odd situation where some Knowledge article sObjects are being inserted into the OST, but are not indexed for code completion.
I’ve attempted to rebuild the cache (Illuminated Cloud > Configure Project > Rebuild Caches and Indices), rebuild the entire OST (Illuminated Cloud > Generate Offline Symbol Table > Full), and started a new project. All end up with the sObject not resolving.
I have also tried this against multiple environments with the same result.
There were no errors in the log, but I couldn’t find any debug log settings for indexing, just OST generation (which appears fine).
Any ideas?
Comments (15)
-
reporter -
repo owner Michael, can you please try to use File>Invalidate Caches to rebuild all IDE caches and indices and let me know if that doesn't work?
-
reporter Hi Scott,
Yeah, same thing happens.
The odd thing is that not all Knowledge Article objects are affected, but the ones that don’t work are all Knowledge Article objects.
Thanks,
Michael -
repo owner Any chance you can either send me that generated OST or, even better, an entire skeletal project against that OST with a sample Apex class that reproduces the issue? Understood if not, but that would be the fastest path to figuring out what's going on. You're welcome to email it to me vs. attaching it here if you'd prefer.
-
reporter I would like to avoid having to send the entire OST. Is there another option to troubleshoot?
-
repo owner Along those lines, if you could create a new generally empty project that includes a KAV that exhibits the same behavior. That would ensure you're not having to send any proprietary info but would provide a reproduction of the issue.
-
reporter How do I provide you with a project that does not have a full OST generated?
-
repo owner There are two ways you can go here:
- You can create a brand new project against a clean scratch org, create simple Knowledge Article/Version objects in that org, and create a simple Apex class that references those where the references don't resolve. In this option, you can provide the entire project including the OST because it will have been against a clean scratch org.
- You can do all of this against your existing project but then just cherry pick what you add to an archive to provide me. I'd primarily just need to the
ka
andkav
files and the Apex class that references them but not the OST because I'd just deploy those against a scratch org, generate my own OST, and try to reproduce this behavior.
Make sense? Let me know if not.
-
reporter Thanks Scott.
I was able to reproduce on a scratch org, and have sent you the project over email.
-
repo owner Thanks, Michael. Easily reproduced with the provided project. I'm pretty sure it has to do with the base names
Process
andSupport
which are also namespaces, and I'm thinking IC2 is interpretingProcess__kav
as typekav
in theProcess
namespace (and similar withSupport
). Should be easy enough for IC2 to filter the known extensions of various SObject types when doing that analysis. I'll put a fix together and include it in next week's build. -
reporter Thanks Scott!
-
repo owner Yep, it was exactly what I thought. About to commit the fix:
I'm really surprised this is the first time this one has come up over the years. I have to assume that others have named some kind of custom object with the same base name as a namespace and just didn't report it. Anyway, the fix will be in next week's build.
-
repo owner Ah, I see. IC2 was already taking this situation into account, but it wasn't including the
__ka
and__kav
extensions (also__b
). I just changed my fix to include those extensions and the world is a happy place without having to change any real existing logic...just the set of known custom object extensions. That explains why I hadn't heard about this until now. -
reporter Yeah that makes more sense, because we do have some objects would have already conflicted with other namespaces, and they were not an issue.
Glad it was an easy fix!
Thanks again Scott.
-
repo owner - changed status to resolved
Delivered in 2.2.0.6.
- Log in to comment