<div dir="ltr">OK，thanks @gord<div><br></div><div>Look forward to other people's suggestion.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 5, 2017 at 12:12 AM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<br>
i think this is best to ask this on mailing list. to be honest, i do not<br>
work on Panko much anymore. feel free to propose something if it doesn't<br>
meet your requirements.<br>
<span class=""><br>
On 04/08/17 10:59 AM, Along Meng wrote:<br>
> HI, gord<br>
><br>
> <a href="https://review.openstack.org/#/c/218706" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/218706</a><br>
><br>
> As the above patch you submitted shows that: ceilometer will restricts<br>
> the scope of returned events. if admin role,<br>
> user is allowed to query all events which have traits.project_id<br>
</span>> value*that match it's own project*OR any event without any project_id trait.<br>
><br>
> I think if admin role, user is allowed to query all events *no matter the *<br>
> *traits.project_id value match it's own project or not *is more property.<br>
<div class="HOEnZb"><div class="h5">><br>
> So, I wonder to know why we designed the principle like your patch's<br>
> commit-message shows.<br>
> Thanks<br>
><br>
> MengAlong<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
gord<br>
</font></span></blockquote></div><br></div>