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

[xwiki-devs] Ending macro syntax as macro content

by Thomas Mortagne

Hi devs, We have a limitation in the xwiki/2.0 parser related to the way macros are parsed: impossible to have the ending syntax of a macro as content of this macro. Here is the related jira issue: http://jira.xwiki.org/jira/browse/XWIKI-5077 A good example is: i want to have "{{/code}}" alone as the content of a code macro. That's impossible. The only way to have {{/code}} in the content is with: {{code}} {{code}} {{/code}} {{/code}} or {{code}} ~{{/code}} {{/code}} but in the first case you get "{{code}}" you did not want and in the second you get "~" you did not want. Only solution i can see is to specifically handle escaping of ending macro syntax inside macros of the same name. Here is some examples: 1) {{code}} ~{{/code}} {{/code}} would give code macro containing "{{/code}}" 2) {{code}} ~{{/somemacro}} {{/code}} would give code macro containing "~{{/somemacro}}" 3) {{code}} ~~{{/code}} {{/code}} would give code macro containing "~" followed by the text "{{/code}}" 4) {{code}} ~~~{{/code}} {{/code}} would give code macro containing "~{{/code}}" 5) Then double escaping for each level to escape: {{box}} {{box}} ~~~{{/box}} {{/box}} {{/box}} would give box macro containing a box macro containing the text "{{/box}}": the first pass change "~~~{{/box}}" into "~{{/box}}" like in example 4) and the second pass escape "{{/box}}" like in example 1). So WDYT ? Here is my +1 -- Thomas Mortagne

15 years, 5 months

3
7
0 0

[xwiki-devs] [Proposal] Stop using XWiki.Admin for contentAuthor in pages in platform/applications and enterprise/wiki unless PR is needed.

by Caleb James DeLisle

Currently everything is saved with the content author set to XWiki.Admin. This means that in a default system, every single page has programming access and any bug which allows for arbitrary velocity to be evaluated or even allows arbitrary xwiki syntax to be rendered in that page will be a PR leak. We can either (A) begin making pages with contentAuthor = XWiki.XWikiGuest or (B) we could create a new default username which has no PR. I'm +1 for A because of it's simplicity and adding default usernames seems ugly to me. Caleb Another though, should we change the values of "creator" and "author" at the same time?

15 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r28168 - platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode

by Sergiu Dumitriu

On 04/07/2010 03:15 PM, lucaa (SVN) wrote: > Author: lucaa > Date: 2010-04-07 15:15:44 +0200 (Wed, 07 Apr 2010) > New Revision: 28168 > > Modified: > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml > Log: > XAANNOTATIONS-13: URL Decode annotation target before using it in AnnotationService > * Fixed encoding across all annotations js and velocity scripts > > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1265236156000</creationDate> > -<date>1266926719000</date> > -<contentUpdateDate>1266926719000</contentUpdateDate> > +<date>1270643626000</date> > +<contentUpdateDate>1270643626000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -37,9 +37,9 @@ > {{html}} > ## get create a hashmap with request data about the selection > #set($annData = $util.hashMap) > -#set($dispose = $annData.put("selection", $util.decodeURI($!request.selection))) > -#set($dispose = $annData.put("selectionContext", $util.decodeURI($!request.selectionContext))) > -#set($dispose = $annData.put("selectionOffset", $util.decodeURI($!request.selectionOffset))) > +#set($dispose = $annData.put("selection", $!request.selection)) > +#set($dispose = $annData.put("selectionContext", $!request.selectionContext)) > +#set($dispose = $annData.put("selectionOffset", $!request.selectionOffset)) > ## pretend that annotation author is current user, and annotation date is now > ##Even if they get sent to the server, the server will overwrite with anything's logged in in there anyway > #set($dispose = $annData.put("author", $context.user)) > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1264959390000</creationDate> > -<date>1267569743000</date> > -<contentUpdateDate>1267569743000</contentUpdateDate> > +<date>1270643964000</date> > +<contentUpdateDate>1270643964000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -47,7 +47,7 @@ > *# > #macro(displayCreateBox $docWiki $docSpace $docPage $annData) > <div class="annotation-box annotation-box-create"> > -<form method="POST" action="/xwiki/rest/wikis/${docWiki}/spaces/${docSpace}/pages/${docPage}/annotations?media=json"> > +<form method="POST" action="/xwiki/rest/wikis/${util.encodeURI($docWiki)}/spaces/${util.encodeURI($docSpace)}/pages/${util.encodeURI($docPage)}/annotations?media=json"> > <div class="hidden"> > #foreach($field in $annData.keySet()) > <input type="hidden" name="${field}" value="$!{annData.get(${field})}"/> > @@ -73,7 +73,7 @@ > <div class="annotation-box annotation-box-edit"> > #if($ann) > ## TODO: fix this url to be generated less hardcoded > - #set($editURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > + #set($editURL = "/xwiki/rest/wikis/" + $$util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > <form method='POST' action="${editURL}"> > #displayAnnotation($ann, 'edit') > #displayAnnotationBoxButtons('edit') > @@ -174,7 +174,7 @@ > #macro(displayAnnotationToolbox $ann $mode $docWiki $docSpace $docPage) > <span class="annotationTools"> > #if($mode != 'create'&& $annotations.canEditAnnotation($ann.id, $docWiki, $docSpace, $docPage)) > - #set($editURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") Instead of $util.encodeURI you should use $escapetool.url > + #set($editURL = "/xwiki/rest/wikis/" + $util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > #if ("$!{ann.state}" == 'UPDATED') > <span class="tool accept"><a class="validate" href="${editURL}" title="$msg.get('annotations.action.validate.tooltip')">$msg.get('annotations.action.validate.text')</a></span> > #end > @@ -183,7 +183,7 @@ > <span class="tool annotationEdit"><a class="edit" href="${editURL}" title="$msg.get('annotations.action.edit.tooltip')">$msg.get('annotations.action.edit.text')</a></span> > #end > ## TODO: fix this url to be generated less hardcoded > - #set($deleteURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=DELETE&media=json") > + #set($deleteURL = "/xwiki/rest/wikis/" + $util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=DELETE&media=json") > <span class="tool delete"><a class="delete" href="${deleteURL}" title="$msg.get('annotations.action.delete.tooltip')">$msg.get('annotations.action.delete.text')</a></span> > #end > </span> > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1264860755000</creationDate> > -<date>1270590698000</date> > -<contentUpdateDate>1270590698000</contentUpdateDate> > +<date>1270643534000</date> > +<contentUpdateDate>1270643534000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -847,7 +847,7 @@ > > fetchAnnotations : function(andShow) { > // TODO: fixme, get the URL in a less hardcoded way > - var getAnnotationsURL = '/xwiki/rest/wikis/' + XWiki.currentWiki + '/spaces/' + XWiki.currentSpace + '/pages/' + $$('meta[name=page]')[0].content + '/annotations?media=json'; > + var getAnnotationsURL = '/xwiki/rest/wikis/' + encodeURIComponent(XWiki.currentWiki) + '/spaces/' + encodeURIComponent(XWiki.currentSpace) + '/pages/' + encodeURIComponent($$('meta[name=page]')[0].content) + '/annotations?media=json'; > new Ajax.Request(getAnnotationsURL, {method: 'GET', > parameters: this.prepareRequestParameters(new Hash()), > onCreate: function() { > @@ -1037,9 +1037,9 @@ > new Ajax.Request('$xwiki.getURL("AnnotationCode.EditForm")', { > parameters: { > 'xpage' : 'plain', > - 'wiki' : encodeURIComponent(XWiki.currentWiki), > - 'space' : encodeURIComponent(XWiki.currentSpace), > - 'page' : encodeURIComponent($$('meta[name=page]')[0].content), > + 'wiki' : XWiki.currentWiki, > + 'space' : XWiki.currentSpace, $$ is really slow in IE, you should use something faster, like setting XWiki.currentDocumentName to this value first. > + 'page' : $$('meta[name=page]')[0].content, > 'id' : id > }, > onCreate : function() { > @@ -1124,9 +1124,9 @@ > parameters: { > 'id' : annotationId, > 'xpage' : 'plain', > - 'wiki' : encodeURIComponent(XWiki.currentWiki), > - 'space' : encodeURIComponent(XWiki.currentSpace), > - 'page' : encodeURIComponent($$('meta[name=page]')[0].content) > + 'wiki' : XWiki.currentWiki, > + 'space' : XWiki.currentSpace, > + 'page' : $$('meta[name=page]')[0].content > }, > onSuccess: function(response) { > // display the annotation creation form -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.3 Milestone 2 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.3 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is second and last milestone of the XWiki Enterprise 2.3 version. Main changes from 2.3 Milestone 1: * New Annotations section in the Administration * New spanish translations for the WYSIWYG editor * Lots of bugs fixes For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise23M2 Thanks -The XWiki dev team

