xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 10.7. One of the main focus of XWiki 10.7 was bug fixing thus this release starts by reducing the bug count by 33, in important areas such as as Notifications, Skin or the core. This version also contains autocomplete of links when using the WYSIWYG editor, Macro content prefill when inserting a Macro from the WYSIWYG editor, and the beginning of replacing the old XWiki Confirmation boxes with Bootstrap modals with a focus on the comments action box to start with. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.7/ Thanks for your support -The XWiki dev team

6 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] [xwiki-contrib/application-xcopy] 5e9148: initial revision

by Vincent Massol

Hi Stephane, Please note that all commits must have a reference to a jira issue, see https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HJIRABe… :) Thanks! -Vincent > On 27 Aug 2018, at 17:23, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/master > Home: https://github.com/xwiki-contrib/application-xcopy > Commit: 5e91487ea3f1bf76ca25fe5fdfcd58ddfd4084d9 > https://github.com/xwiki-contrib/application-xcopy/commit/5e91487ea3f1bf76c… > Author: Stéphane Laurière <slauriere(a)gmail.com> > Date: 2018-08-27 (Mon, 27 Aug 2018) > > Changed paths: > A .gitignore > A application-xcopy-api/pom.xml > A application-xcopy-api/src/main/java/org/xwiki/contrib/xcopy/AbstractXCopyJob.java > A application-xcopy-api/src/main/java/org/xwiki/contrib/xcopy/XCopyConfiguration.java > A application-xcopy-api/src/main/java/org/xwiki/contrib/xcopy/internal/XCopyJob.java > A application-xcopy-api/src/main/resources/META-INF/MANIFEST.MF > A application-xcopy-api/src/main/resources/META-INF/components.txt > A pom.xml > > Log Message: > ----------- > initial revision > > > > **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ > > Functionality will be removed from GitHub.com on January 31st, 2019.

6 years, 3 months

[xwiki-devs] [Contrib] New application for copying pages from one wiki to another (name suggestions welcome)

by Anca Luca

Hello XWiki devs, slauriere and I have worked on an extension that copies pages from one wiki (based on a HQL query selecting them) to another wiki, allowing to exclude some class properties from objects in those pages, if the objects are present. It's coded as an async job, it can be manually triggered or scheduled with a scheduler job. We used it to implement some publication scenario, where contributors work on a set of documents on a subwiki and then these documents, if validated, get copied (published) to another subwiki periodically. The validation is based on the custom structure of those documents, using the generic feature of this extension that allows to select documents to be published based on a query. Otherwise there's nothing else related to publication in the code of the application itself. We'd like to publish this application on contrib, so can we please have a repo for it? However, we have some trouble choosing its name. The name that we used so far is "publication application" but we think it might be misleading esp. because of the similarity with publication workflow with which it has nothing to do. So, if you have an idea for a name that would correctly illustrate this work (and its future enhancements), please help us choose its name and create the repo. Thanks, Anca

6 years, 3 months

[xwiki-devs] Improving tests with Descartes

by Vincent Massol

