Hi, There is a major discrepancy in the way the programming rights are evaluated for the access to the privileged API from velocity compare to the right to execute groovy code. In the API, the right to access a priviledged API is evaluated against the sdoc in the current context, which is the document that contains the currently executed velocity code. Here is the code extracted from the current RightService implementation that does so: public boolean hasProgrammingRights(XWikiContext context) { XWikiDocument sdoc = (XWikiDocument) context.get("sdoc"); if (sdoc == null) sdoc = context.getDoc(); return hasProgrammingRights(sdoc, context); } In the XWikiGroovyRenderer, the right to render a groovy code is evaluated against the content doc, which is the top-level document that have directly or indirectly included the document that contains the evaluated groovy code. Here the excerpt from the code that made this check: if (! context.getWiki().getRightService().hasProgrammingRights(contentdoc, context)) { return content; } These are two opposed methods. As a direct consequence, a Sheet document (ie XWikiUserSheet) may be developed in velocity and use the priviledged API, but it is impossible to put a single line of Groovy in it, since the "instance" of the template documents that include the Sheet are usually created by users without programming rights. The debate is now, what is the original or current intend. Do you want: 1) to have a very secure situation, and therefore change hasProgrammingRights() implementation (why do we have a sdoc than?), or 2) to have a flexible, more responsible solution, were user having programming rights should take care not writing risky code, and therefore change the groovy renderer to accept groovy code based on contextdoc (sdoc in that place), so groovy and velocity gets the same access level ? The current situation is for me not acceptable, since it is a mix of 1) and 2) depending on the language, and there is no reason that the language influence the rights you have. Thanks for your comments... Denis -- Denis Gervalle SOFTEC sa http://www.softec.st