xwiki-devs November 2016

xwiki-devs@xwiki.org

16 participants
40 discussions

Re: [xwiki-devs] [xwiki-notifications] XWiki updates, 5 pages have been modified since 2016/11/28

by Vincent Massol

Sorry about these emails sent by error. It’s XWiki SAS infra preparing the clustering of xwiki.org in the near future. Thanks -Vincent > On 30 Nov 2016, at 00:00, admin(a)xwiki.org wrote: > > Contents > • xwiki > • XWiki > • XWikiAdminGroup > • XWikiServerCommons > • XWikiServerDesign > • Profile of Fabio Mancinelli > • Profile of Kevin Hoarau > Hello Developers, > > This message is sent by XWiki. Here are the pages in your watchlist that have been modified since the last notification: > <wiki.gif> xwiki > <space.gif> XWiki > <document.gif>XWikiAdminGroup <arrowup.gif> > XWiki.XWikiAdminGroup > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiGroups > <string.png>member: > XWiki.khoarau > <metadata.gif>author: XWiki.ThomasMortagne ⇨ XWiki.fmancinelli > <document.gif>XWikiServerCommons <arrowup.gif> > XWiki.XWikiServerCommons > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiServerClass > <string.png>homepage: > Main.WebHome > <string.png>server: > commons.xwikiorg-node1.xwikisas.com > <metadata.gif>author: XWiki.superadmin ⇨ XWiki.fmancinelli > <document.gif>XWikiServerDesign <arrowup.gif> > XWiki.XWikiServerDesign > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiServerClass > <boolean.png>secure: > 0 > <object.gif>XWiki.XWikiServerClass > <string.png>homepage: > Main.WebHome > <string.png>server: > design.xwikiorg-node1.xwikisas.com > <metadata.gif>author: XWiki.superadmin ⇨ XWiki.fmancinelli > <document.gif>Profile of Fabio Mancinelli <arrowup.gif> > XWiki.fmancinelli > > Between 2016/11/28 and 2016/11/28, the page has been modified 2 times, by 1 user: Fabio Mancinelli > <object.gif>XWiki.WatchListClass > <dblist.png>documents: > dev:ReleasePlans.ReleasePlan43M1,xwiki:XWiki.fmancinelli,xwiki:ReleaseNotes.ReleaseNotesXWiki43M1,platform:Features.XWikiRESTfulAPI,dev:ReleasePlans.ReleasePlanHelp,enterprise:Main.Download,manager:Main.Download,xwiki:ReleaseNotes.WebHome,xwiki:Blog.XWikidev:ReleasePlans.ReleasePlan43M1 xwiki:XWiki.fmancinelli xwiki:ReleaseNotes.ReleaseNotesXWiki43M1 platform:Features.XWikiRESTfulAPI dev:ReleasePlans.ReleasePlanHelp enterprise:Main.Download manager:Main.Download xwiki:ReleaseNotes.WebHome xwiki:Blog.XWiki Enterprise and Enterprise Manager 43 Milestone 1 Released,platform:DevGuide.API,rendering:Main.JavaDoc,dev:Community.ReleaseManagerRoster,enterprise:Main.Roadmap,extensions:Extension.RealTimeReleased platform:DevGuide.API rendering:Main.JavaDoc dev:Community.ReleaseManagerRoster enterprise:Main.Roadmap extensions:Extension.RealTime Wiki Editor,dev:XWiki.XWikiPreferences,dev:Community.XWikiDebugIdea,xwiki:ReleaseNotes.ReleaseNotesXWiki43M2,extensions:Extension.Task executor,dev:Hackathon2013.WebHome,dev:Community.BuildingInEclipse,design:Design.DirectoryStructureforXWikiApplications,design:Proposal.ExtensibleAPIforaccessingstructureddata,design:Proposal.ExtensibleAPIforaccessingstructuredata,extensions:Extension.RFC ApplicationEditor dev:XWiki.XWikiPreferences dev:Community.XWikiDebugIdea xwiki:ReleaseNotes.ReleaseNotesXWiki43M2 extensions:Extension.Task executor dev:Hackathon2013.WebHome dev:Community.BuildingInEclipse design:Design.DirectoryStructureforXWikiApplications design:Proposal.ExtensibleAPIforaccessingstructureddata design:Proposal.ExtensibleAPIforaccessingstructuredata extensions:Extension.RFC Application xwiki:XWiki.XWikiServerDesign xwiki:XWiki.XWikiAdminGroup > <document.gif>Profile of Kevin Hoarau <arrowup.gif> > XWiki.khoarau > > Between 2016/11/28 and 2016/11/28, the page has been modified 2 times, by 1 user: Kevin Hoarau > <object.gif>XWiki.WatchListClass > <dblist.png>documents: > xwiki:XWiki.khoarau > On 2016/11/28, the page has been created by Kevin Hoarau > {{include document="XWiki.XWikiUserSheet"/}} > <object.gif>XWiki.XWikiRights > <boolean.png>allow: > Allow > <levels.png>levels: > edit > <users.png>users: > XWiki.khoarau > <object.gif>XWiki.XWikiUsers > <boolean.png>active: > Yes > email_WATCHLIST_IMG_PLACEHOLDERemail: > ****************** > <string.png>first_name: > Kevin > <string.png>last_name: > Hoarau > <password.png>password: > ****************** > <metadata.gif>parent: ⇨ xwiki:Main.UserDirectory > <metadata.gif>author: XWiki.XWikiGuest ⇨ XWiki.khoarau > <metadata.gif>defaultLanguage: ⇨ en > <metadata.gif>syntax: XWiki 2.1 ⇨ XWiki 2.0

8 years

[xwiki-devs] [Brainstorming] Restrict parent page based on its type

by Marius Dumitru Florea

Hi devs, I have an XWiki application that creates two types of pages. Let's call them Category and Procedure. The application has two template providers that allow the users to create Categories and Procedures anywhere on the wiki using the Create Page menu. I would like to restrict the creation like this: * You can create a new Category page either as a top level page or as a child of an existing Category page * You can create a new Procedure page only as a child of an existing Category or Procedure page Category -> ... Category -> Procedure -> ... -> Procedure One solution to achieve this is to add a new property to the template provider, e.g. "parentType", that specifies the type of pages (XClass references) that are allowed as parent. We would use a Database List with multiple selection and relational storage. We can use the empty string to represent "no parent" (i.e. top level page). An empty list would mean no parent type restriction. Category template provider: {parentType: ["CategoryClass", ""]} Procedure template provider: {parentType: ["CategoryClass", "ProcedureClass"]} Do you think this is useful? Do you see any problem with this solution? Is it worth implementing? Thanks, Marius

8 years

[xwiki-devs] [Proposal][UX] Change the user type for the Admin user to 'simple'

by Ecaterina Moraru (Valica)

Hi, A simple change that could improve the experience for newcomers would be that the default Admin user to have a simple type. One of the problems new users have is that they have too many options in the Edit menu and this can be confusing. The downside is that it will add an additional step for developers/testers to change the user type back (or at least until we provide a Developer user/profile). Also we would need to make sure the documentation is up to date and fix the tests. WDTY? I've created http://jira.xwiki.org/browse/XE-1580 Thanks, Caty

8 years

[xwiki-devs] [ANN] XWiki 8.2.2 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 8.2.2. This is a bugfix release that fixes important bugs discovered in the 8.2.1 version. 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/Data/XWiki/8.2.2 Thanks for your support -The XWiki dev team

8 years

[xwiki-devs] [VOTE] Drawer reorganisation

by Ecaterina Moraru (Valica)

Hi, If you want to participate in a quick survey about the Drawer reorganization, please answer these questions: https://goo.gl/forms/WLlAjUGMqaZbUR2l1 (you need a Google account for the form) Thanks, Ecaterina Moraru and Guillaume Delhumeau P.S This is a summary/vote mail about the discussions we had on the "Re-organize the Drawer's entries" thread http://xwiki.markmail.org/thread/6qjwzvteeazlbtn4 P.P.S If you don't have a Google account you can give punctual feedback on the following differences: I. Separation: None (A) vs. Local+Global actions (B) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… II. Index Wording: With (A) ["User Index"] vs. Without 'Index' (B) ["Users"] See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… III. Main Wiki Wording: "Global" (A) vs. "Main Wiki" (B) vs. "Home" (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… IV. Log-out Icon: Without (A) vs. With (B) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… V. Log-out Position: In Header (A) vs. After actions (B) vs. Drawer Footer (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… VI. Administration Wording: "Administer wiki" (A) vs. "Administration" (B) vs. "Wiki Settings" (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic…

8 years

[xwiki-devs] [Brainstorming] Install extension on subwikis that have deps that need to be installed on root

by Vincent Massol

