Ok, this feels so stupid that I have to ask if I am stupid or if this is really the best solution for this scenario.
I have a simple automation that just updates fields in a work item if an asset is updated. Super simple, but I need something to compare to know what work items to update. I can use an attribute in assets or a number field for example in Jira, but they can both be changed and break the automation.
The logical solution is of course to use a read-only text field that you populate the Asset ID with an automation. Easy to set up, but you can't use that in any way that I can think of to compare against the asset ID value.
The reason: You are not allowed to use the = operator for read-only text fields...
So I can't directly query using something like AssetID = "{{object.id}}" and I can't replace the AssetID field in any way with variables or smart values.
So I have to use a regular number field and set up a specific automation that prevent any editing of the value. So I end up with a read only field and a number field and a stupid automation that change the number field with the values from the read only field when it is edited....
I mean, seriously, this can not be the way to actually create a secure connection with data that users can't edit in the UI?
What am I missing?
@Mikael Sandberg and @Bill Sheboy have a valid point.
If you still want to use a read only field, there should be an option to compare.
You would need to store the key of the asset in a variable and then you should be able to compare the variable value with the value in the read-only text field
The comparison could be done with text smart values.
Feel free to show me an example. You have the automation below, so if you have a solution where I can assign a variable for the triggering asset, then I will owe you big time :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am sorry, I should provide a bit more context so you know what help is required :)
I am building a simple automation just to update a work item when an asset is updated.
As you can see, it is very simple, and I just filter out the work items by comparing a value in the work item with the object id of the object that is being updated.
I can use an attribute in assets or a number field in the work item, for example, but both can be tampered with and that would break this connection.
So to be sure that the value I sue for comparing can't be altered, I wanted to use the object id since that can't be changed in the UI and a read only field for the same reason.
But, I can't use that because a read only field does not allow a = operator...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @__ Jimi Wikman
I haven't tried to recreate this scenario, but I have a few questions based on what you wrote.
Can you provide more context around this?
So I can't directly query using something like AssetID = "{{object.id}}" and I can't replace the AssetID field in any way with variables or smart values.
In what type of automation step are you trying to use that? Is AssetID the text read-only field in the Jira issue? What error do you get when you use "="? Is your rule not successful if you use the CONTAINS operator (~) ?
How is the field intended to be set within the Jira issue?
You said you don't want users to edit it. But is it supposed to be editable by Automation?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the additional information @__ Jimi Wikman
What error do you get when you use "="?
Is your rule not successful if you use the CONTAINS operator (~) instead?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The operator '=' is not supported by the 'custom field name' field.
The operator ~ will not work because it will fetch anything that matches and since this is a number field it will fetch things that should not be fetched (32, 321, 3223, 3211223...)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the additional information.
How does the AssetId field get set in the Jira issue?
Who should be permitted to set/edit that field (including Automation Rules and "service" accounts)?
Who should be able to see the contents of that field?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you only need to use the field to store the object key or is the field used for some sort of reporting too? If the answer is no then you could consider using entity property to store the key instead. Entity properties can only be accessed via automation or REST API.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FYI -- With automation rules, entity properties may also be accessed with the relevant smart value's object properties or rule actions.
For example:
{{issue.properties.myWorkItemProperty}}
{{issue.assignee.properties.mySlackId}}
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Bill Sheboy! Yes, that is what I was trying to say, but I now see that my answer missed the mark. What I was trying to say is that entity properties can only be accessed in automations via smart values or via the API and can be used to store values that should not be visible to a user.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you can show me how you get the object id of the triggering asset in this automation and how you compare that to the read only field if the related work items, I would owe you big time :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.