Quantcast

I can see nosy but not repeat over items

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

I can see nosy but not repeat over items

John P. Rouillard
Hi all:

In an issue index page I display a multilink to users (nosy list)
using:

  <td tal:condition="request/show/nosy" content="i/nosy">
  </td>

I see the usernames for the entries on the list.

However I want these usernames to be hyperlinks to the user page.
So I entered the following tal:

  <tal:block tal:repeat="u i/nosy">
     <a tal:attributes="href string:user${u/id}"
        tal:content="python:u.username or default">
        NONE
     </a>
  </tal:block>

However it looks like "u" is never assigned a value and the "a" links
are never generated.

Even using

  <tal:block tal:repeat="u i/verynosy">
     <tal:block tal:content="u/id"> </tal:block>
  </tal:block>

fails to generate any output.

This happens for the anonymous user who has no access to the user
class except for the id and username (which is also the key and the
sort order field).

If I provide full access to the user, then it looks like the repeat
loop works. I was expecting the repeat loop would work if the user had
access to the id (key) field.

Does anybody have an idea where I should look to try to fix this? My
claim is there is a bad permission check somewhere that looks for view
access to the class and not view (or search) access to the key field.

Thanks.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: I can see nosy but not repeat over items

Ralf Schlatterbeck-3
On Sat, Apr 01, 2017 at 06:07:04PM -0400, John P. Rouillard wrote:

>
> I see the usernames for the entries on the list.
>
> However I want these usernames to be hyperlinks to the user page.
> So I entered the following tal:
>
>   <tal:block tal:repeat="u i/nosy">
>      <a tal:attributes="href string:user${u/id}"
>         tal:content="python:u.username or default">
>         NONE
>      </a>
>   </tal:block>
>
> However it looks like "u" is never assigned a value and the "a" links
> are never generated.

I guess that i in that example is the context variable?

> This happens for the anonymous user who has no access to the user
> class except for the id and username (which is also the key and the
> sort order field).

What are the permissions on issue.nosy for the anonymous user?

>
> If I provide full access to the user, then it looks like the repeat
> loop works. I was expecting the repeat loop would work if the user had
> access to the id (key) field.

And to the issue.nosy property.

Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [hidden email]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: I can see nosy but not repeat over items

John P. Rouillard
In message <[hidden email]>,
Ralf Schlatterbeck writes:

>On Sat, Apr 01, 2017 at 06:07:04PM -0400, John P. Rouillard wrote:
>>
>> I see the usernames for the entries on the list.
>>
>> However I want these usernames to be hyperlinks to the user page.
>> So I entered the following tal:
>>
>>   <tal:block tal:repeat="u i/nosy">
>>      <a tal:attributes="href string:user${u/id}"
>>         tal:content="python:u.username or default">
>>         NONE
>>      </a>
>>   </tal:block>
>>
>> However it looks like "u" is never assigned a value and the "a" links
>> are never generated.
>
>I guess that i in that example is the context variable?

Yes. It's the batch variable created from:

 <tal:block tal:repeat="i batch">

where batch is the result for the search.

>> This happens for the anonymous user who has no access to the user
>> class except for the id and username (which is also the key and the
>> sort order field).
>
>What are the permissions on issue.nosy for the anonymous user?

As far as I can tell View is permitted.

Note that if I use:

  tal:content="i/nosy"

in place of the tal:repeat="u i/nosy" the anonymous user can see the
names of the users on the nosy list. So the .plain() representation
works.

>> If I provide full access to the user, then it looks like the repeat
>> loop works. I was expecting the repeat loop would work if the user had
>> access to the id (key) field.
>
>And to the issue.nosy property.

Yup that is already the case since using tal:content="i/nosy" would
produce no output.

This has me stumped. I have created a simple issue template with three
fields: id, assignedto and verynosy (same config/rights as nosy). I am
throwing in stack dumps in my schema check functions and instrumenting
the security.py module to try to figure out what is going on. But no
ideas so far.

I do have incidental proof that the iterator can return the proper
values as:

 cgi/PageTemplates/TALES.py::setRepeat (~line 209)

   def setRepeat(self, name, expr):
        print "** setRepeat: %r, %s"%(name, expr)
        expr = self.evaluate(expr)
        print "** setRepeat2: %r, %r"%(name, expr)
        if not expr:
            print "return not branch"
            return self._compiler.Iterator(name, (), self)
        it = self._compiler.Iterator(name, expr, self)
        old_value = self.repeat_vars.get(name)
        self._scope_stack[-1].append((name, old_value))
        self.repeat_vars[name] = it
        print "** setRepeat3:", it, old_value, name
        return it

prints:

  ** setRepeat2: 'u', <MultilinkHTMLProperty(0x7fed9e767cd0) issue1@verynosy <roundup.hyperdb.Multilink to "user"> ['1', '3', '5']>

and the verynosy list on issue 1 is 1, 3, and 5.

If I change:

        print "** setRepeat2: %r, %r"%(name, expr)
to
        print "** setRepeat2: %r, |%s|"%(name, expr)

I get:

  ** setRepeat2: 'u', |admin, demo, provisional|

which is also correct.

Also it prints:
** setRepeat3: <roundup.cgi.PageTemplates.PathIterator.Iterator instance at 0x7fc537cf6b00> None u

If I dump the arguments to the __init__ method of the Iterator, again
it looks fine:

   Iterator::__init__: name=u, seq=admin, demo, provisional,
       context=<roundup.cgi.TranslationService.Context instance at 0x7f8d31ddcb90>

I guess I need to instrument the iterator's next function (or get pdb
to break there) and see what's happening.

Any thoughts are welcome.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: I can see nosy but not repeat over items

John P. Rouillard
Hi Ralf:

Ok I found the "culprit".

The Iterator uses cgi/templating.py::viewableGenerator.
It only returns id's where:

  check('View', userid, classname, itemid=value)

passes. Since the user object is not viewable, it skips all the
objects.

I am not sure how to address this. I wonder if making the check use
the visibility of the key or id property is sufficient.

-- rouilj


In message <[hidden email]>,
"John P. Rouillard" writes:

>In message <[hidden email]>,
>Ralf Schlatterbeck writes:
>>On Sat, Apr 01, 2017 at 06:07:04PM -0400, John P. Rouillard wrote:
>>>
>>> I see the usernames for the entries on the list.
>>>
>>> However I want these usernames to be hyperlinks to the user page.
>>> So I entered the following tal:
>>>
>>>   <tal:block tal:repeat="u i/nosy">
>>>      <a tal:attributes="href string:user${u/id}"
>>>         tal:content="python:u.username or default">
>>>         NONE
>>>      </a>
>>>   </tal:block>
>>>
>>> However it looks like "u" is never assigned a value and the "a" links
>>> are never generated.
>>
>>I guess that i in that example is the context variable?
>
>Yes. It's the batch variable created from:
>
> <tal:block tal:repeat="i batch">
>
>where batch is the result for the search.
>
>>> This happens for the anonymous user who has no access to the user
>>> class except for the id and username (which is also the key and the
>>> sort order field).
>>
>>What are the permissions on issue.nosy for the anonymous user?
>
>As far as I can tell View is permitted.
>
>Note that if I use:
>
>  tal:content="i/nosy"
>
>in place of the tal:repeat="u i/nosy" the anonymous user can see the
>names of the users on the nosy list. So the .plain() representation
>works.
>
>>> If I provide full access to the user, then it looks like the repeat
>>> loop works. I was expecting the repeat loop would work if the user had
>>> access to the id (key) field.
>>
>>And to the issue.nosy property.
>
>Yup that is already the case since using tal:content="i/nosy" would
>produce no output.
>
>This has me stumped. I have created a simple issue template with three
>fields: id, assignedto and verynosy (same config/rights as nosy). I am
>throwing in stack dumps in my schema check functions and instrumenting
>the security.py module to try to figure out what is going on. But no
>ideas so far.
>
>I do have incidental proof that the iterator can return the proper
>values as:
>
> cgi/PageTemplates/TALES.py::setRepeat (~line 209)
>
>   def setRepeat(self, name, expr):
>        print "** setRepeat: %r, %s"%(name, expr)
>        expr = self.evaluate(expr)
>        print "** setRepeat2: %r, %r"%(name, expr)
>        if not expr:
>            print "return not branch"
>            return self._compiler.Iterator(name, (), self)
>        it = self._compiler.Iterator(name, expr, self)
>        old_value = self.repeat_vars.get(name)
>        self._scope_stack[-1].append((name, old_value))
>        self.repeat_vars[name] = it
>        print "** setRepeat3:", it, old_value, name
>        return it
>
>prints:
>
>  ** setRepeat2: 'u', <MultilinkHTMLProperty(0x7fed9e767cd0) issue1@verynosy <roundup.hyperdb.Multilink to "user"> ['1', '3', '5']>
>
>and the verynosy list on issue 1 is 1, 3, and 5.
>
>If I change:
>
>        print "** setRepeat2: %r, %r"%(name, expr)
>to
>        print "** setRepeat2: %r, |%s|"%(name, expr)
>
>I get:
>
>  ** setRepeat2: 'u', |admin, demo, provisional|
>
>which is also correct.
>
>Also it prints:
>** setRepeat3: <roundup.cgi.PageTemplates.PathIterator.Iterator instance at 0x7fc537cf6b00> None u
>
>If I dump the arguments to the __init__ method of the Iterator, again
>it looks fine:
>
>   Iterator::__init__: name=u, seq=admin, demo, provisional,
>       context=<roundup.cgi.TranslationService.Context instance at 0x7f8d31ddcb90>
>
>I guess I need to instrument the iterator's next function (or get pdb
>to break there) and see what's happening.
>
>Any thoughts are welcome.
>
>--
> -- rouilj
>John Rouillard
>===========================================================================
>My employers don't acknowledge my existence much less my opinions.
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>Roundup-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/roundup-devel