15 years, 5 months

1
0
0 0

[xwiki-devs] [VOTE] Save dirty attachment content when saving documents

by Denis Gervalle

In XWiki(Hibernate|Jcr)Store#saveXWikiDoc(), the attachement list is persisted, but the attachement contents are not persisted. A) I would like to take care of also persisting attachment contents when these contents are loaded and marked dirty (XWikiAttachmentContent#isContentDirty() == true). Why I would like to change this ? 1) I see no use case that would have to persist reference to an attachment and drop its content at the same time, which create records with a size field set to n bytes, while the attachment is 0 or m bytes. 2) When for example an XWikiDocument#copy() is followed by an XWiki#saveDocument() (on the newly created document), without also calling XWikiDocument#saveAllAttachements(), the cache store contains the documents with all their attachments contents, while the DB has not really persisted these contents. 3) In XWikiHibernateAttachmentStore#saveAttachmentContent(), the default is to persist the document, this is not consistent with the document not doing the same in reverse. (I would have better understand that persisting attachment contents does not persist the document.) 4) isContentDirty is properly maintained, and currently it is nearly unused, making the false impression that attachments content are persisted properly 5) This issue is invisible in normal XWiki usage, since we take care of saving attachments contents to avoid it everywhere, for example in XWiki#copyDocument(), attachments contents are saved "manually". 6) As a application developer, using the internal API in groovy, my collegue has missed it, and we have loose production data, since during testing, the cache has always hide the issue. I really dislike API that could introduce inconsistencies in the DB and moreover when you loose large amount of data. B) This change has no real impact on any code that would take care of saving the attachments separatly, it will just be saved twice, isContentDirty() currently only prevent useless archiving. This could be optimized by not saving contents as well when it is not dirty, but I do not want a negative vote on the rest for just this. So please vote this as B) C) I also would like to optimize existing internal usage, removing useless call to saveAttachmentContent() in XWiki.copyDocument() for example. This could have an impact on a custom store that does not take care of saving attachments contents while saving documents. I doubt many user has such a store and release notes could mention this incompatibility. This is my +1 for A) B) and C) Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

15 years, 5 months

6
7
0 0

[xwiki-devs] [Proposal] Structure for extensions.xwiki.org

by Vincent Massol

Hi, I'm implementing the mail entitled "[Proposal] Rationalize our projects and SVN structure" and I need to start creating extensions.xwiki.org (a **first** version of it). Here's my current thinking re its structure: * An ExtensionClass - Description - icon (optional) - Download page (optional) - created by - contributor - bundled with (none, top level projects except contrib, extensions) - content (with template having Tested With + Requirements sections) - type (macro, snippet, application, plugin, skin, other) * A MacroClass - macro type * A SnippetClass - languages (multi choice list: script languages) Note: In the future we'll need to map these classes to the Extension Manager descriptor, with dependencies for example. * Have an ExtensionClassSheet that does basically the same thing as now * Have an ExtensionClassTemplate with predefined sections to guide the author: Usage, Installation & Requirements, Tested With (note: Installation & Requirements could also be put in the Download page, common to all versions) * Keep the Download classes too for now * On the home page, have a big livetable mapped to ExtensionClass for now. * Put all extensions in an Extensions space * Use a prefix of "Extension" * When an extension is made of different "types", then bundle it as a zip with type "other". For example the Watch extension is made of a XAR + 2 jars, it would be bundled as a zip and a type of "other". * Move Module References to platform.xwiki.org * Possibly write some scripts to help migrate current content on code.xwiki.org to extensions.xwiki.org WDYT? Thanks -Vincent

