- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Implement a Notification Center

by Guillaume Delhumeau

Hello XWikiers. In the current roadmap, I have the responsibility to create a notification system. The need has been described in the following page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationSystemforApps In a few words, applications need to send some messages that could be displayed either on the top menu (the "notification" menu we already have and where the Watchlist options are located) or by e-mail. Users should see quickly the new messages and have the ability to mark some messages has read. Use-cases: having a notification when a new message has been posted on the Forum application, having a notification when the user has been invited to join a wiki, having a notification when a new meeting is organized, etc... Users will also have the ability select which type of notifications she wants to receive. Displaying messages is not the difficult part. Neither is sending emails. What is complicated is the storage of them. Since a user should still see messages she marked as read, we need to store the status of each notification for each user. It could be done either on the server-side (in a NotificationUser table), either on the client-side (using local storage: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). I actually see 3 ways to implement the storage: A - When a notification is sent, a job creates all the NotificationUser entries needed (1 per user) with the status "unread". =============================================================================== Pros: * It's quick and easy to retrieve the list of notifications when a user requests a page: all we have to look at is the NotificationUser entries. Cons: * The creation of NotificationUsers entries could take time so notifications will not really be in real-time. * With a lot of users, it creates a LOT of NotificationUsers entries. To avoid having a delay between the sending of a notification and the displaying of it, we can have an in-memory storage in addition to the database storage, which store notifications until they are written in the database. Note: of course, old notifications (even unread) are periodically removed from the database to limit disk usage. B - Create the NotificationUser entries lazily ============================================== When a user requests the list of notifications, we actually look at all notifications and see if they concern the current user. Then, we create NotificationUser entries if some of them are missing. Pros: * In a wiki with a lot of inactive users, we actually store less NotificationUser entries. Cons: * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). C - Store the status on the client-side ======================================= When a user requests the list of notifications, again we look at all notifications and see if they concern the current user. Then, it's the browser which store the "read" status on its local storage. Pros: * We do not store the NotificationUser entries (that can take a lot of places) Cons: * If user changes its browser, she loses all her notifications' status (maybe not that problematic) * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). On this page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationCenterforAppsIm… I have explained they way I consider the implementation. There is a notion of NotificationType for example that might interest you. I'm hesitating between option A and C. I think B has no really benefits. The rest of the mechanism can be implemented right away, so I'm starting it. Please answer quickly if you think I am doing something wrong. What do you think? Thanks -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 6 months

2
2
0 0

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements

by Ecaterina Moraru (Valica)

Hi Denis, Thanks for your feedback. On Thu, Feb 23, 2017 at 1:38 PM, Denis GERMAIN <dt.germain(a)gmail.com> wrote: > We are running multiple flavors of Xwiki including 7.4.4 (production), > 8.4.4 and 9.0 > > 1. what sections are always needed and maybe we could prioritize them; > Users and Groups are the most heavily used menu in administration for us > We also rely heavily on Import/Exports > > 2. what sections could be grouped together, since they are related; > > 3. what sections are not relevant and could be removed (maybe because they > are too technical, or not needed or rarely used); > Creating subwikis is sometime used so it shouldn't be dropped (for us) > Templates are not often used but really important to us > > 4. if there are important recurring things missing from administration; > There is no easy way to troubleshoot users rights on a page. In other > words, sometime users set rights on "pages and children" OR "pages", and it > causes all sort of trouble > - some users can't see some pages but they should (due to misconfiugration > of the rights) > - some users can open pages with the direct link but can't navigate to it > a) I don't see why there is 2 types of rights on a page, I would personnaly > keep only "pages and children" rights and drop "page only" rights > This is when you need to make exceptions: you want all the children to behave in a certain way, but the parent or a certain subpage to have different rights. I agree it's a more marginal use case, but still it could happen. > b) To troubleshoot, I'd like to have a way to see why some users can see > the page and some don't, or to help me find where the problem is > I agree the rights inheritance is problematic and yes we should improve it (in terms of setting it and display the applied rules). This functionality gets outside of the scope of this Administration reorganization/simplification, but it's indeed very important (and apparently a common problem). > > 5. other ideas? > I find the Template creation (with provider) procedure counter intuitive. > Maybe it could be simplified ? > We added some new functionality in terms of visibility and creation restrictions for templates, but they were intended more as powerful features, we didn't focus on simplifying the process. Yes, we could do some improvements there too, especially since we have started promoting Templates more. Thank you so much, Caty > 2017-02-23 11:28 GMT+01:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>: > > > Thanks Stéphane for your answer. It's very helpful. > > > > Caty > > > > On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE < > slassire(a)cesap.asso.fr > > > > > wrote: > > > > > Hello, > > > > > > What a nice idea. > > > We are using a Xwiki 7.4.4 release. > > > > > > 1. what sections are always needed and maybe we could prioritize them; > > > -> Users / groups / right access / extensions / statistics > > > > > > 2. what sections could be grouped together, since they are related; > > > -> Configuration / Look / Email > > > > > > 3. what sections are not relevant and could be removed (maybe because > > they > > > are too technical, or not needed or rarely used); > > > -> wikis (we are using only 1 instance, so no need of multi configs for > > us) > > > > > > 4. if there are important recurring things missing from administration; > > > -> rights "inspector", not really to know the right of a page inside a > > > space > > > for all users and groups > > > -> activity of a group / user. I try to put a counter inside pages to > see > > > if > > > it is accessed but it a basic solution. I would like to see how much > some > > > pages are viewed. The statistics are limited on this part > > > > > > 5. other ideas? > > > -> see 4 > > > > > > Thanks > > > > > > Cordialement > > > > > > Stéphane Lassire > > > Chargé de l'informatique et de la communication > > > Courriel : slassire(a)cesap.asso.fr > > > > > > -----Message d'origine----- > > > De : users [mailto:users-bounces@xwiki.org] De la part de Ecaterina > > Moraru > > > (Valica) > > > Envoyé : mardi 21 février 2017 16:15 > > > À : XWiki Mailinglist; XWiki Mailinglist > > > Objet : [xwiki-users] [UX] Administration Improvements > > > > > > Hi, > > > > > > We are thinking about improving the Administration, so would be great > to > > > hear your opinion about: > > > 1. what sections are always needed and maybe we could prioritize them; > 2. > > > what sections could be grouped together, since they are related; 3. > what > > > sections are not relevant and could be removed (maybe because they are > > too > > > technical, or not needed or rarely used); 4. if there are important > > > recurring things missing from administration; 5. other ideas? > > > > > > We are particularly interested in 1. and that is sections that are used > > > often and would love to know which are those (since they differ so much > > > depending on usage). > > > > > > Let us know, > > > Caty > > > > > >

8 years, 6 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements

by Ecaterina Moraru (Valica)

Thanks Stéphane for your answer. It's very helpful. Caty On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE <slassire(a)cesap.asso.fr> wrote: > Hello, > > What a nice idea. > We are using a Xwiki 7.4.4 release. > > 1. what sections are always needed and maybe we could prioritize them; > -> Users / groups / right access / extensions / statistics > > 2. what sections could be grouped together, since they are related; > -> Configuration / Look / Email > > 3. what sections are not relevant and could be removed (maybe because they > are too technical, or not needed or rarely used); > -> wikis (we are using only 1 instance, so no need of multi configs for us) > > 4. if there are important recurring things missing from administration; > -> rights "inspector", not really to know the right of a page inside a > space > for all users and groups > -> activity of a group / user. I try to put a counter inside pages to see > if > it is accessed but it a basic solution. I would like to see how much some > pages are viewed. The statistics are limited on this part > > 5. other ideas? > -> see 4 > > Thanks > > Cordialement > > Stéphane Lassire > Chargé de l'informatique et de la communication > Courriel : slassire(a)cesap.asso.fr > > -----Message d'origine----- > De : users [mailto:users-bounces@xwiki.org] De la part de Ecaterina Moraru > (Valica) > Envoyé : mardi 21 février 2017 16:15 > À : XWiki Mailinglist; XWiki Mailinglist > Objet : [xwiki-users] [UX] Administration Improvements > > Hi, > > We are thinking about improving the Administration, so would be great to > hear your opinion about: > 1. what sections are always needed and maybe we could prioritize them; 2. > what sections could be grouped together, since they are related; 3. what > sections are not relevant and could be removed (maybe because they are too > technical, or not needed or rarely used); 4. if there are important > recurring things missing from administration; 5. other ideas? > > We are particularly interested in 1. and that is sections that are used > often and would love to know which are those (since they differ so much > depending on usage). > > Let us know, > Caty >

