[xwiki-devs] Message Stream (aka User Status) needs for final 3.0 release
Hi (Sergiu), I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production: * Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org. * Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB). WDYT? Thanks -Vincent
On 03/10/2011 12:22 PM, Vincent Massol wrote:
I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production:
* Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org.
K, but I didn't do anything to customize the wiki filtering, that part was supposed to be handled already by the main {{activity}} code. I just added more constraints on messages. If events do leak, then it's a bug in the activity macro. Did you test it and encountered this problem?
* Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB).
K, I already added the method to the Java component. But currently only the author has the right to remove it, since there's no way to check if a user has admin rights from components. It can be done via a script with PR. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mar 10, 2011, at 6:53 PM, Sergiu Dumitriu wrote:
On 03/10/2011 12:22 PM, Vincent Massol wrote:
I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production:
* Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org.
K, but I didn't do anything to customize the wiki filtering, that part was supposed to be handled already by the main {{activity}} code. I just added more constraints on messages. If events do leak, then it's a bug in the activity macro. Did you test it and encountered this problem?
No I don't have an instance to test it but 'd like to upgrade myxwiki to 3.0M3 tomorrow and I wanted to be sure it's working since you mentioned that filtering wasn't working for message stream. If it's working then great.
* Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB).
K, I already added the method to the Java component. But currently only the author has the right to remove it, since there's no way to check if a user has admin rights from components. It can be done via a script with PR.
I didn't see a way for a user to remove a message. Can you confirm it's possible from the UI? Good to know that at least we have a workaround by writing a script in a page. Thanks -Vincent
On 03/10/2011 07:22 PM, Vincent Massol wrote:
On Mar 10, 2011, at 6:53 PM, Sergiu Dumitriu wrote:
On 03/10/2011 12:22 PM, Vincent Massol wrote:
I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production:
* Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org.
K, but I didn't do anything to customize the wiki filtering, that part was supposed to be handled already by the main {{activity}} code. I just added more constraints on messages. If events do leak, then it's a bug in the activity macro. Did you test it and encountered this problem?
No I don't have an instance to test it but 'd like to upgrade myxwiki to 3.0M3 tomorrow and I wanted to be sure it's working since you mentioned that filtering wasn't working for message stream. If it's working then great.
I didn't do any explicit filtering for messages, but the basic filters for generic events are still in place. For example, this is why on a user's profile page, only messages from that user are displayed (the event.user condition is inherited from the {{activity users="X"}} filtering.
* Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB).
K, I already added the method to the Java component. But currently only the author has the right to remove it, since there's no way to check if a user has admin rights from components. It can be done via a script with PR.
I didn't see a way for a user to remove a message. Can you confirm it's possible from the UI?
No, not yet, but I'm working on it.
Good to know that at least we have a workaround by writing a script in a page.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mar 11, 2011, at 3:23 PM, Sergiu Dumitriu wrote:
On 03/10/2011 07:22 PM, Vincent Massol wrote:
On Mar 10, 2011, at 6:53 PM, Sergiu Dumitriu wrote:
On 03/10/2011 12:22 PM, Vincent Massol wrote:
I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production:
* Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org.
K, but I didn't do anything to customize the wiki filtering, that part was supposed to be handled already by the main {{activity}} code. I just added more constraints on messages. If events do leak, then it's a bug in the activity macro. Did you test it and encountered this problem?
No I don't have an instance to test it but 'd like to upgrade myxwiki to 3.0M3 tomorrow and I wanted to be sure it's working since you mentioned that filtering wasn't working for message stream. If it's working then great.
I didn't do any explicit filtering for messages, but the basic filters for generic events are still in place. For example, this is why on a user's profile page, only messages from that user are displayed (the event.user condition is inherited from the {{activity users="X"}} filtering.
* Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB).
K, I already added the method to the Java component. But currently only the author has the right to remove it, since there's no way to check if a user has admin rights from components. It can be done via a script with PR.
I didn't see a way for a user to remove a message. Can you confirm it's possible from the UI?
No, not yet, but I'm working on it
Great. BTW is there a setting to disable having the user status input form on the main dashboard? I'm not sure everyone will want to have it by default and I' m not sure we want it on in the default XE. Thanks -Vincent
Good to know that at least we have a workaround by writing a script in a page.
On Fri, Mar 11, 2011 at 3:56 PM, Vincent Massol <vincent@massol.net> wrote:
On Mar 11, 2011, at 3:23 PM, Sergiu Dumitriu wrote:
On 03/10/2011 07:22 PM, Vincent Massol wrote:
On Mar 10, 2011, at 6:53 PM, Sergiu Dumitriu wrote:
On 03/10/2011 12:22 PM, Vincent Massol wrote:
I think there are 2 things we absolutely need in the message stream (user status) implementation before we can release 3.0 final, ie so that it can be put in production:
* Ability to filter user statuses per wiki. On a XEM install a user status sent in a given subwiki shouldn't leak to another subwiki. This is required for example for myxwiki.org.
K, but I didn't do anything to customize the wiki filtering, that part was supposed to be handled already by the main {{activity}} code. I just added more constraints on messages. If events do leak, then it's a bug in the activity macro. Did you test it and encountered this problem?
No I don't have an instance to test it but 'd like to upgrade myxwiki to 3.0M3 tomorrow and I wanted to be sure it's working since you mentioned that filtering wasn't working for message stream. If it's working then great.
I didn't do any explicit filtering for messages, but the basic filters for generic events are still in place. For example, this is why on a user's profile page, only messages from that user are displayed (the event.user condition is inherited from the {{activity users="X"}} filtering.
* Ability to remove a given user status. Imagine that we upgrade xwiki.org or myxwiki.org to 3.0M3 and someone registers and send a user status with some spam content... We wouldn't be able to remove it (except by having to go to the DB).
K, I already added the method to the Java component. But currently only the author has the right to remove it, since there's no way to check if a user has admin rights from components. It can be done via a script with PR.
I didn't see a way for a user to remove a message. Can you confirm it's possible from the UI?
No, not yet, but I'm working on it
Great.
BTW is there a setting to disable having the user status input form on the main dashboard? I'm not sure everyone will want to have it by default and I' m not sure we want it on in the default XE.
I agree. At least it could be a separate gadget on the dashboard. Jerome
Thanks -Vincent
Good to know that at least we have a workaround by writing a script in a page.
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol