Hash: SHA1

Ryan Smith wrote:

> Here are the 2 word answers, I go into more detail below.
>  - What kind of index?
> FieldIndex on an attribute I created called 'access'.  Access is a
> list of accesses a user has.
>  - What objects are you indexing?
> Any object with the 'access' attribute

Note that a FieldIndex is likely not to do what you want for
multi-valued attributes, such as lists or tuples:  you probably want a
KeywordIndex, which allows you do supply operators such as 'and' and 'or'.

>  - What kind of query are you making against the index?
> I noticed the problem when doing a folder listing in my Plone Site.

That isn't enough information:  we really need to see the arguments
being passed to the catalog's 'search' or 'searchResults' methods.

>  - What does "completely wrong" mean?
> The index is missing objects that have the 'access' attribute.  If an
> object's 'access' attribute is B it may be mapped in the index to A.

I think you need to give us a script to reproduce the behavior you are
seeing, e.g.:

1. In a folder, create a ZCatalog instance, 'catalog'.

2. On the catalog's "Indexes" tab, add a FieldIndex named 'access'
   (or try it with a Keyword index instead).

3. Create the following DTMLDocuments in the folder, each with the
   specified value for a lines property called 'access'::

   Document ID      access list
   -----------      ------------
   'foo'            ('baz',)
   'qux'            ('bam', 'baz')
   'splift'         ('bar', 'baz')

4. On the catalog's "Find Objects" tab, index the documents.

5. Add a PythonScript, 'show_me' to the folder, with the following

   catalog = context.catalog
   for access_value in ('baz',
                        ('bam', 'baz'),
                        ('bar', 'baz')):
       print 'Querying value for access:', access_value
       brains = catalog.searchResults(access={'query': access_value,
                                              'operator': 'and'})
       for brain in brains:
           print brain.getPath()
   return printed

6. Run the script, then tell us what you see, versus what you expected
   to see, when you run the script.  When I run it using a Keyword index
   and that query, I get the following, which is exactly what I expect::

   Querying value for access: baz

   Querying value for access: ('baz',)

   Querying value for access: ('bam', 'baz')

   Querying value for access: ('bar', 'baz')

> Here is some background on what I am doing -
> For a plone site, I needed a way to allow a user to only see objects
> if they had a certain set of roles.  I can't use the default security
> policy because we may want an object to require the roles Alpha AND
> Beta, but by default if a user has Alpha OR Beta they can see the
> object.
> When creating an object, it is possible to specify and 'access'
> attribute that will require special accesses to view the object.
> I handle if a user can view an object by dynamically adding them to a
> group, via a Group Plugin.
> Problem was this didn't effect if the object showed up in a search
> result, like a folder listing.  Plone calls ZCatalog.searchResults()
> to get the metadata for all the objects in a folder.  I grab these
> results and remove objects that shouldn't be listed to a specific
> user.   To check if a user is allowed to view it, I check in the
> metadata, if my attribute is there I compare it to the users roles and
> remove it if needed
> This all works most of the time.  But sometimes the index changes and
> the results I filter out will be wrong.

You need to show the filter you are using, because nothing in stock Zope
/ CMF / Plone works the way you describe.

>> The two log messages you post are effectively identical: some get
>> served from different ZODB connections, but that shouldn't cause any
>> difference in behavior. If you have one connection with "stale" data
>> for some objects (that would be a bug somewhere), then restarting Zope
>> might make the problem disappear, although we still wouldn't know how
>> that connection got into that state.
> The point I was trying to make with this was that if I reindex 100
> times.  I will get "DEBUG txn.-1223402608 commit <Connection at
> 0b5a01ec>" 80 times and "DEBUG txn.-1244382320 commit <Connection at
> 0965020c>" 20 times.  I realize they are nearly the same, but I get 2
> distinct values every time.  So if I dont restart Zope, it will always
> be one of these 2, nothing else.  And the re-indexes that are wrong
> always share the same value.

The two "values" you are seeing (I'm willing to bet money that the
transaction ID isn't the same) are two different ZODB connections:  some
requests get one connection from the pool, while others get another.

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to