Welcome to the Alloy Ideas Portal đź‘‹ Here, you'll be able to browse improvement ideas raised by our community, vote on ideas you agree with or even raise your own ideas. We review all ideas raised and we endeavour to respond to all raised ideas.
Any ideas submitted will be immediately visible on the portal for others to vote on, please do not include anything in your ideas you do not wish to be shared with others.
I have a workflow which takes the values that have been set during an inspection and then copies them over the previous values that are currently held against a linked item.
The problem is that, in instances where a particular field in the inspection has been left blank, (indicting that there has been no change in status), the workflow would then copy the blank value over the existing value held against the asset, effectively wiping that value.
We have experimented in the workflow by using a filter to check first if the inspection value 'is set' and if true then proceed to edit the item, but because there are multiple values that could potentially be updated against the asset as part of the inspection, and as each value check / update process can't be contained within separate branches of the workflow (owing to the risk of an item signature mismatch), the solution is to create a single workflow branch that addresses each value in sequence and utilizes output nodes to return to the updated item in between each edit node, however this creates a single workflow branch that (at about the 45th node) returns a Bson Serialization Exception error as the 'maximum serialization depth is exceeded'.
We might be able to circumvent this issue by applying the tag 'RequiredOnTaskStatusCompleted' to the inspection, but then this would force the inspector to update every value held in the inspection task whether that value had changed or not. We would like to avoid this because some of these values can be time consuming and unnecessary to produce.
From discussions with Yotta support we thought a possible solution would be to have a tag which could be applied to an attribute on a task, which specified that a value from that attribute could only be utilised to overwrite a corresponding asset value if it was 'greater than zero / not null' so that attribute fields left empty on the task didn't wipe existing data on a linked asset via a workflow update.
Hi Tom, thanks for the idea, we're going to add it to our backlog for now as we have plans to implement some changes that would allow you to do this, but they're not planned for a while yet unfortunately. What you're describing for editing only when there is a value is possible through workflow computations but we understand that they're not the easiest thing to use at the moment. With increasing the BSON max serialization depth, I'm afraid it's a global limitation set by our DB which we're not able to increase.
In the meantime, do you think you could possibly provide a quick fix by increasing the 'BsonDefaults.MaxSerializationDepth' Property? I think by default this will be set to 100, but if you could increase the existing default by a factor of x2 or x4 it would enable me to overcome this issue in a single branch of a workflow.
The essence of this blocker is the difficulty experienced when attempting to edit multiple attributes within a single item via workflow. Consequently could I also please request that consideration is given to refactoring the holding of references in the database (the signature state) to the children/leaves and not the objects themselves? In other words log the signature on an attribute by attribute basis, rather on a per item basis?