15 years, 5 months

3
6
0 0

[xwiki-devs] A Problem about Debug Wysiwyg Editor

by Leon Wang

Hi Marius, hi XWiki Developers, Thank you for your reply and add instructions to http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingtheWYSIWY…<http://www.google.com/url?q=http%3A%2F%2Fdev.xwiki.org%2Fxwiki%2Fbin%2Fview…> Really appreciated! After I executed the start_xwiki.sh and start_wysiwyg_noserver_debug.sh, it gives me new errors. It says: "[WARN] Unable to process 'file:/home/freeleons/XWiki_Enterprise_2.1.1/war/WEB-INF/web.xml' for servlet validation javax.servlet.UnavailableException: Configuration problem at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:298) at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:68) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:51) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:344) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)" also it gives me a hint: "[ERROR] Hint: Check that the type name 'com.xpn.xwiki.wysiwyg.client.Wysiwyg' is really what you meant" Here is the visual: http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink When I made the change to the script (start_wysiwyg_noserver_debug.sh), from: "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.Wysiwyg" to "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg" It will give me the error: "[ERROR] Unable to find 'com/xpn/xwiki/wysiwyg/client/Wysiwyg.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?" Here is the screenshot of hierarchy of the XWiki Enterprise folder, http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink Could you please give me some suggestions? Thank you! Sincerely, Jue Wang

15 years, 5 months

2
2
0 0

[xwiki-devs] A Problem about Debug Wysiwyg Editor

by Leon Wang

Hi Marius, hi XWiki Developers, Thank you for your reply and add instructions to http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingtheWYSIWY… appreciated! In case you might miss the email which I replied. I sent this again. After I executed the start_xwiki.sh and start_wysiwyg_noserver_debug.sh, it gives me new errors. It says: "[WARN] Unable to process 'file:/home/freeleons/XWiki_Enterprise_2.1.1/war/WEB-INF/web.xml' for servlet validation javax.servlet.UnavailableException: Configuration problem at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:298) at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:68) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:51) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:344) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)" also it gives me a hint: "[ERROR] Hint: Check that the type name 'com.xpn.xwiki.wysiwyg.client.Wysiwyg' is really what you meant" Here is the visual: http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink When I made the change to the script (start_wysiwyg_noserver_debug.sh), from: "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.Wysiwyg" to "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg" It will give me the error: "[ERROR] Unable to find 'com/xpn/xwiki/wysiwyg/client/Wysiwyg.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?" Here is the screenshot of hierarchy of the XWiki Enterprise folder, http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink Could you please give me some suggestions? Thank you! Could you please also tell me what "com.xpn.xwiki.wysiwyg.client.Wysiwyg" for in the script below: -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg Sincerely, Jue Wang

15 years, 5 months

2
1
0 0

[xwiki-devs] [Discussion] What direction to take the administration application.

by Caleb James DeLisle

When I was trying to figure out how to cleanly configure the registration page, I wrote a piece of code to handle it. The code is at XWiki.ConfigurableClass and it displays configuration for applications which contain objects of the same class. Documentation is here: http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… In adding this I made a few assumptions which may not be the direction which the community wants to go. #1 I added a document called XWiki.RegistrationHelp to the default XE package which explains how to configure the registration page. In the Registration section of the administration interface, I made the labels for the input fields into links to the relevant sections of the help page (I like links :) ) Vincent has suggested that instead of links we were to use popups or tooltips because they would not allow the user to leave the administration interface. The currently existing links could have click handlers added to show a popup and block the click so that they still work for users without Javascript. The other and more major issue in my mind is that I can't think of a way to show only information for the item clicked on while keeping the help page a single unit which can be read (and edited) easily. Another option would be to remove the help page and links but I found myself reading code to figure out what some of the parameters meant so I don't think that is a realistic option. I am in favor of continuing with the method which I started because I feel that popups are an attack on my browser and I see no way to keep tooltips centralized for reading beginning to end and for easily updating when things change. #2 When I added configuration for the registration page, I did not want to add it to XWikiPreferences. This is not only because I want to keep my code modular but I want to put myself in the position of an application developer so I can see the API from their point of view. This has lead to configuration for XWiki.Registration residing in XWiki.RegistrationConfig. It has been pointed out to me that this will make upgrading more difficult and I agree but I don't think adding properties to XWikiPreferences class for each and every application is reasonable and since third party developers cannot do that I see this as a deficiency in our API. The options I can see are to add a "Document Type" which defines a particular document as a configuration document which should never be upgraded but I think this is wrong because even configuration needs to be upgraded, it is the values which need to remain. Also I am not a fan of separating configuration to a document different than the code because the code needs to handle the case where the configuration is unavailable and I think code making static references to a document name is an antipattern. My proposal is to create another class just like ConfigurableClass except it will be UpgradableClass. A document may have an object of UpgradableClass and that object can either A. Point to another object in the same class which should have it's values loaded in on upgrade or B. Add some code which should be run on upgrade. It is important to understand that the document can be changed but the upgradable objects will load the values from the old object and set them in the new object. #3 Because the configuration for the registration page is seperate, it cannot be saved along with XWikiPreferences in a single save operation and because there is configuration for the registration page in XWikiPreferences and in RegistrationConfig, they are both specified to be displayed in the "Registration" section of the administration interface. XWiki.ConfigurableClass handles this situation by creating two forms with two save buttons and a heading in the middle saying "Configure XWiki.RegistrationConfig" It would be easy to override this with another message and it would be possible to make a single button for users who have Javascript enabled but it introduces the question do we want third party applications to anonymously add parameters to a section of the administration interface. I suppose the best answer would be to separate all of the parameters having to do with registration from XWikiPreferences (and stop referring to them in the core). I can think of no better solutions to this at the moment. #4 (No hasty changes here, just a proposal) The administration application uses the "admin" struts action which calls the AdminAction class. From my looking at AdminAction class I think it can be removed entirely and struts can be redirected to the InlineClass (Unproven claim). This brings up a point about permissions: admin permission must be had in order to use the admin action but only edit access to XWikiPreferences is required to do the things offered by the administration action. see: https://localhost:8443/xwikiTrunk/bin/edit/XWiki/XWikiPreferences?editor=ob… In fact admin action is not even necessary to use the Administration Application see: https://localhost:8443/xwikiTrunk/bin/inline/XWiki/XWikiPreferences?xpage=a… I think the myth that admin access is necessary to do the administrative functions is dangerous for administrators who may leave security holes as a result. My proposal is that we try removing AdminAction to sandbox and redirect /admin/ in struts to InlineAction. I also think we ought to redefine admin access perhaps as the combination of view, edit, and delete which cannot be denied at a lower level (so a space admin can delete a page even if it denies them access.) I have made XWiki.ConfigurableClass with the idea that it should be able to do all of the functions of the administration application (meaning XWikiPreferences would have a ConfigurableClass object for each section in the administration application). I am always happy to hear when somebody wants to use ConfigurableClass but I don't think porting XWikiPreferences over is a good idea until ConfigurationClass has had some time in the field and we are sure that we don't want to change any of it's behavior. Sorry for the long email, I had a lot to discuss and didn't want to spam the list with 4 emails about the administration application. Caleb

