edit_acl.html should reindex

[Paul Everitt]

ChrisRossi noticed that the edit_acl.html saves the security changes but doesn't trigger a reindex.

[Tres Seaver (tseaver)]

Fix commited on 'karl' trunk in r3258.

Please test on staging and close.

[Paul Everitt (paul-agendaless)]

Confirmed fixed.

[Paul Everitt (paul-agendaless)]

ChrisR says, maybe not. Editing works, re-indexing, not so much.

[Paul Everitt (paul-agendaless)]

Re-assigning to Chris for more investigation on production, based on Tres's comment:

"""
I just verified manually that the changes to the ACL get propagated to
the 'allowed' index, as long as the changes involve the 'view' permission::

$ bin/debug
...
root['communities']['default'].docid
492927271
x = root['communities']['default'].docid
root.catalog['allowed']._rev_index[x]
OOSet(['group.KarlAdmin', 'group.KarlStaff', \
u'group.community:default:members', \
u'group.community:default:moderators'])

I then visited http://localhost:6543/communities/default/edit_acl.html,
and granted user 'phreddy' the 'view' permission. Back in the debugger::

root._p_jar.sync()
root.catalog['allowed']._rev_index[x]
OOSet(['group.KarlAdmin', 'group.KarlStaff', \
u'group.community:default:members', \
u'group.community:default:moderators', u'phreddy'])

So I don't know what "doesn't seem to be working" means.
"""

[Chris Rossi (chris-archimedeanco)]

Tres just checked in a patch to also invalidate the catalog cache after reindexing. This fixes the behavior I was seeing.

[Paul Everitt (paul-agendaless)]

I think ChrisM asserted that this is busted. Assigning to him as part of the workflow overhaul.

[Paul Everitt (paul-agendaless)]

Let's move this to next week.

[Paul Everitt (paul-agendaless)]

ChrisM said this is fixed on his branch.

[Paul Everitt (paul-agendaless)]

I believe this one is working.