Hi @Brett Saviano !

I double checked the export format - the format is the same now and is supported both in IPM and VSCode ObjectScript.

The only issue left is file naming: Atelier REST API exports DFI file names with dFI extension as:

Potatos-AnnualPotatos.dashboard.DFI

at the same time IPM can consume DFI resources if they are presented as XML (tested in 0.10.4), e.g.:

Potatos/AnnualPotatos.dashboard.xml

Inviting @Pravin Barton also, maybe there are plans to do something with this in the future. 

And it exports files with "-" as a folder delimeter. Imagine if you have 100+pivots and dashboards in folders - in the code repository, they all will be in one folder with 100+ files with "-" as delimiters. Doesn't sound like a convenient approach. 

It's like ObjectScript code files will be named as:

/src/package-subpackage-class.cls

and all reside in one folder, instead of being distributed in packages as folders, as it is working now:

src/package/subpackage/class.cls

@Brett Saviano - hope we could fix this too in the future.
 

And here is an example of "proper" using DFI resources - OEX module, Github.

There is one dashboard and two pivots here:

 <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-AnnualPotatos.dashboard.DFI" />
      <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-Totals.pivot.DFI" />
      <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-Yearly.pivot.DFI" />

Git-source-control "supports" editing in the UI and exporting to files, but it is quite "buggy" - I hope @Timothy Leavitt and Co will introduce 100% support of DFI someday. Today I prefer to use "isc-dev" and export all the DFI from the namespace into the dev folder to commit changes to the individual DFI files.

But still, the question for the iPM/ObjectScript VSCode team is why the Other section (server-side viewer in VSCode ObjectScript) exports DFI in a different format, which cannot be imported later with the system import method, and thus is not being imported by IPM. Maybe @Brett Saviano can comment here:

Also, why is the naming of resources so complex (you need to use "-" as the folder delimiter and follow this in folder structures.

But it works somehow.
 

You may ask: how to export the file?

There is a special "helper" package "isc dev", once installed via:

zpm "install isc-dev"

and set up then as:

do ##class(dev.code).workdir("/home/irisowner/dev/src")

it will allow at any moment to export all the DFI at once into your dev folder with the command:

d ##class(dev.code).export("*.DFI")

Hi Ashok!

Yes, you can use IPM to support DFI files.

"Lazy", aka "dirty" way - introduce the following resource:

<Resource Name="*.DFI" />

like here, which will package everything you have in a src/dfi folder. Convenient but not optimal and can introduce problems while working with more than one IRIS BI packages.

in this case resource will import all the 100+ DFIs (pivots, dashboards) into IRIS (via load command) and package/publish then:

Don't ask me, why DFI is an XML in fact.

Neat! Thank you, looks easy and practical! Thank you for sharing!

What a milestone! Thanks, everyone, for these remarkable 10 years together!

Thank you for introducing, @José Pereira ! Will take a look!

Thahks @Timothy Leavitt ! Looks better with an example, of course. Hope you'll have some time for it in the future.

Ideally, if you share the code sample somewhere so devs can reproduce and see what's really going on

Perhaps there are no rows that satisfy the dimension conditions?

Or maybe there are build constraints? (1000 rows?)

Also take a look $CASE - in some cases can be less wordy and more effective.

Thanks @John Murray ! It's a good idea. I'm not sure if the Ideas portal allows such functionality, as it turned out that we are not the first enterprise to consider bug reporting functionality via a private channel of communication, but it makes sense to me.

Public exposure of critical bugs is not the best way to support the community. On the contrary, it could be a serious threat to thousands of working and important services. 

Yes. You find a bug and report it privately to InterSystems, avoiding public exposure. 

I wouldn't name this new service to report bugs as "philosophy" as it is a newly introduced service for developers who encounter bugs. We'll see how it works, and maybe after some time, we can assess if it can be a "philosophy" or a reasonable approach. Let's see.

Hi @Dmitry Maslennikov ! Thanks for highlighting that! The point is that bugs can be dangerous, so we have the privilege to know it in advance and address and take care of InterSystems customers. 

We introduced this service to have a legitimate way to report bugs found by developers while developing with InterSystems products.

My bad. It looks like %source lets to refer to properties only, not methods.

you can go for:

$property(%source.%PackageName()_"."_%source.%ClassName(),"client_name")