xwiki-devs December 2014

xwiki-devs@xwiki.org

15 participants
39 discussions

[xwiki-devs] Debugging issue in PDF export functionality.

by Karel Gardas

Hello, I'm trying to debug those two issues: http://jira.xwiki.org/browse/XPDFECA-11 http://jira.xwiki.org/browse/XPDFECA-12 to easy my debugging work, I've installed jetty-based 6.3 xwiki enterprise distro and I'm editing files directly in it (so far just velocity macros hacking). Now I'm in templates/macros.vm which looks like it is kind of processed into skins/flamingo/macros.vm -- so I'm editing directly this file and restarting xwiki server after every change. I'm testing on a page: <page code> This is a page to test pdf export facility. Let's link all the pages here: [[Page1]] [[Page2]] [[Page3]] [[Page4]] [[Page5]] Now, let's test if we're able to pdf export groovy script output. {{groovy}} println 10; println "[[Page6]]" {{/groovy}} </page code> Now, the problem is that for this testing page I get just links to Page1 to Page5. The link to Page6 is missing. I've modified includeLinks to include this code: #macro(includeLinks $page $withPageBreaks) hacked includeLinks is in effect -- 2 -- flamingo!!!! What is clevel?: $clevel #if($clevel && $clevel!=0) we are working on a page: $page #set($pageDoc = $xwiki.getDocument($page)) All links are:<br> #foreach($child in $pageDoc.getLinks()) #set($childDocName = $child.getLink()) $childDocName<br> #end so I can see all the links. So it looks like to fix that I'll need to kind of pre-render the page somehow and then obtain links from the rendered data -- or kind of that. Is there some functionality for this already presented in XWiki? If so, any hint where it is is highly appreciated here! Thanks a lot, Karel

9 years, 8 months

[xwiki-devs] Ownership of the metadata about the subwiki

by Anca Luca

Hello devs, = Short story = Since the metadata about a subwiki (pretty name, description, users scope) are in the middle between main wiki and the subwiki (are used on both), who should have the last word about this data? Global admin of the farm of local admin of the subwiki? = Long story = while looking at http://jira.xwiki.org/browse/XWIKI-11416 , we came across a couple of questions about what is a subwiki and who "owns" (controls) the metadata about it. It all started with the fact that XWIKI-11416 would imply allowing the local admins of the subwiki (potentially local users) to edit information which is stored on the main wiki. There are 2 important things to discuss about this requirement: A. 1/ it is important that the metadata about a subwiki can be controlled by the local admin group, or another _group_ of people. The owner of the wiki is not enough, as owner is not a role and can only be fulfilled by one person, which is limiting in terms of collaboration. 2/ the wiki description and pretty name are stored on the main wiki today, in the wiki descriptor, while information about the user scope and membership are stored on the subwiki. This was changed recently, when the wiki concept was revamped and integrated with workspaces, in 5.3 (before that, everything was on the main wiki). A 2/ takes us to the main question of this mail: who is responsible / should should be responsible for the information about a subwiki? One direct consequence of this answer is the storage of this data, but the implications are larger than that because they can define the usecases that we support for the new wikis (as they are defined by the new implementation from 5.3). This question arises because this metadata is quite tricky as it represents the relation between the main wiki and the subwikis, so it could be considered that both main wiki and subwikis have priority on it. Please express your opinion about the following approaches, both as a general guideline, and in particular in the context of the 5 items from the descriptor that we're discussing: pretty name, wiki description, membership type, user scope, owner. B 1/ the global admin must be able to control the data about the subwikis, regardless of the opinion of the local admins 2/ the local admins should be free to configure the data about the subwikis, without the global admin controlling these settings. Note that this is already the case for wiki rights, by construction of the wiki, and recently this was chosen for user scope and membership type by storing them on to the subwiki in 5.3 3/ both approaches should be possible, depending on the type of farm we make (farm of wikis with subwikis with local users which don't know one about the existence of the other wikis, a la myxwiki.org or farm of wikis where users can create wikis of their own, workspaces style) 4/ both approaches should be possible, depending on the type of wiki, which should be decided by the global admin (on the same farm we could have some wikis on which global admin decides this metadata and some wikis on which local admins decide it) Note that B 3 and 4, in my opinion, have consequences on the type of wikis that we want to make _by default_ (with customization everything will be possible): UC 1 : farm where the wikis are handles as dedicated spaces for collaboration inside the same community, the users all know about the existance of all wikis (workspaces style) UC 2 : farm where the users don't know about the existance of the other wikis, where every subwiki is independent, like an XWiki instance without subwikis, they are just managed by the same farm, for various reasons ( myxwiki.org style, cloud mode, real "farm" mode, the pre-workspaces way of making subwikis). Please comment on these items, from a conceptual point of view. Thanks, Anca P.S. we also discussed a couple of implementation details today, with Denis, Eduard and Guillaume D: * allowing local admins to change data that is stored in a document on the main wiki is problematic because it would mean to code a modification a document which would bypass the rights system, which is not generally a good idea, we should model this by using the regular rights system (the users that must be able to edit the descriptor should be able to have edit rights on it) * normally storing data on the subwiki is problematic because of the performance issues that arise when using this information on the main wiki (it's not possible to fetch it with a hql query). BUT the wiki manager implementation has a cache where this data can be stored so that it's not always looked up on the subwiki when needed on the main wiki. This cache, while quite limited today, can be improved to answer whatever filtering needs.

