On Thu, Mar 22, 2012 at 4:45 PM, Sergiu Dumitriu <[email protected]> wrote: > On 03/22/2012 09:56 AM, Jean-Vincent Drean wrote: >> >> On Wed, Mar 21, 2012 at 9:07 PM, Sergiu Dumitriu<[email protected]> wrote: >>> >>> On 02/13/2012 11:27 AM, Vincent Massol wrote: >>>> >>>> >>>> Hi devs, >>>> >>>> I've been brainstorming with Jean-Vincent about how to implement hiding >>>> technical content for 4.0. Here's what we would like to do: >>>> Note: This is related to the proposal I made earlier: >>>> http://markmail.org/thread/jupn22fdk4nnqj6p >>>> >>>> In summary: >>>> >>>> * Add a RoleVisibilityClass XObject to documents and spaces (in >>>> WebPreferences for Spaces) which is a list of Roles (simple or advanced >>>> users for now) deciding which role should be allowed to view a given >>>> document in result sets. >>> >>> >>> >>> Should we use different objects for different levels of rights? For >>> example, >>> we have XWikiRights and XWikiGlobalRights to distinguish between rights >>> on >>> the WebPreferences document itself and rights on the whole space. If we >>> always assume that a RoleVisibilityClass object on a WebPreferences >>> document >>> always refers to the space visibility, then we will have to rely on the >>> blacklist to hide all WebPreferences documents. Is that something we want >>> to >>> hardcode? >>> >>> An alternative that doesn't require using two classes is to add a "scope" >>> property to the class, to distinguish between document, space and wiki >>> settings. >>> >> >> I still think that we could finish what you've started with >> XWikiDocument#isHidden() by: >> >> - moving it to the query manager >> - making it easy to disable the filtering, with a per-call or per-user >> setting >> - allowing to mark a document as hidden from the UI (the checkbox >> would only be displayed to users who decided to display hidden >> documents) >> - get the list of spaces with : >> >> -------------------------------------------------------8<----------------------------------------------------- >> select distinct doc.space from XWikiDocument doc where (doc.hidden<> >> true or doc.hidden is null) order by doc.space asc >> >> -------------------------------------------------------8<----------------------------------------------------- >> - mark all the technical documents in our distribs as hidden >> >> For example It would allow to display the XWiki space in the list of >> spaces but (by default) the list of pages within this space would be >> the list of user documents. The scheduler space wouldn't appear >> because it only contains technical documents. >> >>> >>>> * Either modify XWikiHibernateStore or introduce a new >>>> FilteredHibernateStore store which would delegate to XWikiHibernateStore >>>> (same mechanism as the cache store) to add the JOIN to check the >>>> visibility >>>> and only return visible documents for the current user >>> >>> >>> >>> I'd rather use a new store interface, since I've changed the default >>> store >>> to exclude the "hidden" documents from results, and this is making it >>> hard >>> to ignore the hidden setting even from internal code. >>> >> >> We discussed another way to do this with Vincent: >> - new QueryFilter interface, with one method QueryFilter#filter(String >> statement, String language) >> - new Query.setFilter(Filter)/getFilter() methods (could be add/remove) >> - Query.getStatement() returns the filtered statement if there's a >> filter to apply >> >> I have a PoC with a TechnicalContentFilter (but TBH I'd rather name it >> HiddenDocumentFilter) which encapsulate the old XWikiHibernateStore >> doc.hidden filtering. >> I do a setFilter(new TechnicalContentFilter()) in the DefaultQuery >> construtor and it works fine. It could be extended and it's easily >> "disableable" through Query#setFilter(null). >> >> The only think I'm not sure how to resolve is the filtering of named >> queries, I can't think of an easy way to support them with what is >> explained above. >> >>> >>>> * Remove the notion of hidden documents and have a migrator to remove >>>> the >>>> column in xwikidocs >>> >>> >>> >>> +1. >>> >>> >>>> * Modify the Lucene plugin to add a VISIBILITY field and return filtered >>>> results based on the visibility and the current user role >>> >>> >>> >>> +1. >>> >>> >>>> * Note1: After much brainstorming we think that the notion of >>>> "application" could be implemented either with an Application XObject >>>> that >>>> tie the document to an application or with an Application Descriptor. >>>> * Note2: We'll need to decide at some point if we want more roles than >>>> just "simple user" and "advanced user" and if we need "developer" and >>>> "admin" too. >>> >>> >>> >>> +1 for more roles in the future. >>> >> >> We talked about the first 5 minutes with Caty, also about roles and >> the fact that having an arbitrary mapping between roles >> (simple/advanced) and displayed actions/items (hidden pages, keyboard >> shortcuts, etc) may not be the best way to do it. What we talked about >> was: >> >> - display a "Get started" wizard the first time a user logs in (it was >> actually the starting point of the discussion) >> - when the user finishes or dismisses the wizard, he's asked to choose >> a "flavor": simple, advanced, developer, etc >> - choosing a flavor sets some properties (display hidden documents, >> enable keyboard shortcuts, watch whole wiki for admins, etc) in his >> profile. Note: since those props will be set to "yes/no" but not >> "undefined" we could know if the user went through the get started >> guide by checking the value of one of this prop. >> - a user can later fine tune his settings by editing his preferences >> >> WDYT ? > > > That's for another thread, but in principle I agree. > >
Yes, I was mentioning it because it doesn't fit with the role/visibility proposal. >>> >>>> * Notes1 and 2 are currently out of scope for this proposal >>>> >>>> However we're wondering how much performance we will loose with this >>>> implementation using XObjects (due to the extra JOIN). >>> >>> >>> >>> With the proper indexes in place, and if we only use this check when >>> running >>> queries from the wiki, it shouldn't have a big impact. >>> >>> >>>> Do you think it's acceptable? >>>> >>>> Could it be improved with custom mapping? (I think not) >>> >>> >>> >>> Not that much, custom mapping helps only when there are objects with lots >>> of >>> properties in them. >>> >>> >>>> Should we implement this without XObjects and instead modify >>>> XWikiDocuments and add a new column in xwikidocs? >>> >>> >>> >>> This would be better for performance (less joins). >>> > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
