In practice there shoud not be much of a delay, but if you change the ACL permission on a top-level folder with 10 million docs beneath, it will take some time before all those docs are reindexed. But if you instead give your friend read access to a new “group” which already have access to the docs, the change is immediate.
I suppose ManifoldCF could start using DocValues for the ACL info and update those atomically much faster than re-indexing the content of every document. Anyone know if that would be feasible? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 19. okt. 2016 kl. 00.30 skrev Markus Jelsma <markus.jel...@openindex.io>: > > ManifoldCF can do this really flexible, with Filenet or Sharepoint, or both, > i don't remember that well. This means a variety of users can have changing > privileges at any time. The backend determines visibility, ManifoldCF just > asks how visible it should be. > > This also means you need those backends and ManifoldCF. If broad document and > users permissions are required (and you have those backends), this is a very > viable option. > > > > -----Original message----- >> From:John Bickerstaff <j...@johnbickerstaff.com> >> Sent: Wednesday 19th October 2016 0:14 >> To: solr-user@lucene.apache.org >> Subject: Re: Public/Private data in Solr :: Metadata or ? >> >> Thanks Jan -- >> >> I did a quick scan on the wiki and here: >> http://www.slideshare.net/lucenerevolution/wright-nokia-manifoldcfeurocon-2011 >> and couldn't find the answer to the following question in the 5 or 10 >> minutes I spent looking. Admittedly I'm being lazy and hoping you have >> enough experience with the project to answer easily... >> >> Do you know if ManifoldCF helps with a use case where the security token >> needs to be changed arbitrarily and a re-index of the collection is not >> practical? Or is ManifoldCF an index-time only kind of thing? >> >> >> Use Case: User A changes "record A" from private to public so a friend >> (User B) can see it. User B logs in and expects to see what User A changed >> to public a few minutes earlier. >> >> The security token on "record A" would need to be changed immediately, and >> that change would have to occur in Solr - yes? >> >> >> >> On Tue, Oct 18, 2016 at 3:32 PM, Jan Høydahl <jan....@cominvent.com> wrote: >> >>> https://wiki.apache.org/solr/SolrSecurity#Document_Level_Security < >>> https://wiki.apache.org/solr/SolrSecurity#Document_Level_Security> >>> >>> -- >>> Jan Høydahl, search solution architect >>> Cominvent AS - www.cominvent.com >>> >>>> 18. okt. 2016 kl. 23.00 skrev John Bickerstaff <j...@johnbickerstaff.com >>>> : >>>> >>>> I have a question that I suspect I'll need to answer very soon in my >>>> current position. >>>> >>>> How (or is it even wise) to "segregate data" in Solr so that some data >>> can >>>> be seen by some users and some data not be seen? >>>> >>>> Taking the case of "public / private" as a (hopefully) simple, binary >>>> example... >>>> >>>> Let's imagine I have a data set that can be seen by a user. Some of that >>>> data can be seen ONLY by the user (this would be the private data) and >>> some >>>> of it can be seen by others (assume the user gave permission for this in >>>> some way) >>>> >>>> What is a best practice for handling this type of situation? I can see >>>> putting metadata in Solr of course, but the instant I do that, I create >>> the >>>> obligation to keep it updated (Document-level CRUD?) and I start using >>> Solr >>>> more like a DB than a search engine. >>>> >>>> (Assume the user can change this public/private setting on any one piece >>> of >>>> "their" data at any time). >>>> >>>> Of course, I can also see some kind of post-results massaging of data to >>>> remove private data based on ID's which are stored in a database or >>> similar >>>> datastore... >>>> >>>> How have others solved this and is there a consensus on whether to keep >>> it >>>> out of Solr, or how best to handle it in Solr? >>>> >>>> Are there clever implementations of "secondary" collections in Solr for >>>> this purpose? >>>> >>>> Any advice / hard-won experience is greatly appreciated... >>> >>> >>
