[BUG] 4.2 PIN issues

[ChadJeffreyAnderson]

Make sure you're on the latest stable or beta build

• [x] I have tested this on the latest stable or beta release

Is this a bug in companion itself or a module?

• [x] I believe this to be a bug in companion and not a specific module

Is there an existing issue for this?

• [x] I have searched the existing issues

Describe the bug

I love the new PIN layout for emulators. It's very clean and intuitive. I'm encountering some inconsistent behavior, though:

• Upon navigating to a locked emulator, I am not presented with a number pad, instead only a grid of blank buttons, which renders the emulator completely inaccessible
  • I can get the number pad to show up if I change the emulator's current page, row/column count/offset, or rotation setting, but if I reload the page while it's locked, the number pad is gone again
• The "Never pin code lock" setting only works one way: once it has been enabled, disabling it does not allow a surface to lock either by timeout or action, until either a Companion restart or, in the case of Stream Decks, the surface is disconnected and reconnected
  • Enabling the setting on a locked emulator does not force it to unlock but instead breaks the number pad, though refreshing the page will load the emulator in an unlocked state.

Steps To Reproduce

1. Enable PIN Code locking and set a code
2. Add an emulator
3. Launch it and see that there is no number pad.

Expected Behavior

The emulator presents a number pad, allowing you to unlock it.

Environment (please complete the following information)

- OS: Windows 11 23H2
- Browser: Edge 143
- Companion Version: 4.2.0+8724-stable-982c8721a8

[Julusian]

The emulator pincode entry is fixed.

I have fixed what I can find with the rest, but am not confident I caught everything.

The "Never pin code lock" setting only works one way: once it has been enabled, disabling it does not allow a surface to lock either by timeout or action, until either a Companion restart or, in the case of Stream Decks, the surface is disconnected and reconnected

Oof, this is a rabbit hole.. It appears that 'never lock' feature is a bit flawed, and has been for years.. It is the group that gets locked/unlocked, but when forcing an individual surface member of a group to never lock then it falls out of sync with the group
I think this needs a larger rework to move this never_lock property to the group, maybe as well as the whole pincode entry status, but that might need to be 4.3 as it is going to be messy and risky.. (For context, every surface is in a group, often an automatic group if it hasnt been explicitly added to one. just to keep the code and structure consistent)

[ChadJeffreyAnderson]

Very well! The PIN code entry not appearing was the bigger issue, so thanks for solving it. The other part I just came across while trying to replicate that. It's not as though I'm regularly toggling that setting, so for the most part it's an invisible bug.

[dnmeid]

Oof, this is a rabbit hole.. It appears that 'never lock' feature is a bit flawed, and has been for years..

Maybe not at this place, but I think it is worth a discussion if we want to keep the pin code system like it is or replace it completely. Since years the pin code system is a source of bugs, problems and constant improvement requests. Also it is unnecessarily a topic for the button rendering and each individual surface type. I'd vote for a module or action/preset based solution, that would give users all the flexibility they want.