You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Richard Hirsch <hi...@gmail.com> on 2010/05/10 15:14:54 UTC
Pool messages are displayed where they shouldn't
I think we have to look at the various screens to make sure that they
reflect access pools. Pools are used in the main message screens and in
public. However, the following UIs don't use pools:
* users
* user messages (second tab)
* Streams (when public messages are displayed with no pool filter active)
I've created a Jira item for this problem:
https://issues.apache.org/jira/browse/ESME-212
D.
Re: Pool messages are displayed where they shouldn't
Posted by Richard Hirsch <hi...@gmail.com>.
That would be great .
Thanks.
D.
On Tue, May 11, 2010 at 7:42 AM, Vassil Dichev <vd...@apache.org> wrote:
> > yep - I saw the problem on the stax instance, because ethan posted a
> message
> > in a pool in which I wasn't a member.
>
> Ah, this might be a result of switching to Lift 2.0, there was a
> general handler which overrides all finders in ESME and filters out
> the unauthorized messages. Seems like it doesn't work anymore. I'll
> check.
>
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
> yep - I saw the problem on the stax instance, because ethan posted a message
> in a pool in which I wasn't a member.
Ah, this might be a result of switching to Lift 2.0, there was a
general handler which overrides all finders in ESME and filters out
the unauthorized messages. Seems like it doesn't work anymore. I'll
check.
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
> I don't get it. Why is Long the problem? It looked to me like the issue was
> Set, but I really can't see why Set and List every would have matched, so I
> don't see why this ever worked.
>
> Looks like I need a Scala matching tutorial :-(
Looks like *I* need a Scala tutorial ;-) You're right again, I should
have read the message more carefully.
Apparently, the compiler will issue an error message if we check for
Full(EmptySet), but not if it's a non-empty instance of Set... go
figure.
Re: Pool messages are displayed where they shouldn't
Posted by Ethan Jewett <es...@gmail.com>.
I don't get it. Why is Long the problem? It looked to me like the issue was
Set, but I really can't see why Set and List every would have matched, so I
don't see why this ever worked.
Looks like I need a Scala matching tutorial :-(
Ethan
On Wed, May 12, 2010 at 5:24 PM, Vassil Dichev <vd...@apache.org> wrote:
> Sure enough, if I enable the "-unchecked" argument to the maven-scala
> plugin, I get this warning:
>
> WARNING]
> /media/DISK_IMG/Develop/esme/src/main/scala/org/apache/esme/model/Message.scala:206:
> warning: non variable type-argument Long in type pattern is unchecked
> since it is eliminated by erasure
> [WARNING] case Full(pools: Set[Long]) if !pools.isEmpty => List(
>
> Darn...
>
>
> On Thu, May 13, 2010 at 12:14 AM, Vassil Dichev <vd...@apache.org>
> wrote:
> > You're certainly right, this is the one place where it expects a Set
> > of Long and the compiler doesn't catch this particular match
> > expression because of type erasure.
> >
> > Then maybe I'm seeing a different problem or it's a message from when
> > the cache is built and there are no current logged in users.
> >
> >
> > On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <es...@gmail.com>
> wrote:
> >> Hmmm, interesting. I was able to determine (on my machine at least) that
> >> this chunk of code wasn't executing:
> >>
> >> case Full(pools: Set[Long]) if !pools.isEmpty => List(
> >> BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL
> IS
> >> NULL ",
> >> IHaveValidatedThisSQL("vdichev", "22 June 2009"),
> >> pools.toSeq:_*)
> >>
> >> Because of this, the additional Pool restriction SQL was not getting
> >> appended to the finder. The compiler wouldn't catch this because it is a
> >> matcher, so the code just runs off to the other branch of the match,
> which
> >> doesn't do anything.
> >>
> >> I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it
> began
> >> appending the required SQL.
> >>
> >> I've committed the change, so you can check it out of trunk and see if
> you
> >> get the same results. Let me know how it goes, or if I'm totally off
> base.
> >>
> >> Ethan
> >>
> >>
> >> On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vd...@apache.org>
> wrote:
> >>
> >>> > I think I've got a fix and I'm running through the tests now. I will
> >>> check
> >>> > in shortly if all goes well. Apparently the issue is that
> viewablePools
> >>> is a
> >>> > List[Long], which no longer matches Set[Long].
> >>>
> >>> Hm, I don't think this is the case here. Nowhere is it specified that
> >>> we want a Set[Long], and even if this were a problem, the compiler
> >>> would have caught it. Check this online scala interpreter:
> >>>
> >>>
> >>>
> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
> >>>
> >>> What happens and what Dick has also noticed is that what's inside the
> >>> yield doesn't execute. The problem here is that User.currentUser
> >>> returns Empty (this is an instance of Lift's Box, which is a container
> >>> type). This is probably related to some changes in the User's
> >>> hierarchy, but it's hard to tell why yet.
> >>>
> >>> At least the good news is that findMapDb is always called when it
> >>> should be. However, in order for it to work it must know which is the
> >>> current user- otherwise it cannot know which messages to restrict.
> >>>
> >>> Vassil
> >>>
> >>
> >
>
Re: Pool messages are displayed where they shouldn't
Posted by Richard Hirsch <hi...@gmail.com>.
Looks like we should add "-unchecked" to the maven plug-in in the pom.xml to
catch problems like this. There are also warnings about deprecated code as
well.
On Wed, May 12, 2010 at 11:24 PM, Vassil Dichev <vd...@apache.org> wrote:
> Sure enough, if I enable the "-unchecked" argument to the maven-scala
> plugin, I get this warning:
>
> WARNING]
> /media/DISK_IMG/Develop/esme/src/main/scala/org/apache/esme/model/Message.scala:206:
> warning: non variable type-argument Long in type pattern is unchecked
> since it is eliminated by erasure
> [WARNING] case Full(pools: Set[Long]) if !pools.isEmpty => List(
>
> Darn...
>
>
> On Thu, May 13, 2010 at 12:14 AM, Vassil Dichev <vd...@apache.org>
> wrote:
> > You're certainly right, this is the one place where it expects a Set
> > of Long and the compiler doesn't catch this particular match
> > expression because of type erasure.
> >
> > Then maybe I'm seeing a different problem or it's a message from when
> > the cache is built and there are no current logged in users.
> >
> >
> > On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <es...@gmail.com>
> wrote:
> >> Hmmm, interesting. I was able to determine (on my machine at least) that
> >> this chunk of code wasn't executing:
> >>
> >> case Full(pools: Set[Long]) if !pools.isEmpty => List(
> >> BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL
> IS
> >> NULL ",
> >> IHaveValidatedThisSQL("vdichev", "22 June 2009"),
> >> pools.toSeq:_*)
> >>
> >> Because of this, the additional Pool restriction SQL was not getting
> >> appended to the finder. The compiler wouldn't catch this because it is a
> >> matcher, so the code just runs off to the other branch of the match,
> which
> >> doesn't do anything.
> >>
> >> I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it
> began
> >> appending the required SQL.
> >>
> >> I've committed the change, so you can check it out of trunk and see if
> you
> >> get the same results. Let me know how it goes, or if I'm totally off
> base.
> >>
> >> Ethan
> >>
> >>
> >> On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vd...@apache.org>
> wrote:
> >>
> >>> > I think I've got a fix and I'm running through the tests now. I will
> >>> check
> >>> > in shortly if all goes well. Apparently the issue is that
> viewablePools
> >>> is a
> >>> > List[Long], which no longer matches Set[Long].
> >>>
> >>> Hm, I don't think this is the case here. Nowhere is it specified that
> >>> we want a Set[Long], and even if this were a problem, the compiler
> >>> would have caught it. Check this online scala interpreter:
> >>>
> >>>
> >>>
> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
> >>>
> >>> What happens and what Dick has also noticed is that what's inside the
> >>> yield doesn't execute. The problem here is that User.currentUser
> >>> returns Empty (this is an instance of Lift's Box, which is a container
> >>> type). This is probably related to some changes in the User's
> >>> hierarchy, but it's hard to tell why yet.
> >>>
> >>> At least the good news is that findMapDb is always called when it
> >>> should be. However, in order for it to work it must know which is the
> >>> current user- otherwise it cannot know which messages to restrict.
> >>>
> >>> Vassil
> >>>
> >>
> >
>
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
Sure enough, if I enable the "-unchecked" argument to the maven-scala
plugin, I get this warning:
WARNING] /media/DISK_IMG/Develop/esme/src/main/scala/org/apache/esme/model/Message.scala:206:
warning: non variable type-argument Long in type pattern is unchecked
since it is eliminated by erasure
[WARNING] case Full(pools: Set[Long]) if !pools.isEmpty => List(
Darn...
On Thu, May 13, 2010 at 12:14 AM, Vassil Dichev <vd...@apache.org> wrote:
> You're certainly right, this is the one place where it expects a Set
> of Long and the compiler doesn't catch this particular match
> expression because of type erasure.
>
> Then maybe I'm seeing a different problem or it's a message from when
> the cache is built and there are no current logged in users.
>
>
> On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <es...@gmail.com> wrote:
>> Hmmm, interesting. I was able to determine (on my machine at least) that
>> this chunk of code wasn't executing:
>>
>> case Full(pools: Set[Long]) if !pools.isEmpty => List(
>> BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS
>> NULL ",
>> IHaveValidatedThisSQL("vdichev", "22 June 2009"),
>> pools.toSeq:_*)
>>
>> Because of this, the additional Pool restriction SQL was not getting
>> appended to the finder. The compiler wouldn't catch this because it is a
>> matcher, so the code just runs off to the other branch of the match, which
>> doesn't do anything.
>>
>> I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it began
>> appending the required SQL.
>>
>> I've committed the change, so you can check it out of trunk and see if you
>> get the same results. Let me know how it goes, or if I'm totally off base.
>>
>> Ethan
>>
>>
>> On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vd...@apache.org> wrote:
>>
>>> > I think I've got a fix and I'm running through the tests now. I will
>>> check
>>> > in shortly if all goes well. Apparently the issue is that viewablePools
>>> is a
>>> > List[Long], which no longer matches Set[Long].
>>>
>>> Hm, I don't think this is the case here. Nowhere is it specified that
>>> we want a Set[Long], and even if this were a problem, the compiler
>>> would have caught it. Check this online scala interpreter:
>>>
>>>
>>> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
>>>
>>> What happens and what Dick has also noticed is that what's inside the
>>> yield doesn't execute. The problem here is that User.currentUser
>>> returns Empty (this is an instance of Lift's Box, which is a container
>>> type). This is probably related to some changes in the User's
>>> hierarchy, but it's hard to tell why yet.
>>>
>>> At least the good news is that findMapDb is always called when it
>>> should be. However, in order for it to work it must know which is the
>>> current user- otherwise it cannot know which messages to restrict.
>>>
>>> Vassil
>>>
>>
>
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
You're certainly right, this is the one place where it expects a Set
of Long and the compiler doesn't catch this particular match
expression because of type erasure.
Then maybe I'm seeing a different problem or it's a message from when
the cache is built and there are no current logged in users.
On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <es...@gmail.com> wrote:
> Hmmm, interesting. I was able to determine (on my machine at least) that
> this chunk of code wasn't executing:
>
> case Full(pools: Set[Long]) if !pools.isEmpty => List(
> BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS
> NULL ",
> IHaveValidatedThisSQL("vdichev", "22 June 2009"),
> pools.toSeq:_*)
>
> Because of this, the additional Pool restriction SQL was not getting
> appended to the finder. The compiler wouldn't catch this because it is a
> matcher, so the code just runs off to the other branch of the match, which
> doesn't do anything.
>
> I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it began
> appending the required SQL.
>
> I've committed the change, so you can check it out of trunk and see if you
> get the same results. Let me know how it goes, or if I'm totally off base.
>
> Ethan
>
>
> On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vd...@apache.org> wrote:
>
>> > I think I've got a fix and I'm running through the tests now. I will
>> check
>> > in shortly if all goes well. Apparently the issue is that viewablePools
>> is a
>> > List[Long], which no longer matches Set[Long].
>>
>> Hm, I don't think this is the case here. Nowhere is it specified that
>> we want a Set[Long], and even if this were a problem, the compiler
>> would have caught it. Check this online scala interpreter:
>>
>>
>> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
>>
>> What happens and what Dick has also noticed is that what's inside the
>> yield doesn't execute. The problem here is that User.currentUser
>> returns Empty (this is an instance of Lift's Box, which is a container
>> type). This is probably related to some changes in the User's
>> hierarchy, but it's hard to tell why yet.
>>
>> At least the good news is that findMapDb is always called when it
>> should be. However, in order for it to work it must know which is the
>> current user- otherwise it cannot know which messages to restrict.
>>
>> Vassil
>>
>
Re: Pool messages are displayed where they shouldn't
Posted by Ethan Jewett <es...@gmail.com>.
Hmmm, interesting. I was able to determine (on my machine at least) that
this chunk of code wasn't executing:
case Full(pools: Set[Long]) if !pools.isEmpty => List(
BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS
NULL ",
IHaveValidatedThisSQL("vdichev", "22 June 2009"),
pools.toSeq:_*)
Because of this, the additional Pool restriction SQL was not getting
appended to the finder. The compiler wouldn't catch this because it is a
matcher, so the code just runs off to the other branch of the match, which
doesn't do anything.
I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it began
appending the required SQL.
I've committed the change, so you can check it out of trunk and see if you
get the same results. Let me know how it goes, or if I'm totally off base.
Ethan
On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vd...@apache.org> wrote:
> > I think I've got a fix and I'm running through the tests now. I will
> check
> > in shortly if all goes well. Apparently the issue is that viewablePools
> is a
> > List[Long], which no longer matches Set[Long].
>
> Hm, I don't think this is the case here. Nowhere is it specified that
> we want a Set[Long], and even if this were a problem, the compiler
> would have caught it. Check this online scala interpreter:
>
>
> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
>
> What happens and what Dick has also noticed is that what's inside the
> yield doesn't execute. The problem here is that User.currentUser
> returns Empty (this is an instance of Lift's Box, which is a container
> type). This is probably related to some changes in the User's
> hierarchy, but it's hard to tell why yet.
>
> At least the good news is that findMapDb is always called when it
> should be. However, in order for it to work it must know which is the
> current user- otherwise it cannot know which messages to restrict.
>
> Vassil
>
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
> I think I've got a fix and I'm running through the tests now. I will check
> in shortly if all goes well. Apparently the issue is that viewablePools is a
> List[Long], which no longer matches Set[Long].
Hm, I don't think this is the case here. Nowhere is it specified that
we want a Set[Long], and even if this were a problem, the compiler
would have caught it. Check this online scala interpreter:
http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
What happens and what Dick has also noticed is that what's inside the
yield doesn't execute. The problem here is that User.currentUser
returns Empty (this is an instance of Lift's Box, which is a container
type). This is probably related to some changes in the User's
hierarchy, but it's hard to tell why yet.
At least the good news is that findMapDb is always called when it
should be. However, in order for it to work it must know which is the
current user- otherwise it cannot know which messages to restrict.
Vassil
Re: Pool messages are displayed where they shouldn't
Posted by Ethan Jewett <es...@gmail.com>.
I think I've got a fix and I'm running through the tests now. I will check
in shortly if all goes well. Apparently the issue is that viewablePools is a
List[Long], which no longer matches Set[Long].
Ethan
On Wed, May 12, 2010 at 4:53 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Vassil is right - findMapDb isn't working any more.
>
> I'm assuming that viewablePools is always empty, it looks like "
> Privilege.findViewablePools(user.id.is)" isn't even being called. No idea
> why - might be the "yield"
>
> D.
>
> override def findMapDb[T](dbId : ConnectionIdentifier, by :
> QueryParam[Message]*)(f : (Message) => Box[T]): List[T] = {
> // modify behavior of find methods so that results include only
> authorized pools of current user
> val user = User.currentUser
>
> val viewablePools =
> for (user <- User.currentUser) yield {
> println ("user.id.is: " + user.id.is);
> Privilege.findViewablePools(user.id.is)
> }
>
>
> val newQueryParams: Seq[QueryParam[Message]] = viewablePools match {
> case Full(pools: Set[Long]) if !pools.isEmpty => List(
> BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS
> NULL ",
> IHaveValidatedThisSQL("vdichev", "22 June 2009"),
> pools.toSeq:_*)
> )
> case _ => Nil
> }
> logger.info("Pool Modified query newQueryParams: " + newQueryParams)
> val modifiedQueryParams = by ++ newQueryParams
> logger.info("Pool Modified query: " + modifiedQueryParams)
> super.findMapDb(dbId, modifiedQueryParams:_*)(f)
> }
>
>
>
> On Tue, May 11, 2010 at 4:19 PM, Vassil Dichev <vd...@apache.org> wrote:
>
> > > @Vassil - where are the lift finders?
> >
> > There's findMapDb in Message.scala, which was supposed to be called by
> > everything which implements a mapper (such as Message). This is
> > brittle and doesn't seem to work, however, probably Lift 2.0 changed
> > their find method hierarchy.
> >
>
Re: Pool messages are displayed where they shouldn't
Posted by Richard Hirsch <hi...@gmail.com>.
Vassil is right - findMapDb isn't working any more.
I'm assuming that viewablePools is always empty, it looks like "
Privilege.findViewablePools(user.id.is)" isn't even being called. No idea
why - might be the "yield"
D.
override def findMapDb[T](dbId : ConnectionIdentifier, by :
QueryParam[Message]*)(f : (Message) => Box[T]): List[T] = {
// modify behavior of find methods so that results include only
authorized pools of current user
val user = User.currentUser
val viewablePools =
for (user <- User.currentUser) yield {
println ("user.id.is: " + user.id.is);
Privilege.findViewablePools(user.id.is)
}
val newQueryParams: Seq[QueryParam[Message]] = viewablePools match {
case Full(pools: Set[Long]) if !pools.isEmpty => List(
BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS
NULL ",
IHaveValidatedThisSQL("vdichev", "22 June 2009"),
pools.toSeq:_*)
)
case _ => Nil
}
logger.info("Pool Modified query newQueryParams: " + newQueryParams)
val modifiedQueryParams = by ++ newQueryParams
logger.info("Pool Modified query: " + modifiedQueryParams)
super.findMapDb(dbId, modifiedQueryParams:_*)(f)
}
On Tue, May 11, 2010 at 4:19 PM, Vassil Dichev <vd...@apache.org> wrote:
> > @Vassil - where are the lift finders?
>
> There's findMapDb in Message.scala, which was supposed to be called by
> everything which implements a mapper (such as Message). This is
> brittle and doesn't seem to work, however, probably Lift 2.0 changed
> their find method hierarchy.
>
Re: Pool messages are displayed where they shouldn't
Posted by Vassil Dichev <vd...@apache.org>.
> @Vassil - where are the lift finders?
There's findMapDb in Message.scala, which was supposed to be called by
everything which implements a mapper (such as Message). This is
brittle and doesn't seem to work, however, probably Lift 2.0 changed
their find method hierarchy.
Re: Pool messages are displayed where they shouldn't
Posted by Richard Hirsch <hi...@gmail.com>.
@Vassil - where are the lift finders?
On Tue, May 11, 2010 at 3:01 PM, Ethan Jewett <es...@gmail.com> wrote:
> Hope it didn't say anything under NDA! I'm working on a secret project
> called "Test". Whoops, I've said too much ;-)
>
> More seriously, I like Vassil's theory. The search filters seem to be
> working fine, but those are not normal Lift finders.
>
> Ethan
>
> On Mon, May 10, 2010 at 11:34 PM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
>
> > yep - I saw the problem on the stax instance, because ethan posted a
> > message
> > in a pool in which I wasn't a member.
> >
> > On Mon, May 10, 2010 at 10:22 PM, Anne Kathrine Petterøe
> > <yo...@gmail.com>wrote:
> >
> > > Do these UIs display all messages from that user?
> > >
> > > On 10. mai 2010, at 15.14, Richard Hirsch wrote:
> > >
> > > > I think we have to look at the various screens to make sure that they
> > > > reflect access pools. Pools are used in the main message screens and
> in
> > > > public. However, the following UIs don't use pools:
> > > > * users
> > > > * user messages (second tab)
> > > > * Streams (when public messages are displayed with no pool filter
> > active)
> > > >
> > > > I've created a Jira item for this problem:
> > > > https://issues.apache.org/jira/browse/ESME-212
> > > >
> > > > D.
> > >
> > >
> >
>
Re: Pool messages are displayed where they shouldn't
Posted by Ethan Jewett <es...@gmail.com>.
Hope it didn't say anything under NDA! I'm working on a secret project
called "Test". Whoops, I've said too much ;-)
More seriously, I like Vassil's theory. The search filters seem to be
working fine, but those are not normal Lift finders.
Ethan
On Mon, May 10, 2010 at 11:34 PM, Richard Hirsch <hi...@gmail.com>wrote:
> yep - I saw the problem on the stax instance, because ethan posted a
> message
> in a pool in which I wasn't a member.
>
> On Mon, May 10, 2010 at 10:22 PM, Anne Kathrine Petterøe
> <yo...@gmail.com>wrote:
>
> > Do these UIs display all messages from that user?
> >
> > On 10. mai 2010, at 15.14, Richard Hirsch wrote:
> >
> > > I think we have to look at the various screens to make sure that they
> > > reflect access pools. Pools are used in the main message screens and in
> > > public. However, the following UIs don't use pools:
> > > * users
> > > * user messages (second tab)
> > > * Streams (when public messages are displayed with no pool filter
> active)
> > >
> > > I've created a Jira item for this problem:
> > > https://issues.apache.org/jira/browse/ESME-212
> > >
> > > D.
> >
> >
>
Re: Pool messages are displayed where they shouldn't
Posted by Richard Hirsch <hi...@gmail.com>.
yep - I saw the problem on the stax instance, because ethan posted a message
in a pool in which I wasn't a member.
On Mon, May 10, 2010 at 10:22 PM, Anne Kathrine Petterøe
<yo...@gmail.com>wrote:
> Do these UIs display all messages from that user?
>
> On 10. mai 2010, at 15.14, Richard Hirsch wrote:
>
> > I think we have to look at the various screens to make sure that they
> > reflect access pools. Pools are used in the main message screens and in
> > public. However, the following UIs don't use pools:
> > * users
> > * user messages (second tab)
> > * Streams (when public messages are displayed with no pool filter active)
> >
> > I've created a Jira item for this problem:
> > https://issues.apache.org/jira/browse/ESME-212
> >
> > D.
>
>
Re: Pool messages are displayed where they shouldn't
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
Do these UIs display all messages from that user?
On 10. mai 2010, at 15.14, Richard Hirsch wrote:
> I think we have to look at the various screens to make sure that they
> reflect access pools. Pools are used in the main message screens and in
> public. However, the following UIs don't use pools:
> * users
> * user messages (second tab)
> * Streams (when public messages are displayed with no pool filter active)
>
> I've created a Jira item for this problem:
> https://issues.apache.org/jira/browse/ESME-212
>
> D.