Development Discussion Board

I don't know if this is a bug in 3.2.10-RC2 or a problem just with phpbb.com, but wildcard searches aren't working as expected.

Search in topic titles only, display results as topics, search for authenticat* . I would expect many topics in the results with authentication in their title, but I get 0 ...

This looks like by design to me. The auth instance you get from the container always belongs to the user of the current request. The notification methods simply weren't built with support for user-depending availability in mind.

mikovchain wrote: Thu Dec 06, 2018 4:57 am the variable $renderer equals to $this->renderer

Not quite:

$renderer !== $this->renderer

because

$renderer === $this

therefore

$renderer->renderer === $this->renderer

I'm #3709. The other kasimi #4467 can be removed, that was also me but from a different computer, not sure why I was able to get the same username. Isn't that supposed to be disallowed?

When viewing a message, adding the unread information is a minor change as there are to_recipient and bcc_recipient blocks being used already.
When viewing a folder, the recipient names are just a string, getting joined before being assigned to the template. The function that fetches the names ...

When sending to users (as opposed to groups), the data is already there, it just needs to be displayed. There won't be any performance penalties.

For multi-groups this will not work, just like it isn't working at the moment when sending to a single group. But we've gotta start somewhere.

When sending a PM to a single user, you know the user has read them PM when it has been moved from your Outbox to your Sent messages folder. When sending a PM to multiple users, the PM is moved the moment the first user reads it. There is no way to know who the first reader was and who hasn't read ...

0 is the correct value here because the query is selecting banned users, as opposed to banned emails or IPs for which ban_userid whould be 0. If you change it to <> 1, the returned array contains an invalid entry.

I think the migrator should take care of this. If the role doesn't exist, the permission.permission_set operation should be skipped, without throwing an error. Admins who delete built-in roles should know that extension won't be able to set default permission values.

Either that, or don't allow ...

There's an extension in [DEV] for this. The confirmation only works with JavaScript enabled though.

https://www.phpbb.com/community/viewtop ... &t=2357461