Jump to:
| Project: | Message |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I am pushing Message to the limit, trying to build a master listing of all messages in the system that a user can access, each decorated with certain betweens of JOINed in data particular to the general kind of message. Unfortunately, this is leading me into some difficulties. It turns out that the Message module really doesn't like to deal with more than one realm at a time, and if it must, it prefers to treat all the different realms as exclusive requirements (must have each realm).
This is difficult when I am trying to build a view of messages that are sometimes related to an organic group, sometimes not. Sometimes related to a node, and sometimes leaning on message to be it's own entity for a short note.
At this point, I am starting to think I need to denormalize the message_instance and message_realm tables, but that would amount to forking the module. I invite any thoughts about alternatives.
Comments
#1
I think that the problem isn't with the Realms, but with its integration with Views. Maybe your queries are to hard to define in one query, or just to hard for Views.
Maybe you should opt for your own listing API that returns the Ids for the message instance. Those message instance you can pass to views as arguments, to get the display you want?
#2
That's an interesting idea, will go chew on that.
EDIT: Okay, quick chew.
The problem with that is once I have all the iid's I want, I still need to pull information in from joins off of each realm. So if I grab all the iids, I'll still have problems with getting at the node associated with message instances that have a node association, and something else associated with message instances that are not.
#3
> I'll still have problems with getting at the node associated with message instances that have a node association
But you can define your own callback and in that callback apply your logic, no?
#4
That is either good insight or unrelated. So I will take another stab at explaining. It is certainly possible that I have a blindspot here.
I want to create a message view with two qualities different from the existing use cases.
The problem I am finding is also twofold:
#5
So if I understand correctly, indeed we have two choices:
1) Look at the code for the access realms and see how to make it OR (AFAIK views 3 allows ORing filters)
2) As I mention in #1. You will not rely on Views to do the query, just to display the result. The query will be handled by your own custom code.
#6
In the last day, it became very clear that one or more subqueries would be necessary to achieve this.
I'm going to change this to a feature request, because a clean way of showing all accessible messages in a master message view seems like something which should be core to the module. If it can't be code, very clear documentation would be useful.
I have no more time to do this right now, so I've pushed back the full scope to another phase of the project, but when I get back to it I will update with what I did.
#7