Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Not sure why you created this module...
- privatemsg.module has a privatemsg_get_link() function that is much more advanced that your privatemsg_adv_create_link('message') (checks permissions, *all* possible blocking reasons (not just the hard-coded pm_block_user check) and multiple recipients). There was a bug in that function, see #896880: Recipients array is not keyed by uid in privatemsg_get_link() when checking for blocking.
- I suggested that you create a patch to split the block/unblock check into a separate function. Note that your version is incomplete since it doesn't account for the blocking rules that are part of pm_block_user. They can for example disallow someone to block users of a specific role. See #893184: API function to get block/unblock link.
- Privatemsg already has views integration for the send message link and I'm willing to accept a patch that adds the block/unblock link integration as well.
- Note that you have a dependency on pm_block_user as well, you actually query the tables directly instead of using the existing hooks/apis.
I am trying to avoid confusion for users when they are looking for modules. Your module name sounds... well, advanced while it in fact only does minor things and you don't have a single line in your project description that says what your module actually does.
Comments
Comment #1
quiptime commentedAnswer:
See also http://drupal.org/node/894450#comment-3383832
The PM adv module realized no bug fixes.
PM adv don't needs to check specific roles to test if a user blocked or unblocked. But, I can implement this.
PM adv implemented functions for the brunch 1. And, who used PM in version 1, does not have to implement several patches to get functionalities - he can simply use PM adv.
I see it differently.
You are not accepted my first patch for brunch 1. See http://drupal.org/node/894450#comment-3383344
Please, feel free to use the code from PM adv to implement the missing functions to brunch 1.
But, I will send patches to integrate the Realname compatibility.
But, I will send patches to correct the illogical confirm messages of block and unblock actions.
There is no reason to use the hooks and API functions. It works perfectly without. And so I am independent of the two PM versions.
Sorry for that. You've read the projects page at a time when I worked on it. Meanwhile, the project site has been corrected.
========================
Your topic title "Merge with privatemsg?"
I have no problem if one takes over the code of PM adv. As I said earlier: Please, feel free to use the code from PM adv to implement the missing functions to brunch 1.
Comment #2
berdirYes. But that doesn't mean that we can't add the additional feature (IMHO, there is only one, the block/unblock views integration) to 6.x-2.x.
No, the module obviously doesn't. But it's a feature of pm_block_user.module and users which use that feature might want to use your module as well. What your module currently does is implementing a specific use case. That's how custom modules work, contrib modules should be flexible and configurable.
I don't see how you could see anything differently. That the link shows up when a user has blocked you is a simple bug, fixed by this patch #896880: Recipients array is not keyed by uid in privatemsg_get_link() when checking for blocking. Apply the patch and try it out yourself. With this patch, privatemsg_get_link() does everything privatemsg_adv_create_link('message') does and more. Again, I don't see how you can see it differently.
No, because that feature is already part of 6.x-2.x. (And there it is a site configuration setting, and it works for *all* write this user a message links not only the views integration.).
First, what I meant is that you don't specific in your .info file (nor say it anywhere) that the pm_block_user module must be enabled. If someone enables your module without having pm_block_user enabled, he will get ugly sql errors. Second, there are many reasons to use the apis/hooks and being independent of the version is not a reason against, actually the opposite. For example, Privatemsg 6.x-2.x has a setting that allows users to disable private messaging for them, disallowing others to write them messages. And for example UR provides integration with privatemsg so that you can only send private messages to your friends. Sites might even have custom modules that implement blocking rules. Currently, privatemsg_adv doesn't work together with all these features/modules. If it would would use the hook, all of these would just work.
I don't see where you say something along the lines of "This module provides views integration for the block/unblock link" etc. You are only saying that it extends privatemsg but not *how*.
Comment #3
crea commentedYou could contribute to the Privatemsg Views module which has much better Views integration for Privatemsg 1.x. There is no need to create another module just to provide 1 more handler.
And I also think "Privatemsg Advanced" is too loud & misleading title for this module.
Comment #4
berdirThat would be possible as well, but I'm totally fine with adding that to privatemsg.module as well. It's similar to the send message to author link and doesn't depend on anything that privatemsg_views provides.
I think there is already an issue for that, all it needs is a patch...
Agreed, that's what I was trying to say above.