8 years, 6 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 9.1 Release Candidate 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 9.1 Release Candidate 1. This version contains mainly CKEditor integration, HTML export and Job REST API improvements. Page delete UI is also a lot safer. 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/9.1RC1 Thanks for your support -The XWiki dev team

8 years, 6 months

1
0
0 0

[xwiki-devs] [UX] Administration Improvements

by Ecaterina Moraru (Valica)

Hi, We are thinking about improving the Administration, so would be great to hear your opinion about: 1. what sections are always needed and maybe we could prioritize them; 2. what sections could be grouped together, since they are related; 3. what sections are not relevant and could be removed (maybe because they are too technical, or not needed or rarely used); 4. if there are important recurring things missing from administration; 5. other ideas? We are particularly interested in 1. and that is sections that are used often and would love to know which are those (since they differ so much depending on usage). Let us know, Caty

8 years, 6 months

1
0
0 0

[xwiki-devs] HK2 DI framework

by Vincent Massol

Hi devs, While researching whether we could use CDI for XWiki (see https://issues.jboss.org/browse/CDI-114), I was pointed to HK2 (https://hk2.java.net/2.5.0-b34/). I’ve quickly started to read about it and it really looks very similar to our Component Manager. See for example the introduction at https://hk2.java.net/2.5.0-b34/introduction.html I still need to read more about it but I thought I’d share this with you. Thanks -Vincent

8 years, 6 months

1
0
0 0

[xwiki-devs] [XWiki Day] Test Day #2

by Thomas Mortagne

Hi devs, The idea today is to do a Test Day with priority to fixing long standing flickering (integration mostly) tests. You can find known flickering tests on http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix them, not just add some random wait here and there ;) If you are really not confident with the area around those specific flickering tests here are some other ideas for this kind of Day: * obviously add more tests and increase the code coverage * move tests from enterprise to platform. Needed for the platform flavor and removal of XE * update jacoco covering setup (we often forget to increase it when adding more tests) * move more tests from JMock to Mockito * work on new test setups and tools: ** improve docker containers for packaging XWiki (possibly several for multiple DBs and Servlet containers). ** work on spreading Jenkins platform job into one job per maven module so that build can be spread on various agents (groovy scripting) ** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit the jenkinsfile in SCM ** Test platform to run contrib extension tests on various versions of XWiki automatically * Speedup existing tests (research xwiki startup time, remove unnecessary modules, etc) When what you fix can be linked to an issue, tag it with "testday" (same idea as "bugfixingday" when doing BFD). If not then answer to this mail to explain what you did. Good Test Day !

8 years, 6 months

1
1
0 0

[xwiki-devs] [Proposal] Use <thead> to improve the HTML produced by the XHTML renderer for tables

by Vincent Massol

Hi devs, For the following XWiki Syntax 2.1 input: |=head11|=head12 |cell11|cell12 We generate the following XHTML 1.0 output: <table> <tbody> <tr> <th>head11</th> <th>head12</th> </tr> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> I think it would be better to generate: <table> <thead> <tr> <th>head11</th> <th>head12</th> </tr> </thead> <tbody> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> Arguments: * More standard. * In addition I read I the XHTML spec that "Table rows may be grouped into a table head, table foot, and one or more table body sections, using the thead, tfoot and tbody elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.” I haven’t checked but hopefully it should relatively painless for our CSS (unless we use a rule for tbody/tr/th instead of tr/th or th). However even if it changes our CSS I still fee it’s the right thing to do with a note in the Release Notes for the unlikely chances that it would break something. Note tat I know that for example for the http://extensions.xwiki.org/xwiki/bin/view/Extension/Datatables+Macro extension, we cannot use xwiki syntax because of this issue (this is why the example is using the html macro). WDYT? Thanks -Vincent PS: our XHTML parser already supports this as can be verified with the following test: {{groovy}} def input = ''' <table> <thead> <tr> <th>head11</th> <th>head12</th> </tr> </thead> <tbody> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> ''' def xdom = services.rendering.parse(input, 'xhtml/1.0') println "{{{" println services.rendering.render(xdom, 'xwiki/2.1') println "}}}" {{/groovy}}

8 years, 6 months

3
2
0 0

[xwiki-devs] [Brainstorming] Interesting config library: cfg4j

by Vincent Massol

This could be an idea to replace our aging commons-configuration at some point: https://github.com/cfg4j/cfg4j It looks a bit more modern. WDYT? Thanks -Vincent

