Would it be possible to add a feature where Organic Group Admin's, or members of a group to message the group?

Would you like this to be part of the module. If so would you like to create it or should I develop it and submit a patch?
If you would not like it as part of a module I will create a module for it myself as it is needed by a customer.

Keep up the good works.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

This is an often requested feature, and we already thought about how to do it. See also #555016: Planning for sending messages to roles..

The thing is, I'd like a way that would allow other types of groups too (roles, og, user relations, flags, whatever...) and we haven't found a solution yet that allows that.

Feel free to provide a solution, either as a separate module or a patch against privatemsg.module. Even if it does not match the above requirements, I'm sure some users would use it anyway and we can improve it to be more flexible at a later point.

stephenhendry’s picture

Thanks for the reply. I will see what I can come up with over the next week or so.

Berdir’s picture

Great. If you have any questions (It's not an easy feature if you want to do it well) feel free to ask them here or join #drupal-games and I'll try to help out as much as I can.

stephenhendry’s picture

Code wise I have not started as not been commissioned to do the work yet. I may start in my own time as it would be a good feature to have.

Feature wise I feel I need the following:

  • Message All members
  • Message OG
  • Message Role
  • The ability to reply only to the person who sent the message (option when sending the initial message and for the person replying)

Can anyone think of anything I have missed?

Berdir’s picture

Other ideas (some you might be interested in)

- Don't allow reply to all (You don't want that users can send messages to all others)
- Performance: Make sure things work out with big groups/sites
- Display of many users. If you send a message to a group consisting of 1000 users, you don't want that all of the show up on the view messages thread and show just the group name instead.

stephenhendry’s picture

Sadly I won't be able to start on this work until January as the project date has been pushed back until then. Once January comes and the funding is available I will start.

Bilmar’s picture

subscribing

ideafarm’s picture

I would be intersted in using this feature, can I put some money towards funding?

Berdir’s picture

You can. I'm currently working on a generic solution for #555016: Planning for sending messages to roles. that should also allow sending messages to groups.

I'm going to release a first version soon, but that will require further development, testing and documentation. You are welcome to contact me directly.

shaneod’s picture

I am also interested in this feature, have you had a chance to look into it gazelle? - i can help with testing or make a donation.

stephenhendry’s picture

I have funding to do the work. Just waiting for the project to start. Start date keeps getting pushed back as the client are not ready. The project "should" be starting in the next two weeks.

Berdir’s picture

Great. Once you start this, please ping in in IRC or write me a message so that we can discuss this. I plan to re-roll the linked patch and fix a few bugs until then so that you can base your work on that.

YK85’s picture

+1 subscribing

igorik’s picture

subs, would be great to have an option to send the message to all my members or to other members

hkvd’s picture

subscribing

hkvd’s picture

FileSize
4.05 KB

Hi guys,

I've developed a module which allows users to send private messages to a subscribed group (organic groups). I'm still a noob Drupal module developer so your help/suggestions/comments are required.

When the user creates a new message, a select box appears in the form displaying the user's subscribed groups. I'm still facing the following issues with this module -

1) The group select box should not appear while replying to a message. I'm unable to get this working... I've added comments for help in the source code of the module. Please look into it. Any help would be great....

2) As Berdir pointed out, when replying to a message a group's name should be displayed instead of a list of all group members. I tried implementing but wasn't successful since I couldn't find a way to override the 'privatemsg_new()' function defined in the privatemsg.module file. To facilitate other developers, I've implemented hook_schema() for my module so that the module creates a new database table at installation. The database table is named 'privatemsg_group' and it stores the id of the group (gid) to which a message was sent along with the message id (mid). If a message isn't sent to any group, its entry is not made in the table.

Hope you guys find this useful. I've tried to include detailed comments in most places. The module is attached with this post. Please feel free to edit the module code. Also should I add this module to the Drupal project repository (this is my first drupal module)???

Looking forward to your replies...

hkvd’s picture

FileSize
4.44 KB

I've made some further changes to the privatemsg_group module!!

