Yes there can be cases where user is allowed a subset of a content type, or a combination of content type groups and individual documents, where this would break down.
And yes, afaik, if you want to update the permissions in the document (seems slightly strange, since you would potentially many more users than documents, so you may want to think this requirement through some more), you would need to update the document. -sujit On Thu, 2011-03-10 at 21:24 -0800, go canal wrote: > I have similar requirements. > > Content type is one solution; but there are also other use cases where this > not > enough. > > Another requirement is, when the access permission is changed, we need to > update > the field - my understanding is we can not unless re-index the whole document > again. Am I correct? > thanks, > canal > > > > > ________________________________ > From: Sujit Pal <sujit....@comcast.net> > To: solr-user@lucene.apache.org > Sent: Fri, March 11, 2011 10:39:27 AM > Subject: Re: Solr and Permissions > > How about assigning content types to documents in the index, and map > users to a set of content types they are allowed to access? That way you > will pass in fewer parameters in the fq. > > -sujit > > On Fri, 2011-03-11 at 11:53 +1100, Liam O'Boyle wrote: > > Morning, > > > > We use solr to index a range of content to which, within our application, > > access is restricted by a system of user groups and permissions. In order > > to ensure that search results don't reveal information about items which the > > user doesn't have access to, we need to somehow filter the results; this > > needs to be done within Solr itself, rather than after retrieval, so that > > the facet and result counts are correct. > > > > Currently we do this by creating a filter query which specifies all of the > > items which may be allowed to match (e.g. id: (foo OR bar OR blarg OR ...)), > > but this has definite scalability issues - we're starting to run into > > issues, as this can be a set of ORs of potentially unlimited size (and > > practically, we're hitting the low thousands sometimes). While we can > > adjust maxBooleanClauses upwards, I understand that this has performance > > implications... > > > > So, has anyone had to implement something similar in the past? Any > > suggestions for a more scalable approach? Any advice on safe and sensible > > limits on how far I can push maxBooleanClauses? > > > > Thanks for your advice, > > > > Liam > > >
