Hi @Maximiliano.tx,
Thanks for the update back in April. Since the April/May window has now passed, I wanted to check in on the status of this fix.
Did it make it into a recent sprint, and is there an updated estimate for when we can expect it?
Thanks,
Wouter
Hi @woonk
there was some progress on this, but unfortunately not quite ready yet. Apologies for the delay.
It seems that on the cloud-side we can get merged and have it deployed relatively soon, there is still work to do on the device side. Let me apply some pressure to the dev-team, and see if I can get a clear deadline.
thanks for the patience! I will get back to you as soon as possible
Circling back on this. In your June reply you said the cloud-side could be merged and deployed soon, with work still to do on the device side, and that you’d apply some pressure to get a clear deadline.
Has the cloud-side been deployed in the meantime, and did the dev team manage to commit to a date for the device-side fix?
Wouter
Hi @woonk ,
yes, apologies for the delay, this is definitely not the impression we want to make.
I did raised this several times internally, and it got prioritized.
on 15 June the change was merged in PILOT on the Cloud-side.
On 24 June the OS team raised some valid UX concerns when reviewing the solution. After some internal discussions, the PR return to the Torizon team to review and propose some alternatives.
Trust me, we are taking this seriously, I am trying to be as transparent as possible here, I am checking week by week the progress. Maybe I should have communicated about this setbacks before. We are certainly working on this.
As long as this ticket is with me I will do my best to push the teams to work on it. Bear with me a bit and we will get a solution sooner than later
thank you for your understanding
I will keep you informed
best regards
hello @woonk
The PR has finally been merged by R&D. The change should be available in the next nightly Torizon OS image.
In summary, now when a device is awaiting consent for an update you can cancel the update on the server-side without waiting for consent to be given/denied on the device-side. After cancelling you can then issue another update from the server. This should satisfy your use-case.
Also, I am editing my original comment since, as I just learned, there is one point to be considered:
the consent API now requires you to read the correlationId of the update you’re presenting to the user, and then pass that back when you grant consent. This change is documented as a breaking change in the dbus API. This will require a change on your code.
Once again, thank you for your patience, we faced some setbacks on the implementation which delayed the estimated delivery
Let me know if you have questions
best regards