Hi devs, I’d like to discuss a use case that we don’t support ATM. Imagine the following scenario: * I have an extension that can be installed in a subwiki * That extension has some transitive dependencies and one of them has a constraint of being installed on root: <xwiki.extension.namespaces>{root}</xwiki.extension.namespaces> * The user has PR Right now EM refuses to install it. I’ve discussed quickly with Thomas and he said the limitation currently exists to prevent subwikis to have impact on other subwikis (because if you install something in the root namespace then it’ll be visible to all subwikis). So the question I want to ask: should we offer this possibility? IMO we should because the user has PR. Now we could also display some warning or make it visible that some extensions will be installed in root in the plan for example. WDYT? Thanks -Vincent

8 years

[xwiki-devs] XWiki on docker and docker hub

by Ludovic Dubost

Hi, I've made a pull request to Fabio's dockerfile to update it to 8.4.1. https://github.com/xwiki-contrib/docker-xwiki/pull/2 In the process I made quite some changes: - Support for XWiki 8.4.1 and Java 8 (needed debian jessie-backports) - Added libreoffice server - Added xinit to manage xwiki instance - Added webapps/ROOT/index.html to redirect to XWiki page from root URL - Persistence handled in a data container - Added quickRun.sh for one click build and run I think it would be good for the xwiki community to have an officiel Dockerfile and to publish it on docker hub for people to find an "official" XWiki available for the latest version. The approach in this Dockerfile might not be perfect but it's an acceptable one I think. I would like to change the distributionId for this instance. Once the xwiki war is deployed, what needs to be changed to change the distributionId ? Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/08c3c9b2cf61b703f121baebe7511ede?d=http%3A%2F%2Fblog.lud…>

8 years

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

by Alexandru Cotiuga

Hello all, This Thursday is BFD#128: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 40 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#128 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13707 Have a nice BugFixing Day, Alex

8 years

[xwiki-devs] [ANN] Release of Limits Application 1.2.1.

by Guillaume Delhumeau

Hello A new version of the Limits Application is available. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application/#Hv… You can install with the Extension Manager. This version fixes an important bug which prevents the user to install the application via the Extension Manager. However, I would remind you that using the Extension Manager to install this particular application is not the recommend way, since any user having the administration right will be able to uninstall it. And thus remove the limitations you wanted to enforce. Have a good day, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years

[xwiki-devs] Evolution of the Blog Application

by Guillaume Delhumeau

Hi. The Blog Application is one of our main applications. It has been fully written in Velocity, so that even users who don't have programing rights can install it on their wiki. However, I am currently working on XWIKI-13861 [1]. It is about marking the blog documents as hidden when they are not "published" so that visitors won't find them by mistake with the search engine. To accomplish it, I've created a listener that change the document visibility when a blog post is saved. To implement this listener, we have 2 options, with both benefits and drawbacks: A: Write the listener with Java and introduce an xwiki-platform-blog-api module. =========================================================== Pros: * It follows our Best Practices. * We use a nice and powerful language: Java. Cons: * It make the Blog Application dependent to a Java Module, so the wiki administrator needs the PR to install it if the JAR is not already installed in the WAR. * Note that this JAR would be bundled in the XE's WAR while the Blog Application is part of the main wiki flavor, so XE users won't see the change right now. B: Write the listener with Groovy directly on a wiki page. ========================================== Pros: * Blog Application remains a full XAR extension that you can install without PR, as it has always been. Cons: * We need to use the groovy macro, which is not consistent with our Best Practices. * We need a bit of plumbing to register the listener (what we really need is to be able to write listeners easily with an XObject). * If the user has not the PR, the listener will not be registered, so the new behavior introduced by XWIKI-13861 won't be applied. It's a kind of nice degradation but we need to explain it to the user, which will be technical and not user-friendly (we already have lacks on this domain). C: Don't write a listener, but make all changes in Velocity ========================================= Pros: * It remains a full XAR extension. * No degradation Cons: * We need to make the business logic of hiding the blog document in a velocity service and in the blog post sheet. * It is less safe than the listener because a user can still change the "hidden" and the "published" values of the XObjects and bypass the synchronization. * We cannot write an automatic migrator that would be executed only on wiki events. Conclusion ======== My preference goes to A, because: * I don't really like the degradation principle for technical reasons that the user might not understand. * It's simple & safe. * If I would have written the Blog App myself, I would have made a Script Service in Java to put the business logic away from Velocity. * We have plenty of extensions having Java modules. A better approach would be to authorize the installation of approved and/or signed modules even when the admin has not the programming right. Since we need a collegial decision, I am asking you your opinion :) Thanks, [1] http://jira.xwiki.org/browse/XWIKI-13861 -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2016