Autocomplete fields on managed objects
Issue #123
resolved
Hi,
I was about to write about this for weeks but today I remembered as I stumbled into issue again. On some orgs we have some managed objects that are part of some external package that was developed before on some other org, but it is reused on others. Everything works nicely until I add some new custom fields. When I do so, and I use autocomplete IDEA or plugin autocompletes field name with package prefix which causes error and I have to manually edit field name (delete package prefix) all the time. It would be nice to have autocomplete detect which field were added later and which one are already part of package (I think their names are also without package prefix in salesforce, but I'm not 100% sure).
Also I have discovered some other issue with autocomplete. Sometimes it just stops working and only thing that helps is to save everything and restart IDEA, after that it usually start working again normally.
Comments (15)
-
repo owner
-
repo owner
- removed responsible
- removed version
-
Wanted to note that I've encountered the same issue with the autocompete prepending the namespace on unpackaged custom fields on a packaged managed object. It's not a critical issue for us, but it is aggravating; the majority of our field customizations are on managed objects.
-
repo owner
No, I can absolutely understand the annoyance. Some of these features I've added to IC were to make typing these things considerably easier, e.g., the auto-namespace prefixing, so when this type of thing does happen, it's contrary to that goal. I'll be making a pass on usability items like this after I knock out some of the features on the near-term list. I'll make sure to include this one.
-
I absolutely love the Run in Background functionality and a number of the other enhancements you've gotten out. Any chance enhancement can be moved up on the to-do list? It bites me regularly.
-
repo owner
Hi, June! Let me see where I can slot it in. I'm getting REALLY close on the offline debugger and want to get that out ASAP (hopefully in the next week or two). After that I really need to go deep on first-class Lightning support for a few weeks, but it's possible I can find a few hours to get this one knocked out in between the two. I'll let you know when I land on something more concrete.
-
repo owner
Issue
#322was marked as a duplicate of this issue. -
repo owner
Issue
#325was marked as a duplicate of this issue. -
repo owner
FYI, I'm now experiencing this exact pain on one of my own projects, so it pushes it up in priority considerably! I'll see if I can put together a fix in the next few days or else I'm going to go crazy myself!
-
repo owner
Okay, I have a fix for this that will be in the next version. It will require you to regenerate your OSTs, minimally the SObjects aspect.
-
Yesssss!
-
reporter
Nice one! Hope to get this soon, as I really have enough of deleting package prefix on all fields that are new...
-
repo owner
I'll post an update with it this morning, Matej. You've definitely waited long enough for this one! Sorry it's taken so long...
-
repo owner
- changed status to resolved
Delivered in 1.7.2.5.
-
repo owner
Oh, and just a reminder that you'll need to regenerate the OST, minimally the SObjects portion, for this to take effect.
- Log in to comment
Interesting. So basically unpackaged custom fields on custom objects are causing this issue. Makes total sense. Right now I haven't recorded anything in the OST that would allow me to differentiate between packaged and unpackaged custom fields, so I'll need to capture that information so that I can use it when adjusting completions for the namespace prefix. Let me finish up this current round of deployment/retrieval metadata enhancements and I'll take a look at it. Thanks for the report!