xwiki-devs October 2016

xwiki-devs@xwiki.org

12 participants
40 discussions

[xwiki-devs] Release notes strategy for included contrib extensions

by Vincent Massol

Hi devs, We now include a few contrib apps in XE. However, when someone checks the RN for XE, for example http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki83M2 all they see is this: “The following dependencies have been upgraded: * Tour Application 1.0.4” It doesn’t say if there are any substantial things added those deps. I can think of 2 solutions: 1) When something is noticeable, add it to the RN of XE. So for example if CKEditor extension adds something new, users checking the RN of XE can see it immediately. 2) Link to the RN of the extension. However RN of extensions on e.x.o are not nice. They’re just lists of JIRA issues. So for this solution to be a bit satisfactory we would need to improve the RN of extensions, starting with those we bundle in XE. Another possibility is to say that for Recommended Extensions we pay an extra care to write nice Release Notes. But that’s harder to enforce and ensure. Option 1) is my preference. WDYT? Thanks -Vincent

7 years, 10 months

[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

by Vincent Massol

Hi devs, With the recent introduction of the Applications Index (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we need to agree on a few things. In the past we had: * We wanted all new app that you installed to automatically be visible in the Applications Panel * This is why the Applications Panel config had a blacklist (and not a white list) What we’ve done: * We add the Applications Index * We removed some apps from the Applications Panel. Namely: Invitation, Panels, Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration. The need: * We need to remove this hack. It’s not normal for the Panels module to know all the apps that shouldn’t be listed in it! Proposal: * Replace the blacklist configuration of the Applications Panel by a whitelist one * When a new app is installed, list it in the Applications Index but don’t add it to the Applications Panel * If an admin wants to add this new for his users, he’ll need to add it in the Admin UI for the Applications Panel. WDYT? Thanks -Vincent

7 years, 10 months

[xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

by Vincent Massol

Hi devs, I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been reported by Nicolas that all the users he’s seen use XWiki don’t use the Message Stream feature and moreover they even ask him to remove it. One specific issue he’s raised is that the messages are sent to the AS (either the global one or the user’s one) and the messages are drowned with the page updates. Basically we’d need to polish this feature better to make it really useful. I agree with this POV. I also agree that in order to make XWiki simpler and less cluttered, this feature could be disabled. Thus I’m proposing to still bundle it but to disable it, since we already have a Message Stream Admin UI config. WDYT? Thanks -Vincent

7 years, 10 months

[xwiki-devs] Problem of certificate in latest XE build

by Vincent Massol

Hi devs, I’ve rebuilt XE today from sources and I got the following certificate errors in my console: https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3af5cb3ce90c582b… As you can see there are a lot of errors displayed. We need to fix this ASAP. Thanks -Vincent

7 years, 10 months

[xwiki-devs] [Usability] Newbie feedback - Creating pages

by Vincent Massol

Hi devs, Over the weekend I asked my brother in law (who doesn’t anything about XWiki) to test it and give me some feedback. He did this test with me next to him so I could observe and ask him what was going through his head. I’m sending below a summary of the session. We now need to address each point and see what we want to do to improve the situation. The Setup ======== * HSQLDB/Jetty already setup with an Admin user already logged in. * I had made the Admin user a simple user. * I later realized that I had forgotten to remove my local cookie on my computer and he didn’t have the Tour. Thus I don’t know if he’d have read it till the end of not. * I asked him 2 things only: ** Create some new pages ** Modify the home page The Feedback =========== * First thing he wanted to do was to switch the UI to French (he’s French). He looked for his user profile, found it, and couldn’t find a way to change the language. Fail. I had to tell give him the hint that language was a global wiki-level setting and I had to do it for him. Other feedback: The French translation for the language settings is really not user-friendly and needs to be changed, it’s currently “Localisation”, which is too technical. * Then he said he spotted a bug. The home page had a title of “Home” in French instead of “Accueil”. * He looked around in the UI and at some point he clicked on Page Administration on the home page. This opened a UI with a title of "Administration : Main”. He asked: “what is Main?”. Indeed he was on the home page that was entitled “Home” and suddenly he was shown “Main” which 1/ was in English and 2/ didn’t mean anything to him. * Then he went on to create a new page and initially was looking for that in the drawer in the Wiki Administration UI… At some point, I had to tell him to stop and I created a simple user for him (that is not Admin so that he couldn’t do in the wiki administration - I should have started with this probably although we need to fix our issue that first time users are admins). Once this was done he was able to quickly find the “+” to create a new page. * However, he wanted to create a structure with a “Domain” folder and some pages inside that folder. He saw the Tree in the Navigation Panel and saw that it was hierarchical and thus he wanted to do the same and create that “Domain” folder first. So he cancelled the Create Page UI since this was about creating a page and he wanted a folder. He then found the “Children Pages” entry in the “More” menu. Note that in French it’s badly labelled as “Enfant de XXX” which was weird to him (FTR it’s also invalid grammatically, missing an “s” for plural) but he understood it was related to children page he suggested “Sous-pages” as a better translation). So he clicked on it and he saw a form displayed (actually it was the filter of the LT UI). And he started typing “Domain” in the text input but nothing happened and he was puzzled. —> When you look at the children LT for a page not having children, you’ll see that we should improve the UI. It doesn’t even say that’s it’s empty and that there are no children pages… * At this point he was a bit stuck and couldn’t understand how to create a folder. I had to tell him that in XWiki you could created hierarchical pages and that there’s no notion of folders (I didn’t want to explain the concept of Spaces especially since he hide this in the UI). He mentioned that after 20 years of Microsoft practice, everyone understands the concept of folders and files and that it’s hard to understand that we only have hierarchical pages. He suggest that we may want to have 2 “+” buttons next to each other (like “+” and “++” or some other visual with a tooltip of “Créer page” and “Créer sous-page"). One to create sibling pages and another one to create children pages). In his head, the default when you create a page is to create a sibling page, not a sub-page. * After this he was able to create his pages (note that he used immediately the templates we provided for his test and selected the Encyclopedia template). * He noted that the icon for Rename/Move/Delete was weird and he didn’t understand the relationship between the actions and the icon which is the one for settings (the cog). He suggested to use something different like a rubber (which incidentally I see that it’s missing from http://design.xwiki.org/xwiki/bin/view/Proposal/XWiki+Icon+Set and we need to add it). FYI he was no longer Admin at this point so the “Page Administration” entry wasn’t visible. * When he edited his first page, he quickly told me that that the “Save” buttons are way too hidden (they’re usually not even visible when you edit if you don’t scroll down). He was expecting them to see them at the top, close to the page menus. He suggested that we should have a horizontal bar that stays always visible when you scroll down and that contains the save buttons. * At this point he created a hierarchy of pages and then wanted to move some page around to test this feature. However he could find the menu entry to do so. He could easily find the move, copy and delete entries but that’s not what he was looking for. The reason is that the French translation is “Renommer”. On English I see that we’ve now renamed it to "core.menu.rename=Move / Rename”. But the French translation is still “Renommer”. When I suggested to have “Renommer / Déplacer” to him he said that he’d simply call it “Déplacer” since for renaming a page he doesn’t need to go to that screen and he can simply edit the page and change the title. He said it’s fine to leave the ability to change the title on the Move UI but that it was just a nice bonus and not the main goal of this screen in his opinion. * On the Rename UI screen, he started by clicking in the source breadcrumb, and he was surprised that the browser navigated away. Later on he realized that the was a target section. At this point he commented that he expected to see the target first since that’s what he wanted to change. He also suggested that if would be simpler to use if the target breadcrumb was replaced by a Tree to choose the new location. * When he tried to modify the home page he did it very easily and was able to put his own content. When I told him that some user find it difficult to understand that they could modify the home page he said that it’s not the first thing he’d have done. * On the positive side, the navigation panel was really nice for him. He kept using it all the time to navigate. Thus navigation wasn’t an issue for him. That’s it. Hope we can use this to improve basic user experience. The biggest item by far is to make users understand that there’s no folder and that there’s only hierarchical pages. I think I like his idea of the 2 add buttons (create sibling page and create children page), or something similar (I guess the Create UI itself could have a different UI to ask the user clearly if he/she wants to create a sibling or a children page). Thanks -Vincent

7 years, 10 months

[xwiki-devs] [Proposal] Officially deprecate GWT WYSIWYG editor and don't fix issues related to it

by Vincent Massol

Hi devs, I’d like that we agree on an official position re the GWT WYSIWYG editor. We’ve already decided to make CKEditor the default editor and to keep the GWT editor bundled (but off by default) till the end of the 8.x cycle. I’d like now that we agree about 2 points: * We don’t fix issues related to the GWT editor that do not reproduce on the CKEditor editor. * Now remains the question as to whether we close them as won’t fix or not. Ideally the best IMO is to create a new JIRA project for the GWT Editor in the Contributed Extensions category, and move all opened JIRA issues to it. We create a version labelled “Previous versions when the GWT editor was in platform” so that we can use that as affects. Of course another option would be to not touch those issues FTM and wait till we do the move in 9.0+. I prefer moving the issues now if we agree now that we don’t fix issues related to the GWT editor. WDYT? Thanks -Vincent

7 years, 10 months

[xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

by Guillaume Delhumeau

Hi. Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor. However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly! So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments). But this might be not relevant for the class and the object editor. My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs. WDYT? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 10 months

[xwiki-devs] [Proposal] Roadmap for 8.4.x till end of the year

by Vincent Massol

Hi devs, After discussing with XWiki SAS internally here’s a list of items that’s interesting to fix for XWiki SAS (in that order, from top to bottom) from now till end of the year (i.e. 8.4.x). The goal is to try to take as many issues as possible from this list, starting from top to bottom. Process I propose: * For each dev, take an issue that is the closest possible from the top and work on it. Put your name on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ and assign yourself to the jira issue. * Once done, repeat. * The names put below are just indicative and should be considered as ideas of devs who could work on them. Ordered list (top is most important): * Periodic crashes with ClassLoader related locking issue - XWIKI-13792 - Thomas * Admins should be able to decide the order in which apps are displayed in the Applications Panel - XWIKI-13075 - Guillaume * When I'm in full mode I would like to save directly without returning to normal Edit Mode - CKEDITOR-112 - Marius? * Make the WYSIWYG admin UI display configuration for all available WYSIWYG editors - XWIKI-13654 - Marius? * Sort Recommended Extensions by Ratings when no search query is specified - XWIKI-13779 - Thomas * When inserting large images while editing, it should all fit, the user should not need to scroll to the right to see it all. - CKEDITOR-108 - Marius? * Clarify the Hamburger Menu - XE-1582 - Guillaume * Provide an option in the AWM wizard that creates a Template Provider for the app - XWIKI-13761 - Marius? * Solr search UI is still very slow - XWIKI-13192 - Thomas * Provide a way to filter templates in the creation step - XWIKI-13762 - Guillaume * Simplify creation of New link to new page in CKEditor - CKEDITOR-116 - Marius? * Cannot upgrade the CKEditor extension - XE-1570 - Guillaume? * Cannot delete document with many large attachments - XWIKI-8910 - Thomas * For regular users, "Data" level is confusing in the Pages tree for an application created with App Within Minutes - XWIKI-13360 - Guillaume? * Customizing the PDF export CSS could cause a NPE - XWIKI-13457 - Vincent * The parent-child relationship of a page is not updated during a move - XWIKI-13493 - Marius? * Add Check List of actions to perform to create first content in XWiki with links to video tutorials - (Missing JIRA) - Caty? * --Attachments are not copied from a Template Provider - XWIKI-13524 - Edy-- * Extension Manager add extension search should suggest only compatible versions - XWIKI-9920 - Thomas? * Hard to understand which is the default value for Profile's Preferences entries (edit/view mode) - XWIKI-7715 - Guillaume * Adding a new overriding template resulted in the creation of 190 XWikiSkinFileOverrideClass - XWIKI-13179 - Thomas? * Demo Content Inside XE - (Missing JIRA) - Caty? * Admin UI to allow disabling tours on a given wiki or for all wikis - TOUR-50 - Guillaume? * Bad Image Scaling Quality - XWIKI-7623 - Guillaume? * See to which groups a user belongs to - XWIKI-1901 - Guillaume? * Make a tool to evaluate the status of the hierarchy before running the nested spaces migrator - NPMIG-46 - Guillaume * Hide "XWiki" space from Navigation Tree - (Missing JIRA) - ? * Reorder the "Create a Page" menu steps in a more coherent way - XE-1588 - Marius? * Allow resetting changes found by the "Compute change" feature of EM - XWIKI-13747 - Thomas * Admin tools doesn't work anymore on 8.0+. In general test features to see if they work in 8.3+ - ADMINTOOL-45 + ADMINTOOL-46 + ... - Alex * Add highlighted text to invite newcomers to click on the edit button to start modifying content - XE-1583 - Caty? * Change the user type for the Admin user to 'simple' - XE-1580 - Guillaume? * Page creation date should be the date of the installation - XWIKI-7058 - Thomas? * Add an administration control panel for the redirects created on rename - XWIKI-13385 - Guillaume? * Add "Index Page" Template - TEMPLATES-7 - Caty? * Deactivate "section editing" by default and/or hide them in CSS and display them with hover - (Missing JIRA) - Caty? * Change saved into a LESS SSX that is already cache does not always get recompiled - XWIKI-13300 - Thomas? * Have an option to edit directly in full screen mode - XWIKI-13793 - Marius? * Add support for nested spaces in Distribution Wizard report - XWIKI-12270 - Guillaume? * Remove XWiki Enterprise and transform it into a Knowledge Base Flavor - XE-1581 - Thomas * Replace Home Page with actual content and move current Home page to a documentation page accessible from that home page - (Missing JIRA) - Caty? * Move "Last modified by" next to "Create by" - (Missing JIRA) - Caty? * Display sponsored extensions on extensions.xwiki.org - XINFRA-211 - Vincent * Implement a View mode in addition to Standard/Advanced, with cookie based setting - (Missing JIRA) - Caty? * Put the "Add a new page" button is (really) outside of the Menu relating to the current page (because it's about another page) - XE-1587 - Caty? * Allow searching for Forum discussions - XAFORUM-144 - Alex * Rights can be lost after a migration - NPMIG-20 - Guillaume * Missing indexes in 3.2 index auto creation system - XWIKI-7125 - Thomas? * LESS compilation of SSX may sometimes generate invalid CSS with missing colors - XWIKI-13299 - Guillaume? * Allow upgrading a flavor in Distribution Wizard - XWIKI-12148 - Guillaume? * Use the language set for the Main Wiki for newly created subwikis - XWIKI-11431 - Guillaume * Deactivate messaging feature by default - XWIKI-10543 - Alex? * Clarify advanced Users "Edit Menu" + use the term "Duplicate" instead of "Copy" in the wheel menu - XWIKI-13774 - Caty? * Maps not working because of missing API key - MAP-13 - Alex * When leaving the edit mode without saving, notify the user that there are changes he needs to save - XWIKI-6927 - Guillaume? * Allow inviting global groups to a subwiki - XWIKI-7531 - Guillaume? * Make the "redirect" option on page rename configurable - XWIKI-13384 - Marius? * Add an option to disable automatic silent merges when upgrading an extension - XWIKI-12705 - Thomas * Redesign the delete UI to look more like the other refactoring actions - XWIKI-12548 - Guillaume? * In the CKEditor, I would like the toolbar to be displayed in one line (and not 2) - CKEDITOR-110 - Marius? == Dates == * 8.4RC1: 31 October 2016 * 8.4Final: 7 November 2016 * 8.4.1: 21 November 2016 * 8.4.2: 5 December 2016 * 8.4.3: 19 December 2016 * 8.4.4: 9 January 2017 (to account for Christmas + new Year celebrations) WDYT? Note that I’ve put this on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ @Non XWIKI-SAS developers: please add any item you’d like to work on to the list and on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ and put your name next to it! (that’s if you wish to make it visible to all, no pressure ;)). Thanks -Vincent

