We reported the issue as a bug to Support over a week ago, hopefully they'll provide a solution. If so, we'll share it here.
This does not seem to be true for address.full_address, which is setup the same way (but in baseline)<hierarchy_select return_only_requested_attrs="true"> <attrs> <attr>address.address_id</attr> <attr>address.full_address</attr> </attrs> <from> <table>address</table> </from> <where> <data_constraint> <constraint> <left_operand>address.address_id</left_operand> <operator>eq</operator> <right_operand>324</right_operand> </constraint> </data_constraint> </where></hierarchy_select>gives the full address.<address_hierarchy_select_result result_name=""> <address> <address_id>324</address_id> <full_address>Streetname 123Placename 2323 ABNL</full_address> </address></address_hierarchy_select_result>Also, regardless of the hierarchy_select, which
Did you ever manage to make the first of the calls from IFS FSM instead of from Postman?We did not succeed in doing just that, and our token expires every 24h, so we need some automation within FSM...https://community.ifs.com/ifs%2Dfield%2Dservice%2Dmanagement%2Dfsm%2Demployees%2Dpartners%2Donly%2D103/making%2Dan%2Darbitrary%2Doutgoing%2Dintegration%2Dcall%2D14337
Use mass_update instead of perform_batch: <mass_update_task_person> <hierarchy_select> <attrs> <attr>task_contact.task_id</attr> </attrs> <from> <table>task_contact</table> <table>task</table> </from> <where> <join_constraint> <constraint> <right_operand>task.task_id</right_operand> <operator>equi</operator> <left_operand>task_contact.task_id</left_operand> </constraint> </join_constraint> <data_constraint> <constraint> <left_operand>task.request_id</left_operand> <operator>eq</operator> <right_operand>@request_id</right_operand> </constraint> <constraint> <left_operand>task.task_status</left_operand> <operator>ne</operator> <right_operand>TECH COMPLETE</right_operand> </constraint&g
Apart from the limitations for the mobile client, the additional fields added this way are also not useable in sorting/ordering the list view of the primary table.
Using an extension table like this, it seems impossible in the Place list screen to order by one of the fields from the extension table. Is this correct? Can you only order by the UDF fields?
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.