8 years, 6 months

1
0
0 0

[xwiki-devs] [ANN] Official docker image for XWiki on dockerhub

by Vincent Massol

Hi everyone, Just wanted to let you know that the XWiki docker image is now an official image on docker hub! See https://hub.docker.com/r/library/xwiki/ Please try it out and let us know how it goes. That’s probably one of the simplest way to try XWiki now. It comes configured with filesystem attachment by default and libreoffice configured too for office imports/exports/viewing office docs. Thanks -Vincent

8 years, 6 months

1
1
0 0

[xwiki-devs] [VOTE] Get rid of xwiki-enterprise-archetype module

by Thomas Mortagne

Hi devs, Maintaining something like xwiki-enterprise-archetype is a pain and really does not worth it IMO since it's probably not used at all. And as you can see from the history it's never really been maintained after it's introduction 3 years ago and XE changed a lot since that time. We should simply get rid of it IMO. If someone really wants to provide something like this it can be done in Contrib. In the meantime copy/pasting XE and modify the few things you need to modify is not very hard i you want to introduce a new XWiki distribution (and if flavor is not enough for you). WDYT ? -- Thomas Mortagne

8 years, 6 months

3
2
0 0

[xwiki-devs] Edit Modes vs. Editors

by Marius Dumitru Florea

Hi devs, While working on adding extension points to support the replacement of the current WYSIWYG editor I came to the conclusion that we need to make a clear distinction between Edit Modes and Editors. An Edit Mode is basically an HTML *form* that allows you to edit some data that is associated with an XWiki document. There can be for instance an edit mode to edit the document title and content, another edit mode to edit the document objects, another one to edit the document access rights, and so on. Ideally, XWiki extensions should be able to provide new edit modes. The current place where we expose the Edit Modes is the Edit Menu. Class, Objects, Access Rights, Inline Form are well defined edit modes. Before we talk about the Wiki and WYSIWYG "edit modes" let's define what an editor is. An Editor is basically a form *field*. Most of the time it is an enhanced form field, a widget, that allows you to edit a single document field. The editor obviously depends on the field type. There can be a date editor (known as date picker), a plain text editor, a rich text editor, and so on. Ideally, XWiki extensions should be able to provide new editors for specific data types. For instance an extension could replace the date picker. Another one could replace the rich text editor. The relation between Edit Modes and Editors is many to many. An Edit Mode can use multiple editors and an Editor can be used by multiple Edit Modes. For instance the rich text editor can be used in the "Content" edit mode (for document content) but also in the Inline Form edit mode, for TextArea object properties. If we agree with this distinction then I think XWiki should have separate extension points for Edit Modes vs. Editors. What does this mean for the CKEditor integration? Well, CKEditor is an editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor can be used to edit the document content as well as the TextArea object properties that contain wiki syntax. So there should be no "CKEditor" entry in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also, and so on for each Edit Mode that can use the CKEditor. So I think we should go in the following direction: * Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry that will represent the Edit Mode for editing the document title, content and syntax. I'm not yet sure what name should we use for this Edit Mode. Let's call it "Content" for now. * The default edit action (for simple users) will ** open the Inline Form edit mode if the document has a sheet associated ** open the "Content" edit mode otherwise * The "Content" edit mode will use the Editor configured in the User Profile, falling-back on the wiki preferences * The Inline Form edit mode will use for TextArea properties the Editor specified in the property meta data, falling-back on the User Profile setting, then on the wiki preferences * We should have an administration section to configure the default Editor as wiki level (wiki preferences) We don't have to implement all this right away. I'd like to start by making the editor list from the TextArea meta data, User Profile and wiki preferences extensible, so that CKEditor can add its entry there. WDYT? Thanks, Marius

8 years, 6 months

8
14
0 0

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

by Alexandru Cotiuga

Hello devs, Today is BFD#136: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 500 days period is 39 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-R… Here's the BFD#136 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13804 Happy BugFixing Day, Alex

8 years, 7 months

1
1
0 0

[xwiki-devs] Help Center

by Marius Dumitru Florea

