Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#90 | privatemsg_og.tar_.gz | 30 KB | Patrizio |
#89 | privatemsg_og.tar_.gz | 5.26 KB | Patrizio |
#74 | custom_privatemsg.module.txt | 2.97 KB | te-brian |
#74 | custom_privatemsg.groups.inc_.txt | 7.57 KB | te-brian |
#67 | privatemsg_group_module-612664-67.patch | 19.21 KB | paolomainardi |
Comments
Comment #1
BerdirThis 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.
Comment #2
stephenhendry CreditAttribution: stephenhendry commentedThanks for the reply. I will see what I can come up with over the next week or so.
Comment #3
BerdirGreat. 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.
Comment #4
stephenhendry CreditAttribution: stephenhendry commentedCode 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:
Can anyone think of anything I have missed?
Comment #5
BerdirOther 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.
Comment #6
stephenhendry CreditAttribution: stephenhendry commentedSadly 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.
Comment #7
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #8
ideafarm CreditAttribution: ideafarm commentedI would be intersted in using this feature, can I put some money towards funding?
Comment #9
BerdirYou 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.
Comment #10
shaneod CreditAttribution: shaneod commentedI 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.
Comment #11
stephenhendry CreditAttribution: stephenhendry commentedI 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.
Comment #12
BerdirGreat. 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.
Comment #13
YK85 CreditAttribution: YK85 commented+1 subscribing
Comment #14
igorik CreditAttribution: igorik commentedsubs, would be great to have an option to send the message to all my members or to other members
Comment #15
hkvd CreditAttribution: hkvd commentedsubscribing
Comment #16
hkvd CreditAttribution: hkvd commentedHi 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...
Comment #17
hkvd CreditAttribution: hkvd commentedI'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....
Comment #18
Berdir@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.
Comment #19
Berdirpostponing 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.
Comment #20
hkvd CreditAttribution: hkvd commentedjust 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....
Comment #21
BerdirAnd 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)
Comment #22
hkvd CreditAttribution: hkvd commentedhmmm... thanks for pointing out the advantages Berdir... they cleared my confusion... my faith is restored in this feature.. ;)
Comment #23
max.andresen@gmail.com CreditAttribution: max.andresen@gmail.com commentedHello, 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.
Comment #24
BerdirNo. 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.
Comment #25
scarvajal CreditAttribution: scarvajal commentedI'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?
Comment #26
BerdirThis 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.
Comment #27
EndEd CreditAttribution: EndEd commentedIm interested in the Flag Friends integration.
Comment #28
NathanM CreditAttribution: NathanM commentedCopied 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.
Comment #29
BenK CreditAttribution: BenK commentedNow 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
Comment #30
asiby CreditAttribution: asiby commentedHello 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
Comment #31
YK85 CreditAttribution: YK85 commented@asiby - can your work be shared here for testing? It would be great to have OG integration.
Comment #32
BenK CreditAttribution: BenK commentedBumping this since we can now message User Relationships relationship types (such as a "friend")... sending to organic groups should be very similar.
--Ben
Comment #33
paolomainardi CreditAttribution: paolomainardi commentedHi 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! :)
Comment #34
marco.giaco CreditAttribution: marco.giaco commentedSubscribe
Comment #35
paolomainardi CreditAttribution: paolomainardi commentedIf 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!
Comment #36
BerdirGreat!
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.
Comment #37
paolomainardi CreditAttribution: paolomainardi commentedOk, 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
Comment #38
paolomainardi CreditAttribution: paolomainardi commentedHere 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.
Comment #39
paolomainardi CreditAttribution: paolomainardi commented+ $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.
Comment #40
BerdirComment #42
BerdirLooks 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.
Missing a Implements .. docblock.
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.
Same here, an Implements hook_form_FORM_ID_alter() docblock should be added.
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..
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.
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?
Looks like this is missing the $limit/$offset handling, this could lead to issues for large groups.
Powered by Dreditor.
Comment #43
paolomainardi CreditAttribution: paolomainardi commentedThanks 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.
Comment #44
paolomainardi CreditAttribution: paolomainardi commentedPlease forget this patch, it was intended for another issue.
Comment #45
BerdirWrong issue ;)
Comment #46
paolomainardi CreditAttribution: paolomainardi commentedAttached 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
Comment #47
te-brian CreditAttribution: te-brian commentedSubscribing. 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.
Comment #48
paolomainardi CreditAttribution: paolomainardi commentedAttached a new patch with some small refactoring plus the complete test suite (201 passes).
Comment #49
paolomainardi CreditAttribution: paolomainardi commentedAn updated one with more tests (221).
Comment #51
paolomainardi CreditAttribution: paolomainardi commentedRetest.
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.
Comment #52
paolomainardi CreditAttribution: paolomainardi commentedI've just realized that patch was in a wrong format, now should be works fine.
Comment #53
BerdirYour 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.
Comment #54
paolomainardi CreditAttribution: paolomainardi commented@Berdir Ops, give me some time to upload the corrected one, sorry :/
Comment #55
BerdirCrossposted above, setting the status back.
Comment #56
paolomainardi CreditAttribution: paolomainardi commentedThe corrected one, seems to be applied fine with "git apply" (apart the warning about on trailing whitespaces)
Comment #58
Berdir#56: privatemsg_group_module-612664-56.patch queued for re-testing.
Comment #60
BerdirThat 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)
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.
Comment #61
BerdirConfirmed 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.
Comment #62
paolomainardi CreditAttribution: paolomainardi commentedWhy 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 :(
.info file already have dependency:
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
Comment #63
paolomainardi CreditAttribution: paolomainardi commentedOgTestCase class exists enforced.
Comment #64
BerdirUntil 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.
Comment #65
BerdirQuickly 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.
Please add the dependencies key anyway, as done in privatemsg_realname.test
You seem to return an node array (why not the object)...
You already cast it inside that function, this shouldn't be necessary :)
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.
Comment #66
te-brian CreditAttribution: te-brian commentedAt 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 :)
Comment #67
paolomainardi CreditAttribution: paolomainardi commentedUpdated 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 :)
Comment #68
JonasK CreditAttribution: JonasK commentedI 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!
Comment #69
BerdirThat 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.
Comment #70
JonasK CreditAttribution: JonasK commentedBerdir, 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.
Comment #71
BerdirWell, 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
Comment #72
paolomainardi CreditAttribution: paolomainardi commented@Berdir Hi :) Did you plan to integrate privatemsg_group in the -dev branch ?
THanks
Comment #73
BerdirYes, 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 ;)
Comment #74
te-brian CreditAttribution: te-brian commentedI 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:
Things my code does that the patch does not:
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).
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 :)
Comment #75
BerdirThanks 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.
Comment #76
paolomainardi CreditAttribution: paolomainardi commented@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.
Comment #77
BerdirMinor 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.
Comment #78
websule CreditAttribution: websule commented#67: privatemsg_group_module-612664-67.patch queued for re-testing.
Comment #79
pmackay CreditAttribution: pmackay commentedsubscribe
Comment #80
nagiek CreditAttribution: nagiek commented.
Comment #81
Crom CreditAttribution: Crom commentedsubscribing
Comment #82
paolomainardi CreditAttribution: paolomainardi commentedBerdir, any chance to get this module commited ?
Thanks!
Comment #83
dddbbb CreditAttribution: dddbbb commentedI'd also be pretty keen to see this functionality commited. Any plans in the near future?
Comment #84
Parkes Design CreditAttribution: Parkes Design commentedsubscribe +1
Comment #85
Berdir@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.
Comment #86
paolomainardi CreditAttribution: paolomainardi commented@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.
Comment #87
fuzzy76 CreditAttribution: fuzzy76 commentedPaolomainardi, any progress on publishing the module as a "normal" contributed module? Or should I just test the patch as is now?
Comment #88
paolomainardi CreditAttribution: paolomainardi commentedfuzzy76, 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.
Comment #89
Patrizio CreditAttribution: Patrizio commentedI had some problem using #74
This is my module version for 6.x-2.x-dev. Place it into the privatemsg module.
Comment #90
Patrizio CreditAttribution: Patrizio commentedTwo new lines to integrate the autocomplete configuration http://drupal.org/node/1232374#comment-5711280
Comment #91
paolomainardi CreditAttribution: paolomainardi commented@Patrizio: Did you try to use my patch ?
Please, post your modification as a standard patch as described here: http://drupal.org/patch
Comment #92
BalfNl CreditAttribution: BalfNl commentedGood 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?
Comment #93
paolomainardi CreditAttribution: paolomainardi commentedBerdir, any chance to get this patch committed ?
Comment #94
jeremy.zerr CreditAttribution: jeremy.zerr commentedWow... 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.
Comment #95
jrao CreditAttribution: jrao commentedFor D7 port of this module, see #1539306: Private Message Organic Group for D7
Comment #96
paolomainardi CreditAttribution: paolomainardi commentedHi 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!
Comment #97
Apfel007 CreditAttribution: Apfel007 commentedsub
Comment #98
paolomainardi CreditAttribution: paolomainardi commentedAgain, any chance to get this patch committed ?
Comment #99
BerdirI 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?
Comment #100
asiby CreditAttribution: asiby commented@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.
Comment #101
ckpoon CreditAttribution: ckpoon commentedsubscribe
Comment #102
Rob C CreditAttribution: Rob C commented@ckpoon please read and stop subscribing > http://drupal.org/node/1306444
Comment #103
Rosamunda CreditAttribution: Rosamunda commentedIs this available in D7? Because it has started as a D6 issue, but now it would be good to implement this in D7.
Comment #104
Rosamunda CreditAttribution: Rosamunda commentedSorry, haven´t realized there was a D7 issue already :)
Comment #105
asiby CreditAttribution: asiby as a volunteer and commentedSorry 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.