15 years, 5 months

2
6
0 0

[xwiki-devs] [Proposal] XWiki.org Logo Challenge - Round 2

by Sergiu Dumitriu

Hi devs, Votes are now closed for the new XWiki.org logo, and, according to http://spreadsheets.google.com/ccc?key=0Ah6DqXzfHT2vdHV5Ty1LX3lKU3U5V3M4YmN… , they seem pretty tight for: 12A, 12E, 15, 16B and proposals 4A and 19 were also mentioned by a significant number of voters (feel free to double-check the spreadsheet, at least for your own votes if not for the whole thread, to make sure I entered the right values). So, I propose to organize a second round of votes, from Thursday April 8th until Sunday April 11th. The voters will be asked to choose only ONE logo proposal (no more fuzzy votes this time) between 4A, 12A, 12E, 15, 16B and 19. Before the new round of votes starts, the authors of these 6 proposals are kindly asked to do the following by Wednesday, if not already done for round 1: * correct any inaccuracies that might have appeared in the name * try to integrate any constructive feedback that came with the votes (I tried to gather this feedback from the emails on http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallengeRound2 ) * polish the design (if they consider it necessary) * provide the requested variations for .org, enterprise and office * provide samples for light and dark background * provide a black&white version * provide a 16X16 icon containing the logo or a representative part of the logo * provide a nice "Powered by XWiki" button that goes with the logo * provide a mockup/screenshot with the logo used in the current skin, colibri The _final_ versions should be uploaded here: http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallengeRound2 . Unless updated, the versions that participated in round 1 will also be used for round 2, and voters will have to use their imagination in case any of the required use cases is missing. Please let me know if there are any objections regarding the finalists, the timeline or the requirements for round 2. Some commiters disagree with including in the final vote proposals 12A, 12E and 15, because of their similarity with the XWiki.com and Atlassian Confluence logos respectively. Since it seems that not everybody sees these resemblances, I tried to do the most impartial thing I could think of: I included these 3 proposals on the finalist page, with a visible warning that those who agree there is a similarity should definitely not vote for them in round 2, even if they like them very much (the goal being to have a new, original logo, not a variation of the old one or the logo of a competitor). My hope is that the community will properly decide whether these logos are suitable and meet the uniqueness requirement. Note that this is not the e-mail for _starting_ the second round, but rather for _agreeing on_ the second round. Thanks in advance for the cooperation. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

1
0
0 0

[xwiki-devs] [VOTE] Add 6 new methods to com.xpn.xwiki.api for loading and saving documents as the content author of the script calling the method.

by Caleb James DeLisle

Hello all, I'd like to make this change: Add to xwiki.api.Document saveAsAuthor() saveAsAuthor(String comment) saveAsAuthor(String connent, String isMinorEdit) deleteAsAuthor() Add to xwiki.api.XWiki getDocumentAsAuthor(DocumentReference reference) getDocumentAsAuthor(String fullName) They save, load or delete the document if the script's contentAuthor has the necessary permission, the user in context is switched so the contentAuthor is listed as having done the operation. Though they say *AsAuthor the action will take place in the name of the contentAuthor of the document this is mainly because *AsContentAuthor is long and confusing. This is already partially available if the script has programming access but I think it is an important enough feature that it should not be limited to scripts with programming access. Use case: allowing users to submit information without letting them see or modify what other users had submitted. This is my +1 Caleb

15 years, 5 months

5
9
0 0

[xwiki-devs] [Proposal] Rationalize our projects and SVN structure

by Vincent Massol

