Timeline for How to get full name for installed package just knowing its namespace prefix?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 29, 2015 at 18:09 | comment | added | wesaw | Yep, you are right about classes from managed packages, the source code is hidden anyway. The main idea of my quest is to build kinda usage statistics, i.e. for each field identify list of formulas, layouts, workflows where it's used. That's why retrieving all packages at once through MDAPI in the form of xml files is very convenient for me. No need to make couple calls for each field or package, and it's relatively easy then to gather all necessary info from retrieved bunch of xmls. Tooling API approach doesn't look quite good due to huge amount of info to be fetched individually & analyzed. | |
| Jan 29, 2015 at 17:03 | comment | added | Jason Lantz | I totally understand the desire to avoid web scraping. I don't like using Selenium in our use case, but it does work pretty reliably for us. However, I think you can get at what you want through the Tooling API as noted in the answer. It would just require some scripting. You wouldn't get the same thing as you'd get from the MDAPI, but you can't get the contents of classes from managed packages anyhow. | |
| Jan 29, 2015 at 16:47 | comment | added | wesaw | Thanks, Jason. I was trying to avoid 'web scraping', but looks like it's the only way to go for me. It's really strange that SF guys don't provide access to package name, but still require it as parameter for metadata retrieve call. It would be smart to extend metadata api with retrieve by namespace method for packages. Eh, it's just my dreams) Some SF glitches make me really nervous) | |
| Jan 29, 2015 at 15:58 | history | answered | Jason Lantz | CC BY-SA 3.0 |