xwiki-devs August 2010

xwiki-devs@xwiki.org

29 participants
47 discussions

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

by Sergiu Dumitriu

Hi devs, I just realized that there was no official roadmap proposal for XE 2.5 yet, since Vincent, the usual release manager, is on holidays. I volunteered for performing the releases, so I'll assume the release manager role as well until Vincent returns. Proposed features for the 2.5 release: - Improved wiki dashboard - Improved edit modes UI - Office Preview - Action menu improvements (Caty, JV, Sergiu) - Export UI improvements (Caty, Sergiu) - "Email this page" feature (Sergiu) - User Directory Generic stuff: - More UI standards (avatars, icons, forms) - Improved performance - Improved security - WYSIWYG bugfixing and optimization - More 2.0 macros Possible new features: - Portlet integration (Marius) - Layout Themes (Sergiu) - Gadgets (Anca) - Wiki Import (Thomas) Proposed dates: - 2.5M1: 30 Aug - 2.5M2: 27 Sep - 2.5RC1: 11 Oct - 2.5RC2/Final: 25 Oct -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 3 months

[xwiki-devs] Status of the includeMacros macro in XE 2.4

by Luis Arias

Hi, I posted http://jira.xwiki.org/jira/browse/XE-700 a couple of days ago and am writing now because more and more of the Balsamiq Mockups for XWiki users are attempting or would like to migrate to 2.4 but have pages with mockups embedded using #includeMacros. I'd like to know if #includeMacros is definitely not going to be supported from 2.4 onwards or if this is a bug that will be fixed at some point. We can update the plugin (already have actually) to use the recommended syntax for new mockups but still have the issue of dealing with existing pages. I would also like your thoughts on a simple workaround which ideally we could ask our users / wiki admins to do. Thanks, Luis

14 years, 3 months

[xwiki-devs] Supress contents from PDF export

by Luiz Marcelo Serique

Hu guys, there is any way to supress content parts from the pdf report? Here is the problem: Most of pages have a toc macro with this code {{box cssClass="floatinginfobox"}} {{toc depth="3"/}} {{/box}} As we know, the pdf report also puts a toc page. My reports are getting two tocs, one from report and one from content. But i do not want to remove de pdf toc because some wiki pages do not have the content toc. There is a way to supress the content toc from appearing in the pdf report? thanks -- L. Marcelo Serique

14 years, 3 months

[xwiki-devs] [discussion] Macro categories usage & multiple categories per macro

by Anca Luca

Hi guys, Short story: 1/ glorify macro categories and use them for more than presentational purposes (e.g. using a category to differentiate "gadgets" macros from other macros) 2/ allow a macro to be part of multiple categories at the same time WDYT? Long story: I have read http://markmail.org/thread/wwv56pojo6rix5zv about the current implementation for macro categories and I noticed that the discussion / approach there focuses on the presentational use of categories for macros, how to display them grouped to the user. I would say there's an important additional usecase, the usage of categories as macros metadata, describing their semantic, to allow some apps to implement different behaviour for macros in a category or another. For example, in the case of gadgets / dashboard, if a gadget would be implemented as a macro, then we'd need some sort of method to differentiate the macros that can be used as gadgets. The most 'semantic' way would be to use a gadgets category to mark the gadgets, and the dashboard implementation will allow only macros from this category to be added in the dashboard. However this approach would mean that macro category gains importance, and we need to think if it's still ok that an admin can change the category of a macro and the macro category declared by the author can be completely overwritten. WDYT about using the macro categories for much more than grouping for presentation? I'm +1, and I think that ftm there's no need to strategy change wrt to who establishes the category of a macro. Also, because of this, it's very possible that we might need a macro to be part of more than one category, because, to continue the example, we might want gadgets to also be grouped in several categories (of gadgets), or a gadget to also be included in the, say, "presentation" category of macros to be used in plain xwiki documents. WDYT? I am +1 for this as well, and ready to start building the patch (modulo some macros API changes) as soon as we all agree. Thanks, Anca

14 years, 3 months

[xwiki-devs] [VOTE] Alex Busenius as a committer.

by Caleb James DeLisle

Hello, I have been working with Alex on security related code and have been impressed with his abilities as well as dedication to consistent improvement of the project and his own code. Alex has worked on some complex changes to difficult code such as: XWIKI-5275: Prevent nested script macros. http://jira.xwiki.org/jira/browse/XWIKI-5275 As well as a large quantity of cross site script related patches such as: XWIKI-5161: Using XML symbols (<, >, &, ") inside the document title/name/space breaks various parts of the UI and causes the PDF export to throw exceptions http://jira.xwiki.org/jira/browse/XWIKI-5161 A full list is here, most are not viewable by the public. http://jira.xwiki.org/jira/secure/ViewProfile.jspa?name=nickless#selectedTa… Alex has developed an automated cross site script fuzzing test which can be seen here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-enterprise-test-es… He is also responsible for parts of xwiki-crypto including PKCS7 signing and validation and X509 certificate handling. see: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… As far as write access to the main repository, I think there is no question that he will be a good committer. It should be noted that I would be +1 for giving write access to anyone who demonstrates a need. The remaining issue is the responsibility of being on the "steering committee", having the power to -1 a vote. Alex and I agree on a lot of issues where we hold the minority position so my opinion should be taken with the salt it deserves. That said, he has the courage to voice disagreement when he has it, he takes an interest in decisions regarding the core rather than being concentrated on the user interface, and he has the ability to spot problems in design which will not become obvious until later. I think Alex Busenius will be a great committer. +1 Caleb

14 years, 3 months

[xwiki-devs] Email application

by Sales, G. (Grant)

My send page by email panel isn't functional. I get a error telling me that there might be an error in the email address I've entered. This panel was installed correctly with a user that has programming rights. Any thoughts on the settings that I need to play with? Or is my version of xwiki not capable of doing this? I've been reading some of these emails and it looks like maybe in a new version of xwiki this panel will come standard, is this true? If so I can I update to the current version and also be able to delete properties in a class? Thanks for your help ~Grant Grant Sales Security Operations Analyst ING 111 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

14 years, 3 months

[xwiki-devs] Wysiwyg editor and macro accessing to Alfresco (or other external tool)

by jurevert

Hi, Our goal is to develop a wysisyg macro allowing to : - Insert an Image stored on Alfresco - Insert a link to a document stored on Alfresco To do this; we have develop a small browser on Alfresco in order to choose the image to insert (img src) or the file to link (a href). After selecting the Alfresco file; we need to generate a macro like : [[Lien vers le doc toto>>http://alfresco.airfrance.fr/alfresco/.../toto.doc||rel="__blank" title="Ouvrir le doc toto..."]] or [[image:http://alfresco.airfrance.fr/alfresco/..../image.jpg]] Using the wiki editor and the old Wysiwyg editor; we had no problem to do this. (Openning popup and populate les link field with alfresco file path.) With the new editor; I can't find the way to do this. In fact my problem could be resume to add a picto in the 'link' and 'image' macro GUI allowing to open my alfresco browser in order to populate the path ! Any idea to do this ? Thanks, Julien -- View this message in context: http://xwiki.475771.n2.nabble.com/Wysiwyg-editor-and-macro-accessing-to-Alf… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 3 months

[xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Ecaterina Valica

Hi, This is a page centric proposal for "Recent Changes": * Partial Prototype (Firefox) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamP3D * Some screenhots http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV3 Any feedback is greatly appreciated. Thanks, Caty P.S: Older user centric proposal was http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV2

14 years, 3 months

[xwiki-devs] [proposal] Move servlet filters out of the core

by Alex Busenius

Hi devs, I propose to move servlet filters out of the old core to xwiki-container-servlet. There are 3 filters, com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it. Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters. Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem. In more detail, * SetCharacterEncodingFilter would be moved as is to filters.internal. * SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter. * ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value. There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too I'm +1 for 2, since it's the cleanest option. WDYT? Thanks, Alex

14 years, 3 months

[xwiki-devs] [Proposal] Stop logging errors when a wiki macro cannot be registered due to insufficient privileges for the asked visibility

by Jerome Velociter

Hi friends, I'm proposing a patch (see http://jira.xwiki.org/jira/browse/XWIKI-5439) to stop logging a full exception at error level when the wiki fails to register a wiki macro due to insufficient privileges for the asked visibility. This is currently what happens, and it can trash your log, for example if you initialize a farm with hundreds of wikis throwing couple of times such error :) Thing is this is not a real error, in the sense "something went wrong" so it should be logged at the debug level. The patch introduce a new exception : org.xwiki.rendering.macro.wikibridge.InsufficientPrivilegesException, which when caught by the wiki macro initializer is logged at debug level, by opposition of the more generic org.xwiki.rendering.macro.wikibridge.WikiMacroException that remains logged at error level. I'm calling for a vote since the patch introduce a API signature change. Though I tend to think it's internal enough not to go through deprecation cycle. My +1 Jerome.

14 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2010