Hi all, For the 9.1 roadmap, see http://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki9.0-9-2, Caty and I have worked on a Help Center to cover the "Demo Content" and (partially) the "In-Product Tours and Documentation" topics. I opened this issue http://jira.xwiki.org/browse/XWIKI-14018 to follow the progress. I committed a first working version on https://github.com/xwiki/xwiki-platform/tree/feature-help-center . I committed the code in platform mainly because we already have a xwiki-platform-help-ui module which is related, but we can discuss putting the help center in a different place: * either a separate child module of xwiki-platform-help (to separate the help center from the rest of the help pages like the XWiki syntax help and the tips panel) * on xwiki-contrib Caty named it "Help Center" in the initial proposal, then used "Help" in the prototype. We need to decide which one is best. I'm fine with both. The version I committed uses "Help Center". The help center pages have quite a few images and 4 big gifs (animated steps) which leads to a 22Mb XAR. I hope the size won't cause any issue. It may slow down the XWiki Enterprise functional tests setup? Caty and I would like to put the help center pages on playground.xwiki.org so that we can measure if it's useful (without having to wait for the playground wiki to be upgraded to XWiki 9.1). WDYT? Thanks, Marius

8 years, 7 months

4
6
0 0

[xwiki-devs] Default location for new pages in customized main space?

by Lilianne E. Blaze

Hello, Is there a way to customize default location for new pages? (Added later - I figured it out, I'm leaving the previous steps of how and why) I set up a new XWiki (9.0) from scratch, created "Public" space, configured it so non-admins don't see anything else, switched it to default both in web.xml "homePage" param and Admin -> Descriptor -> Homepage "Public.WebHome", everything works as intended, but when I'm at host/bin/view/Public/ and I click "Plus icon (Create)" it offers to create a new page at top level "home /", while I want it to select "home / Public /" by default, which I assume would be a reasonable behavior. Is it possible? >From what I checked it's handled in file skins/flamingo/menus_content.vm ? "#macro(displayCreateButton) <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create')" role="button" title="$services.localization.render('core.menu.create')"><span class="glyphicon glyphicon-plus"></span></a> </div> #end" Any suggestions on how to change it? I tried replacing the lines: <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create')" role="button" title="$services.localization.render('core.menu.create')"> <span class="glyphicon glyphicon-plus"></span></a> </div> With: #set( $parentEqualsDocFullName = "parent=$escapetool.url($doc.getFullName())" ) <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create', $parentEqualsDocFullName)" role="button" title="$services.localization.render('core.menu.create')"> <span class="glyphicon glyphicon-plus"></span></a> </div> Turns out it just ends up being ignored. (Added later) Also, as I understand now it would be redundant. After some googling I found createinline.vm, lines 239-243 #if ($parentReference.equals($homeReference.lastSpaceReference)) ## We want to discourage ending up with all the pages children of the homepage so we ## default to top level documents, unless the user explicitly says otherwise. #set ($parentReference = $parentReference.wikiReference) #end Actually that's exactly what I want. I'm trying to comment out the 4th line. Restarted, it worked. It all seems a bit counterintuitive, could you please consider making it configurable, in "xwiki.properties" maybe? Why exactly is it "discouraged"? Is it only a matter of "style" or are there any potential complications I'm unaware of? Greetings, Lilianne

8 years, 7 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 7.4.6 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 7.4.6. This is a bugfix release that fixes important bugs discovered in the 7.4.5 version. This release is the last release for the 7.x cycle, since the 7.4 branch reached end of life on January 2017. You can download it using these links: JAR: http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-generic-7.4.… EXE: http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-windows-7.4.… ZIP: http://download.forge.ow2.org/xwiki/xwiki-enterprise-jetty-hsqldb-7.4.6.zip WAR: http://download.forge.ow2.org/xwiki/xwiki-enterprise-web-7.4.6.war XAR: http://download.forge.ow2.org/xwiki/xwiki-enterprise-ui-mainwiki-all-7.4.6.… Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/7.4.6/ Thanks for your support -The XWiki dev team

8 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] [ANN] First version of the XWiki docker packaging

by Vincent Massol

