- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] xwiki database -> ldap
by Thomas Mortagne 08 Dec '08

08 Dec '08

On Mon, Dec 8, 2008 at 12:20 PM, Bartłomiej Radziszewski <br(a)debian.linux.pl> wrote: > Hi Thomas, > > Thx for replay. > > Yep I know about synchronization ldap to xwiki database. > I want to use xwiki like central managment system for other services like > for example SVN (For authentication to the SVN i'm using htaccess with > ldap). You mean synchronize the other way ? When something change in XWiki, it has to modify LDAP entry ? XWiki does not support this by default. But you can do that with a script or a plugin if know JAVA and a little LDAP apis. In your plugin you can register for receive notifications of user modifications and then connect to LDAP and modify the LDAP user entry. See http://platform.xwiki.org/xwiki/bin/view/DevGuide/Notifications In the meantime you can add an "idea" or "improvement" entry on http://jira.xwiki.org/jira/browse/XWIKI about "Synchronizing any XWiki user modification back to LDAP server" or something like that but I think you will have to wait quite a long time to see it unless someone provide a good patch/contrib for it ;) > > So.. after user registration i need to have the same user in ldap. > > It is posible in xwiki? > > Thx and Greetings! > Bart >> >> Hi Bart, >> >> 2008/12/6 Bartłomiej Radziszewski <br(a)debian.linux.pl>: >> >>> >>> hello Thomas, >>> >>> If i good know You are developing all ldap staff in xwiki. >>> I'm searching simple way how to synchronize xwiki users to ldap >>> posixAccount.. i need only login, pass and mail attributes.. do You have >>> idea how to make it? >>> >> >> You don't need to synchronize LDAP login or pass, the LDAP >> authenticator validate login/pass directly on LDAP server then the >> informations like name, mail etc... are synchronized with XWiki. >> >> To define which information to synchronize between LDAP and XWiki user >> profile you can use xwiki.authentication.ldap.fields_mapping. >> >> For example : xwiki.authentication.ldap.fields_mapping=email=mail if >> you want only email. >> >> See >> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HGeneric… >> for more details on LDAP authentication configuration. >> >> >>> >>> Thanks and Greetings, >>> Bart >>> >>> -- >>> Bartłomiej Radziszewski >>> mobile: +48 509 561 540 >>> e-mail: br(a)debian.linux.pl >>> JID: br(a)debian.linux.pl >>> ICQ: #305569725 >>> >>> >>> >>> >> >> >> >> > > > -- > Bartłomiej Radziszewski > mobile: +48 509 561 540 > e-mail: br(a)debian.linux.pl > JID: br(a)debian.linux.pl > ICQ: #305569725 > > > -- Thomas Mortagne

1 0

Re: [xwiki-devs] xwiki database -> ldap
by Thomas Mortagne 08 Dec '08

08 Dec '08

Hi Bart, 2008/12/6 Bartłomiej Radziszewski <br(a)debian.linux.pl>: > hello Thomas, > > If i good know You are developing all ldap staff in xwiki. > I'm searching simple way how to synchronize xwiki users to ldap > posixAccount.. i need only login, pass and mail attributes.. do You have > idea how to make it? You don't need to synchronize LDAP login or pass, the LDAP authenticator validate login/pass directly on LDAP server then the informations like name, mail etc... are synchronized with XWiki. To define which information to synchronize between LDAP and XWiki user profile you can use xwiki.authentication.ldap.fields_mapping. For example : xwiki.authentication.ldap.fields_mapping=email=mail if you want only email. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HGeneric… for more details on LDAP authentication configuration. > > > Thanks and Greetings, > Bart > > -- > Bartłomiej Radziszewski > mobile: +48 509 561 540 > e-mail: br(a)debian.linux.pl > JID: br(a)debian.linux.pl > ICQ: #305569725 > > > -- Thomas Mortagne

1 0

[xwiki-devs] [VOTE] XMLRPC API Extension
by Fabio Mancinelli 07 Dec '08

07 Dec '08

Dear all, since the 1.7 release has been delayed I would like to propose to add 3 methods to the XMLRPC API. These methods are the following: /* Returns a list of all the changed pages starting from a given date */ public List<XWikiPageHistorySummary> getModifiedPagesHistory( Date date, Integer numberOfResults, Integer start, Boolean fromLatest) /* These are basically equivalent to original store functions, but if checkVersion is true then a check of the current page version is done before storing the page/object. This check handles the case in which a page has been modified by somebody else after the last getPage or getObject */ public XWikiPage storePage(XWikiPage page, Boolean checkVersion) public XWikiObject storeObject(XWikiObject object, Boolean checkVersion) Besides their usefulness there is also a rationale: these are actually a need for the Concerto project and it would be great to have them already available in 1.7. >From the implementation point of view, these methods have almost no impact on the current code base and they are purely an extension (i.e., no pre-existing critical code has been touched) Here it is my +1 -Fabio

7 11

[xwiki-devs] users registration problem
by antoine Seilles 06 Dec '08

06 Dec '08

Hi My xwiki works fine. But when users try to register, they have the following error. The registry is allright but it seems that mail can't be send. A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 10003 in 10: Exception while sending email from antoineseilles(a)gmail.com to [Ljava.lang.String;@b5d71 Wrapped Exception: Connection refused com.xpn.xwiki.XWikiException: Error number 10003 in 10: Exception while sending email from antoineseilles(a)gmail.com to [Ljava.lang.String;@b5d71 Wrapped Exception: Connection refused at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3347) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3370) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3284) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3249) at com.xpn.xwiki.XWiki.createUser(XWiki.java:3203) at com.xpn.xwiki.web.RegisterAction.action(RegisterAction.java:41) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) 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.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) Wrapped Exception: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at java.net.Socket.(Socket.java:366) at java.net.Socket.(Socket.java:180) at org.apache.commons.net.DefaultSocketFactory.createSocket(DefaultSocketFactory.java:53) at org.apache.commons.net.SocketClient.connect(SocketClient.java:162) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3320) at com.xpn.xwiki.XWiki.sendMessage(XWiki.java:3370) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3284) at com.xpn.xwiki.XWiki.sendValidationEmail(XWiki.java:3249) at com.xpn.xwiki.XWiki.createUser(XWiki.java:3203) at com.xpn.xwiki.web.RegisterAction.action(RegisterAction.java:41) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) 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.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:94) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619)

3 5

[xwiki-devs] [VOTE] Make DocumentAccessBridge#getDocumentContent(String documentName) use the current language in place of the default one
by Thomas Mortagne 06 Dec '08

06 Dec '08

Hi devs, I was looking for issue http://jira.xwiki.org/jira/browse/XWIKI-2892 (Include Macro should support including pages matching the current language) and i'm thinking it's not the include macro work to take care of the language. Include macro use the DocumentAccessBridge to acces document content and I think unless you don't explicitly specify that you want the default language content DocumentAccessBridge#getDocumentContent(String documentName) should return the content for the current language. It's more consistent with DocumentAccessBridge#etDocumentContent(String documentName, String language) IMO and anyway except for very specific needs I don't see the point of manipulating the content of the document's default language for components. WDYT ? Here is my +1 Thanks, -- Thomas Mortagne

4 4

[xwiki-devs] [Proposal] New Line behavior in the new WYSIWYG editor
by Guillaume Lerouge 06 Dec '08

06 Dec '08

Hi, In the current implementation of the WYSIWYG editor, when adding content, pressing the return key creates a new paragraph () and pressing shift-return creates a new line ( ). In the wiki editor, the following behavior was discussed and implemented ( http://www.mail-archive.com/[email protected]/msg04436.html ) : *>> So typing a new line in the wiki editor will result in a br tag in the >> corresponding HTML? And two consecutive new lines in wiki editor will >> result in a new paragraph? >> >> yep exactly.* After talking with our project managers and gathering their feedback from the way customers use our tool, I think that implementing a similar behavior in the WYSIWYG editor would be more intuitive for users : - Pressing return once generates a new line - - Pressing return twice generates a new paragraph - In order for this behavior to be transparent for the user, the CSS setting the height of blank space between 2 paragraphs should set it a one line's height. In order to respect user intentions on the screen, we would also need to handle the case where the user inputs, say, 4 return keypresses in a row. We could handle it by inputting tags and having the last tag be a paragraph : Some text some other text Another option would be to go the way of recent editors such as Google Docs and ditch in favor of tags only. So there are 3 options: 1. Keep the current implementation (*pros:* it's working this way already, *cons:* it's not what our project managers say our users expect) 2. Use 1 return keypress for and 2 return keypresses for (*pros: * it's more intuitive for users, it keeps the semantic meaning of , * cons:* it takes time to implement and we're already lacking time) 3. Input only everywhere, all the time (*pros:* that's what modern editors do, *cons:* additional work, we lose the semantic meaning of ) I'm +1 for option 2. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

5 4

[xwiki-devs] [VOTE][UI] WYSIWYG Image dialogs
by Jean-Vincent Drean 05 Dec '08

05 Dec '08

Hi XWikiers, I've made mockups for the WYSIWYG Image dialogs, you can see them at : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HImage Votes for internal image insertion : 1) Image size ------------------ In the mockup you can see a dropdown allowing to set some predefined sizes to the image (inspired by google docs). We could rely on the browser's image resizing feature for this and drop this setting. I'm in favor of keeping it (see my votes below) since it allow to keep size consistency between multiple images (screenshots for example) in the same page. Also, IE and FF have this resizing feature but we can't assume that it'll be the same for all the browsers we will target in the future. 2) Image size option --------------------------- a) Allow to edit only the image width (guarantee that the image width/height ratio won't be affected by the resize). b) Allow to edit both image width and height. 3) Text flow --------------- I think it's a must have but since it'll rely on a touchy parameter I prefer that we vote for it. Generated wiki syntax example : [[image:awsome.jpg||style="float:right"]] Notes : - for the moment using this will cause issues with titles, see : http://www.jean-vincent.org/xwiki/bin/view/Main/Image - I'm not sure that we'll be able to combine position center + text flow. 4) Preview -------------- I've put an image preview in the mockup, we've multiple choices: a) Drop it since it makes the dialog heavy. a) Keep it stupid simple, the image is represented by a placeholder and the 6 possible states are "prerecorded" (could be images). d) Make it an advanced preview, the image is the selected image, the preview takes the size of the image into account (by calculating what the selected size would look like compared to the page content in a predefined resolution, like 1024x768). Votes for external image insertion : 5) Number of wizard steps ----------------------------------- Like for the link insertion dialogs we have a major difference between internal and external stuff. We could : a) Have 2 steps to be consistent with the internal insertion. First step : image URL, second step : image options. b) Ease the edit work and have all the settings in the same screen, this is how I've presented it in the mockup. My votes : 1) +1 2) +1 for a) 3) +1 4) +1 for d) if possible 5) +1 for b) Thanks, JV.