9 years, 8 months

[xwiki-devs] XWiki 6.3 Flamingo disappeared after import large XAR

by Andrea Ferroni

I have installed XWiki enterprise 6.3 Flamingo skin is visibile. After import my previous XWiki 5.1 content, using extension Large+XAR+Import, Flamingo skin disappeared. XWiki is exactly 5.1 style and I can't select Flamingo from Admin panel. Why ? Ho to restore Flamingo ? Andrea

9 years, 8 months

[xwiki-devs] [ANN] XWiki 6.4 Milestone 2 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 6.4 Milestone 2. This version brings mainly UI improvements in the Menu application, Mail application and Flamingo skin, while offering developers the ability to write LESS in Skin Extensions, a cool icon picker and new ConfigurableClass and Mail Sender API features. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64M2 Thanks -The XWiki dev team

9 years, 8 months

[xwiki-devs] [Proposal] Delay the 6.4 release by introducing a milestone

by vincent＠massol.net

Hi devs, When we look at our roadmap at http://www.xwiki.org/xwiki/bin/view/Roadmaps/ we can see that there are some issues that we wanted fixed in 6.4 and that are not done yet and they wouldn’t fit in a RC: - batch mail feature (ability to send large volumes of mails) - several outstanding issues for flamingo - "Move the "Pretty Name" and Description sections from the Main Wiki to their respective subwiki Administration page” - "Extension Manager add extension search should suggest only compatible versions - Addition of Ratings feature in Repository app In summary, we’re very very late and not in a good shape, and holidays are coming soon… So I’m proposing the following: - release 6.4M2 this week (Edy to do the release) - add a 6.4M3 release spanning 2 weeks, to be released on 5th - move the RC to 12th of Jan - move the final to 19th of Jan. Overall this means a delay of 3 weeks compared to our initial plan of: - 6.4M1: --1st of Dec-- 3rd of Dec - 6.4M2: 15 Dec - 6.4RC1: 22 Dec - 6.4Final: 29 Dec This is not nice obviously since it impacts our ability to start XWiki 7.0 at beginning of January but I don’t see any other option. Note that the reason why it’s important to have these features in 6.x is because a lot of users are still on 5.x or older and are going to move to 6.x during the coming year and it’ll be another year before they move to some XWiki 7.x release so we need to close the 6.x cycle nicely. Also note that I’ve considered adding a 6.5 release but I think it’s better to extend 6.4 because: - our cycles go from N.0 to N.4 - adding a full release would delay the starting date of 7.0 dev even more Also note that we’ll probably have 6.4.1, 6.4.2, … stabilization releases too. WDYT? Thanks -Vincent

9 years, 8 months

[xwiki-devs] [Review] Extension Repository App & Ratings

by Victor Rachieru

Hei devs, I've been working on implementing ratings for the Extension Repository App and making that information available via Extension Manager. Also, this required the integration of the ratings module from xwiki-contrib into xwiki-platform. On my personal repository you'll find two branches containing the 1st version of the working code. The tasks covered ------------- XWIKI-11507 <http://jira.xwiki.org/browse/XWIKI-11507> : Integrate the ratings system from xwiki-contrib XWIKI-7780 <http://jira.xwiki.org/browse/XWIKI-7780> : Rating and advice system for extensions XWIKI-11508 <http://jira.xwiki.org/browse/XWIKI-11508> : Include ratings information in the Extension REST API XWIKI-11509 <http://jira.xwiki.org/browse/XWIKI-11509> : Display ratings information in the Extension Manager UI Modules modified ------------- xwiki-commons-extension xwiki-commons-repository xwiki-platform-extension xwiki-platform-flamingo xwiki-platform-ratings xwiki-platform-repository xwiki-platform-web Branches ------------- https://github.com/vrachieru/xwiki-platform/tree/xwiki-platform-ratings https://github.com/vrachieru/xwiki-commons/tree/xwiki-commons-ratings Feedback is welcome. Thank you, Victor