Thanks Denis for the feedback. Done, it’s now deleted :) The official image is now the first one… Come on xwiki users, let’s get this pull number increased now! (7 pulls already) https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=… Thanks -Vincent > On 9 Feb 2017, at 13:48, Denis GERMAIN <dt.germain(a)gmail.com> wrote: > > Agreed, > > The longer you leave it, the longer people might use it instead of the > official. As of today, the official isn't even the first to appear in the > list when you search for xwiki in dockerhub (but I suspect this will soon > change as people start pulling it). > > And people who already have pulled it won't be affected aside from the fact > that they won't get updates, so no impact for them. > > Regards, > Denis > > 2017-02-09 11:40 GMT+01:00 Vincent Massol <vincent(a)massol.net>: > >> Ok so now that we have an official xwiki image on dockerhub at >> https://hub.docker.com/_/xwiki/ we need to decide what we do with >> https://hub.docker.com/r/xwiki/xwiki-mysql-tomcat/ >> >> I think we should remove it to avoid confusion. >> >> Anyone having any issue with me removing it now? WDYT? >> >> Thanks >> -Vincent >> >>> On 16 Jan 2017, at 18:37, Vincent Massol <vincent(a)massol.net> wrote: >>> >>> Hi everyone, >>> >>> I’ve started a first version of a XWiki docker packaging at >> https://github.com/xwiki-contrib/docker-xwiki and I’ve created an >> automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal >> is to provide an official packaging done by the XWiki dev team. >>> >>> Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes >> and not following some best practices, even though I’ve tried my best to do >> that ;) >>> >>> So it would be great if: >>> * Some users could try it out and let me know how it works >>> * Users could tell me what they’d expect in term of setup from a docker >> distribution. >>> * Some Docker experts review my code and let me know what I should >> improve! >>> >>> After I receive some confirmation that it works well-enough, my goal is >> to document it as an official way of installing xwiki on xwiki.org. >>> >>> Feel free to create jiras for ideas and bugs at >> http://jira.xwiki.org/browse/XDOCKER. >>> >>> Thanks a lot! >>> -Vincent >>> >>> PS: Note that I’m sure some will want a different DB, such as postgreSQL >> for example. That should be easy to do. Pull request accepted! :) >>> >> >>

8 years, 7 months

1
0
0 0

[xwiki-devs] So what do we do about https://jira.xwiki.org/browse/XWIKI-14016

by Thomas Mortagne

Hi devs, We have a unintended regression in the standard import: if what you import is identical to what is already in the database (including the author) it won't add a new version (if you use the default option "Add a new version to the existing page"). What happen in practice is that if you keep calling XWikiDocument#set* methods with the same data it won't update the metadata or content dirty flags. This flags are what hibernate store look at to know if it should add a new version or not. You can reproduce the same behavior with a simple script which load a document, always set the same content and save. You will notice that the history of that document does not change. So the question is do we force metadata dirty to true all the time in the instance output filter or do we keep this feature (in which case we should optimize it a bit to not do the useless XWiki#saveDocument but that's another subject). WDYT ? It could be seen as a nice feature but in practice my first reaction was WTF and you often want to be sure the import actually did something so I'm +1 to force metadata dirty. But I'm +0 to keep the current behavior if there is a majority for it. -- Thomas Mortagne

8 years, 7 months

6
16
0 0

[xwiki-devs] [Proposal] Extend the ack section of the Release Notes

by Vincent Massol

Hi devs, Right now we’ve started acknowledging the committers in the Release notes. I’d like to propose to extend that try to ack everyone who participates in one way or another to a release, and not just developers. I can think of 3 more items to add: A) All the JIRA issue reporters that have had an issue fixed for the release (bug, improvement, new feature, etc). They took the time to report an issue and thus they’ve helped the committers to improve the quality of the release and thus they should be acknowledged. This allows us to also ack QA. We could decide to exclude the reporters who’ve also been committers or leave them in. B) The people who’ve contributed translations done after the start of the release development. Ideally we would also ack: C) The people who’ve helped on the list for the release D) The people who’ve helped on the Design and made proposals that made it to the release. I’m thinking of Caty for example. Luckily Caty also commits some code and often she’s recognised through commits. The problem with C) and D) is that they’re hard to gather. But we could do it on an ad-hoc basis by adding them to the RN during the development (when they help) instead of doing it at the end. In any case I’d like to focus on A) and B) FTM and I’m proposing to add them to the Release Plan since they’re easy to find out. WDYT? Thanks -Vincent

8 years, 7 months

7
13
0 0

[xwiki-devs] [ANN] First version of the XWiki docker packaging

by Vincent Massol

