[Bug]: New LDAP-users don't get notifications even if the app settings force this

Bug Summary

user.notifications_enabled is 0 when a new LDAP-user automatically is created by the app

Description

When LDAP is configured and users login the first time, an entry in the users table is created. Since 1.2.46 a setting "feat: add new option to enable notifications by default for new users" was introduced, which btw. should be activated by default as using Kanboard without getting notifications doesn't make sense.

Now the problem: If the mentioned option "add new option to enable notifications by default for new users" in the app settings is enabled, users nevertheless get a 0 value in the DB field user.notifications_enabled. This means that they don't get notifications at all.

Notice: This is only true on auto creating of the user via LDAP. If a user is created from the backend, no matter if local or remote user, then user.notifications_enabled has the correct value of 1.

Stumbled over this just lately when we noticed that users don't get notifications at all even if web and/or email notification are enabled in their user settings.

Btw. I wonder why this DB-field is necessary at all. The web/email settings of each user should cover if a user gets notifications. Would reduce some complexity and avoid potential errors like this without the field!?

Steps to Reproduce

• Configure LDAP in the config.php. Make sure LDAP_USER_CREATION is true.
• Enable the option "add new option to enable notifications by default for new users" in the app settings
• Let a user login for the first time f.e. with his Windows login so that the user is created in the DB
• See that user.notifications_enabled = 0

Expected Behavior

user.notifications_enabled = 1

Actual Behavior

user.notifications_enabled = 0

Version

1.2.53

Database

MySQL

PHP Version

8.2

Browser

All

Operating System

Windows 11

Relevant Logs or Error Output

Additional Context

No response

Checklist

• I have searched existing issues to ensure this bug hasn't been reported before.
• I verified that the problem is not caused by a plugin. Please report the issue to the plugin author if applicable.