In message <[hidden email]>,
Ralf Schlatterbeck writes:

>On Sat, Apr 01, 2017 at 06:07:04PM -0400, John P. Rouillard wrote:
>>
>> I see the usernames for the entries on the list.
>>
>> However I want these usernames to be hyperlinks to the user page.
>> So I entered the following tal:
>>
>>   <tal:block tal:repeat="u i/nosy">
>>      <a tal:attributes="href string:user${u/id}"
>>         tal:content="python:u.username or default">
>>         NONE
>>      </a>
>>   </tal:block>
>>
>> However it looks like "u" is never assigned a value and the "a" links
>> are never generated.
>
>I guess that i in that example is the context variable?

Yes. It's the batch variable created from:

 <tal:block tal:repeat="i batch">

where batch is the result for the search.

>> This happens for the anonymous user who has no access to the user
>> class except for the id and username (which is also the key and the
>> sort order field).
>
>What are the permissions on issue.nosy for the anonymous user?

As far as I can tell View is permitted.

Note that if I use:

  tal:content="i/nosy"

in place of the tal:repeat="u i/nosy" the anonymous user can see the
names of the users on the nosy list. So the .plain() representation
works.

>> If I provide full access to the user, then it looks like the repeat
>> loop works. I was expecting the repeat loop would work if the user had
>> access to the id (key) field.
>
>And to the issue.nosy property.

Yup that is already the case since using tal:content="i/nosy" would
produce no output.

This has me stumped. I have created a simple issue template with three
fields: id, assignedto and verynosy (same config/rights as nosy). I am
throwing in stack dumps in my schema check functions and instrumenting
the security.py module to try to figure out what is going on. But no
ideas so far.

I do have incidental proof that the iterator can return the proper
values as:

 cgi/PageTemplates/TALES.py::setRepeat (~line 209)

   def setRepeat(self, name, expr):
        print "** setRepeat: %r, %s"%(name, expr)
        expr = self.evaluate(expr)
        print "** setRepeat2: %r, %r"%(name, expr)
        if not expr:
            print "return not branch"
            return self._compiler.Iterator(name, (), self)
        it = self._compiler.Iterator(name, expr, self)
        old_value = self.repeat_vars.get(name)
        self._scope_stack[-1].append((name, old_value))
        self.repeat_vars[name] = it
        print "** setRepeat3:", it, old_value, name
        return it

prints:

  ** setRepeat2: 'u', <MultilinkHTMLProperty(0x7fed9e767cd0) issue1@verynosy <roundup.hyperdb.Multilink to "user"> ['1', '3', '5']>

and the verynosy list on issue 1 is 1, 3, and 5.

If I change:

        print "** setRepeat2: %r, %r"%(name, expr)
to
        print "** setRepeat2: %r, |%s|"%(name, expr)

I get:

  ** setRepeat2: 'u', |admin, demo, provisional|

which is also correct.

Also it prints:
** setRepeat3: <roundup.cgi.PageTemplates.PathIterator.Iterator instance at 0x7fc537cf6b00> None u

If I dump the arguments to the __init__ method of the Iterator, again
it looks fine:

   Iterator::__init__: name=u, seq=admin, demo, provisional,
       context=<roundup.cgi.TranslationService.Context instance at 0x7f8d31ddcb90>

I guess I need to instrument the iterator's next function (or get pdb
to break there) and see what's happening.

Any thoughts are welcome.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: I can see nosy but not repeat over items

Ralf Schlatterbeck-3
On Sun, Apr 02, 2017 at 12:57:05PM -0400, John P. Rouillard wrote:

> Hi Ralf:
>
> Ok I found the "culprit".
>
> The Iterator uses cgi/templating.py::viewableGenerator.
> It only returns id's where:
>
>   check('View', userid, classname, itemid=value)
>
> passes. Since the user object is not viewable, it skips all the
> objects.
>
> I am not sure how to address this. I wonder if making the check use
> the visibility of the key or id property is sufficient.

Looks like this is an effect of the recent changes to the permissions in
schema.py? Previously this wouldn't have failed because checking 'View'
on the class would return True if the user had view permission on a
single property?
So, yes, I think checking only on the id property should be fine
but could still break for people porting their code to the new
permissions.

Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [hidden email]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: I can see nosy but not repeat over items

John P. Rouillard
Hi Ralf:

In message <[hidden email]>,
Ralf Schlatterbeck writes:

>On Sun, Apr 02, 2017 at 12:57:05PM -0400, John P. Rouillard wrote:
>> Ok I found the "culprit".
>>
>> The Iterator uses cgi/templating.py::viewableGenerator.
>> It only returns id's where:
>>
>>   check('View', userid, classname, itemid=value)
>>
>> passes. Since the user object is not viewable, it skips all the
>> objects.
>>
>> I am not sure how to address this. I wonder if making the check use
>> the visibility of the key or id property is sufficient.
>
>Looks like this is an effect of the recent changes to the permissions in
>schema.py? Previously this wouldn't have failed because checking 'View'
>on the class would return True if the user had view permission on a
>single property?

Agreed. This is only an issue if you use the new props_only=True
feature in your permissions.

>So, yes, I think checking only on the id property should be fine
>but could still break for people porting their code to the new
>permissions.

Well if they are using props_only, they have to make sure that they
allow the labelprop if they want the item displayed when they are
iterating over it.

There always was and is difference in how multilink.plain() and
iterating over a multilink is handled.

In the multilink.plain() case, the code checks to see if the multilink
value is viewable (e.g. is nosy property viewable). There is no check
to see if the object represented by the multilink is viewable to the
user (i.e. is the user1 item viewable to the user). If the multilink
is viewable, the labelprop for the items in the multilink are shown.

However if you iterate over the multilink, the View access for each
object in the multilink is checked for View access.

Is this a problem? Should plain() act like the iterator case?  In the
templates the user can choose to iterate rather than using the plain()
display for multilinks so they can have it either way if they wish.
So I claim this provides user choice which is a good thing 8-).
However this difference should be documented.

Also to fix the original issue in the iterator case, I am using the
property returned by labelprop(default_to_id=1) since that is how
multilink's plain() function displays the label. So I get one of:

        0. self._labelprop if set
        1. key property
        2. "name" property
        3. "title" property
        3a. "id"
        (a 4th (well 5th) alternative, the first element in the
         sorted list of propnames, is not used when default_to_id
         is True.)

Too bad plain() for multilinks in templating.py doesn't support
hyperlink=True like plain() for Strings. That would solve my immediate
problem. However not being able to iterate over a multilink where the
user could see the value using multilink_field.plain() seems to be a
bug to me.

Does anybody have an opinion about adding a feature flag for this
change? I am tempted to just make it the default as there are only a
handful of possible scenarios in currently released (1.5.1 and prior)
code:

  If a user has view access to the class (no properties or check
  command), they have view access to the labelprop field.

  If the user has view access to a property, they also have view
  access to the class (there is no props_only setting in current
  permissions) unless they are denied access to the item by a check.

  If the user has view access to the class but not to the particular
  item (because executing check option returns false), View access to
  the property for that item will fail and it will not be shown.

In all of these cases, checking for View access to the labelprop will
succeed where the check without the labelprop would have succeeded.

The only place this becomes an issue is when using the new
props_only=True feature.

The other reason I don't want to create a feature flag for this is
that I am having a real problem trying to describe it. It allows
iteration over a multilink to the class if the labelprop is viewable
to the user. But this is something that as a user, I would expect
would just work. Rather than a feature flag I think it's jut a missed
item in the original props_only implementation.

I do think a note in the documentation describing this in the
props_only section is needed.

Thoughts?

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Loading...