The value 0 for the setting means that the default access level for the content created inside the group will be private (only the person who created it can see it).

Elgg core doesn't have that feature by default, so it must have been added by some third-party plugin (most likely by group_tools).

Does it matter that some groups have different default access level? After all it can be changed when creating content.

If you were to remove the values manually from the database, how would you prevent it from getting saved there again?

Consistency matters for a UI.. People expect a certain behaviour across the whole site. My particular group of people are not very technology savvy and the less they need to touch the better. So I want defaults to be the most common use case (i.e. publish the object and send the notification). This is particularly important when the creator of an object does not get notification, someone could easily think the discussion or other object was notified to others and in fact it was not.

Its cool. I think I understand which combination of settings creates the entry. I think its a bug, but I believe its in group_tools. Need to do some more fiddling to isolate the conditions.

Register a plugin hook handler for the desired type:

https://github.com/Elgg/Elgg/blob/1.9/mod/blog/start.php#L41

And edit the title, body and/or summary in the handler:

https://github.com/Elgg/Elgg/blob/1.9/mod/blog/start.php#L248

Could be 700 to avoid problems due to missing permissions for creation a folder with more liberal access permissions which might only root be allowed to create (and not the apache user).

OK.. So far seems like no problems are going to be caused if I give group read permissions. This will allow me to backup effectively...

Surprised no one else has found this a problem when executing backups. Must be backing up as root or using a multipurpose account as the apache user..

B

Everything you've stated is correct and is expected, the situation is much better for 1.9

In 1.8 I have solved these issues for high volume sites by deferring the sending of emails to the system shutdown handler with the vroom plugin.

OK.. Thanks.. Waiting with 1.9 release with expectation :)

Further analysis showed some of my stupidity. My delays were increased because of the configuration of the MTA. It was processing way too much in foreground and not returning control to elgg. Once I changed the config to increase background processing, the delays were greatly reduced. 

There is still an idelay ssue with users clicking buttons more than once because of the delay from "Save" to a screen refresh, but I have enough of a solution until 1.9 I believe.

Brad

Quick :) question (no such thing)..

I looked at Vroom and it looks like it could be interesting short term. Not sure I have the skills to do it.

I want to implement it for group discussion notifications. Discussions are a little special from what I can determine.. 

Seems like I need to change start.php in mod/groups

if ($interested_users && is_array($interested_users)) {
                                foreach ($interested_users as $user) {
                                        if ($user instanceof ElggUser && !$user->isBanned()) {
                                                if (($user->guid != $poster->guid) && has_access_to_entity($topic, $user) && $topic->access_id != ACCESS_PRIVATE) {
                                                        $body = elgg_trigger_plugin_hook('notify:annotation:message', $annotation->getSubtype(), array(
                                                                'annotation' => $annotation,
                                                                'to_entity' => $user,
                                                                'method' => $method), $string);
                                                        if (empty($body) && $body !== false) {
                                                                $body = $string;
                                                        }
                                                        if ($body !== false) {
                                                                notify_user($user->guid, $topic->getContainerGUID(), $subject, $body, null, array($method));
                                                        }

The notify_user line needs to change to something like;

if ($body !== false) {
elgg_register_event_handler('shutdown', 'system', 
    function () use ($user->guid, $topic->getContainerGUID(), $subject, $body, null, array($method)) {
           notify_user($user->guid, $topic->getContainerGUID(), $subject, $body, null, array($method));
    }
, 500);
}

All normal disclaimers about not changing core elgg and this is a completely non-prod instances which I can easily break and restore.