Unapproved/soft deleted posts are posts, that have a different visibility than
the topic. All others will be hidden from the posts list and can be managed
with the topic modules.
PHPBB3-9567
How do we do this? If an item is unread, the URL to view that item will
be the URL to mark it as read (index.php?mark_notification=$id). When the
URL is visited it marks the item as read and redirects them to the correct
URL for the item.
If the item is read, the URL is directly to the item.
Prettify the html output
PHPBB-11103
EXTENSION AUTHORS TAKE NOTE! This is to prevent errors with notifications
from extensions!
Set is_disabled to 1 for all your notifications when your extension is
disabled so they are ignored and do not cause errors.
When your extension is enabled again, set is_disabled to 0 and your
notifications will be working again.
PHPBB3-11103
From a recent change, when your posts/topics are approved, they will be
marked read automatically because you've read the topic/post already.
To change that I've forced the notification to be marked unread and
attempted to reset the read status on the post/topic to be unread before
the post that was approved.
This does not seem to work so well and I don't know of any way this can
really be properly fixed, so the code I was working on I've commented out.
For now, users will just need to manually mark these types of notifications
as read. I cannot think of a way for this to be fixed without running
two additional queries on every viewtopic.
PHPBB3-11103
Mark post/topic in queue notifications read when visiting mcp
Change post/topic in queue notification url to use MCP.
Fix the bug:
Approving a topic marks the topic as read, but before the notification
is created for the user approving the topic (if they would get a
notification that the topic has been made). This causes it to be
stuck "unread".
PHPBB3-11103
* dhruvgoel92/ticket/11051:
[ticket/11051] fix spaces
[ticket/11051] add common_words variable
[ticket/11051] remove unnecessary comment
[ticket/11051] add get_word_len() in sphinx search
[ticket/11051] use get_word_length in search backend
[ticket/11051] use get_common_words in search backend
[ticket/11051] function instead of accessing property in search
[ticket/11051] add public functions for public properties
* bantu/ticket/8713:
[ticket/8713] Update untrimmed_variable() doc block.
[ticket/8713] Revert changes to ucp_profile, ucp_register and acp_users.
[ticket/8713] Trim password in auth_db to keep compatibility.
[ticket/8713] Call htmlspecialchars_decode() on transfer (e.g. ftp) passwords.
[ticket/8713] Rename untrimed_variable() to untrimmed_variable().
[ticket/8713] DRY: variable() and untrimed_variable() into a protected method.
[ticket/8713] Fix type_cast_helper.php doc blocks: Add punctuation etc.
[ticket/8713] Always trim array keys.
[ticket/8713] Add simple (non-nested) test case for untrimmed set_var().
[ticket/8713] Use \t in double quotes instead of tabs.
[ticket/8713] Use correct parameter for nested data.
[ticket/8713] Adjust test method name to other recursive_set_var() tests.
[ticket/8713] Do not trim login inputs
- $post_visibility is not boolean, so we need to check for == ITEM_APPROVED
- sync() already updates the topic/forum info, so we don't need to do that again
- use set_post_visibility() when changing the posts visibility
Should be ready for testing.
PHPBB3-9567
This also makes sync('topic_visibility') obsolete, but we keep it for now.
Also fix a unit test, because ITEM_DELETED overpowers ITEM_UNAPPROVED
PHPBB3-9567
The function can not rely on the first post anymore, as that one could be soft
deleted but the topic still has approved replies which are still visible.
PHPBB3-9567
Before soft delete this was much easier, as an unapproved topic could only
have one post, because no one could reply to unapproved topics. Now we need
to run multiple queries to correctly reduce the post counts.
PHPBB3-9567
The Logic of $forum_ary was inverted, so if the array is empty, we can skip
the queries. We also should not merge passworded forums into the $forum_ary
as we removed them from that array right before that.
PHPBB3-9567
This is an additional query in some rare cases,
but it makes it much easier to use and understand.
This is mostly a preparation for the restore case.
PHPBB3-9567