7 years, 10 months

Re: [xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

by Denis Gervalle

+1 for your proposal until we have a better solution. I would avoid comment tab if ever possible, since it increase the inconveniences already explained. I agree with almost all other comments, but until we have time for something better, this proposal would be a first improvement. We should just ensure it does not cause any regression. -- Denis Gervalle SOFTEC sa - CEO On Fri, Oct 14, 2016 at 12:19 PM, Denis Gervalle <denis.gervalle(a)softec.lu> wrote: +1 for your proposal until we have a better solution. I would avoid comment tab if ever possible, since it increase the inconveniences already explained. I agree with almost all other comments, but until we have time for something better, this proposal would be a first improvement. We should just ensure it does not cause any regression. -- Denis Gervalle SOFTEC sa - CEO On Thu, Oct 13, 2016 at 11:28 AM, Guillaume Delhumeau <guillaume.delhumeau(a)xwiki.com> wrote: 2016-10-13 11:07 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>: > Some notes about the comments: > - @GD: In CkEditor when drag&dropping it doesn't open a file explorer > (that's for the simple upload), instead you just drag the image from > Desktop and it inserts it. > I think I was not clear. I know CKEditor does not a file explorer. But you have to open that kind of application by yourself (in mac it's called "Finder", on my laptop it's called "Nautilus") if the file you plan to drag is not on your desktop (which is the case 99% of the time). That is exactly what I dislike. > - @Vincent: the inline editing approach (with keeping the attachments tab > in the same location) doesn't work for cases when we hide the docextra: we > will have the same problem, and we might plan to remove that area for other > skins. > - @Thomas: yes this approach to have attachments tab in edit is problematic > because of the save and other js events, plus to me is still oldish. > > So I don't want us to include the attachment tab in edit mode (although it > sounded as a nice option). Instead I would like at least to have an > improved drag&drop for CkEditor (improvement) and in the 'future' to > support drag&drop in wiki mode (new feature). > > Thanks, > Caty > Thanks, > > > On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com > > wrote: > > > Something is not clear to me. What is exactly going to happen in edit > > mode when you select an attachment ? > > > > If the plan is to let the attachment tab behave exactly as it does in > > view mode (which is to actually upload the attachment and save the > > document) I'm really not a big fan of this. If we support attachments > > in edit view it should not send anything until we click save. > > > > > > On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <vincent(a)massol.net> > > wrote: > > > > > >> On 12 Oct 2016, at 18:47, Guillaume Delhumeau < > > guillaume.delhumeau(a)xwiki.com> wrote: > > >> > > >> Just some remarks before I go: > > >> * As a developer, I always use the Wiki editor, and even for me it's a > > pain > > >> to go to view mode to upload a file (for example, an image in the > > release > > >> notes). > > >> * I never use drag&drop in whatever application I have. I have never > > liked > > >> it because it requires to open a file explorer specially for that and > > it's > > >> always a pain because I use applications in full size mode. I'm sure > I'm > > >> not the only one so I'm not fond of having it as the only way to > upload > > >> attachments. > > > > > > For the sake of the discussion, also note that there’s another option. > > Don’t leave the view page when editing (ie. inline editing) and just > > replace the view area by an edit area. And find how to display the page > > syntax and include/display references in the UI. > > > > > > The nice part is that it 1) it saves a reload of the UI (good for perf) > > and 2) it feels more snappy and no context switching for the user (better > > usability). > > > > > > If you remember this was a proposal done a very long time ago by > > Jean-Vincent Drean (tried to find the thread again but didn’t succeed). > > > > > > Thanks > > > -Vincent > > > > > >> Thanks, > > >> > > >> 2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) < > valicac(a)gmail.com > > >: > > >> > > >>> There are some problems with docextra, because it contains comments, > > which > > >>> are mostly needed in view mode, not in edit. So in edit mode, we > would > > need > > >>> just some tabs from docextra. But I'm not sure that adding docextra > now > > >>> will fix the underlying problem of the issue. > > >>> > > >>> The issue was trying to fix the attachments uploading limitation of > the > > >>> editor. The problem is that the editors (including CKEditor) are > > >>> advertising that they add images and not other file types. If users > > want to > > >>> add a PDF they might be confused. > > >>> > > >>> Ideally the users would just need to drag&drop a file and we would > > insert a > > >>> displayer depending on the dragged type (viewer for PDFs, gallery for > > >>> multiple images, image macro for single image, etc.) > > >>> Also even if in CKEditor the drag&drop option for images is > permitted, > > >>> nobody knows about it. And currently CKEditor has the limitation to > > allow > > >>> dragging just images and not other types (dragging an image inserts > it, > > >>> dragging a text file does nothing). > > >>> > > >>> Other thing to consider is that for Groupware flavor, where we > promote > > >>> applications, we hide the docextra, since this is not so relevant for > > >>> application entries. Hidding docextra creates > > >>> http://jira.xwiki.org/browse/XWIKI-13799 and > > >>> http://jira.xwiki.org/browse/XWIKI-12993 . > > >>> > > >>> So, a conclusion: I'm not sure adding #docextra in the edit mode is > the > > >>> best solution, especially since we try to make the interface more > > simple > > >>> and we usually hide docextra also from view. > > >>> An idea would be to better mark in the Edit mode that Drag&Drop is > > >>> permitted (at least for the CKEditor - the wiki mode will still have > > the > > >>> same issue). Have a drag&drop behavior also for other file types, not > > just > > >>> images (for text files we could create a link for the attached file, > > etc.). > > >>> Plus have a link to manually go to the attachments viewer as a backup > > (by > > >>> fixing the 2 additional issues mentioned). The problem will still > > remain on > > >>> wiki mode, but let's say those users are more advanced and know how > to > > use > > >>> viewers (although consistency between the edit modes would be ideal). > > >>> > > >>> Thanks, > > >>> Caty > > >>> > > >>> > > >>> On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < > > >>> guillaume.delhumeau(a)xwiki.com> wrote: > > >>> > > >>>> Hi. > > >>>> > > >>>> Currently a user have 2 ways to attach a file to a wiki page: > > >>>> - in the attachment tab in VIEW mode only ; > > >>>> - if it's an image, using a WYSIWYG editor. > > >>>> > > >>>> However, if it's not an image, you cannot add it while you're > writing > > the > > >>>> content. It's a bit as if you were not able to attach a file while > you > > >>> were > > >>>> writing an email... not user friendly! > > >>>> > > >>>> So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 > > >>>> > > >>>> To fix it, I see 2 options: > > >>>> - add the handling of attachments in edit mode. > > >>>> - add *all* docextra tabs like we have in view mode (it's not > because > > you > > >>>> are editing a page that you don't need to see the history of the > page, > > >>> nor > > >>>> the comments). > > >>>> > > >>>> But this might be not relevant for the class and the object editor. > > >>>> > > >>>> My proposal: > > >>>> * Display docextra tabs by default. > > >>>> * In class and object editors, set $docExtras = []. > > >>>> * Set $docExtras = [] in all sheets where we consider it's not > > relevant > > >>> to > > >>>> have the tabs. > > >>>> > > >>>> WDYT? > > >>>> > > >>>> Thanks, > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

7 years, 10 months

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#121: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 58 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#121 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13698 Happy Bug Fixing Day, Alex

7 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2016