just to confirm teammates can no longer open doors boxes without entering the code first.. 

"Code Lock Settings": {
"Enabled": true,
"Share Door": true,
"Share Box": true,
"Share Other Locked Entities": true

is there any update to fix this problem ?

The only way i got it going is to change all the locks to the same number and lock them , then the other players unlock them with the code and they all open/close thereafter without having to enter any code, its not good if  you have chests/rooms set to certain players/admin but nothing to do but wait for a fix

there is a plugin for this to fix the codelocks

When will this be updated?

Sven

there is a plugin for this to fix the codelocks

themagicword

What is that ? Why don't you share the plugin's name ?

anyone find a plugin to correct this issue? having the same issue on my server.

Plugins which allow sharing code lock authorization have typically worked on-demand by hooking when the player attempts to open the door, in order to allow the action even when the player is not authorized to the lock. Previously, when aiming at a door for instance, even if the player was not explicitly added to the list of allowed steam IDs on that door's code lock, the player would be shown the "Open" prompt, rather than the "Unlock" prompt. That was vanilla Rust behavior. When pressing the +use key while the "Open" prompt was visible, the client would send a request to the server to open the door, even when the client knew the player wasn't authorized on the code lock. That allowed plugins like this to forcibly permit the action. The issue is, since this month's Rust update, the default prompt is now "Unlock". When the player presses their +use key while the "Unlock" prompt is visible, no request is sent to the server, until the player submits a pin. This is client side behavior, so plugins (which are server side) have no control over this.

As far as I know, players have a workaround already available to them. Instead of simply pressing the +use key on the door or box, players should hold the +use key to open the radial menu, then select the "Open" option. That will always send a request to the server to open the door, allowing plugins like this to detect the action and forcibly allow it. I haven't tested this specifically with this plugin, but it can be made to work if it's not already. This workaround should be recommended to players until a longer term solution can be implemented.

As for long term solutions,

• Facepunch could change or revert the behavior.
  • Facepunch could change the default prompt to be "Open" instead of "Unlock". This would be a complete 180, since showing the "Unlock" prompt was an intended usability improvement for vanilla servers.
  • Facepunch could reduce the area of the "Unlock" prompt to only be near the lock, instead of taking up the entire space of the door or box. That would allow players to simply aim at a different part of the door or box, in order to discover the "Open" prompt without using the radial menu. I think this is closer to how it used to work, since I've gotten reports for Vehicle Deployed Locks where people are now seeing the "Unlock" prompt for vehicles they are mounted to, at view angles that previously did not show any lock-related prompt.
• This plugin could be updated to detect when the player enters a pin, in order to forcibly allow them even when the pin is incorrect. That way, even if a player does open the pin prompt, they could just type any pin to get access. This would only be a partial mitigation, but it would probably be helpful if the ideal solution needs more time.
• This plugin could be updated to proactively synchronize the list of authorized players on code locks, instead of allowing access on-demand. The result would be that players with shared lock access would be shown the "Open" prompt by default, instead of the "Unlock" prompt. This would take some work, as the plugin would need to detect various events like team changes, clan changes, friends changes, and players connecting/disconnecting in order to update authorization lists. There are some alternate ways the plugin could decide when to update authorization lists, such as by adding triggers to all lockable objects to detect when players are nearby, but that would be more difficult to optimize in terms of performance impact.

If people run this plugin, the best way around it is to tell people to use key locks instead of code locks. That does seem to work 100%.

No fix yet for this issue? Love this plugin!

WhiteThunder

Plugins which allow sharing code lock authorization have typically worked on-demand by hooking when the player attempts to open the door, in order to allow the action even when the player is not authorized to the lock. Previously, when aiming at a door for instance, even if the player was not explicitly added to the list of allowed steam IDs on that door's code lock, the player would be shown the "Open" prompt, rather than the "Unlock" prompt. That was vanilla Rust behavior. When pressing the +use key while the "Open" prompt was visible, the client would send a request to the server to open the door, even when the client knew the player wasn't authorized on the code lock. That allowed plugins like this to forcibly permit the action. The issue is, since this month's Rust update, the default prompt is now "Unlock". When the player presses their +use key while the "Unlock" prompt is visible, no request is sent to the server, until the player submits a pin. This is client side behavior, so plugins (which are server side) have no control over this.

As far as I know, players have a workaround already available to them. Instead of simply pressing the +use key on the door or box, players should hold the +use key to open the radial menu, then select the "Open" option. That will always send a request to the server to open the door, allowing plugins like this to detect the action and forcibly allow it. I haven't tested this specifically with this plugin, but it can be made to work if it's not already. This workaround should be recommended to players until a longer term solution can be implemented.

As for long term solutions,

• Facepunch could change or revert the behavior.
  • Facepunch could change the default prompt to be "Open" instead of "Unlock". This would be a complete 180, since showing the "Unlock" prompt was an intended usability improvement for vanilla servers.
  • Facepunch could reduce the area of the "Unlock" prompt to only be near the lock, instead of taking up the entire space of the door or box. That would allow players to simply aim at a different part of the door or box, in order to discover the "Open" prompt without using the radial menu. I think this is closer to how it used to work, since I've gotten reports for Vehicle Deployed Locks where people are now seeing the "Unlock" prompt for vehicles they are mounted to, at view angles that previously did not show any lock-related prompt.
• This plugin could be updated to detect when the player enters a pin, in order to forcibly allow them even when the pin is incorrect. That way, even if a player does open the pin prompt, they could just type any pin to get access. This would only be a partial mitigation, but it would probably be helpful if the ideal solution needs more time.
• This plugin could be updated to proactively synchronize the list of authorized players on code locks, instead of allowing access on-demand. The result would be that players with shared lock access would be shown the "Open" prompt by default, instead of the "Unlock" prompt. This would take some work, as the plugin would need to detect various events like team changes, clan changes, friends changes, and players connecting/disconnecting in order to update authorization lists. There are some alternate ways the plugin could decide when to update authorization lists, such as by adding triggers to all lockable objects to detect when players are nearby, but that would be more difficult to optimize in terms of performance impact.

This does make sense. But also does not I think. I've been a server owner for about 14 months now. But have only dabled here and there in the plugin dev realm. From testing on my server. Auto Auth already does the last point you made about synching. Players who get invited to a clan will retro actively get TC auth as well as Code locks before the update. After the update. It does the same for TC but now, does not auto auth on the code lock. When a player leaves or get kicked from the clan. The plugin again. retro actively removes there auth from the TC. So some form of Synching does happen. I'm still not understanding why it's not possible to have players auto auth on Codes locks and bypass the first step from "Unlcoking" the door. from my eyes. All it looks like is that facepunch added a step process and we can just confirm that added step automatically. Just looking to learn. Thanks.

So will this plugin be updated or will everyone now need to use key locks from now on?

So I spent about 2 hours with a dev testing out options and it looks like no matter what we did. It was still broken. We did get the doors to work without that UI popping up. But then we couldn't unlock the codelock as if we were trying to change the code. The other issue was that as soon as a TC was placed. Whether playters had TC auth or not. The Doors stopped working again. We did some Janky stuff. At this point. Unless there are some other creative thinkers. There is no way to patch this. I'll be moving my server over to Keylocks now anyone have contacts for Chaos code/Killyou so he can add Keylocks to his autocodelock plugin?

Is this fixed by facepunch? 😅

it's not Arainrr if you can update would be insane ^^
update you just did would have fixed it