You can’t do this declaratively. You could write javascript to create models but that would be a very long rabbit hole IMHO.

So what should one ideally do in such scenario? Is it possible to add single field i.e currencyIsoCode based on org multi-currency-setup?

You might be able to include the field by default and use javascript to remove them for non multi currency Orgs.

Thanks, but could you provide a little insight on how could I remove it using javascript.

My understanding is we have to run it on page load and perform required operation on every model. Also is there any other way apart from javascript remoting to verify whether org is multi-currency enabled or not within the script. Thanks for your help. This can save a lot of extra hours for redundant development for multi-currency and non-multi-currency org’s.

Ashish,

First of all, in Multi-currency Orgs, Skuid automatically queries for the CurrencyIsoCode field on all Models where a Field whose Display Type is CURRENCY is included. This is done across relationship fields as well.

For example, if you were had a Model on the Opportunity object and requested the Amount field, Skuid would automatically query for the CurrencyIsoCode field because Amount, a Currency field, was requested.

The nice thing about this for your scenario is that you can rely on Skuid querying for this field, so you don’t have to.

However, this does not necessarily help you if you are trying to add the CurrencyIsoCode field to the UI so that users can modify it, as Skuid does not currently pull down the field metadata for the CurrencyIsoCode field automatically. 

Here’s my recommended approach:

1. Include the CurrencyIsoCode in the Model, and in any UI Components as appropriate.
2. At runtime, for users in non-multi-currency orgs, Skuid will automatically, gracefully strip out the CurrencyIsoCode field from any Models that request it, as well as from UI Components, e.g. Tables, where the field is referenced. The red error message (a “Page Problem” in Skuid terminology) that you are seeing will NOT appear for normal Users — this message only appears to Users that have the ability to edit Skuid Pages. So as long as your customers have their Skuid Permissions correctly setup so that they do NOT have the ability to edit Skuid Pages, they will not see this error message.

On the Skuid side, we’ll talk this over, but to me right now it seems like we should just hide the red error message automatically for users in non-multi-currency enabled orgs. We could be smarter about the error and say “The field being requested is CurrencyIsoCode, but this is not a Multicurrency org. Don’t display the error message we usually would, just strip the field from the Model at query-time like we already do, and move on”.

Zach,

That was really helpful. I have a query regarding the explanation.
1. If we have referenced currencyIsoCode in javascript code, for instance under updateRow() skuid API , will it break JS in non-multi-currency org’s. My initial thought is it will. In that case is there a workaround to do in JS to conditionally check for org multi-currency enabled setup?

Multi-currency enablement can be easily checked in JavaScript like this:

var isMulticurrency = skuid.utils.isMultiCurrencyOrganization;<br>if (isMulticurrency) {<br>&nbsp; &nbsp;// Multi-currency org<br>} else {<br>&nbsp; &nbsp;// &nbsp;Single-currency org<br>}

Thanks a lot Zach. This is really great. One last query , What if we don’t want those error message from skuid about no currencyIsoCode found in the object to display, This can be done if we can remove the currencyIsoCode from the model if it’s not a multi-currency org. How can we remove a field from the model (conditionally) before page loads and remove all reference to currencyIsoCode from models? Really appreciate your help.Almost done Zach :) 

Ashish, regarding the error messages, one hacky way to achieve this would be to add a CSS rule to the page that prevents the page problems container element from ever displaying — I don’t recommend this but if you’re desperate, you could do this.

There’s no good way to intercept a declaratively-defined Model and adjust its XML before it gets queried on initial page load. Your only real alternative would be to dynamically generate the Models with JavaScript, and then query them. 

The Hacky way will prevent any error message from getting displayed. That will not be a good trade-off. Thanks a lot for your time. This was helpful.