On Feb 23, 2012, at 3:13 PM, Guillaume Lerouge wrote:
Hi Joris,
plese see my answers below.
On Thu, Feb 23, 2012 at 12:56 PM, Joris Dirks <[email protected]> wrote:
Before I promote this to a bug or improvement request, I'd like to get your feedback on my perceived problem.
I'm having some trouble understanding how messages are handles. I must admit I don't even know where messages are being stored (googling "messages xwiki" doesn't exactly provide useful results ;) I expect all messages are stored in one general storage.
It's a bit more complicated than that. Messages are not stored in objects nor documents the traditional XWiki way. They are stored as events in the activity stream itself. Thus they do not respect the usual XWiki best practices (I'm not even sure you can search the content of a message for instance).
Example usage:
1) create space Sandbox2 2) restrict view right for space Sandbox2 3) using SpaceDashboardTemplate, create dashboard for Sandbox2.WebHome 4) post message on this dashboard using the activity gadget, without changing the "visible to everyone"
Result: message is not shown on Sandbox2.WebHome dashboard
This is because the message is stored globally whereas the code in space dashboard display only the activity happening in that given space. In other words, the message itself does not know that it is being posted from the homepage of a specific space.
message is shown on Dashboard.WebHome
User (at least I) would expect the message to be shown: - on Sandbox2.WebHome dashboard, because it's written there/for this group - on Dashboard.WebHome only when user has access to space Sandbox2., with the attribution: "ExampleUser posted the message *in Sandbox2*"
I expect this would change the fundamentals behind the messaging app because messages would have to be stored in a page in the space they are written in,
Yes, that's a normal expectation, but as desribed above messages don't really follow the usual XWiki conventions.
so I propose removing the 'post message' block in the activity stream when called for a space ($aSpace != $util.null)
Indeed, that sounds like an acceptable workaround. In any case I think a parameter to select whether or not to display the message box should be included by default in the {{activity /}} macro.
For me it's completely separate and shouldn't be displayed at all by the activity macro. It should be displayed by another macro. And I think it should also be located in a different gadget. Thanks -Vincent
I already had to remove it by hand several times, this is not optimal.
Guillaume