xwiki-devs April 2010

xwiki-devs@xwiki.org

34 participants
77 discussions

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 5 months

[xwiki-devs] Redirect to a space

by Bruno Amaro Almeida

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

11 years, 1 month

[xwiki-devs] Pretty Time library

by Vincent Massol

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

12 years

[xwiki-devs] How to load GWT application on Xwiki pages?

by Leon Wang

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

12 years, 8 months

[xwiki-devs] [VOTE] Edit UI improvements and panelless edit

by Sergiu Dumitriu

Hi devs, We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote. The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit Here are the individual voted points: 0 Remove all panels in edit mode 1a Parent and title above the content in wiki/wysiwyg mode 1b The same style in edit mode as in view mode for the parent/title fields 1c AJAX Suggest for the parent field 2a New label for the content textarea ("Content") 2b List of included documents after the Content label 3a Syntax switcher in the top right corner of the content 3b Syntax help in the top right corner of the content 3c Syntax help and switcher only in the wiki editor 4 Better label for the version comment 5a Right float the Minor edit field 5b Put the Minor edit label after the checkbox 6 Move autosave in line with the submit buttons 7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects 8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list 9 Move the class switcher in the top right corner 9b Remove the class switcher 10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii) -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 10 months

[xwiki-devs] [Proposal] Selective Export UI

by Ecaterina Valica

Hi, Please provide feedback for the Selective Export UI: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize. Thanks, Caty

14 years, 1 month

[xwiki-devs] [proposal] Add support for secet token verification

by Alex Busenius

Hi, I would like to add support for secret token verification to prevent CSRF attacks (see http://jira.xwiki.org/jira/browse/XWIKI-4873). The main idea is to add a random token as a parameter to each request that requires edit/comment/admin rights and check that this token is present on the server side. Since there are many ways one can modify documents, it would require many changes all over the place, in particular: * add a public method to XWikiContext: String getSecretToken() that generates a random token and caches it in the session * add a public method to XWikiRightService*: boolean isRequestLegitimate(String action, XWikiContext context) to check if the given action is allowed to be executed * add the following API methods to Context: String getSecretToken() boolean checkSecretToken() for including the secret token into forms/AJAX requests and checking that the current request is legitimate * add a new configuration parameter core.useSecretTokenValidation for disabling this functionality, and the corresponding method useSecretTokenValidation() to CoreConfiguration and DefaultCoreConfiguration * use the secret token (hidden input for forms or parameter of GET requests) in all templates (*.vm files in web/standard and skins, velocity macros in applications/**/resources/*.xml) * check the secret token in Save/Delete/Upload/etc.-Actions and throw an exception to deny the access if the check fails * check the secret token in all templates that directly modify data (e.g. web/standard/src/main/webapp/templates/admin.vm) * fix all selenium tests that directly modify pages using the open(...) method * make sure nothing else is broken WDYT? Thanks, Alex

14 years, 1 month

[xwiki-devs] [Proposal] Roadmap for XE 2.4

by Vincent Massol

Hi devs, It's time for roadmap again in order to define what we want to work on for XE 2.4 (as usual this list doesn't include bugs that we have to fix). Here's a proposal that takes into account past stuff that we had planned for XE 2.3 and that haven't been done: * Work on improving performances in general (could be a cache macro, object handling improvements, etc). Any taker? * Finish xwiki-localization. Suggestion: Sergiu + Thomas * Lucene as main search engine in XE: Thomas * Fix some security issues. Sergiu + others? * Edit Mode UI Changes: JV/Sergiu/Marta * Continue the Model Reference refactoring - Vincent * Office preview - Asiri * Invitation Manager - Caleb * Rights UI improvement to make rights easy to use at last - Suggestion: Caty + Sergiu * Support for component versioning and claddloader isolation (prereq for the extension manager) - Vincent * Integration of xwiki-portlet in sandbox into the platform - Marius Nice to have: * Livetable macro - Asiri * Selective Export UI - Any taker ? * Continue work on Model. Suggestion: Vincent * Office Export - Asiri Proposed dates: * XE 2.4M1: 24 May 2010 * XE 2.4M2: 14 June 2010 * XE 2.4RC1: 28 June 2010 * XE 2.4 RC2 (if needed): 5 July 2010 * XE 2.4 Final: 12 July 2010 WDYT? Please everyone confirm if what is put next to your name is ok with you or if you have other ideas or wish to work on something else. I'll then update http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks a lot -Vincent

14 years, 1 month

[xwiki-devs] Introduce new tempresource action

by Vincent Massol

Hi, Part I ===== I've started implementing a Ditaa Macro over the weekend (http://ditaa.sourceforge.net/ ) but we need an Action to return the Ditaa-generated image file. For the chart macro we're using the charting action but I think we can make this generic and instead introduce a tmp (or temp or tmpresource or ...) action instead that would return any resource located in the xwiki temporary directory. For ex: /xwiki/bin/tmp/SomeResource would return SomeResource found in container.getApplicationContext().getTemporaryDirectory(). Part II ===== The only thing to be careful about is to not be able to read what's for another user and for which you don't have access to see it. For example an image generated by the chart macro for a page for which the user doesn't have view rights. This can be partially solved by ensuring that file names include a generated token. However the pb is that this token cannot be unique since, for ex, generated image need to be shared to anyone having the rights to view a page. <brainstomring mode> A solution I see would be to include the "rights" to check + the full page name in the URL, in addition to the resource. For example: /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource A more generic solution would be to add a notion of Check Handler, i.e. code that would perform the check. For example in the previous solution it's not possible to check for 2 permissions, nor any complex scheme. This would mean something like: /xwiki/bin/tmp/<check handler name>/<resource name>?<check params> Ex: /xwiki/bin/tmp/simple/SomeResource? checkPermission="view"&checkDocument="wiki:Space.Page" Implementation: A component with a role hint of "simple" would be looked-up and the check logic delegated to it. However someone could use a some check for a resource that wasn't meant to be used for that resource. Thus the check and its params should probably instead be included in the resource name with some algorithm instead. Thus the solution maybe to have a high level API to create a resource name and that API would take a Check Handler hint + some arbitrary params and that API would generate a resource name with these added. For ex something like:: "SomeResource-simple-view-wiki:Space.Page" (or any other format). Another solution would be to follow a completely different direction and for example to introduce a new XDOM representation for a TMP- image, i.e. in addition to URLImage and DocumentImage, to add a TemporaryImage implementation. </brainstomring mode> WDYT about these 2 ideas and especially about Part I since I would need that sooner rather than later to implement the Ditaa macro, and Part II is already a problem today. Thanks -Vincent

14 years, 2 months

[xwiki-devs] Should email invitation app be a top level application? How should I add it to the sandbox?

by Caleb James DeLisle

I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. Caleb

14 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2010