Person with correct Skill unable to tap into Textiles

[jschrempp]

We found that a person with a lot of skills will cause the response from amiliaGetPackagesByClientID to split the response into multiple packages back to the device. Our code in ezfReceivePackagesByClientID does not correctly handle a multipart response.

This was not a problem in the past because we didn't have that many packages. With Amilia we have expanded the number of packages - and the length of their names - and so now we have to deal with this.

It should be noted that if the packages arrive at the device in correct order, then it is handled correctly. However these are UDP packages and order is not guaranteed.

[jschrempp]

In testing we found that the person in question had 40 different skills out of a total (currently) of 48. Our mustache filter in the getPackagesByClientID only takes the first 16 Skills (we have to do this manually because the Particle implementation of mustache filtering does not support the automatic iteration over an array).

We found that the Skills list from Amilia is not ordered. In our testing it was always the same, but we know that it is different from one transaction we captured a week earlier.

So, if the Skill needed for entry was provided within the first 16 Skills returned from Amilia, then the person would have been granted entry.

I still believe the firmware does not correctly handle out of order messages from the cloud, but that is just another problem in this area. We are considering other solutions.

As a temporary measure we have set the woodshop and textiles devices to NOT require any specific Skill for entry.

[jschrempp]

We think the long term solution to this is to move the package decision making from the firmware and into the cloud. We envision the local station calling a Particle Webhook, as today. But instead of the web hook calling the CRM system it will call an endpoint on our FDB system. That endpoint will query the CRM, it's own FDB, and do the work of determining access rights for the person and station in question. Instead of returning a bunch of data to the station firmware, the FDB endpoint will return a yes/no answer.