Hi devs, Jean-Vincent, Thomas and I (hope I didn't forget anyone) would like to propose the reorganization described below: = Projects = In 2007 we decided to start multiple projects based on the XWiki platform, namely: manager, workspaces and watch. The objective was to provide multiple products based on the XWiki platform with the same expectations in terms of quality; all those projects were top level projects to reflect that. A year later we decided to put all our development effort in XWiki Enterprise, since then all the projects except Enterprise and Office have been left aside. == XWiki Watch == * Last significant jira issue fixed on 12/Jun/2009 * Last release 1.1M1 (based on XE 1.5.1) - 11/Sep/08 While watch code is compatible with recent XE versions its distribution is not maintained. The proposal is to move watch code somewhere else in the SVN (see below) and to drop the distribution modules (database, distribution, installers). Watch documentation (including installation guides) would be placed on code.xwiki.org and watch.xwiki.org pages would redirect to this new location. Watch JIRA would be made read only and move to the retired category. All new issues should use the existing Watch application JIRA. == XWiki Workspaces == * Last significant jira issue fixed on 19/Oct/2008 * Last release 1.2M1 (based on XE 1.5.2) - 19/Sep/08 Workspaces is no longer maintened and it doesn't work with XE > 1.5.2. The proposal is to move it to contrib/retired and to display a banner on workspaces.xwiki.org saying that this product is retired (see http://beehive.apache.org/ for an example). Workspaces JIRA would be made read-only. == XWiki Eclipse == * Last significant jira issue fixed on 06/Jan/09 * Last release 2.2 - 11/Jan/09 XEclipse is no longer maintained and it doesn't handle the xwiki/2.0 syntax. The proposal is to move it to contrib/retired and to display a banner on xeclipse.xwiki.org saying that this product is retired. XEclipse JIRA would be made read-only. Note that we hope the project will be brought back from the dead in the future. == XWiki Manager == * Last significant jira issue fixed on 11/Apr/09 (XEM jira project) * Last release 2.2 (based on XE 2.2) - 16/Feb/10 The Manager case is different, it's released often and isn't lagging behind XE. The problem is that we only release it labeled as stable, based on XE stable versions, which is bad since it's not properly tested before that. Manager is not a product per-se, all the code that allows to run a wiki farm is located in the xwiki platform, which means that having a different life-cycle for its distribution doesn't make sense and doesn't serve the product (less testing). Manager is a set of 2 plugins making easier to run a wiki farm. We should emphasize on this, make people understand that the virtual feature is a core feature and that they can take advantage of it on any XE release by using the correct plugins and apps. This way we could get feedback from people doing staged deployment. We wouldn't mislead people by releasing a distribution directly in a stable version. = SVN Organization = If we agree on the proposal above we need to refactor the SVN according to it. Possible implementation: {{code language="none"}} /svnroot/xwiki/ |_ contrib/ |_ people/ |_ projects/ |_ retired/ |_ photoalbum/ |_ s5/ |_ workspaces/ |_ xeclipse |_ enterprise/ |_ extensions/ |_ administration |_ application-manager/ |_ plugin/ |_ application/ |_ blog |_ calendar |_ ircbot |_ officeimporter |_ panels |_ scheduler/ |_ plugin/ |_ application/ |_ selenium/ |_ skins/ |_ colibri/ |_ statistics/ |_ plugin/ |_ application/ |_ tag/ |_ plugin/ |_ application/ |_ watchlist/ |_ plugin/ |_ application/ |_ webdav/ |_ wiki-macro-bridge/ |_ wiki-manager/ |_ watch |_ application/ |_ component/ |_ gwt/ |_ gwt-client/ |_ gwt-server/ |_ workstream/ |_ platform/ |_ components/ |_ components-all/ |_ xwiki-component/ |_ xwiki-rendering/ |_ ... |_ gwt |_ xwiki-gwt-api/ |_ xwiki-gwt-dom/ |_ xwiki-gwt-user/ |_ xwiki-gwt-wysiwyg-client/ |_ xwiki-gwt-wysiwyg-server/ |_ web |_ tools/ |_ xoffice {{/code}} Modifications summary: * 4 projects moved to retired: photoalbum, s5, workspaces, xeclipse * platform/web/standard content (templates and resources) moved to platform/core/web (packaging: zip) * platform/web/ gwt modules moved to platform/core/gwt (packaging: zip) * new plaform/distribution module (packaging: war) it replaces the previous platform/web-standard minimal webapp * new extensions top level project gathering plugins and applications, rationale: ** applications made of a plugin and an application will now be released in one place ** with the future extension-manager all the extensions (plugins, document sets, skins) should be released as a XAR ** coherent with extensions.xwiki.org = XWiki.org Website Organization = {{code language="none"}} |_ www.xwiki.org |_ dev.xwiki.org |_ enterprise.xwiki.org |_ extensions.xwiki.org (was: code.xwiki.org) |_ l10n.xwiki.org |_ platform.xwiki.org |_ xoffice.xwiki.org {{/code}} wdyt? Thanks -Vincent

15 years, 5 months

4
4
0 0

[xwiki-devs] [VOTE] Escaping for document references in xwiki syntax links

by Vincent Massol

Hi, I'm working on fixing http://jira.xwiki.org/jira/browse/XWIKI-4957 I'm proposing to use \ as the escape char since we're already using it for escaping chars in references. for ex: [[My\.Page\@\#\?]] here's my +1 Thanks -Vincent PS: for xwiki syntax 2.1, i'd like to propose that we use [[reference||anchor="..." queryString="..."]] but that'll be another vote

15 years, 5 months

5
5
0 0

[xwiki-devs] XWiki Logo Challenge

by Jean-Vincent Drean

Hi XWikiers! It's time to inject new blood in XWiki.org. While discussing about improving its look & feel we thought it would be a good time to create a new logo for XWiki.org as it's an important part of a website design. We borrowed the current logo from XWiki.com some time ago and, in order to keep the distinction between the company and the Open-Source project clear, we think XWiki.org websites and projects need their own logo. As you may know, we love proposals, that's why we'd like to make the logo design an open challenge, anyone interested can join and a vote amongst the community will determine the winner. Even if the main purpose of the challenge is to have fun, the person whose design gets selected will receive XWiki goodies, including his logo printed on a t-shirt obviously :) The designer of the selected logo will enter the Hall Of Fame, and last but not least reward : the design will be spread wide (XWiki Enterprise is more than 10000 downloads/month and XWiki.org web site more than 50000 visits a month). The challenge takes place there: http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallenge Thanks, JV.

15 years, 5 months

19
30
0 0

[xwiki-devs] [Proposal] Handling document references in UIs?

by Vincent Massol

Hi, We need a consistent way to handle document references in UIs. For example, on the rename template, the title is "Renaming <string serialization of a reference here>". Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). Proposal ======= Since references are technical I don't think we should print them in the UI. Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: wiki >> space >> page where >> is the HTML Å symbol. You can check visually what I mean here: http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… Thus applying this to the example above, we would have: "Renaming Main >> ?." And thus this removes the technical aspects: * no ":" or "." to separate wiki and space *no character escaping WDYT? Any other idea to achieve the same result ? Thanks -Vincent

15 years, 5 months

3
5
0 0

Re: [xwiki-devs] [Proposal] Handling document references in UIs?

by Thomas Mortagne