8 13

[xwiki-devs] [VOTE][UI] WYSIWYG Link dialogs
by Jean-Vincent Drean 05 Dec '08

05 Dec '08

Hi, Now that we have agreed on the "wiki explorer" thing I've updated the link proposal accordingly. The mockups are available at : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HLink I've tried to spot all the items that we'd want to discuss but I may have forgotten some of them, feel free to raise new discussions. Votes for internal links : 1) Flyover ------------- Do we want to be able to easily set the link title ? Wiki syntax : [[current selection>>Main.WebHome||title="flyover"]] Votes for external links : 2) Number of wizard steps ----------------------------------- We have a major difference between external and internal links, pasting a URL doesn't require a fancy editor. We could : a) Have 2 steps to be consistent with the internal insertion. First step : link URL, second step : link options. b) Ease the edit work and have all the settings in the same screen (URL + options), this is how I've presented it in the mockup. My votes : 1) +1 2) +1 for b) JV.

8 9

Re: [xwiki-devs] [xwiki-notifications] r14570 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: . web
by Sergiu Dumitriu 05 Dec '08

05 Dec '08

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-05 12:29:12 +0100 (Fri, 05 Dec 2008) > New Revision: 14570 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/XWikiRequestProcessor.java > Log: > XWIKI-2824: Support multiwiki using path urls and not host urls > * make action name for servlet configurable ("wiki" by default) > > + > + private String getProperty(String propertyKey, String defaultValue) > + { > + if (this.config == null) { > + // Make XWikiRequestProcessor own configuration loader since XWiki of Configuration component are not > + // initialized at this time This part should be synchronized, to prevent parallel initialization. Or, load it in a constructor or static block (making the config static, also). You could also comment this setting in xwiki.cfg.vm -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

Re: [xwiki-devs] [xwiki-notifications] r14565 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: api doc
by Vincent Massol 05 Dec '08

05 Dec '08

On Dec 5, 2008, at 7:55 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-12-05 07:55:30 +0100 (Fri, 05 Dec 2008) > New Revision: 14565 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > Log: > XWIKI-2549: Make Document.addAttachment public > Done. > > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > api/Document.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java 2008-12-05 04:30:58 UTC (rev 14564) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java 2008-12-05 06:55:30 UTC (rev 14565) > @@ -20,7 +20,6 @@ > */ > package com.xpn.xwiki.api; > > -import java.io.ByteArrayOutputStream; > import java.io.IOException; > import java.io.InputStream; > import java.util.ArrayList; > @@ -32,7 +31,6 @@ > import java.util.Vector; > > import org.apache.commons.fileupload.FileItem; > -import org.apache.commons.io.IOUtils; > import org.apache.commons.lang.StringUtils; > import org.suigeneris.jrcs.diff.DifferentiationFailedException; > import org.suigeneris.jrcs.rcs.Version; > @@ -1721,7 +1719,7 @@ > filename = filename.replaceAll("\\+", " "); > > if ((data != null) && (data.length > 0)) { > - XWikiAttachment attachment = > addAttachment(filename, data); > + XWikiAttachment attachment = > this.doc.addAttachment(filename, data, getXWikiContext()); > getDoc().saveAttachmentContent(attachment, > getXWikiContext()); > // commenting because this was already done by > addAttachment > // getDoc().getAttachmentList().add(attachment); > @@ -1736,39 +1734,26 @@ > return nb; > } > > - protected XWikiAttachment addAttachment(String fileName, > InputStream iStream) throws XWikiException, IOException > + public Attachment addAttachment(String fileName, InputStream > iStream) > { > - ByteArrayOutputStream bAOut = new ByteArrayOutputStream(); > - IOUtils.copy(iStream, bAOut); > - return addAttachment(fileName, bAOut.toByteArray()); > + try { > + return new Attachment(this, > this.doc.addAttachment(fileName, iStream, getXWikiContext()), > getXWikiContext()); > + } catch (XWikiException e) { > + // TODO Log the error and let the user know about it > + } catch (IOException e) { > + // TODO Log the error and let the user know about it I don't like this... Don't we have a solution to handle it in a better way? With the current solution scripts calling this method need to check for null and take action if null which I'm pretty sure none care about so it'll silently fail. The best current solution is probably to store the result in the "error" variable in the Velocity context (we have a variable for this) and modify a main template to check for errors in page execution and if there are redirect to an error page printing them. The script should then be able to do a check for null itself and have the ability to clear the error if it can handle it gracefully so that the error page doesn't appear for the user. WDYT? [snip] Thanks -Vincent

2 1