Hi everyone, I’ve started a first version of a XWiki docker packaging at https://github.com/xwiki-contrib/docker-xwiki and I’ve created an automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal is to provide an official packaging done by the XWiki dev team. Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes and not following some best practices, even though I’ve tried my best to do that ;) So it would be great if: * Some users could try it out and let me know how it works * Users could tell me what they’d expect in term of setup from a docker distribution. * Some Docker experts review my code and let me know what I should improve! After I receive some confirmation that it works well-enough, my goal is to document it as an official way of installing xwiki on xwiki.org. Feel free to create jiras for ideas and bugs at http://jira.xwiki.org/browse/XDOCKER. Thanks a lot! -Vincent PS: Note that I’m sure some will want a different DB, such as postgreSQL for example. That should be easy to do. Pull request accepted! :)

8 years, 7 months

1
2
0 0

[xwiki-devs] New contrib repository and Jira project for the Tooltip Macro extention

by Raluca Stavro

Hello, Can someone please create the repository and the Jira project for the Tooltip Macro <http://extensions.xwiki.org/xwiki/bin/view/Extension/Tooltip+Macro> extention ? At this point, it can't be installed with EM and we need to do some adjustments to this macro. Repository name : macro-tooltip Jira project name : MTOOLTIP Thank you, Raluca.

8 years, 7 months

2
2
0 0

[xwiki-devs] [Proposal] Create a xwiki-jenkins repo in the xwiki GitHub org

by Vincent Massol

Hi devs, I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is already set up for xwiki contrib: http://ci.xwiki.org/job/XWiki%20Contrib/ What it means: * Whenever a contrib project commits a Jenkinsfile (see example: https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) then automatically this project gets built by jenkins * It works for all branches and is removed when branches are removed Now, I’m working on creating some shared pipeline libraries (see https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can avoid duplications in Jenkinsfile. So I need an SCM location for it and it seems that it cannot be in a directory of an existing repo and it needs to be in the root of a repo. Thus I’m proposing https://github.com/xwiki/xwiki-jenkins WDYT? Note: we could also use xwiki-contrib but it would be a bit weird to use that for building xwiki org repos and my plan is to move to Jenkinsfile also for repos in the xwiki GitHub org (commons, rendering, etc). Thanks -Vincent

8 years, 7 months

3
6
0 0

[xwiki-devs] [GSOC] Org registration deadline and admin needed

by Ecaterina Moraru (Valica)

Hi, Reminder: According to the timeline https://developers.google.com/ open-source/gsoc/timeline February 9 16:00 UTC is the Mentoring organization application deadline. Because of the differences in stipends for students around the world that were introduced thi year, see https://developers.google. com/open-source/gsoc/help/student-stipends I will not be this year a mentor or an org administrator. I find the segregation offensive and contrary to the principles I was promoting as part of the GSOC program. I ask someone else to continue with the registration process, in case we want to attend. You can find all the documents needed at http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ OrganizationAdministratorGuide We also need proposals so mentors should revive proposals from previous years or propose new ideas for this year. Thanks, Ecaterina Moraru Eduard Moraru

8 years, 7 months

3
3
0 0

[xwiki-devs] [Proposal] Roadmap for XE 9.0-9.2

by Vincent Massol

Hi devs, Here’s a proposal of topics to cover for XE 9.0-9.2 (i.e. Jan-Mar 2017). This proposal is proposed by XWiki SAS and was discussed with XWiki committers who work for XWiki SAS. If you also want to propose some other items, please do so. Ofc if you have some problems or questions with the proposed roadmap let me know in reply. * Distribution Manager Command Line Upgrade (aka Unattended Upgrades) - Thomas * Polish CKEditor - Marius * Auto-ajust column size on PDF export, to get different column lengths - Guillaume * Extension manager improvements to allow cleaner upgrades (XWIKI-12705 and XWIKI-13747) - Thomas * More Ease of Use - Marius * Default product pages should not be easily deleted - Guillaume * Move from XE to KB Flavor (up to the distribution) - Thomas * In-Product Tours and Documentation - Marius * Notification System - Guillaume @Devs: if you’re assigned to some tasks above please make sure you create JIRAs for XWiki 9.0-9.2 ASAP and assign yourself. Thanks -Vincent

8 years, 7 months

1
2
0 0

[xwiki-devs] [ANN] CKEditor Integration v1.12 Released

by Marius Dumitru Florea

Hi all, I released 2 new versions of the CKEditor Integration this week, 1.11 and now 1.12. Both bring lost of bug fixes. I recommend upgrading to version 1.12 ASAP. See http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#H… . Thanks, Marius

8 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs