1. Scott Wells Avatar Scott Wells
  2. Illuminated Cloud
  3. IlluminatedCloud
  4. Issues

After OST generation, unmanaged field in managed object is completed with ns prefix

Issue #854 resolved
Alan Birchenough created an issue

Apologies if this has already been reported. It is hard to look through all the issues and make sure of that before posting.

In the OST, I have an unmanaged field called Job__c in a managed object called SCMC__Requisition. When the field name is auto-completed in the editor, it has an SCMC ns prefix that prevents it from compiling, i.e., req.SCMC__Job__c is generated instead of req.Job__c even though the field is unmanaged.

BTW, this is actually in 1.8.1.6-idea14, but there is no pick list value for that.

Comments (21)

  1. Alan Birchenough reporter

    Aarg the double underscores have gotten mangled by the markup processing. I am attempting to refer to an object whose ns prefix is SCMC. Let me know if anything is unclear.

  3. Scott Wells repo owner

    Alan, let me make sure I follow correct. You have a managed package installed in your org with namespace SCMC. You've added a custom field, Job__c to the packaged custom object SCMC__Requisition__c. You've regenerated your OST and, in the OST, your Job__c field is being rendered as SCMC__Job__c and is therefore completing in that manner incorrectly.

    I realize I'm pretty much repeating your original statement, but these types of issues can be tricky in terms of whether something is packaged or not vs. someone developing a managed package, etc., so it always helps to make sure I'm starting with the correct understanding.

    Also, in your OfflineSymbolTable.zip file, there should be a file named META-INF/PackagedCustomObjectFields.properties. Can you see if you see an entry like the following in that file?

    SCMC__REQUISITION__C.SCMC__JOB__C=true

    That would tell me whether IC has interpreted that field as a packaged custom field. Thanks!

  4. Alan Birchenough reporter

    That is nearly correct. In the OST the object is declared as "global class /SCMC__/Requisition__c extends SObject". This file is located inside the SCMC folder. The offending field, which is auto-completing incorrectly in the Apex editor, is declared as "global Id Job__c". When I place a dot after a variable of type SCMC__Requisition__c in the editor, and type J, then select Job__c from the auto-completion list, it is inserted as SCMC__Job__c, which is of course incorrect since it is an unmanaged field.

    I have also checked the entry in META-INF/PackagedCustomObjectFields.properties. It states SCMC__REQUISITION__C.JOB__C=false.

    Please let me know if you have any further questions.

  5. Scott Wells repo owner

    Okay, that helps. So the good news it that it's not fundamentally deciding it's a packaged field based on the properties file. Let me take a look at the insertion handler that takes care of adding the namespace if required and see why it might be doing this. I'll keep you posted and of course let you know if I need any further info from you as part of the diagnostic process. Thanks!

  6. Scott Wells repo owner

    Alan, I thought I might be able to debug this pretty easily since you sent over your OST for the other issue, but while I see SCMC__Requisition__c in the OST, it doesn't have a field named Job__c. Do you want to send over that file for including in your OST to facilitate debugging? No question this will go very quickly for me if I have access to the actual OST that's contributing to the issue. Thanks!

  8. Alan Birchenough reporter

    Now I think about it, that was intentional. These issues are in different orgs. I will get you the OST that goes with this one.

    On Sun, Jan 14, 2018 at 4:15 PM, Alan Birchenough < alan.birchenough@ic

  10. Scott Wells repo owner

    Thanks! I'll let you know if I need anything else from you to reproduce/address this.

  11. Scott Wells repo owner

    Easily reproduced with your OST. I'll debug a bit and will plan to include a fix in the next build. Thanks again!

  12. Scott Wells repo owner

    Aha! So it looks like you have two files called PackagedCustomObjectFields.properties in your OST, one in the root of the archive and one under META-INF. It's been a while since IC placed one in the root of the OST. Was this OST completely regenerated recently, or has it been incrementally updated by virtue of deploying .object files to the org? The other OST that you sent only has it under META-INF (even though it's missing a BUNCH of other stuff).

    I know we've already discussed this, but would you mind doing a full OST regen and seeing if you still see both copies of this file? While you're doing that, I'm going to do two things: 1) see if I can figure out how you'd end up with two copies; 2) make the code that retrieves it only consider the one under META-INF if more than one copy is found. The former is the fix (if it's a real problem), but the latter will make it work properly even if something unexpected happens.

  13. Scott Wells repo owner

    Okay, one more update. So I've implemented the second item above to make it defensive against this situation and it properly fixes the issue against the OST you've provided. I've also looked at how that properties file is created and it's always created under the META-INF directory, so my guess is that you'll see this problem go away by fully regenerating your OST. If you don't, please let me know.

  14. Alan Birchenough reporter

    I am now running the full regen and will let you know what happens. Thanks. To pick up the fix I assume I just go update my version of IC1.

  15. Scott Wells repo owner

    Yeah, let me know. Again, if you see two versions of that file after regen, please let me know. Otherwise I'll see if I can get a new build of IC1 out tomorrow with these fixes and you'll just update as normal. I'll let you know here when the new version is available.

  16. Alan Birchenough reporter

    Yes, this is now resolved. I don't know how I managed to keep vestiges of an old OST lying around but will try full regeneration if I run into this type of thing again in future.

    This can be closed. Thanks.

  17. Scott Wells repo owner

    Thanks for confirming, Alan. I'll plan to include the defensive handling for this in the next build anyway just in case anyone else might encounter the same issue, but glad to know that an OST update took care of it.

  18. Alan Birchenough reporter

    I am getting a recurrence of this in IC2. I have an unmanaged field called Training_Location__c on object pse__Project_Task__c. The Apex editor keeps auto-completing this as pse__Project_Task__c.pse__Training_Location__c. FWIW my current build is the last one you gave me for Issue 991. I am not sure what released version of IC2 that is closest to TBH.

  20. Alan Birchenough reporter

    I can confirm that the faulty behavior goes away when full OST generation is performed. Given all this and the previous history I guess you could mark this as resolved when you're ready.

  21. Scott Wells repo owner

    Sounds good, Alan. I'll resolve this now. Sounds like we're just waiting for your OST generation to fail in the other ticket so I can figure out which calls are the root cause. Overall, though, it seems like we have you in a much, much better state than ever before!

  22. Log in to comment
Assignee
Type
bug
Priority
minor
Status
resolved
Component
Apex Editor
Version
1.8.1.5
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!