On Wed, Mar 31, 2010 at 13:29, Vincent Massol <vincent(a)massol.net> wrote: > > On Mar 31, 2010, at 12:50 PM, Sergiu Dumitriu wrote: > >> On 03/31/2010 11:30 AM, Vincent Massol wrote: >>> >>> On Mar 31, 2010, at 10:30 AM, Vincent Massol wrote: >>> >>>> Hi, >>>> >>>> We need a consistent way to handle document references in UIs. >>>> >>>> For example, on the rename template, the title is "Renaming<string serialization of a reference here>". >>>> Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." >>>> Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). >>>> >>>> Proposal >>>> ======= >>>> >>>> Since references are technical I don't think we should print them in the UI. >>>> >>>> Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). >>>> >>>> This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: >>>> >>>> wiki>> space>> page >>>> >>>> where>> is the HTMLÅ symbol. >>>> >>>> You can check visually what I mean here: >>>> http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… >>>> >>>> Thus applying this to the example above, we would have: >>>> >>>> "Renaming Main>> ?." >>>> >>>> And thus this removes the technical aspects: >>>> * no ":" or "." to separate wiki and space >>>> *no character escaping >>>> >>>> WDYT? Any other idea to achieve the same result ? >> >> +1. >> >> Maybe / would be good as a separator. It's respecting the directory/file >> separator, it's also used in the URLs. it's familiar. > > "/" would be ok too but provided it's displayed in a different color and appropriate spacing between reference parts and "/". I have the feeling Å provides less ambiguity since it cannot appear easily in a document name while "/" is common. I think i would also prefer an arrow or any other shape more UI oriented than "/". > > Thanks > -Vincent > >>> Another idea: >>> have a rectangle box drawn with 3 internal boxes, each for a reference part (wiki, space, page). >> >> I don't like this. Boxes are visual only, and borders aren't really good >> at being suggestive. >> >> -- >> Sergiu Dumitriu > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

15 years, 5 months

2
1
0 0

Re: [xwiki-devs] [Proposal] Handling document references in UIs?

by Thomas Mortagne

On Wed, Mar 31, 2010 at 10:30, Vincent Massol <vincent(a)massol.net> wrote: > Hi, > > We need a consistent way to handle document references in UIs. > > For example, on the rename template, the title is "Renaming <string serialization of a reference here>". > Thus if the page is named "?." in the space "Main" for example we get: "Renaming Main.?\." > Same for the wysiwyg editor's insert link dialog box (under the title we have the technical reference printed). > > Proposal > ======= > > Since references are technical I don't think we should print them in the UI. > > Instead we should print its constituents: wiki, space, page (or just space, page when not in multiwiki or when handling a ref not from the current wiki). > > This is what Caty has done in the Search UI BTW. Thus I propose to reuse her idea and print this: > > wiki >> space >> page > > where >> is the HTML Å symbol. > > You can check visually what I mean here: > http://playground.myxwiki.org/xwiki/bin/view/Main/WebSearch?text=test&x=0&y… > > Thus applying this to the example above, we would have: > > "Renaming Main >> ?." > > And thus this removes the technical aspects: > * no ":" or "." to separate wiki and space > *no character escaping > > WDYT? Any other idea to achieve the same result ? +1 for no reference syntax in the UI Now how to show it in the UI is another subject and i don't have precise idea, search UI looks nice enough to me. What is sure is that we need a common tool to show a reference in the UI and to use everywhere as much as possible. > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

15 years, 5 months

1
0
0 0

[xwiki-devs] About integrating office-preview module in platform

by Asiri Rathnayake

Hello Devs, I committed an office-preview module in sandbox ( http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-officepreview/) about a month or two ago. The purpose of this module is to enable previewing of office attachments (word, spreadsheets, presentations) using the office-importer module. This module was developed for a demonstration purpose and needless to say it was cooked up as fast as possible without much attention to technical aspects. We've planned to integrate this module into platform and therefore need to clear out those technical issues. Our initial plan was to make this module available in 2.3 final release, but I doubt if I would have enough time to spend on purifying the code before it can be integrated. In any case I will list the technical issues we have with current code and propose some solutions so that we can come to an agreement about the design: 1. Each office-preview consists of an XDOM and a bunch of temporary files corresponding to images embedded inside the original office document. Currently these temporary files are stored inside the "charts" directory used by the charting plugin. I'm not sure if using "charts" directory and the "charting" action is a good idea, may be we should introduce the "tempresource" action before integrating this code. 2. An office-preview needs to be aware of attachment version (if a new version of an attachment is uploaded, preview must change). Also, when building the office preview, urls to temporary files (images) must be generated. 2.1 Currently DocumentAccessBridge does not provide an API to query the attachment version. 2.2 Generating urls to temporary files inside "charts" directory cannot be done via any component api. Because of above two reasons, office-preview module currently depends on xwiki-core module which is a bad practice for newer modules. We can deal with this issue by adding new methods to DAB (not good) or by having a component interface inside xwiki-officepreview module and it's implementation in xwiki-core module. I'm not sure if any of these solutions is perfect. 3. Each generated office-preview is cached. When a cache entry is disposed, all the temporary files associated with that preview is deleted (DisposableCacheValue). However, I noticed that DisposableCacheValue::dispose() is not invoked when XE shuts down. We could fix this by adding an event listener to listen for XE shutdown events and calling DisposableCacheValue::dispose() manually. 4. A requested feature (by ludovic) is to cache the whole office-preview (i.e. XDOM + tempfiles) on the disk, this way previews will even survive XE restarts. This is something we need to agree on. 5. Previewing office presentations (ppt) poses a lot of problems. A presentation import (as in officeimporter) consists of a .zip archive with image slides and html slides (text version) and the XDOM simply hosts a piece of html that reads slides from this .zip attachment. This idea does not jump into office-preview module very well and therefore we dumped html slides and kept image slides only for previewing. There are few hacks I did to implement previewing presentations but I'll talk about them in a separate email. I would be very glad if you can comment on first 4 points I've mentioned. Once we have reached an agreement on these points, I'll make necessary changes and integrate the code in our main source tree. Thanks. - Asiri

15 years, 5 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r28004 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api

by Sergiu Dumitriu

