Hi,
Hi need to create some documents to my xwiki without using the xwiki editor.
So I created some insert's tu create the document.
INSERT INTO XWIKIDOC VALUES (2141806153, 'Histórico.O processo que executa
os eventos não estava a remover os eventos pendentes que não davam origem a
eventos', 'O processo que executa os eventos não estava a remover os eventos
pendentes que não davam origem a eventos', '', '', 'en', 0, '2008-12-16
17:36:50', '2008-12-16 17:36:50', '2008-12-16 17:36:50', 'XWiki.Admin',
'XWiki.Admin', 'XWiki.Admin', 'Histórico', '','1.1', '', '', null, '2', '',
'', '', b'0', 'xwiki/1.0');
INSERT INTO xwikiobjects VALUES (2125339131, 0, 'Histórico.O processo que
executa os eventos não estava a remover os eventos pendentes que não davam
origem a eventos', 'XWiki.TagClass');
INSERT INTO xwikiproperties VALUES (2125339131, 'tags',
'com.xpn.xwiki.objects.DBStringListProperty');
INSERT INTO xwikilists VALUES (2125339131, 'tags');
INSERT INTO xwikilistitems VALUES (2125339131, 'tags', 'HS-Histórico', 0);
INSERT INTO xwikilistitems VALUES (2125339131, 'tags', '1.0.3 2008/05/20',
1);
INSERT INTO xwikircs VALUES (2141806153, 1, 1, '2008-12-16 17:36:50', '',
'XWiki.Admin', b'1', '<xwikidoc><web>Histórico</web><name>O processo que
executa os eventos não estava a remover os eventos pendentes que não davam
origem a
eventos</name><language></language><defaultLanguage>en</defaultLanguage><translation>0</translation><parent></parent><creator>XWiki.Admin</creator><author>XWiki.Admin</author><customClass></customClass><contentAuthor>XWiki.Admin</contentAuthor><creationDate>1229428967000</creationDate><date>1229428972000</date><contentUpdateDate>1229428972000</contentUpdateDate><version>1.1</version><title>O
processo que executa os eventos não estava a remover os eventos pendentes
que não davam origem a
eventos</title><template></template><defaultTemplate></defaultTemplate><validationScript></validationScript><comment></comment><minorEdit>false</minorEdit><syntaxId>xwiki/1.0</syntaxId><object><class><name>XWiki.TagClass</name><customClass></customClass><customMapping></customMapping><defaultViewSheet></defaultViewSheet><defaultEditSheet></defaultEditSheet><defaultWeb></defaultWeb><nameField></nameField><validationScript></validationScript><tags><cache>0</cache><displayType>input</displayType><multiSelect>1</multiSelect><name>tags</name><number>1</number><prettyName>Tags</prettyName><relationalStorage>1</relationalStorage><separator>
</separator><separators>
,|</separators><size>30</size><unmodifiable>0</unmodifiable><values></values><classType>com.xpn.xwiki.objects.classes.StaticListClass</classType></tags></class><name>
Histórico.O processo que executa os eventos não estava a remover os eventos
pendentes que não davam origem a
eventos</name><number>0</number><className>XWiki.TagClass</className><property><tags/></property></object><content>O
processo que executa os eventos não estava a remover os eventos pendentes
que não davam origem a eventos</content></xwikidoc>');
After this X-Wiki "tells me" that the page does not exist and it shows me
the editor, so I click "Save and view" and the page works fine but I get
duplicated values in my db.
What's wrong with this code?
Thanks in advance.
Winners :
1) With height +1 : offer predefined image sizes.
2) With five +1 : allow to edit image width _and_ height.
3) With seven +1 : offer text flow option.
4) With height +1 : have a simple preview using images.
5) With height +1 : source + options in the same screen for external images (b).
See the mockups here :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HImage
A question from Vincent has not been answered here nor in the link
thread : ability to filter nodes appearing in the tree. The suggest
input under the tree must be powerful enough to avoid this need.
Thanks,
JV.
Winners :
1) With seven +1 : display the tooltip option.
2) With seven +1 : have a one-step dialog for external links.
See the mockups here :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HLink
Vincent raised an important issue, how do we handle special parameters
in the WYSIWYG (%%), this will be discussed later since it not only
related to links but any element.
Thanks,
JV.
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.6.2 and XWiki Enterprise Manager 1.4.1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This are the last bug fixes version before deleting the 1.6 branch.
Changes from XE 1.6.0:
* XWIKI-2790 - Jboss cache load configuration in the wrong place
* XWIKI-2821 - Older document revisions have the wrong contentUpdateDate
* XWIKI-2835 - New object may not have their wiki (database) sets,
and defaults is not applied
* XWIKI-2836 - Property validation does not report classname in context
* XWIKI-2852 - The old LDAP authenticator is still used by default
in some cases
* XWIKI-2905 - XWiki#parseGroovyFromPage(page, jarPage) is not
loading jars from jarPage
Changes from XEM 1.4:
* XAWM-91 - When wiki template don't have pretty name it shows
empty string in wiki creation template list
For more information see the respective releases notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise162
and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM141
Thanks
-The XWiki dev team
Hi devs,
We currently have 2 parsers and 2 macros depending on whether the
content is HTML 4.01 or XHTML 1.0. This is way too complex for users.
In addition the XHTML parser/macro expect the content to have the
DOCTYPE declaration + a root element which make them even harder to use.
I propose to simply all this by doing the following:
* A single HTML parser
* A single html macro
* The HTMLCleaner is always called thus transforming HTML into clean
XHTML and not doing anything in case of clean XHTML (actually it'll
add the DOCTYPE and a root element if it's not there)
This simplifies code, documentation and more importantly its usage for
our end users.
Since the xhtml macro was released not long ago I'd rather not go
through a deprecation period and instead commit the changes above for
1.7.1 (with a nice message in the release notes).
I've started working on this (should be finished tonight). Please
shout if you don't agree.
Thanks
-Vincent
I would like to modify navigation panel to list only spaces for wich a
user has at least the view access level.
How to test the access Level of a user for a space?
How to get the current user?
Thank for your time.
Hi devs,
I would like to release XE 1.6.2 before closing the 1.6 branch (since
1.7 final is released) and XEM 1.4.1 based on it next Monday (because
I don't have time to do a release this week).
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi, devs.
I have a small review of XWIKI-1090: XWiki Query Generator,
XWikiQuery/makeQuery
in order to move it to new XWQLanguage instead of old QueryPlugin.
>This features allows to generate a Query UI and the corresponding
query automatically to run on the storage engine.
>The displaySearch APIs allow to display the query UI and makeQuery
allow to generate the query
It is easy to rewrite syntax to XWQL, but there are some problems in design.
1. To make it run on XWQL we just need to replace QueryPlugin#makeQuery
with something similar.
I propose:
1.1 move XWikiCriteria to xwiki-query/manager module
(it is not depend on core. except only one util method)
1.2 add
Query QueryManager#createQuery(XWikiCriteria)
as analogue to QueryPlugin#makeQuery
1.3 fix all affected references.
There are one method that need be bridged (xwiki-bridge) for this:
BaseClass#makeQuery.
I don't like to bridge it, so looking other ways.
2. General overview of query generator:
It is very connected with core and distributed across many classes. This
is not good for our component architecture.
There are:
UI Generator:
XWiki#displaySearch*
PropertyClass#displaySearch* and overrides
XWikiDocument#displaySearch
Query Generator:
XWiki#createQueryFromRequest
BaseClass#makeQuery
PropertyClass#makeQuery, #fromSearchMap and overrides
Executers:
XWiki#search*(XWikiQuery, ...)
I'm doing 1. now.
Query Generator redesign(2) is not important for now, I think. It works
well.
asiri (SVN) wrote:
> Author: asiri
> Date: 2008-12-15 17:45:22 +0100 (Mon, 15 Dec 2008)
> New Revision: 14754
>
> Modified:
> platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/domain/DavPage.java
> platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages/PagesBySpaceNameSubView.java
> Log:
> XWIKI-2982: Not possible to rename pages / spaces via the WebDAV interface
>
> Fixed.
>
> Modified: platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/domain/DavPage.java
> ===================================================================
> --- platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/domain/DavPage.java 2008-12-15 16:44:07 UTC (rev 14753)
> +++ platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/domain/DavPage.java 2008-12-15 16:45:22 UTC (rev 14754)
> @@ -284,7 +284,9 @@
> */
> public void move(DavResource destination) throws DavException
> {
> - getContext().checkAccess("delete", this.name);
> + // Renaming a page requires edit rights on the current document, delete rights on the
> + // target document (if it exists) and edit rights on all the children of current document.
> + getContext().checkAccess("edit", this.name);
> XWikiDavResource dResource = (XWikiDavResource) destination;
> String dSpaceName = null;
> String dPageName = null;
> @@ -302,8 +304,10 @@
> String sql = "where doc.parent='" + this.name + "'";
> List<String> childDocNames = getContext().searchDocumentsNames(sql);
> // Validate access rights for the destination page.
> - getContext().checkAccess("edit", newDocName);
> - // Validate access rights for all the renamed pages.
> + if (getContext().exists(newDocName)) {
> + getContext().checkAccess("delete", newDocName);
> + }
You still have to check for edit right:
} else {
getContext().checkAccess("edit", newDocName);
}
> + // Validate access rights for all the child pages.
> for (String childDocName : childDocNames) {
> getContext().checkAccess("edit", childDocName);
> }
>
> Modified: platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages/PagesBySpaceNameSubView.java
> ===================================================================
> --- platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages/PagesBySpaceNameSubView.java 2008-12-15 16:44:07 UTC (rev 14753)
> +++ platform/core/trunk/xwiki-webdav/src/main/java/com/xpn/xwiki/plugin/webdav/resources/views/pages/PagesBySpaceNameSubView.java 2008-12-15 16:45:22 UTC (rev 14754)
> @@ -168,11 +168,10 @@
> removeTempResource((DavTempFile) member);
> } else if (member instanceof DavPage) {
> String pName = ((DavPage) member).getDisplayName();
> - if (getContext().hasAccess("delete", pName)) {
> - XWikiDocument childDoc = getContext().getDocument(pName);
> - if (!childDoc.isNew()) {
> - getContext().deleteDocument(childDoc);
> - }
> + getContext().checkAccess("delete", pName);
> + XWikiDocument childDoc = getContext().getDocument(pName);
> + if (!childDoc.isNew()) {
> + getContext().deleteDocument(childDoc);
> }
> } else {
> throw new DavException(DavServletResponse.SC_BAD_REQUEST);
> @@ -192,13 +191,15 @@
> if (getCollection().equals(dSpace.getCollection())) {
> String sql = "where doc.web='" + this.name + "'";
> List<String> docNames = getContext().searchDocumentsNames(sql);
> - // To rename an entire space, user should have delete rights on all the
> - // documents in the current space and edit rights on all the documents that
> - // will be created after the rename operation.
> + // To rename an entire space, user should have edit rights on all the
> + // documents in the current space and delete rights on all the documents that
> + // will be replaced (if they exist).
> for (String docName : docNames) {
> String newDocName = dSpace.getDisplayName() + "." + docName;
> - getContext().checkAccess("delete", docName);
> - getContext().checkAccess("edit", newDocName);
> + getContext().checkAccess("edit", docName);
> + if (getContext().exists(newDocName)) {
> + getContext().checkAccess("delete", newDocName);
> + }
This looks like duplication. Can you move this check in a common method?
> }
> for (String docName : docNames) {
> XWikiDocument doc = getContext().getDocument(docName);
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-12-15 18:26:24 +0100 (Mon, 15 Dec 2008)
> New Revision: 14755
>
> Modified:
> platform/skins/trunk/albatross/src/main/resources/albatross/wiki.css
> Log:
> XSALBATROSS-44: Add support for BoxMacro
>
> Modified: platform/skins/trunk/albatross/src/main/resources/albatross/wiki.css
> ===================================================================
> --- platform/skins/trunk/albatross/src/main/resources/albatross/wiki.css 2008-12-15 16:45:22 UTC (rev 14754)
> +++ platform/skins/trunk/albatross/src/main/resources/albatross/wiki.css 2008-12-15 17:26:24 UTC (rev 14755)
> @@ -75,6 +75,20 @@
> font-size: inherit;
> }
>
> +.box {
> + margin-top: 4px;
> + margin-bottom: 4px;
Could be replaced with the shorter:
margin: 0 4px;
> + padding: 5px 5px 5px 5px;
Could be replaced with the shorter:
padding: 5px;
> + color: inherit;
That's useless, since this is the default. Should be removed. If there's
another CSS rule that overrides this, than that rule should be either
removed or narrowed down to a more specific set of elements.
> + background-color: #eeeeee;
Could be replaced with the shorter:
background-color: #EEE;
> + border: 1px dotted #003366;
Could be replaced with the shorter:
border: 1px dotted #036;
> + font-size: 12px;
I prefer not to use px for font sizes, since this prevents increasing
the font size in IE6, for those that don't see so well.
> + line-height: 100%;
> + white-space: pre;
> + width: 70%;
> + overflow: auto;
> +}
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Asiri has been around for a while (since last year's Summer of Code),
providing good code. He participated in the initial XEclipse design and
implementation, he wrote the WebDAV support, and is now managing the
Office Importer component.
I have been monitoring his commits, and the quality of his code has
rapidly increased. I believe that he deserves the right to commit his
own changes.
Here's my +1.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
I must recognize that I've lost contact with the status of development
of XWiki for some time. Sorry about that!
I will probably have to face some tasks here that will imply to manage
big files (>100Mb): pictures, raster maps, short video clips,... To
store all this stuff in the database (we are currently using MySQL) will
imply huge tables/databases.
Please, could you help me or point me in the right direction to catch up
with the discussion about using the file system as an
alternative/complementary repository for such kind of files?
Thanks you so much!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
Hi,
I'm hitting a problem I can't see the cause of again. When I try to
get the external url for a document, I get an exception:
Exception in thread "Thread-14" java.lang.NullPointerException
at com.xpn.xwiki.XWiki.getServletPath(XWiki.java:4317)
at
com
.xpn
.xwiki
.web.XWikiServletURLFactory.addServletPath(XWikiServletURLFactory.java:
208)
at
com
.xpn
.xwiki
.web.XWikiServletURLFactory.createURL(XWikiServletURLFactory.java:178)
at
com
.xpn
.xwiki
.web
.XWikiServletURLFactory.createExternalURL(XWikiServletURLFactory.java:
273)
at com.xpn.xwiki.doc.XWikiDocument.getExternalURL(XWikiDocument.java:
925)
Not tried to run it any other way but as xe-debug-web. I did not get
this problem before, can it have something to do with the switch to
version 1.7-SNAPSHOT? I'm not sure if it's related, but I also get a
LOT of these errors:
org.hibernate.ObjectNotFoundException: No row with the given
identifier exists: [com.xpn.xwiki.doc.XWikiDocument#723512152]
I tried flattening the database, let the xwiki rebuild it from
scratch, I keep getting these.
Cheers,
J.L.Simon
Hi,
I'd like to propose using smartGWT/smartClient for all our widget
needs both in GWT and in JS:
* Their set is pretty impressive and has all we need.
* It's under LGPL
* Sanjiv has moved from Ext GWT to SmartGWT and since he's had a bad
history with Ext GWT we can assume he has received enough reassurance
from smartClient to remain open source and under the LGPL license.
* It's both GWT and JS and we need both
* The little of the source I have seen look very clean.
Some links:
* http://www.jroller.com/sjivan/entry/smartgwt_1_0_released
* http://code.google.com/p/smartgwt/
* http://www.ongwt.com/post/2008/11/27/SmartGWT-%3A-A-
QampA-with-Sanjiv-Jivan2
* http://www.smartclient.com/product/smartLGPL.jsp
Here's my +1 (barring any issue we see when we start using it of course)
Thanks
-Vincent
Hi devs,
I'd like to suggest to move our current xwiki-web-gwt and
xwiki-web-wysiwyg modules from platform/web to platform/.
Rationale :
- Generic GWT modules to come (wiki-explorer, color picker, etc).
- xwiki-web would hold only fully functional WARs.
- WYSIWYG release cycle should be different from the one of web. This
would allow to benefit from WYSIWYG improvements in branch releases
(ex: XE 1.7.2, 1.7.3, etc) without requiring devs to commit on
multiple branches.
- A lot of issues regarding the wysiwyg editor are created in the
XWiki Core project in jira, I think having a dedicated project makes
sense.
Current organization :
|- platform/
|- web/ (xwiki-web)
|- exo/ (xwiki-web-exo)
|- gwt/ (xwiki-web-gwt)
|- standard/ (xwiki-web-standard)
|- wysiwyg/ (xwiki-web-wysiwyg)
New organization proposal :
|- platform/
|- gwt/ (xwiki-gwt)
|- commons/ (xwiki-gwt-commons)
|- wysiwyg/ (xwiki--gwt-wysiwyg)
|- web/ (xwiki-web)
|- exo/ (xwiki-web-exo)
|- standard/ (xwiki-web-standard)
This would also mean that we'd need 2 new projects in JIRA :
XWiki GWT Commons (XGCOMMONS) and XWiki GWT WYSIWYG (XGWYSIWYG).
Here's my +1.
Thanks,
JV.
Hi,
I'm experiencing a problem trying to debug XWiki from Eclipse when
using version 1.7. I replaced the xwiki.cfg file with the version from
the xwiki-enterprise-web.war file. I get the following exception:
java.lang.RuntimeException: Failed to load component
[org.xwiki.cache.CacheManager] for hint [default]
at com.xpn.xwiki.web.Utils.getComponent(Utils.java:547)
at com.xpn.xwiki.XWiki.getCacheFactory(XWiki.java:5270)
at com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:
90)
at com.xpn.xwiki.store.XWikiCacheStore.initCache(XWikiCacheStore.java:
84)
at com.xpn.xwiki.store.XWikiCacheStore.<init>(XWikiCacheStore.java:64)
I noticed that there is no pom.xml file for version 1.7 yet in the
tutorial page on xwiki and Eclipse. Do I have to make some changes to
the pom.xml in xe-debug-web other than changing xwiki version to 1.7?
Cheers,
J.L.Simon
Hi,
i've been writing a custom authentication plugin for xwiki. The
implementation was
pretty straightforward, however I'm having trouble deploying the
plugin. I bundled
it with other plugins for the same purpose in a jar file.
The jar file is deployed to my local repository. It's pulled in when I
build the
xe-debug-web in Eclipse and it's present in the xe-debug-web/WEB-INF/
lib directory
of the deployed app (in .metadata/.plugins/org.eclipse.wst.server.core/
tmp0 ...).
I altered the xwiki.cfg, adding the following line:
xwiki
.authentication
.authclass=com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin
However, when starting the application, I get the following problem:
- Initializing AuthService...
- Failed to initialize AuthService
com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin using
Reflection, trying default implementations using 'new'.
java.lang.ClassNotFoundException:
com.kontrast.vodafone.portal.xwiki.PortalAuthenticationPlugin
at
org
.apache
.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1387)
at
org
.apache
.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.xpn.xwiki.XWiki.getAuthService(XWiki.java:4630)
at com.xpn.xwiki.XWiki.checkAuth(XWiki.java:3566)
at
com
.xpn
.xwiki
.user
.impl
.xwiki.XWikiRightServiceImpl.checkAccess(XWikiRightServiceImpl.java:170)
at com.xpn.xwiki.XWiki.checkAccess(XWiki.java:3574)
at com.xpn.xwiki.XWiki.prepareDocuments(XWiki.java:4480)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:190)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at
org
.apache
.struts
.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org
.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:
1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
290)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com
.xpn
.xwiki
.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:
94)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com
.xpn
.xwiki
.web
.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:
287)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com
.xpn
.xwiki
.web
.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:
112)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org
.apache
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
233)
at
org
.apache
.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
191)
at
org
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
128)
at
org
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at
org
.apache
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
845)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
447)
at java.lang.Thread.run(Thread.java:637)
Any idea what I've missed?
Thanks in advance,
J.L.Simon
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.7. This is the final 1.7 version.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
Changes from 1.6:
-------------------------
- New XWiki Syntax 2.0 (xwiki/2.0)
- New WYSIWYG 2.0 (Alpha version)
- New script macro (xwiki/2.0)
- New Box macro (xwiki/2.0)
- Multiwiki (a.k.a farm mode or virtual mode) is now available using
special URLs for wikis (and not only subdomains). Note that this
option is available from xwiki.cfg and not enabled by default.
- Webdav support : XWiki now expose a webdav server interface. This
means you can now access/edit/delete page sources and attachments from
any webdav client.
- Groovy upgrade : The groovy engine has been upgraded to the last
1.6 beta version. You can now use all the new features of groovy as
well as speed improvements and bugfixes from groovy 1.0 to 1.6 beta 2.
- New Attachment view in the Index : you can now see all the
attachments of the wiki in the wiki index, under the "Attachment" tab.
- Reorganized, documented and enhanced xwiki.cfg configuration file.
- Added a ROOT webapp to the standalone distribution.
Important bug fixes:
--------------------------
- Saving a blank wiki page throws exception in Oracle
- Registration is still possible when right to register for
Unregistered user is explicit set to deny
- Documents with name with spaces or other special chars can't
properly save added image in WYSIWYG editor
- Support of dots in ldap login has introduce a security hole
- SMTP server address is not re-read when it's changed in global preferences
- Watchlist update sent by email does not contain the full path to a
changed attachment
- Wrong user name is inserted in group during LDAP membership synchronisation
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17
Thanks
-The XWiki dev team
Hi there,
Since there are still some wysiwyg bugs that can't be finished for
today we're proposing to move the XE 1.7 release to Monday or even
Tuesday (deadline is that it needs to be released for Tuesday night so
that we have it for Devoxx 2008 as planned).
I've done a status call with Anca/Marius and the outcome is that for
1.7 our wysiwyg will not work well enough to be called "usable" so I'm
proposing to call it alpha and to only call it "usable" for 1.7.1
which is planned for the 17th.
Let me know what you think.
Thanks
-Vincent
Hi Devs,
I've looked into the issues with webdav on MacOSX and following is the
diagnosis:
Finder(Mac) and other text editors on Mac relies a lot on temporary files /
directories created just for the duration of their operation. These files
usually start with a "." and can be easily distinguished from others. But
ignoring these files does not help at all because they are needed for the
proper operation of those applications. There for, we need to support them
somehow.
Approach 1: Store all of those temporary files inside user's session object
- This doesn't work always because some clients (Nautilus, Redirector,
Davfs) creates a new session for each and every request they make, so the
information will not be persistent across different requests. Although some
clients (Konqurer, NetDrive, DAVExplorer) keeps a single session open
throughout their operation and they can support temporary files with this
approach.
Approach 2: Store the temporary objects (resources) inside a database table
or file system - This can be complex to implement and will slow down the
operations.
Approach 3: Use an in-memory storage in a per-user basis and store temporary
files there (Ex HashMap<User,Object>). This is quite easy to implement but
we need to manage the temporary storage carefully.
I have implemented and tested Approach 1 and I will convert this to Approach
3 asap. In the mean time, if you think there is a better way to do this,
please let me know.
Thanks.
- Asiri
PS: Some clients are aware of webdav protocol and they workaround temporary
files themselves, these clients work fine oob.
Note: Temporary files that need to be supported:
.* (Unix like OSs)
Desktop.ini (XP)
Thumbs.db (XP)
*~ (gEdit)
*.swp (Vim)
Hi,
Here's a proposal:
* We don't bundle it in XE 1.7 since its integration is not finished
(missing integration with old Articles + Dashboard + Panel).
* We release it as an independent application on code.xwiki.org and we
update http://code.xwiki.org/xwiki/bin/view/Applications/BlogApplication
* We send Announcement email on users/devs lists asking for feedback
* We work on its integration so that it can replace the old blog
application
* If ready we bundle it in 1.7.1 as the main blog application. If not
then we bundle it in 1.7.2 or 1.7.3, i.e. as soon as it's ready. I
really think it's an important app for XE and thus we shouldn't wait
for 1.8 to release it.
WDYT?
For those who haven't tried it:
http://incubator.myxwiki.org/xwiki/bin/view/Blog/
Thanks
-Vincent
Hi all,
I would like to draw attention to those two bugs:
http://jira.xwiki.org/jira/browse/XWIKI-2899http://jira.xwiki.org/jira/browse/XWIKI-2938
They are very relevant and they could be easily fixed (patches are
already there).
I've been using the patch proposed for XWIKI-2899 in my local XWiki for
a while and I haven't noticed any side effects. For the patch concerning
XWIKI-2938, I talked again to Ludovic and it seems that it's ok.
So I would like to ask to other committers if they could have a quick
look at these bug fixes so that they can be applied.
Thanks,
Fabio
HI devs,
For http://jira.xwiki.org/jira/browse/XWIKI-2880 I need to know if the
current user has view right on a specified document.
For this there is many solutions, lets proposes some:
1) just add a isDocumentViewable(String documentName) in
DocumentAccessBridge and see later if we need more
2) add a more generic hasAccessRights(String documentName, String
rightLevel) in DocumentAccessBridge
3) or even more generic hasAccessRights(String user, String
documentName, String rightLevel) in DocumentAccessBridge
4) all of this
...
Since it's a bridge, I prefer 1) for now, that way component does not
need to know exactly what means that a document is readable/viewable
and that it needs to use the right level identifier "view". At some
point we will need to define a real rights component api and I think
we should wait for it before refactoring in component anything that
need a lots more that isDocumentViewable.
WDYT ?
Thanks,
--
Thomas Mortagne