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.
* 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.
* 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.
* 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).
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