1) Instead of a single select box, a multiple select box is now displayed wherein users can select multiple organic groups to send messages to. Appropriate checks are made so that a user who is subscribed to one or more of the selected groups is sent only one copy of the message.

The updated module file is attached....

Berdir’s picture

@hkvd
Thanks for working on this. Basing your work on #555016: Planning for sending messages to roles. would allow much better integration without the need to override internal privatemsg functions. But that other issue needs a major re-roll first before it can be be used.

Also, it seems your module integrates with Privatemsg 6.x-1.x, new features will only be added to the 2.x-branch.

I suggest you join #drupal-games in IRC and ping me if I'm around so that we can discuss this.

Berdir’s picture

Status: Active » Postponed

postponing this on #555016: Planning for sending messages to roles. for the reasons outlined before. The latest patch in that issue should work fine and privatemsg_og could be created based on privatemsg_roles everything should just work.

hkvd’s picture

just a thought.....

Is the feature for sending private messages to groups really needed? I ask this because there is already a provision in the Organic Groups module for posting a message in a group which is visible only to the group members. This is effectively the same as sending a private message to all group members. I'd like to hear your opinions/comments on this....

Berdir’s picture

And where would that message be displayed?

I assume that integrating that message sending has a few advantages over a og internal message, what about the following...
- The message shows up just as any other private messages, including notifications (on-site like pmgrowl and/or email)
- Normal users can reply (only to the author if they are not allowed to write messages to groups, to all if they are)
- Integration with other privatemsg modules (tagging, attachments, rules)
- Multiple recipients: #555016: Planning for sending messages to roles. allows to send messages to multiple groups/roles/users, it is even possible to mix them ( send a message to two groups, a role and three single recipients)

hkvd’s picture

hmmm... thanks for pointing out the advantages Berdir... they cleared my confusion... my faith is restored in this feature.. ;)

max.andresen@gmail.com’s picture

Hello, I am a drupal designer. I dont have a knowledge of php at all but i am wondering if this module or maybe another on can do the following: Restrict the recipients list to only the users that belong to your Organic group. and if you belong to more than 1 you need to select 1 group then the users in that group to send your message to. The reason I ask is because its a little weird for a user to be typing ion a recipient and be able to see tons of people that they dont know.

Thanks for any help you guys can provide.

Berdir’s picture

No. This module will allow to write a message to "OG X", and all users in that group will see the message and be able to respond to it.

What you are describing woud be a different feature, which could live in the same module however.

scarvajal’s picture

I'm wondering what is the development status of this feature.

I think that could be great if this feature allow us to select as destination:

- Select one or multiple OG
- Select one or multiple User Roles

So I can restrict my recipients to be only the parents (role) of a class (OG)

In addition I think that could be great if I can send this message with the following options as checkboxes:
- Allow reply to all (or at least dont allow this by default).
- Allow reply (if not checked send the message in anonymous mode)

I have been looking for a way to send a message to an entire OG but as far as I saw there is not. Even using other modules.
I'm right?

Berdir’s picture

Status: Postponed » Needs work

This isn't postponed anymore, but it should not be that complicated.

I actually suggest to start with the privatemsg_rules module, and then reimplement all callback functions with OG. To do that, I guess a part of the functions in this module can be re-used.

EndEd’s picture

Im interested in the Flag Friends integration.

NathanM’s picture

Copied from another issue:
http://drupal.org/node/935670

I saw that in the 2.x features section there seems to be planned support for organic groups integration. However, looking in the issue que, it seems that this mostly revolves around being able to message all members of a group. Would it also be possible to look at integrating messaging individual members of a group, similar to the way the UR limits integration is set? By that, I mean it would be nice if there were options similar to this:

Allow Privatemsg to work only between related users. Note that this setting does not affect the site's admin user.
Restrict Private Messaging to only related users:
Allow sending messages to all users
Allow sending messages to all users, users have option to accept messages only from their confirmed relationships
Allow sending messages only to confirmed relationships (You probably should enable "Suggest only relationships" below)
Allow sending messages only to fellow Organic Groups members (You probably should enable "Suggest only relationships" below)
Allow sending messages only to confirmed relationships & fellow Organic Groups members (You probably should enable "Suggest only relationships" below)
Suggest only relationships in To: field
Show only user's relationships when autocompleting the To: field.