Hi devs, It would be great if you could help improve our unit tests using Descartes. This is needed for the STAMP research project (https://www.stamp-project.eu/view/main/) and will benefit XWiki by having 2 effects: * increasing the test coverage * improving the tests themselves (increasing their mutation score) Since 10.7 is 50% testing and 50% BFD, it would be great if you could spend all or a substantial part of your testing time working on this. I propose the following strategy: * You find a module you want to work on. * In that module you run: mvn clean install -Pquality -Dxwiki.pitest.skip=false * Then you check target/pit-reports/<date>/issues/index.html and verify if there are "pseudo tested" methods listed (when we have finished fixing all of those we can move to “partially tested methods”). * If there are some, then please record the current jacoco threshold and the current mutation score. * You can get the jacoco threshold by running "mvn clean install -Pquality -Dxwiki.pitest.skip=false -Dxwiki.pitest.mutationThreshold=100” (or by checking target/pit-reports/<date>/index.html, I haven’t checked yet if they are the same). * You can get the current mutation score by checking target/pit-reports/<date>/index.html * Then fix the test so that Descartes doesn’t report any pseudo tested or partially tested methods * Update the jacoco threshold and the mutation scores in the pom.xml * Send a PR on https://github.com/STAMP-project/descartes-usecases-output/tree/master/xwiki using the format already defined there. WDYT? Doable? Thanks -Vincent

6 years, 3 months

[xwiki-devs] [UX][Polishing] Modals Overview

by Ecaterina Moraru (Valica)

Hi devs, I've made an overview of our usage of modals and popovers. You can find it at: https://design.xwiki.org/xwiki/bin/view/Proposal/Polishing10x/PolishingModa… Ideally we should use as few methods as possible of displaying modals/popovers/tooltips, in order to assure a consistent user experience. Also there are some components that could be deprecated / refreshed. I did my best to visually find all the locations, but I'm missing some alerts for extreme compatibility cases. Let me know if something is missing and your thoughts. Thanks, Caty

6 years, 3 months

[xwiki-devs] [Brainstorming] Servlet Container support strategy

by Vincent Massol

Hi devs, Right now we have: * Supported browsers: https://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy * Supported DBs: https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy But we don’t have a list of supported Servlet Containers. I think the reason is that we considered that XWiki would work on all of them. While this is true, in practice it means testing and finding the right configuration for XWiki to work on the various contrainers. Thus it requires time and testing, thus support. For example right now lots of users have trouble making XWiki work on Wildfly or Glassfish. In the past I had worked on those and documented how to make XWiki work on them but new version have come up and XWiki has changed too and seems work is needed to document. I also added some jboss-reated config files in our distribution to make it easy and work OOB for JBoss. We might need to do that for other containers or udpate those files. So IMO we should list a subset of Servlet Containers that we official support (ie. that we actively tests and update documentation, fix code when needed). Same as for DBs and browsers, the community is welcome to provide support for more ofc. For me the supported list should be for now: * Jetty * Tomcat I’m hesitating with Wildfly and Glassfish since they’re quite popular too. It would be nice to have them but I don’t think we have the manpower ATM so I would leave them to the community for now, as a best effort. WDYT? Thanks -Vincent

6 years, 4 months

[xwiki-devs] [ANN] XWiki 10.7-rc-1 released

by Alex Cotiugă

The XWiki development team is proud to announce the availability of XWiki 10.7-rc-1. Since the plan for the XWiki 10.7 is to be a bugfixing one, this release starts by reducing the bugs number with 30, in important areas as Notifications, Skin or Old Core. This version also represents the beginning of replacing the old XWiki Confirmation boxes with Bootstrap modals having the comments' actions to benefit at first. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.7RC1/ Thanks for your support -The XWiki dev team

6 years, 4 months

[xwiki-devs] Users and Groups properties are stored as LargeStringProperty. Why?

by Marius Dumitru Florea

Hi devs, As you probably know, UsersClass and GroupsClass overwrite the newProperty implementation from ListClass and hard code the usage of LargeStringProperty. The implementation from ListClass takes into account the relational storage and multiple selection meta properties while UsersClass and GroupsClass are completely ignoring them. Do you have any idea why? It's been like this for more than 11 years.. The hard coded LargeStringProperty was introduced in https://github.com/xwiki/xwiki-platform/commit/e4800bd2ebf97d2e12282ab56ff5… even though at that point ListClass#newProperty was already taking into account relational storage. As for the hard coded StringProperty that was before it, it is since the start of the XWiki history I can access on GitHub, same as the ListClass#newProperty implementation that take into account relational storage. So I have no idea why we had to overwrite ListClass#newProperty in UsersClass and GroupsClass. The big problem is that in the current state the Users and Groups properties cannot be filtered in Oracle because they are stored as CLOB. See http://jira.xwiki.org/browse/XWIKI-14634 and https://jira.xwiki.org/browse/XWIKI-15500 . Fixing this by removing UsersClass#newProperty and GroupsClass#newProperty requires a migrator and breaks existing queries that join the LargeStringProperty table to get the users and groups values. Is it acceptable to break those queries? I'm afraid there are quite a lot of them, especially since we have examples of such queries on https://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module . WDYT? Thanks, Marius

6 years, 4 months

[xwiki-devs] Security cache doing a large clear every 4 hours

by ktc

Hi, we are running into an issue with our Wiki security cache where we notice a large dump of the cache every 4 hours. The reason this happens every 4 hours is because we have configured out infinispan expiry time to 4 hours; however, we would expect a gradual expiration of the cache. After investigating the DefaultSecurityCache logic, we discovered that the dispose() method is being called whenever infinispan attempts to expire a security cache entry. When disposing an entry, it will rightfully disconnect the entry from its parent(s) and remove all children. What happens is that the XWiki root page ("xwiki:XWiki") is one of the first entries to be created. As such, it is one of the first entries to be expired. When it is expired, it removes all children from the cache as well. This results in all user pages ("xwiki:XWiki.user1", "xwiki:XWiki.user2", ...) as well as our permission groups (stored under "xwiki:XWiki.POSIX.group1", "xwiki:XWiki.LDAP.group2", ...). This also removes all children linking to documents ("xwiki:user1@@Document"). In order to fix this, we were planning on adding logic around the DefaultSecurityCache.dispose() method to skip disposal of certain core pages ("xwiki:XWiki.POSIX", and "xwiki:XWiki.LDAP") as there is no real benefit of removing them from the security cache, but need to further investigate possible risks or side effects. Some questions we had for the XWiki dev team were: 1. Where are XWiki groups stored? Are they not under the document "xwiki:XWiki.group1"? 2. If they are stored under a shared parent, shouldn't they run into the same issue as we are experiencing where clearing the "xwiki:XWiki" entry also removes all user entries and groups? -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

6 years, 4 months

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#186: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday <http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays> Our current status is: * -52 bugs over 120 days (4 months), i.e. we need to close 52 bugs to have created bugs # = closed bugs # * -105 bugs over 365 days (1 year) * -151 bugs over 500 days (between 1 and 2 years) * -351 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#186 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14315 Happy Bug Fixing Day, Alex

6 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs