boa_site_control.ini not being respected by new BOA changes?

[petrowsky]

I only use BOA for one single site and about a week ago I started getting emails for account approvals. This is an upgraded BOA, not newly installed, and I do not have disable_user_register_protection.info within ${User}/static/control/. I do, however, have a boa_site_control.ini file with disable_user_register_protection = TRUE.

After setting user_register to 1 it seems that daily or something else is setting it back to 2 on a daily basis. Is this is lite vs. pro change that is happening? This started when I was running BOA-5.1.0-head and I have since updated to BOA-5.2.0-lite. Both releases are reverting any change to Vistors to Visitors, but administrator approval is required. Tried looking at the commit history on daily.sh but can't find where the change may have happened.

Current mitigation is to force $conf['user_register'] = 1; in local.settings.php

[petrowsky]

Ok, it looks like it might be related to fa3ccd973938fe8e7d1168968e4ca8cd3b615603? Without having the new disable_user_register_protection.info file the former behavior of simply looking at the boa_site_control.ini is not enough given the &&? Yes, this is a D7 site. Looking forward to migrating to Backdrop along with Omega. ;)

[omega8cc]

It’s a bug. Should be hot-fixed today.

_{Sent with GitHawk}

[omega8cc]

Should be fixed now.

_{Sent with GitHawk}