phpBB 3.3.13-RC1 released

[Marc]

Release highlights

• Notable Improvements
  • Delete Users by ID via console: PHPBB-17347
  • Gravatar Avatar URL Update: PHPBB-17355
  • Enhanced PM Recipient Removal: PHPBB-17317
  • Better Error Handling in PHP 8: PHPBB-17356
• Notable Bugfixes
  • User lastvisit update frequency: PHPBB-17375
  • Rehashing of phpBB2 passwords via cron after upgrade: PHPBB-17351
  • reCAPTCHA issues with registration errors: PHPBB-17366

The packages can be downloaded from our package archive or the Area51 downloads page. Please test the packages to extent, so we can have a fail-safe final release.

• https://gist.github.com/marc1706/ffce9d ... d2ad7584e3 Language changes
• https://gist.github.com/marc1706/5bc566 ... 9692c88f93 Prosilver changes

[Marc]

Event changes

PHP Events

• None

Template Events

• ucp_group_settings_after
  Prosilver Placement: ucp_groups_manage.html
  Added in Release: 3.3.13-RC1
  Explanation: Add content after options for managing a group in the UCP

• ucp_group_settings_before
  Prosilver Placement: ucp_groups_manage.html
  Added in Release: 3.3.13-RC1
  Explanation: Add content before options for managing a group in the UCP

ACP Template Events

• acp_groups_add_user_options_after
  Placement: acp_groups.html
  Added in Release: 3.3.13-RC1
  Explanation: Add content after options for adding user to group in the ACP

• acp_groups_add_user_options_before
  Placement: acp_groups.html
  Added in Release: 3.3.13-RC1
  Explanation: Add content before options for adding user to group in the ACP

• acp_groups_add_user_usernames_before
  Placement: acp_groups.html
  Added in Release: 3.3.13-RC1
  Explanation: Add content before usernames option for adding user to group in the ACP

[Crizzo]

Did install smooth and without probs

[Fred Rimbert]

Installation done on my test board, without any problem

[Scanialady]

Update 3.3.12 -> 3.3.13-RC1 without problems on my test board.

An anomaly since phpBB 3.3.12:

ACP - Permissions - Permission Masks: View user-based permissions
Select a user with permission allowed for any setting, for example "Can change password" and click "View permissions" - than click "Profile" Tab there.

You see can change password is yes and green.

Click on the Trace Setting link there. The window "Trace for: Testuser / Can change password " opens. You see the result

"Trace result Never"

If this behavior is intentional, I don't understand the background. My Testuser has permission "Can change password" allowed in both groups, NRU and RU

[danieltj]

Click on the Trace Setting link there. The window "Trace for: Testuser / Can change password " opens. You see the result

"Trace result Never"

If this behavior is intentional, I don't understand the background. My Testuser has permission "Can change password" allowed in both groups, NRU and RU

I've been developing an extension and had an issue recently where the permission tracer was acting weirdly. I think (and I need to do more testing) that the permissions might be corrupted in some way so it's returning an incorrect result due to (maybe) a bad database migration.

I'm going to hazard a guess and say it's definitely not intentional but I'm stumped as to how it happens.

[Scanialady]

Thank you for your statement.
It already felt like no one else had noticed. Although I know for a fact that there are at least two other people who know about the problem.

[P_I]

Full package update done on my test board, without any problems detected.

Server is running Ubuntu 24.04 with PHP 8.3.6 and MySQL(i) 10.11.8-MariaDB-0ubuntu0.24.04.1

[warmweer]

Update 3.3.12 -> 3.3.13-RC1 without problems on my test board.

An anomaly since phpBB 3.3.12:

ACP - Permissions - Permission Masks: View user-based permissions
Select a user with permission allowed for any setting, for example "Can change password" and click "View permissions" - than click "Profile" Tab there.

You see can change password is yes and green.

Click on the Trace Setting link there. The window "Trace for: Testuser / Can change password " opens. You see the result

"Trace result Never"

If this behavior is intentional, I don't understand the background. My Testuser has permission "Can change password" allowed in both groups, NRU and RU

Strange.
I just read this and tested this on a 3.3.12 testing board (permissions set as in the printscreen - permission mask was correct), updated to 3.3.13 RC1 and checked permissions: all OK, permissions trace also all OK.

[Scanialady]

Strange.
I just read this and tested this on a 3.3.12 testing board (permissions set as in the printscreen - permission mask was correct), updated to 3.3.13 RC1 and checked permissions: all OK, permissions trace also all OK.

Did you try this with a normal user, an newly registered or an admin account? I tested it again on another testboard with a newly registered user - the same.