as promised, here's my first pass at views integration for privatemsg. It is definitely a first pass, with a lot of functionality missing. What it does do:
- exposes privatemsg as a base table for views, allowing you to create views of messages.
- provides all of the fields from the pm_index and pm_message tables as fields for views
- provides a message field handler that will link a subject to the message view
- provides a handful of filters
- provides relationships to the user table, for both recipient and author
- provides a default view of an inbox. this is really just a proof of concept so that reviewers don't need to create a view to review the patch.
This patch works much better in conjunction with #502664: remove duplicate records from pm_index and add primary key. Otherwise you will see messages that you have sent in your inbox.
Also check out #502666: devel_generate functionality to help create a bunch of messages for testing!
Comment | File | Size | Author |
---|---|---|---|
#30 | privatemsg-views-integration.patch | 13.18 KB | infojunkie |
#29 | privatemsg-views-integration.patch | 11.12 KB | infojunkie |
#12 | privatemsg-views-integration.patch | 11.06 KB | dagmar |
privatemsg.views_.patch | 16.02 KB | zroger |
Comments
Comment #1
BerdirWell, the problem is that this does display each message on it's own. While this might work, you cannot view that message then, because the links point to messages/view/{mid}. However, that needs to be messages/view/{thread_id}. But then, you view the thread, and not the message.
Comment #2
RoboPhred CreditAttribution: RoboPhred commentedThere is another views integration patch at #502688: Views integration
Comment #3
Michsk CreditAttribution: Michsk commenteddamn i reallllly hoped this module had a views integration... any idea how long it would take for a views integration?
Comment #4
BerdirFor messages? Long, because our queries to select them correctly ( with threads and everything) are really complex and cannot be converted to a view easily. However, there is a patch that adds a "send user a message" link integration for views, that can be used for node and user listing...
Comment #5
Michsk CreditAttribution: Michsk commentedwould it be possible to get the query to select messages from the module source, and with a little bit of tweaking place that in a block. I don't necessarily need it to be in a view, but i would need it in a block.
// i would only need the title, participates and date to show, when they click a row they would be send to the messages page with the clicked message
Comment #6
BerdirYou don't even need the query, we have a API function for that, see #492822: to display latest 5 (more or less) messages
Comment #7
Michsk CreditAttribution: Michsk commentedawesome thanks!
Comment #8
SystemicPlural CreditAttribution: SystemicPlural commentedThis is looking great. One minor issue:
I can't work out how to create a delete message link. (sorted)Also, it would be great if it integrated with flags.
Comment #9
R.Hendel CreditAttribution: R.Hendel commentedHi - I would be happy having a views implementation.
subscribing...
Comment #10
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #11
rburgundy CreditAttribution: rburgundy commentedhowdy- may I kindly ask if there is any update on this with release of privatemsg v1.0
Comment #12
dagmarI want to participate in this task.
I have relloled this patch and added some filters, sorts options, and removed the view_default for now, I think we should add the privatemsg.views_default.inc once views integration be working.
I have renamed views_handler_field_privatemsg to views_handler_field_privatemsg_subject and added an initial handler to display Participants.
There is two @TODO notes that remark features that still have to be implemented.
After this be done, I think we should provide a privatemsg.view_default.inc file with this views:
My Private Messages
Private messages for user %uid
Since they use some complex relationships + arguments configurations.
One last thing, I would like to add views bulk operation support for this two operations
Mark private message as readed.
Mark private message as unreaded.
If anybody can take care about the vbo support I will apreciate.
I will try to complete the unfinished parts soon.
Comment #13
BerdirYou are of course welcome to work on this, I assume the list still shows a list of messages and not threads?
The latter is imho not possible without GROUP BY support. There are other issues, for example that the Inbox list currently even needs HAVING.
Comment #14
BerdirAlso, I'm interested to hear why there are so many interested in this, what do you except and what do you want to do?
- There is no fancy UI, but privatemsg contains a simple query builder (with hooks) too and the list table should be quite flexible to extend with more columns or change existing ones.
- As said above, I don't believe that views can do the same as we do currently in our listings, these queries are simply way to complex at the moment.
Comment #15
artscoop CreditAttribution: artscoop commentedHi Berdir,
Actually I use this on a site to prevent spam and scams.
I display a view of titles (not message content, as it is the most private part) of the latest sent messages on the site.
This way I can spot very quickly the spamming users : They send 10, 100, or even 500 times a message in a few minutes (despite the use of Message Limit)
Without the Views integration, most of them may not be seen and banned.
Comment #16
rburgundy CreditAttribution: rburgundy commentedI have been using views and privatemsg a lot recently and really appreciate the development of both modules. From a beginners perspective, it seems a lot easier to customize columns with views, and so I have been following the privatemsg views integration.
Comment #17
BenK CreditAttribution: BenK commentedSubscribing.... +1
Comment #18
Bilmar CreditAttribution: Bilmar commentedHi dagmar!
I'm so glad to hear you will be helping Privatemsg integrate with Views!
I really feel this is going to be a great new feature to Privatemsg, and, from what I've learned about Views in the past couple months, I believe it will add a lot of value.
Patching went smoothly and I tested by creating a Private Message view type and added all the fields available.
All fields showed correct information except for:
1) Adding field "Private message: Subject" resulted in error "Broken/missing handler Broken handler pm_message.subject"
2) Participants field did not show any information
I look forward to your next update on this!
Comment #19
crea CreditAttribution: crea commentedSubscribing
Comment #20
crea CreditAttribution: crea commentedViews is great in many aspects:
- flexible theming - including basic theming without coding
- easy configuration with almost no coding. Possible to alter columns very easy and fast. How about adding user avatar in message list, or "contact list" ? In Views it's several clicks away.
- integration with tons of modules, plugins. Display plugins of views will allow to display messages in different ways. View panes and blocks are especially cool because you can create several blocks containing message lists with different columns - e.g. small list for sidebar, medium list for middle, full sized list for big Panel page.
Comment #21
BerdirYeah, I know that Views is great, the question was more what specific things you want to to with Views integration as most should already be possible with the existing hooks and theme functions.
The issue is, there is a really complex backend behind those lists, with big and complex queries. There are queries which are simply *not* possible with Views, for example GROUP BY and HAVING stuff.
Also, we do have our own query builder and there are several modules that integrate with it, so everything would have to be rewritten or duplicated.
And our theming layer isn't that bad either, it's actually quite similiar to the one that comes with Views except the nice UI that views does have. See http://blog.worldempire.ch/api/group/theming/1. You can theme each column/field differently and add new columns.
Also (and I know that it isn't as easy as in Views, but not hard either), you can easily create a list of messages for a block, see http://drupal.org/node/624528
Comment #22
crea CreditAttribution: crea commentedI understand your points, but I'm not arguing that it's not achievable with Privatemsg alone. Everything is possible with lots of custom coding. Rather, it's much more simple with Views.
Btw, Views 3.x has GROUP BY support.
Comment #23
YK85 CreditAttribution: YK85 commentedHi, I was wondering if there has been any further development in Views Integration?
Thank you
Comment #24
crea CreditAttribution: crea commented@yaz085
I plan to look at it at some point later. It's not high priority for me, since Private Messages can be used without this, but stil it's on my todo list.
@Berdir:
Even if we won't have Views integration for lists of threads, it could still be very good partial integration. And it's not uncommon to integrate partially: for example, when DruBB group discussed Views integration to get rid of forum module, they totally abandoned Views for forum containers, partially because there were no real payout for the effort. Real goodness were forum threads - i.e. lists of posts - that's where Views shine.
Btw recently I got cool idea, related to this feature. One example of Views goodness: if we had Views integration it would be possible to use Views Accordeon module to show messages in sidebar. When I had a look at that module, first idea was : that would make really nice pager.
Comment #25
NaheemSays CreditAttribution: NaheemSays commented@ Crea - the problem with partial implementations is that Private messages are by nature private and should remain so. Having a partial or incomplete implementation may jeopardise the security that is afforded by this module.
Comment #26
crea CreditAttribution: crea commented@nbz: Huh ? Ofcourse private stuff should remain private even in Views...the point of discussion is _some_ integration is still much better than nothing.
Comment #27
litwol CreditAttribution: litwol commentedi really want to "won't fix" this or at the very least postpone until d7 where views will hopefully work out of the box with any custom fieldable entity.
/me considers.
Comment #28
crea CreditAttribution: crea commentedWhatever.. Views integration could always be provided in third-party module since it's possible to attach handlers to any table. Just a matter of management.
Comment #29
infojunkieViews integration is important for site builders who want to minimize hand-theming. I am using the patch here to create a message list with some custom user profile fields. I don't even want to think about the code I would have to write without Views :-)
Attached is a new version of the patch that fixes the subject field. I didn't fix the participants field.
Comment #30
infojunkieI've been working a lot on this module lately, so here's another patch with new features:
* A "Private message: Head?" filter that allows to filter messages by thread: only returns messages where mid = thread_id
* A "Private message: Count" field that returns the number of messages per thread
Enjoy!
Comment #31
YK85 CreditAttribution: YK85 commentedawesome to see big leaps towards views integration!
are the below some areas that you may be able to look into? (some highlighted in #12 by dagmar)
1) the relationships + arguments configurations needed for a My Private Messages view.
2) bulk operation support for 'Mark as read' and 'Mark as unread' and 'Delete' and 'Tag'
3) an icon to show for HAS attachment? [privatemsg now supports attachments with messages]
4) a view for the actual message thread - would be awesome to have the messages already read to be collapsed and the new messages to be not collapsed [kinda like how gmail works]
5) participants field => it would be nice to be able to replace the current logged in user's name with 'me' so for example if it was Jack and Jill (Jill being the current logged in user looking at her inbox) it would say Participants: Jack, me
I look forward to testing your patch above tonight!
Comment #32
crea CreditAttribution: crea commentedUnless someone stops me, I'm going to open a separate "privatemsg_views" project and start from there.
Comment #33
YK85 CreditAttribution: YK85 commentedI was wondering if the work on privatemsg_views cannot be continued here and included with the core privatemsg module?
Will you be continuing the work from #30? It would be really great to see this further develop =)
Comment #34
crea CreditAttribution: crea commentedWell the issue here is Views integration is optional feature and given that the developers are already satisfied with how PM own UI works, it makes sense to split this to a separate project and not put additional stress on maintainers of PM. Also it's worth to notice #735132: Refactor code to move UI in a submodule here cause it's related
Comment #35
crea CreditAttribution: crea commentedhttp://drupal.org/project/privatemsg_views
Comment #36
crea CreditAttribution: crea commentedHmmmm, Is it good idea to query like that: "SELECT DISTINCT(pm_index.thread_id), ... from pm_index ...." ?
Comment #37
YK85 CreditAttribution: YK85 commentedthanks for the explanation! i look forward to following you work at http://drupal.org/project/privatemsg_views
Comment #38
robby.smith CreditAttribution: robby.smith commented+1 subscribing - was this the agreed upon decision with the maintainers of privatemsg?
maybe it would be better if crea was to join as a co-maintainer of privatemsg to support the views integration going forward?
Comment #39
NaheemSays CreditAttribution: NaheemSays commentedWithout working code it is just an experiment.
If it gets done (in a secure manner), then where the code stays is a secondary concern IMO.
As for what queries to use, the way I do things is to just experiment and see if they throw up the correct results.
Comment #40
litwol CreditAttribution: litwol commentedplease continue related discussion with relevant project :)
Comment #41
infojunkieConcerning comment #36, displaying threads: threads are not well-defined in the privatemsg data model. For example, there is no {pm_thread} table that contains the thread subject, and towards which {pm_message} would hold a foreign key. Instead, we have {pm_index} which is just a map of threads to messages, but we still need to get the thread info from the message table.
My solution to find threads is included in my latest patch (#30), in the form of the "Head?" filter (bad name perhaps). This filter only returns messages where thread_id = mid, which is the definition of a thread as far as I could tell.
Comment #42
Bilmar CreditAttribution: Bilmar commentedvery exciting updates!
we all look forward to your work crea
Comment #43
crea CreditAttribution: crea commented@infojunkie:
Yeah, I thought about adding pm_thread too. Having a secret object in the database which you can't access directly is very confusing from developer point imho :(
Comment #44
crea CreditAttribution: crea commentedFYI, I've also found some good SQL tricks on topic ;)
I especially liked LEFT JOIN trick.
http://dev.mysql.com/doc/refman/5.0/en/example-maximum-column-group-row....
Comment #45
crea CreditAttribution: crea commentedI've made first commit with initial support for threads, basic handlers, advanced handlers for message counts and participants. I've also provided default View that mimics Gmail. It needs user argument and will only work for currently logged-in user, so make sure you add "page" or "pane" display depending on if you embed your View in a page or in Panels.
I'm closing this issue. For further discussions separate please open separate issues.
Comment #46
YK85 CreditAttribution: YK85 commentedvery exciting! i will be testing this tonight
thanks for the hard work!
Comment #47
yajnin CreditAttribution: yajnin commentedSubscribe.
##
PS: This is a super cool module to have discovered. Thank you!
Comment #48
superdorx CreditAttribution: superdorx commentedSubscribe =)
Comment #50
mrgoltra CreditAttribution: mrgoltra commentedsubscribing.