On 03/29/2010 06:57 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-03-29 18:57:58 +0200 (Mon, 29 Mar 2010) > New Revision: 28004 > > 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/XWiki.java > Log: > XWIKI-5041: Allow script authors to load and save documents in their own security context, not the user's Quick review: 1. Although this is not always the case in the current API, methods should not throw exceptions, since there is no way to catch them in Velocity, and it's not nice at all to display exceptions and stacktraces to the user. It would be better to catch all and return a boolean if the save/delete fails. 2. I don't quite like the comments; with an empty mind, I wouldn't understand what "the author of the code calling this function takes responsibility" actually means. Maybe something like this would be better: Save the document under the privileges of the script's author. More specifically, before saving, access rights are checked for the {@link #getContentAuthor content author} of the context document on the target document, which also is set as the new author of the document. The comment for XWiki.getDocumentAsAuthor is quite good. Read below for more comments. > 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 2010-03-29 16:57:48 UTC (rev 28003) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java 2010-03-29 16:57:58 UTC (rev 28004) > @@ -1823,6 +1823,64 @@ > } > } > > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * Saves with minorEdit set to false and no edit comment. > + * > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @see #saveAsAuthor(String, boolean) 2.3M2 already. > + * @since 2.3M1 > + */ public boolean saveAsAuthor() > + public void saveAsAuthor() throws XWikiException > + { > + saveAsAuthor("", false); > + } > + > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * Saves with minorEdit set to false. > + * > + * @param comment The comment to display in document history (what did you change in the document) > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @see #saveAsAuthor(String, boolean) > + * @since 2.3M1 > + */ > + public void saveAsAuthor(String comment) throws XWikiException > + { > + saveAsAuthor(comment, false); > + } > + > + /** > + * Save the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * This document will be saved if the author of the document containing the code which calls this function has > + * edit access to it. The contentAuthor of this document will be set to the author of the calling script, not the > + * viewer. This line doesn't make sense: > + * It is unwise to allow this function to be called by the viewer of the script. > + * > + * @param comment The comment to display in document history (what did you change in the document) > + * @param minorEdit Set true to advance the document version number by 0.1 or false to advance version to the next > + * integer + 0.1 eg: 25.1 > + * @throws XWikiException if script author is not allowed to save the document or if save operation fails. > + * @since 2.3M1 > + */ > + public void saveAsAuthor(String comment, boolean minorEdit) throws XWikiException > + { I wonder if this is the best way to get the content author. What happens with all the different include methods? Specifically, DocumentA includes DocumentB (sheet or topic), the call is in DocumentB; what is the context document? > + String author = getXWikiContext().getDoc().getContentAuthor(); > + if (hasAccessLevel("edit", author)) { > + String viewer = getXWikiContext().getUser(); > + try { > + getXWikiContext().setUser(author); > + saveDocument(comment, minorEdit); > + } finally { > + getXWikiContext().setUser(viewer); > + } > + } else { > + java.lang.Object[] args = { author, getXWikiContext().getDoc(), this.doc.getFullName() }; > + throw new XWikiException(XWikiException.MODULE_XWIKI_ACCESS, XWikiException.ERROR_XWIKI_ACCESS_DENIED, > + "Access denied; user {0}, acting through script in document {1} cannot save document {2}", null, args); > + } > + } > + > protected void saveDocument(String comment, boolean minorEdit) throws XWikiException > { > XWikiDocument doc = getDoc(); > @@ -1952,6 +2010,31 @@ > } > } > > + /** > + * Delete the document, the author (contentAuthor) of the code calling this function takes responsibility. > + * It is unwise to allow this function to be called by the viewer of the script. > + * > + * @throws XWikiException if script author is not allowed to delete the document or if save operation fails. > + * @since 2.3M1 > + */ > + public void deleteAsAuthor() throws XWikiException > + { > + String author = getXWikiContext().getDoc().getContentAuthor(); > + if (hasAccessLevel("delete", author)) { > + String viewer = getXWikiContext().getUser(); > + try { > + getXWikiContext().setUser(author); > + deleteDocument(); > + } finally { > + getXWikiContext().setUser(viewer); > + } > + } else { > + java.lang.Object[] args = { author, getXWikiContext().getDoc(), this.doc.getFullName() }; > + throw new XWikiException(XWikiException.MODULE_XWIKI_ACCESS, XWikiException.ERROR_XWIKI_ACCESS_DENIED, > + "Access denied; user {0}, acting through script in document {1} cannot delete document {2}", null, args); > + } > + } > + > public void deleteWithProgrammingRights() throws XWikiException > { > if (hasProgrammingRights()) { > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-03-29 16:57:48 UTC (rev 28003) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-03-29 16:57:58 UTC (rev 28004) > @@ -172,6 +172,53 @@ > } > > /** > + * Loads an Document from the database. Rights are checked on the author (contentAuthor) of the document > + * containing the currently executing script before sending back the loaded document. > + * > + * @param fullName the full name of the XWiki document to be loaded > + * @return a Document object or null if it is not accessible > + * @throws XWikiException > + * @since 2.3M1 > + */ > + public Document getDocumentAsAuthor(String fullName) throws XWikiException > + { > + DocumentReference reference; > + This branching could be replaced by ....resolve(StringUtils.defaultString(fullName); > + // We ignore the passed full name if it's null to match behavior of getDocument > + if (fullName != null) { > + // Note: We use the CurrentMixed Resolver since we want to use the default page name if the page isn't > + // specified in the passed string, rather than use the current document's page name. > + reference = this.currentMixedDocumentReferenceResolver.resolve(fullName); > + } else { > + reference = this.defaultDocumentReferenceResolver.resolve(""); > + } Perhaps you mean: return getDocumentAsAuthor(reference); > + return getDocument(reference); > + } > + > + /** > + * Loads an Document from the database. Rights are checked on the author (contentAuthor) of the document > + * containing the currently executing script before sending back the loaded document. > + * > + * @param reference the reference of the XWiki document to be loaded > + * @return a Document object or null if it is not accessible > + * @throws XWikiException > + * @since 2.3M1 > + */ > + public Document getDocumentAsAuthor(DocumentReference reference) throws XWikiException > + { > + String author = getXWikiContext().getDoc().getContentAuthor(); > + XWikiDocument doc = this.xwiki.getDocument(reference, getXWikiContext()); > + if (this.xwiki.getRightService().hasAccessLevel("view", author, doc.getFullName(), == false should be replaced by a ! > + getXWikiContext()) == false) { > + return null; > + } > + > + Document newdoc = doc.newDocument(getXWikiContext()); > + return newdoc; > + } > + > + /** > * @param fullname the {@link XWikiDocument#getFullName() name} of the document to search for. > * @param lang an optional {@link XWikiDocument#getLanguage() language} to filter results. > * @return A list with all the deleted versions of a document in the recycle bin. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

3
4
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.2.4 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.2.4. This is a bug fix release for the 2.2 branches. It fixes mainly two important regressions on rights manager UI and statistics module. Important Bugs fixed: * XASCH-52 - Job script shouldn't be edited with wysiwyg * XABLOG-99 - Blog Category Name with Apostrophe crashes Blog Category function * XWIKI-5057 - Rights aren't saved if the groups/users radio button is not manually selected * XWIKI-5039 - When starting a wiki on a sub wiki page, main wiki main page is broken by statistics module * XWIKI-4957 - Allow entering @, ? and # characters in link references * XWIKI-5053 - Cannot upload attachments to pages with # in their name * XWIKI-5063 - Don't fail the rendering when the document's title fails to be rendered * XWIKI-4984 - Header ids are always the same ("H") with Chinese or any other language without any ASCII character * XWIKI-5035 - LazyXWikiDocument is not synchronized anymore with XWikiDocument * XWIKI-5036 - WYSIWYG editor doesn't display when creating a document named #"&§-_\ * XWIKI-5021 - "Save and Continue" doesn't work in Preview mode only with IE7 * XWIKI-4723 - Could not restart only one cluster instance in cluster mode because of stuck JVM Translations: * Newly supported language: Vietnamese For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise224 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM224 Thanks -The XWiki dev team

15 years, 5 months

1
0
0 0

[xwiki-devs] XWiki Office 1.1 Released!

by Silvia Rusu

Hello, The XWiki development team is pleased to announce the release of XWiki Office 1.1. Go grab it at: http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWiki20Office All active XOffice 1.0& 1.1 instances will be automatically updated to the final version. Summary of features for XOffice 1.1: - Optional Startup - Document refresh and View active document in browser - Styling support for XWord 2007 and better text formatting - Page version checking when publishing - Document compare and conflict resolution View detailed release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice11 For more information about XOffice visit: http://xoffice.xwiki.org Thanks, -The XWiki dev team

15 years, 5 months

1
0
0 0

[xwiki-devs] [vote] Release the xwiki-model-backport project in the sandbox

by Anca Luca

Hi devs, I would like to release the xwiki-model-backport project at https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-model-backport/ . This project is a backport of the xwiki-model module, as it was released in version 2.2 and in addition with http://jira.xwiki.org/jira/browse/XWIKI-4775 applied, which can be deployed on a 2.1 wiki and a 2.2 wiki (with some extra-hacks though), so that references in general and references for objects & properties can be used on these versions. In particular, it is useful to be able to install the annotations extension on these 2 versions. I would like to release it now since it won't have any improvements (this is its final version), and it should be published in the maven repo so that projects can depend on it. here's my +1, WDYT? Happy coding, Anca

15 years, 5 months

4
4
0 0

[xwiki-devs] [Proposal] Allow users to invite friends to join a wiki by email.

by Caleb James DeLisle

Should this be a jira top level project? I don't see what existing application it would fit in. Some information about the code's current form: It allows users to invite their friends to join a wiki, it has some strict measures too handle spam situations, the email message is saved and administrators (people with edit rights on that page) can review sent emails. The email has an ID string which is contained in a link sent to the email address so that the invitee can report the email as spam (this is a function of the template.) falsely reporting messages as spam is protected because the ID string is a large random number. Users can send to one address and admins can send to as many addresses as they like. Email addresses are checked against a regular expression before sending and invalid addresses will not be sent to. If the sender is a user and can only send to one address then the address is checked against LiveValidation as well. If a message is reported as spam, then it is flagged on the list and when an admin views the list they can inspect the message and select a button to indicate that the situation has been investigated. Caleb

15 years, 5 months

2
4
0 0

[xwiki-devs] [Proposal] XE 2.3 Updated Roadmap

by Vincent Massol

Hi, Since today is the day we're supposed to release XE 2.3M2 and since we've released 3.2M1 quite late compared to the original date we need to decide what we do from now on. Original dates: * XE 2.3M1: 8 March 2010 (1 month after XE 2.2 final) * XE 2.3M2: 29 March 2010 * XE 2.3RC1: 12 April 2010 * XE 2.3 RC2/Final: 26 April 2010 Here's my proposal: * We have enough new features already (captcha in comments, new theme editor, annotation features, any char supported un doc names, lots of rendering fixes, etc) to justify a final XE 2.3 release * I suggest Thomas finishes putting our Lucene search as the default search since it's now working well enough. AFAIK Thomas is only missing an admin screen to finish it. * I suggest we don't have more new features (unless someone has something that can be committed this week - Caleb: what about the invitation feature?) * I suggest we release: ** XE 2.3M2 on the 5th of April ** XE 2.3RC1 on the 12th of April (one week after) ** XE 2.3RC2/final on the 19th of April (and in case we have problems we can delay by one week till the 26th of April) WDYT? Thanks -Vincent

15 years, 5 months

4
5
0 0

[xwiki-devs] Issue with Pygments/Python

by Nicola Nardino

Hi all, I've come across this issue today while using the code 20 macro. It seems that there's an issue with the class loader that is unable to locate one of the packaged python modules (os). It might explain the cause given the fact that with Tomcat I've no issues (now using Weblogic as company wide app server). Have you ever experienced something line this: Caused by: Traceback (most recent call last): File "<string>", line 1, in <module> File "__pyclasspath__/pygments/__init__.py", line 36, in <module> ImportError: No module named os at org.python.core.PyException.fillInStackTrace(PyException.java:70) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.python.core.PyException.<init>(PyException.java:46) at org.python.core.PyException.<init>(PyException.java:43) at org.python.core.PyException.<init>(PyException.java:61) at org.python.core.Py.ImportError(Py.java:264) at org.python.core.imp.import_first(imp.java:672) at org.python.core.imp.import_name(imp.java:756) at org.python.core.imp.importName(imp.java:806) at org.python.core.ImportFunction.__call__(__builtin__.java:1232) at org.python.core.PyObject.__call__(PyObject.java:367) at org.python.core.__builtin__.__import__(__builtin__.java:1202) -- View this message in context: http://n2.nabble.com/Issue-with-Pygments-Python-tp4816815p4816815.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 5 months

2
13
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs