[Isomorphic]

SmartClient 8.2p = SGWT 3.0p
SmartClient 8.3d = SGWT 3.1d

The issue with includeFrom fields not being exported is addressed in both of these versions and the fixes will appear in nightlies in those branches from tomorrow.

[ajmarrer]

I've just downloaded the nightly build and will try it. Thank you for following up on this issue.

[ajmarrer]

A few more things that I wanted to share.

The exporting of dynamically included fields worked as expected. So thanks for that!

However, there is still a difference between Dynamic Included fields and .ds.xml field includes, which may in fact be a bug.

Given a list grid, say using Field Includes, the fields are described as below

                <field name="ManifestId" type="sequence" primaryKey="true" hidden="true" />
		<field name="EmployeeId" type="integer" hidden="true" foreignKey="Employees.EmployeeId" />
		<field name="ProjectId" type="integer" hidden="true" foreignKey="Projects.ProjectId" />
		<field name="CompanyId" type="integer" hidden="true" foreignKey="Companies.CompanyId" />
                <field includeFrom="Employees.FirstName" />
		<field includeFrom="Employees.LastName" />
                <field name="EmbarkDate" title="Embark Date" type="date" />
		<field name="DisembarkDate" title="Disembark Date" type="date" />

If i were to set/edit the Embark/Debark date from the ListGrid, everything would show as expected and the respective fields would just be updated and displayed.

However, if I were to use the same ListGrid and instead of having the "FirstName" and "LastName" as Field Includes, if I were to switch those to Dynamic Includes. When I go and perform the same set/edit operation on either of the Embark/Debark fields from the ListGrid. Both of the dynamically included fields disappear from the ListGrid when the update to the Embark/Debark fields is processed.

Is this by design or is this a bug?

[Isomorphic]

By design, because a request from the client for fields from related DataSources is straightforward to check for security, but a save request on fields for related DataSources has a lot more nuances to it, and could open up security holes by bypassing DMIs, etc. But we may, in the future, add some additional declarations that would allow saving to dynamically included fields, with appropriate docs explaining security implications.