he XWiki development team is pleased to announce the release of XWiki
Enterprise 1.7 Milestone 3.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
Last milestone of the XWiki Enterprise 1.7 version.
Main changes:
* Webdav support
* Groovy upgrade
* New script macro
Important bug fixes:
* The old LDAP authenticator is still used by default in some cases
Note that general goals for XWiki Enterprise 1.7 are
* Working and usable (i.e. users can use them for their day to day
work instead of the old Syntax and old WYSIWYG editor) versions of new
rendering and new WYSIWYG editor.
* Working JCR (can be used for day to day work instead of Hibernate).
* French XE
* Blog revamping
* Webdav integration
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17M3
Thanks, The XWiki dev team
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-11-19 15:57:38 +0100 (Wed, 19 Nov 2008)
> New Revision: 14298
> Log:
> XWIKI-2825: Create a generic script macro
A quick review of the xwiki-script module:
- DefaultScriptContextManager and ScriptExecutionContextInitializer
should be in the internal package.
- ScriptExecutionContextInitializer is not declared in components.xml,
thus it is not used.
- getScriptContext calls the initializers on each call. Is that correct?
Shouldn't the context be initialized only once?
- scriptContextInitializerList (which also contains a typo in its name)
could be completely injected by Plexus, thus there's no need for
Initializable and Composable on this class. Just declare a dependency on
ScriptContextInitializer components.
- The javadocs on the interfaces could be improved... They are rather
short right now.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-11-19 15:48:09 +0100 (Wed, 19 Nov 2008)
> New Revision: 14297
>
> Modified:
> platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/DocumentAccessBridge.java
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/DefaultDocumentAccessBridge.java
> platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/internal/MockDocumentAccessBridge.java
> Log:
> XWIKI-2855: Add a bridge to know if current document author has programming rights
>
I don't quite like this. Programming rights should not be part of the model.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Just to let you know that for the next 20 minutes, it's possible that
you'll find some problem saving tasks in jira, or wiki pages on our
free wikis.
Thanks
-Vincent
Hi,
I created a new widget displaying some statistical data via the Panel
Wizard. With the 'admin' logins, that widget
is always visible. However, when i logged in with non-admin username ( with
View right granted), the newly created
widget is no longer visible.
Apparently, there are 2 most likely causes:
-The widget contains a Groovy/Velocity snippet that requires Programming
right to see
- The non-admin username does not enough rights to see the widget
Anyone could help me?
Hi devs,
I'm finishing the generic script macro (based on jsr 223) and the
groovy macro based on it.
It's working pretty well but I have a last issue: what do we do about security ?
I can't commit as it is because, like the "old" groovy macros, you can
do almost everything so we have to protected the script macros from
"simple" users.
Now how do we do that ?
1) The quicker is to use the programming right with some bridge like
the old groovy macro but it would be better to get rid of this special
right in the new architecture.
2) we could also use the JAVA security policy to run the scripts in a
"sandbox" but I think it means that the XWiki platform called by a
scripts is also running in the same limited sandbox (?).
3) groovy has it's own support of JAVA security policy (see
http://groovy.codehaus.org/Security) which give us the best control on
it but it means it's only groovy
2) and 3) means also for us to define the exhaustive list of allowed
or forbidden JVM api.
I'm -1 for 1), I'm not sure for the details of 2) and I would prefer
to be as generic as possible so i don't like 3) very much.
I did not looked deeply on 2) and 3) yet, it's just a first mail to
know if someone already played with theses concepts in JAVA.
So WDYT ? Any other ideas ?
--
Thomas Mortagne
On Sun, Nov 16, 2008 at 3:56 AM, SVN sdumitriu
<platform-notifications(a)xwiki.org> wrote:
> Author: sdumitriu
> @@ -376,9 +372,10 @@
> * @return the given text rendered in the context of this document
> * @deprecated since 1.6M1 use {@link #getRenderedContent(String, String)}
> */
> + @Deprecated
> public String getRenderedContent(String text) throws XWikiException
> {
> - return doc.getRenderedContent(text, getXWikiContext());
> + return this.doc.getRenderedContent(text, getXWikiContext());
> }
We currently have 6 pages using this method in XE wiki :
http://hudson.xwiki.org/job/xwiki-product-enterprise-test-trunk/com.xpn.xwi…
WWYT about un-deprecate this method and make it return
getRenderedContent(text, getSyntaxId()); ? Seems logical to me since
this is what we would do from velocity.