This would be good, because it allows people to message other people on the site in a broader way than just through user relationships, but it also requires you to somehow be involved with those you are messaging. Likewise, it would be great if this also could be limited by role, like the User Relationships limit is.

BenK’s picture

Version: » 7.x-1.x-dev

Now that sending to roles has been committed, it's the perfect time to work on this. My suggestion is that we first work on the D7 version because most of our new development work has been going into 7.x branch first, then ported to D6. So I'm changing the version tag on this thread.

But we should check with Berdir to see what he wants to do (and can change back the version tag if needed).

--Ben

asiby’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs review » Needs work

Hello Fellows

I don't know if this thread is dead, but I might have made some tweaks that worked for me. I am still testing though. I have modified the code to make it do the following:

- Display the og group select element in the privatemsg form (this will show groups that the connected user is member of). Only one group can be selected at a time.
- Added AHAH to the group select element to dynamically show the members belonging to the selected group.
- The group member list is a multi-select list. So instead of sending a message to the entire group, you can select any combination of members to be used as recipients
- Hide the group select element and the group member select element when replying to a message.
- Disabled the default "message field" (it is useless in my case cause I need to restrict privatemsg to og only. This will need to be configurable)

Possible future modifications:

- Use hooks instead of using functions copied from the privatemsg module.
- Allow multiple selection of group then use "option groups" in the member select element to show the separation between group members lists and remove duplicates if any.
- Add "Select all" checkboxes for groups and members (unlikely)

Known issue:
- For the moment, after a validation error, the AHAH causes the form submit handler to malfunction.

P.S.: These are based on hkvd submitted file (http://drupal.org/node/612664#comment-2775860).

Cheers

Asiby

YK85’s picture

@asiby - can your work be shared here for testing? It would be great to have OG integration.

BenK’s picture

Bumping this since we can now message User Relationships relationship types (such as a "friend")... sending to organic groups should be very similar.

--Ben

paolomainardi’s picture

Hi all, any news about 6.x privatemsg_group module ? Anyone is working on that ? I've just started to code a module based on privatemsg_roles but i prefer to collaborate with someone if already available some code.

Thanks! :)

marco.giaco’s picture

Subscribe

paolomainardi’s picture

Issue tags: +OG

If anyone is interested, i've just deployed a beta version of privatemsg_group module (compatible with 6.x-2.x-dev), based on privatemsg_roles, please feel free to clone by my sandbox: http://drupal.org/project/user/302937

Actually supported:
1) "Write to all groups"
2) "Write to own groups"
3) Admin settings to restrict sending only to group administrators (depends on 2) activation)

Let me know your feedback, thanks!

Berdir’s picture

Issue tags: -OG

Great!

I suggest you post a patch, then I can give you a proper review with Dreditor and we can talk about integrating this properly.

PS: Tags are meant to be used for specific, predefined tags to group multiple issues together, not a for a list of arbitrary tags like on a blog.

paolomainardi’s picture

Ok, whats going wrong on using og and privatemsg_group as tags on this thread ? I mean, not arbitrary as a blog but specific to this issue thread.

BTW :) i will post a patch against the 2.x-dev branch as soon as possible, probably just tomorrow.

Thanks

paolomainardi’s picture

Here we go, sooner than i expected, find in the attachment the requested patch.

I've just found some bugs:

1) Add a description as privatemsg_role on autocomplete textfield to explain howto use group autocomplete.
Edit: Seems to be a privatemsg bug, see this issue: http://drupal.org/node/1169440#comment-4518740

2) Print a recipient on inbox table, now is hidden but i saw the same behaviour on privatemsg_role module, see the attached image.

paolomainardi’s picture

+ $form['groups']['privatemsg_group_admin_grant'] = array(
+ '#title' => t('Restrict access to group administrators'),
+ '#type' => 'checkbox',
+ '#default_value' => variable_get('privatemsg_group_admin_grant', 1),
+ '#description' => t("Enabling this setting will restrict message sending only to group administrator."),
+ '#weight' => -4,
+ );
+}

Should be read as: Activating this option, only group administrators will be able to send message to group, subscribed users will be able only to respond to administrator.

More or less.

Berdir’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, privatemsg_group_module-612664-38.patch, failed testing.

Berdir’s picture

Looks pretty good, some feedback below. Tests would be awesome to get this included in the Privatemsg project, because I currently don't use OG and it would therefore easy to break this module if I can't test it properly manually.

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+
+function privatemsg_groups_theme() {
+  return array(
+    'privatemsg_groups_format' => array(
+      'arguments' => array('group' => NULL, 'options' => array()),

Missing a Implements .. docblock.

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+function privatemsg_groups_privatemsg_recipient_type_info() {
+  return array(
+    'group' => array(
+      'name' => t('Group'),

Wondering if it would make sense to also define a second type, group_admin, that allows you to contact the administrators of a group. They would then have separate permissions.

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+
+
+function privatemsg_groups_form_privatemsg_admin_settings_alter(&$form, &$form_state) {
+  $form['groups'] = array(
+    '#type' => 'fieldset',

Same here, an Implements hook_form_FORM_ID_alter() docblock should be added.

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+    '#title' => t('Privatemsg groups'),
+    '#collapsible' => TRUE,
+    '#collapsed' => TRUE,

Is it clear what is meant with "Privatemsg groups"? That it is related to OG, I mean. Not sure how OG is referencing to itself, not using it..

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+/**
+ * View permission check for group recipients.
+ */
+function privatemsg_group_view_access($nid) {
+
+  if (user_access('write privatemsg to all groups')) {
+    return TRUE;

Not sure if we should add a separate permission to view recipients. You might want to allow your users to see for which group they received a message without giving them access to writing messages themself.

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+  if ($recipient) {
+    if (empty($recipient->title)) {
+      $recipient = reset(privatemsg_groups_load_multiple(array($recipient->recipient)));
+    }
+    return privatemsg_group_view_access($recipient->recipient);
+  }
+
+  // check if user has group subscriptions
+  return (bool) (count(og_get_subscriptions($user->uid)));
+}

Using reset like that results in a E_STRICT notice, use_array_shift() instead or save it to a temporary variable.

Also, not really sure what exactly you are doing here, you might want to add a comment or two. What exactly does that subscriptions check do?

+++ b/privatemsg_group/privatemsg_groups.moduleundefined
@@ -0,0 +1,213 @@
+  $result = db_query(og_list_users_sql(1, 0, null, false), $nid);
+  while ($row = db_fetch_object($result)) {
+    $recipients[] = $row->uid;

Looks like this is missing the $limit/$offset handling, this could lead to issues for large groups.

Powered by Dreditor.

paolomainardi’s picture

Thanks a lot for the comments, let me write some documentation about the code you pointed, i'll come back with a new patch in some hours.

paolomainardi’s picture

Please forget this patch, it was intended for another issue.

Berdir’s picture

Wrong issue ;)

paolomainardi’s picture

Status: Needs work » Needs review
FileSize
7.67 KB

Attached a patch to fix all the issues pointed.

1) docblock implemented
2) access functions refactored, now using an unique function for view/write/autocomplete access
3) removed "$recipient = reset(privatemsg_groups_load_multiple(array($recipient->recipient)));" that it was not useful (it was a backport from privatemsg_roles)
4) added more documentation

Issues to be pointed:

1) Query paging offset
2) Test suite

te-brian’s picture

Subscribing. I have my own working version of og integration with pm that I never got around to properly 'generifying'. I'll try to review this and compare it to my implementation so we can have a nice official version.

paolomainardi’s picture

Attached a new patch with some small refactoring plus the complete test suite (201 passes).

paolomainardi’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
FileSize
17.69 KB

An updated one with more tests (221).

Status: Needs review » Needs work

The last submitted patch, privatemsg_group_module-612664-49.patch, failed testing.

paolomainardi’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
FileSize
17.69 KB

Retest.

I can't change status and it's really boring that users can't do that :(

I wait Berdir to change the status and test the patch, this patch is intended for 6.x-2.x-dev branch but seems that can't be applied with automated testing.

paolomainardi’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Needs review
FileSize
17.68 KB

I've just realized that patch was in a wrong format, now should be works fine.

Berdir’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs review » Needs work

Your last two patches are backwards, you are removing your code instead of adding it :)

Also, the automated tests won't find your tests nor can they run it because of the OG dependency. Don't worry about that, as long as the patch applies, that's fine. I'll run the tests manually for now.

paolomainardi’s picture

@Berdir Ops, give me some time to upload the corrected one, sorry :/

Berdir’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Needs review

Crossposted above, setting the status back.

paolomainardi’s picture

The corrected one, seems to be applied fine with "git apply" (apart the warning about on trailing whitespaces)

Status: Needs review » Needs work

The last submitted patch, privatemsg_group_module-612664-56.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, privatemsg_group_module-612664-56.patch, failed testing.

Berdir’s picture

2) access functions refactored, now using an unique function for view/write/autocomplete access

That is the opposite of what I meant :) It should be separated, with separate permissions for view (a simple permission might be enough, doesn't need a callback I guess)

+++ b/privatemsg_groups/privatemsg_groups.testundefined
@@ -0,0 +1,257 @@
+  public static function getInfo() {
+    return array(
+      'name' => 'Privatemsg Group functionality',
+      'description' => 'Tests sending messages to groups',
+      'group' => 'Privatemsg',
+    );

You need to add a dependencies key here, look at privatemsg_realname.test for an example. Also, it will need a test_dependency in the .info file, again, see privatemsg_realname.info.

Nice work on the tests, haven't reviewed them in detail yet, but will try them out soon.

Powered by Dreditor.

Berdir’s picture

Confirmed that the tests pass when og.module exists. The problem is that when it doesn't, you end up with a fatal error on admin/build/testing, which is the same reason the test bot is currently failing too.

I guess the easiest way to deal with this is to add a if (!class_exists('OgTestCase') { return; } to that file before the class definition. Additionally to the dependencies declaration above.

paolomainardi’s picture

2) access functions refactored, now using an unique function for view/write/autocomplete access

That is the opposite of what I meant :) It should be separated, with separate permissions for view (a simple permission might be enough, doesn't need a callback I guess)

Why should be separated ? If user can't write why he is supposed to have read access ? As a user is i see also the group name (in this specific case) in the partecipants fields i think that i'm able to reply to all partecipants, included the group.

But probably i don't have understood totally the permissions system :(

You need to add a dependencies key here, look at privatemsg_realname.test for an example. Also, it will need a test_dependency in the .info file, again, see privatemsg_realname.info.

.info file already have dependency:

name = Privatemsg Groups
description = Allows to send message to all members of a group.
package = Mail
core = 6.x
dependencies[] = privatemsg
dependencies[] = og

I can't find privatemsg_realname.test to check the dependency key you wrote above neither here (http://drupalcode.org/project/privatemsg.git/tree/refs/heads/6.x-2.x:/pr...)

Thanks

paolomainardi’s picture

Status: Needs work » Needs review
FileSize
17.7 KB

OgTestCase class exists enforced.

Berdir’s picture

Why should be separated ? If user can't write why he is supposed to have read access ? As a user is i see also the group name (in this specific case) in the partecipants fields i think that i'm able to reply to all partecipants, included the group.

But probably i don't have understood totally the permissions system :(

Until recently, we also showed who will actually receive your message above the reply form. We could re-add that and show it only when necessary (= you can't write all participants). If you can't see it, then you might be missing important context. There is no other way to know through which group this message was sent to you unless they write it in the text.

Having those permission allows to make the site builders that decision. You could implement it so that it first checks the view permission and if a user does not have that, fall back to the write permission check. Then users can always see recipents they can write to even without the read permission.

Berdir’s picture

Status: Needs review » Needs work

Quickly went through the tests, they look good, just a few minor remarks below...

- Would be great to get feedback from te-brian and integrate whatever additional stuff he has.
- Still missing the limit/offset handling. Should be really easy to add, just replace db_query() with db_query_range() and pass $limit and $offset to that. This is important so that Privatemsg can correctly process these recipients through batch api/cron if a group has hundreds/thousands of subscribers.

+++ b/privatemsg_groups/privatemsg_groups.testundefined
@@ -0,0 +1,259 @@
+  public static function getInfo() {
+    return array(
+      'name' => 'Privatemsg Group functionality',
+      'description' => 'Tests sending messages to groups',
+      'group' => 'Privatemsg',
+    );

Please add the dependencies key anyway, as done in privatemsg_realname.test

+++ b/privatemsg_groups/privatemsg_groups.testundefined
@@ -0,0 +1,259 @@
+   * @return
+   *   The newly created node id.

You seem to return an node array (why not the object)...

+++ b/privatemsg_groups/privatemsg_groups.testundefined
@@ -0,0 +1,259 @@
+  function testMessageToGroup() {
+    // Create a group node.

You already cast it inside that function, this shouldn't be necessary :)

+++ b/privatemsg_groups/privatemsg_groups.testundefined
@@ -0,0 +1,259 @@
+
+    // check if normal user subscribed to group has received the message and have access to group write
+    $this->drupalLogin($this->group_user);
+    $this->drupalGet('messages');
+    $this->assertRaw($edit['subject'] . '</a> <span class="marker">new</span>', t('Message is displayed as new'));

Can you go over the comments in the test and make sure they follow the coding standards? That is:

- start with a uppercase character.
- End with a .
- No longer than 80 chars.

Powered by Dreditor.

te-brian’s picture

At first glance this looks to implement more functionality than my code. My main concern was group recipients of private messages, so that is primarily what I implemented. If I am in the office tomorrow I will try to compare this patch with my stuff more closely. Its a holiday though, so I may be out in the sun :)

paolomainardi’s picture

Status: Needs work » Needs review
FileSize
19.21 KB

Updated patch.

Tests fixed and refactored.

View access permission implemented as "view access" (like in privatemsg_roles) waiting to integrate a sort of "reply tp recipient display based on user permission".

db_query changed to db_query_range.

Thanks :)

JonasK’s picture

I have just tested this privatemsg_group_module and it seems to be just what I need.
There is just one problem: If I type a letter lets say 'j' then all people starting with this letter are listed as recipients regardless whether they belong to 'my' group or not. In my view only the people within the groups that I have access should be listed.

Is this possible to configure? Did I just miss a configuration step? If not, would it be possible to add such a restriction which would make this module more group friendly?

Thanks a lot for all your efforts!

Berdir’s picture

That would be a useful, but currently missing feature. So you aren't missing anything.

Right now, this module just adds the ability to write all users which belong to a group at once.

My suggestion would be that we continue with this issue, commit it and and then you can create a new feature request for adding that to the privatemsg_group module.

JonasK’s picture

Berdir, thanks for the quick response.
Ok, I will wait for you guys to finish this great module.

As a very quick (and dirty) workaround I have added the following code to the function 'privatemsg_sql_autocomplete' within the file privatemsg.module:

global $user;
$fragments['where'][] = "u.uid IN (select uid from {og_uid} WHERE nid IN (select nid from {og_uid} WHERE uid = ". $user->uid ."))";

Now only the users having access to the same group (as the user writing the message) will be shown as sugesstions. Of course, it is still possible to enter an existing name of a user within another group and send the message. But at least the autocomplete function does only show the needed names, which is all I need at the moment. I thought I might still quickly share this as it might help someone else too.

Berdir’s picture

Well, if you know *how* to do it, you are more than welcome to add it to the existing patch or make a new issue with a patch against privatemsg_group.module once it's commited.

Instead of hacking it in... :

- Add it in a hook_privatemsg_sql_autocomplete_alter() for privatemsg_group. Pass the user id as an argument to the query and not directly.

- Implement http://api.worldempire.ch/api/privatemsg/privatemsg.api.php/function/hoo... and do the check there again.

- Make both things configurable with settings

paolomainardi’s picture

@Berdir Hi :) Did you plan to integrate privatemsg_group in the -dev branch ?

THanks

Berdir’s picture

Yes, I plan to add, but I'd love to see some more feedback from users testing it.. I haven't tried it myself. Also feedback from te-brian would be nice, but he's a busy man ;)

te-brian’s picture

I don't have time right now to really apply the patch and test it .. but in combing through the code here is a quick review and comparison to my custom module.

Things the patch does that I did not:

  • Better write access checking.
  • Confirming that the node is a group in the ...load_multiple() callbacks.
  • Settings form.
  • Admin permission to 'write message to all groups'
  • Has tests :)

Things my code does that the patch does not:

  • I've added two new recipient types: 'group members' and 'group admins'
    • I think 'group admins' is really useful if you want an easy way for members to get in touch with their admins.
    • 'Group members' includes admins, but, in my version only group admins can message members.

And that's really the only major difference. Overall, the patch appears to be more complete and contrib-ready than what i have. The interesting (and good) thing is that paolomainardi arrived at a lot of the same code as me. In some places its nearly identical line-for-line.

I've posted most of the relevant snippets of my custom implementation for comparison.

At first glance .. if I was going to directly use the patch on my production site the following changes would need to take place (however, don't take this as an indication that this needs to happen for it to be useful for others).

  • Add a group-admins recipient type.
  • Add more permissions (and therefore access checks)
    • 'write privatemsg to group admins'
    • 'write privatemsg to own group admins'
    • 'view group admin recipients'
    • 'view own group admin recipients'
  • Put an option somewhere and figure out how to limit group members to only msg admins, but admins can message group members. If memory serves I am doing this by giving people who are group admins a special role (though this is probably beyond the scope of the privatemsg module)

Now, having said all that I should disclose one more fact:

We are considering stopping support for group private message on our site :) We have several groups with over 1,000 members (not a lot compared to say g.d.o, but still sizable). When admins message those group members and a conversation takes place .. it generates a TON of rows in the pm_index table. There are many threads between those group members that have over 200 replies. So .. our pm_index table is approaching 3 million rows ... and the pm_index queries are not exactly high-performance ones :) Our solution will likely be adding a group-only message board and directing people to communicate there. We still would like people to be able to message admins, but will probably shut down messages to the whole group, other than perhaps no-reply broadcasts from admins to members. Also, with messages to groups of that size regular users are encountering the batch api on a regular basis.. and that is never a good thing :)

