Repository navigation
Conversation
|
Invitation URL: |
|
zwave-lock_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against e1f498a |
Test Results 73 files 546 suites 0s ⏱️ Results for commit e1f498a. ♻️ This comment has been updated with latest results. |
| local associated_credentials = tables.find_all_entries_by(device, "credentials", "userIndex", command.args.userIndex) | ||
| for _, associated_credential in ipairs(associated_credentials) do | ||
| if lock_utils.is_master_credential(device, associated_credential.credentialIndex) then | ||
| -- this user holds the master code, which cannot be removed |
There was a problem hiding this comment.
I've been thinking- maybe we should allow this to occur, and just let it fail on the device? Perhaps we shouldn't be the arbiter here.
There was a problem hiding this comment.
Good point! "Letting the device device" actually better matches the legacy behavior to begin with, so I agree with moving forward with this approach.
However, one thing I did add was a read to check whether the delete was successful. This follows legacy behavior as well, and also allows us to still send the COMMAND_RESULT.INVALID_COMMAND when the the delete fails. This way a failed attempt to delete the master code is still sent back to client for an UI that may be associated with it.
Make these changes here! e1f498a
The slot 0 / numeric ordering migration test is now covered by the upstream tests added in #3313. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Remove the driver-side block on deleting the Yale master code. As in the legacy lockCodes deleteCode, an unconfirmed delete is read back with a User Code Get after 4.2 seconds, and a slot that is still occupied is reported as a failure instead of leaving the command to time out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6d08930 to
e1f498a
Compare
Check all that apply
Type of Change
Checklist
Description of Change
Summary of Completed Tests