9 years, 8 months

[xwiki-devs] [Proposal] Introduce LESS in Skin Extensions (SSX)

by Guillaume "Louis-Marie" Delhumeau

Hi. Since the beginning of the week, I am working to have the LESS pre-processor inside our Skin Extension objects (see: http://jira.xwiki.org/browse/XWIKI-10708). It would enable us to use the Flamingo Theme variables and all bootstrap's mixins inside SSX (see http://jira.xwiki.org/browse/XWIKI-11374). Example of use-case: http://jira.xwiki.org/browse/XWIKI-11408 (Menu Application: Improve default look to make it better-looking with the Flamingo skin). I have created a design page there for the details: http://design.xwiki.org/xwiki/bin/view/Proposal/LESSModuleImprovements I propose to add a new property inside the XWiki.StyleSheetExtension class which will be called "CSS preprocessor". The actual possible values would be "LESS" or "none", but in the future we can imagine having "SASS" or anything else. Then I propose to change the actual SSX action to perform a LESS compilation if needed. Note that the user would still be able to use or not Velocity in addition of the CSS preprocessor. The other possibilities (that are not part of this proposal) are to create a new XWiki.LESSStyleSheetExtension and a new LSSX action which would behave exactly as the previous objet and action, or to have the ability to choose the processor directly inside the SSX content, with a special line like "# preprocessor = less" or something like that. I have made a prototype that is working ( https://github.com/xwiki/xwiki-platform/tree/feature-less-ssx) and I am taking care of the compatibility with older skins that do not use LESS (Colibri for instance). Here is my +1. I would like to commit it today to have it in 6.4M2. I have done a lot of refactoring on the LESS module (with a better cache system among other things) that I don't want to commit in a release candidate. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 8 months

[xwiki-devs] [Discussion] Replacing the use of PR checks. Is it really an option? How exactly?

by Eduard Moraru

Hi devs, We are all waiting for signed scripts to come to the rescue, but until then, we have pretty much agreed that it is a good idea to remove PR checks, which don`t work in subwikis (see activity stream [1], wikis module [2], etc.) However, once we do that, we open up a big security problem, such as "trap pages". These are basically documents containing malicious usage of our services, that are written by regular users and that are waiting (or tricking) for admins (or users with privileges) to access them by mistake. Since those script services will be looking only at the current user's rights, they will be executing the malicious code and the security will be compromised. What options do we have here? On some modules (like the wiki module) it might be useful to check the context security document (sdoc) and see if its author is an admin (of the wiki descriptor that is being saved) or a global admin, thus replacing a PR check on the current document with an "admin check on the current document". Using sdoc instead of just doc avoids attempts of using proxy documents (e.g. default ones like /bin/view/someDocument?sheet=SomeBadDocument or custom ones created by the usage of the display or include macros), but unfortunately that is not set by default by XWiki's actions and is only available in a handful of locations, meaning we can not rely on sdoc. A mechanism similar to CSRF protection API but for script services to confirm that the user really intended to execute them might be another idea, but I`m not sure how that might be implemented without allowing easy bypass by directly providing the challenge result. CAPTCHA for sensitive script services? :) That might be too extreme and completely ruin the UX. Any ideas? Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-10446 [2] http://jira.xwiki.org/browse/XWIKI-11416

9 years, 8 months

[xwiki-devs] [Idea] Sandbox flavor

by vincent＠massol.net

Hi devs, Here’s an idea we discussed with Charles yesterday when he was surprised that clicking on “Sandbox” in the QuickLinks Panel wasn’t leading to a new wiki but to a page. The idea is: - create a Sandbox flavor - add training content in several spaces, on the home page of the wiki, that the user is encouraged to modify/edit - more generally make this whole wiki a training wiki for learning how to use xwiki - When an admin sets up an XWiki instance, if he wants a zone for his users to learn xwiki, he’d create a subwiki and choose the Sandbox flavor WDYT? Thanks -Vincent

9 years, 8 months

[xwiki-devs] [XWiki Day] BFD#74

by Eduard Moraru

Hi devs, As you probably already know, today is BFD#74: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 55 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Still half way there... With just a bit more participation, we can make it. Here's the BFD#74 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12990 Thanks and enjoy your bug fixing day! -Eduard

9 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2014