Berdir’s picture

Thanks for the review again!

I agree that being able to write the group admins is a useful feature and the write permissions make sense.

Not sure if we need two separate view permissions for all/own group admins? Is there a use case where you'd want to separate that? Remember, that permission is only relevant for recipients/authors of a message. And if you are a recipient of that message, it is by definition your group :)

So I'd vote for a single view permission for admin recipients.

The third point already exists, there is a setting that only allows admins of a group to write their members. It could also be converted to a a permission I guess (3 permissions: write to members of all groups, write to members of my groups, write to members of groups I'm an admin). Not sure if that's better. Either that or make sure the setting only applies for group member recipients I think.

paolomainardi, any chance that you can integrate the member/admin part, based on te-brians code? I think with that we'll be close to be able to commit this.

paolomainardi’s picture

@te-brain thanks a lot for reviewing the patch, my implementation take inspiration by privatemsg_roles module, i didn't see your patch before to start my module, it's interesting that are nearly identical, probably because the same (good) inspiration source :)

@Berdir i will try to find some time to review Berdir code and integrates the relevant parts about member/admin part if needed. Actually the settings variable is needed to restrict message sending only by group administrators to group users, there no access setting to make the inverse (is already available og_contact module in og core, we really want to duplicate the functionality ?)

Thanks guys.

Berdir’s picture

Minor misunderstanding :)

The setting as it exists right now is perfectly fine (allowing only admins to contact all members). What I meant is that this setting should not affect the new group-admins recipient type, once added. So even if checked and you only have the write own group admins permission, you can write your group admins without being one.

I am not sure what og_contact does, does that directly send mails, similar to contact.module? Then it imho makes sense to duplicate it because it's a different use case. Some people want to only use private messages for contacting other people to keep them on the site. There is even a privatemsg_contact module in the issue queue, which replaces contact.module by sending private messages instead of mails.

websule’s picture

pmackay’s picture

subscribe

nagiek’s picture

.

Crom’s picture

subscribing

paolomainardi’s picture

Berdir, any chance to get this module commited ?

Thanks!

dddbbb’s picture

I'd also be pretty keen to see this functionality commited. Any plans in the near future?

Parkes Design’s picture

subscribe +1

Berdir’s picture

@paolomainardi: AFAIK, we'd wanted to integrate some parts from brian's patch first, see #77.

@others

If you want this module to be commited, then test and provide detailed reports if it works for you and what you tested! As I'm not using this feature myself, I'd like a few confirmations that this is working as expected.

paolomainardi’s picture

@Berdir I think that i will publish this module like a contrib, i don't have time to integrate Brian's code right now.

Please, if someone have time to test my patch is really welcome to write here their feedback.

fuzzy76’s picture

Paolomainardi, any progress on publishing the module as a "normal" contributed module? Or should I just test the patch as is now?

paolomainardi’s picture

fuzzy76, no contrib module released yet, please feel free to use last submitted patch and come back here to report your feedback, i'm using in some production platform without any problems.

Thanks.

Patrizio’s picture

FileSize
5.26 KB

I had some problem using #74
This is my module version for 6.x-2.x-dev. Place it into the privatemsg module.

Patrizio’s picture

FileSize
30 KB

Two new lines to integrate the autocomplete configuration http://drupal.org/node/1232374#comment-5711280

paolomainardi’s picture

@Patrizio: Did you try to use my patch ?

Please, post your modification as a standard patch as described here: http://drupal.org/patch

BalfNl’s picture

Good afternoon,

Im looking into this addition to Privatemsg and it does almost everything I needed extra. There is just one change / feature I'd like to have or some pointers on how to do this myself.

For this project the recipients of a group message are not allowed to reply to the entire group but just to the original author/sender of the first message. How could I do this?

paolomainardi’s picture

Berdir, any chance to get this patch committed ?

jeremy.zerr’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Needs review

Wow... wish this was committed (I need for D7, I would love to port it, don't have a D6 site that needs it). Great work paolomainardi! Really great functionality you've worked on adding.

jrao’s picture

For D7 port of this module, see #1539306: Private Message Organic Group for D7

paolomainardi’s picture

Hi jeremy.zerr! Thanks for your appreciation :) I'm, waiting for Berdir to get this patch committed to the 6.x branch.

Berdird, please could you give us some updated ?

Thanks!

Apfel007’s picture

sub

paolomainardi’s picture

Again, any chance to get this patch committed ?

Berdir’s picture

Status: Needs review » Needs work

I was hoping that the group admin recipient type will get added, it's also not clear to me what #89 and #90 exactly changes and which is the correct version now. Can you do a re-roll with the changes of that included, if necessary?

asiby’s picture

@YK85. Sorry for the delay. Are you still interested in the code. I know it was well over a year ago. My bad. But yes it is possible to share the code.

ckpoon’s picture

subscribe

Rob C’s picture

@ckpoon please read and stop subscribing > http://drupal.org/node/1306444

Rosamunda’s picture

Is this available in D7? Because it has started as a D6 issue, but now it would be good to implement this in D7.

Rosamunda’s picture

Sorry, haven´t realized there was a D7 issue already :)

asiby’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

Sorry guys. So many things was going on that I haven't realized that I didn't send you the code. It's probably too late now. But I would like to offer my sincere apologies for my lack of activity.

I suggest closing this issue as it is now outdated. Please feel free to open it if still needed.