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

[xwiki-devs] XWiki 5.x cycle in term of issues

by vincent＠massol.net

Hi devs, FYI I’ve updated the 5.x cycle jira dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11607 FTR here’s the 4.x one (that I’ve updated to include latest bug fix releases): http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11192 For 5.x: - 988 issues so far (vs 1269 for 4.x but we still have 5.4.1 to go and possibly some 5.4.2, etc later on. But in the end it’ll be slightly less than for 4.x) - 20 source contributors (vs 15 for the 4.x cycle) It would be great to start an aggregated release notes of the top features of the 5.x cycle as we did in the past. Any volunteer? :) Thanks -Vincent

11 years, 7 months

1
0
0 0

[xwiki-devs] [Reminder] BFD#53

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 53. We're currently at -47 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#53 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11997 Happy BFD! -Vincent PS: I’m sending an email later on to propose some changes for BFDs for the 6.x cycle.

11 years, 7 months

1
1
0 0

[xwiki-devs] [ANN] XWiki 5.2.4 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 5.2.4. Bugfix release. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki524 Thanks -The XWiki dev team

11 years, 7 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 5.4 Released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.4. This is an improvement and stability release for things started during the 5.x cycle and will be the last major version of this cycle. The highlights of this release are Solr, WikiStream, Distribution Wizard and Activity Stream improvements. In numbers its 96 bug fixed, 49 improvements and 6 new features. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki54 Thanks -The XWiki dev team

11 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] Resource module API change

by vincent＠massol.net

Hi devs, I’d like to make 2 changes to the Resource module that are breaking (but this module has @Unstable annotations so it should be ok): * Change 1: Move getAction() to Resource. Right now it’s only in EntityResource but I’d like that each Resource has an action associated to it. I also propose that we use a GET action for the single action that currently exist for non Entity Resources (for example for skin resources). * Change 2: I’d like to type more the Resource action and introduce a ResourceAction class (exactly similar to the Syntax class in the Rendering). The idea is to have a list of well-known resource actions and at the same time be able to create new actions. This is better than constantly comparing and using strings. So for example this means that instead of the following in Resource (currently in EntityResource but see change 1): /** * @see #getAction() */ private String action; we would have: /** * @see #getAction() */ private ResourceAction action; WDYT? Barring any negative comments, I’ll implement this in the coming days. Thanks -Vincent

11 years, 7 months

1
0
0 0

[xwiki-devs] Possible important issues with PR when upgrading a farm-mode subwiki

by vincent＠massol.net

Hi guys, I’ve just realized that on farm wiki like myxwiki.org we have an important issue when we upgrade the WAR. When local admins log on their wiki they get the DW, they follow it and then they find their wiki is broken in several places: - search/search suggest not working - activity stream stays empty - reset password feature doesn’t work - etc The problem is that the local admin users do not have PR on subwikis and since we have several pages requiring them, this breaks their upgrades. This is a pretty serious problem since they have no way of doing a proper upgrade and this doesn’t do good advertising for xwiki... What can we do in the short term (for 5.4.1 for example since I believe this is something really urgent to fix)? Only solution I can think of (which should be pretty quick) would be to look at all pages requiring PR in our default XE XAR package and replace those with specific API calls. WDYT? Thanks -Vincent

11 years, 7 months

3
6
0 0

[xwiki-devs] [VOTE] Remove feature of extracting the title from the content

by vincent＠massol.net

Hi devs, I’d like to propose removing the feature of extracting the title from the content in 6.x. The rationale is: * This is costing more than it should. It needs parsing the document content to get its XDOM and then to traverse it to find Heading blocks. When we display doc titles in lists (in livetables for example or in the activity stream) it costs a lot to do so. * Our implementation is broken since if you use an include macro that generates a heading for ex, it won’t be taken into account since we don’t apply transformations ATM when computing the title since it would be even more expensive. Since 6.x is about performance I believe this would be a good step forward. Now in order to handle backward compatibility. I propose that we: * Add a legacy configuration parameter to keep the behavior (but off by default). This would be in order to let users using this feature convert their wiki * Move the code to a legacy module (I hope it’s possible) Here’s my +1 Thanks -Vincent

11 years, 7 months

9
10
0 0

[xwiki-devs] [VOTE] Stop supporting export to RTF without an open office server

by vincent＠massol.net

Hi, Our RTF export has never been very good and is even crashing depending on the reader you use (see for example http://jira.xwiki.org/browse/XWIKI-5251 ). I propose to drop the RTF support without OO Rationale: * If a user really needs it he can make it work with an OO server connected to xwiki * RTF is not really a mainstream format * I don’t think we want to invest in fixing our RTF export Here’s my +1 Thanks -Vincent

11 years, 7 months

9
9
0 0

[xwiki-devs] [Proposal] Getting ready to release XWiki 5.4 - Stop the commits!

by vincent＠massol.net

Hi devs, Today is the day we’re supposed to release 5.4 final. I’ve checked with a few committers on IRC and it seems they’re good to go. They still have issues but they plan to fix them in 5.4.1. Thus I’m proposing: * to stop committing on the 5.4 branch today * work on fixing failing builds on the CI * release either this afternoon if all is ok or do it tomorrow morning * then once 5.4 final is released resuming committing on the 5.4 branch for the 5.4.1 release WDYT? Thanks -Vincent

11 years, 7 months

2
1
0 0

[xwiki-devs] Experiment using emberJS

by Ludovic Dubost

Since we will be working on investigating Javascript Frameworks the following might be useful to help compare how the frameworks can be integrated. After last year's experimentation with AngularJS available at http://extensions.xwiki.org/xwiki/bin/view/Extension/AngularJSDemo I've done an experimentation with emberjs which is a similar framework. The result is available here: http://extensions.xwiki.org/xwiki/bin/view/Extension/TodoList%20Application… Some feedback on the process: 1/ The templates (handlebars) can be put directly in the wiki pages which is good. In this case I put them in the todolist macro which I created. You can see the code in the WikiMacro TodoListMacro 2/ The JS and CSS could be put in JS and CSS extension 3/ The storage could be integrated by implementing an Adapter. In this case I did some special server code in order to store the content in the content field of my todolist macro. However in most case we will probably want to map the emberjs model to the XWiki Object model. For this we can either improve our REST api to provide an API that emberjs would natively understand (this is from what I saw very possible), but we can also write an adapter that maps the emberjs store api to our REST API. This is also very possible, however we might still need some improvements in the XWiki rest api (some improvements have already been commited as part of the mobile app development). emberjs has a chrome extension to help see the results. I did not have too many bugs because I use the tutorial so I cannot say how easy or not it is to debug issues in emberjs. I remember it was a bit painful with Angular. This is something important to look at. In general it was not too difficult to adapt the emberjs todo demo to XWiki and wire it to an XWiki storage. This type of framework can be very productive if we have already some generic wiring to XWiki storage. Now to be fully productive we also need to improve a it the way we develop in Javascript in XWiki. When you do a complex applications with multiple JS/CSS/Template then you need a better way to navigate between the different content with some nice syntax coloring. So we need to improve the way we can edit this type of files. This will revive the XEclipse/WebIDE and file system view of XWiki code debate. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 7 months

2
1
0 0

[xwiki-devs] [Proposal] Improving extensions.xwiki.org classification

by Ecaterina Moraru (Valica)

Hi, This mails wants to cover two topics: 1. Improving/cleaning/standardizing a bit the current tags added for e.x.o entries; 2. Proposal to use the tag system to mark the extension's compatibility field. ------ 1. Currently we have 545 tags for 660 extensions (with 705 pages in Extension space). Also we have 367 pages with no tag found in the Extension space. The idea is that I will want to clean a bit the useless tags and keep just the relevant ones. Having useful tags will improve the findability of extensions. Also all extensions should have a tag (right now we have extensions without tags). Tags should be written using small-caps. The current tags are a bit more complex because right now e.x.o also contains 'Snippets' and their scope can be much broader. The current extensions 'Types' (JAR, XAR, Plugin) are very technical and not intended for end-user. I've investigated a bit the tags used on e.x.o and you can see some results here: By Count: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Type: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Keep: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… The tags investigation images contain a 'Keep' (Y/N) column. If a tag is marked as 'No keep' we should remove that tag (in some cases I provide an alternative found in 'Type/Category' column). This is the first organization, we could further improve on the categories/tags. Having some 'standard' categories but also having multiple extensions share the same tag/category will let us have something like 'Related extensions' in the future. Also very important is to 'standardise' the 'deprecated'/'obsolete'/'archive' tag to mark old/unmaintained extensions. In the future we could display the deprecated extensions in a separate place, maybe called 'Archive'. ------ 2. Right now the 'Compatibility' field of extensions is a free form textarea. This is bad when you want to filter working extensions for a specific version. Example: http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication Adding something in the 'Compatibility' field means that the extension has been tested with that version and not that it works only with that version. Using tags for the 'Compatibility' functionality will improve filtering (and maybe reporting). Also we could parse tags and display in top Compatibility section just the numeric tag entries (that will correspond to the tested versions). The format would be the same as in JIRA: '5.2.4', '6.0-milestone-1', '5.4-rc-1', '4.5.x', etc. Let me know what you think, Caty

11 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] XWiki Days for the 6.x cycle

by vincent＠massol.net

Hi devs, We’ve done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We’ve first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we’re very close to succeed for the last 1600 days (ie 4.4 years)! :) I’d like to congratulate everyone on this achievement which is really awesome. I don’t know a lot of other projects who’ve had this kind of success so we can be proud of ourselves! Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that there are still 357 opened bugs which were created since the beginning of the project. My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air. Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success. So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ): A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting? The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above. So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others. I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc. WDYT? Any other proposal or better idea? Thanks -Vincent

11 years, 7 months

6
13
0 0

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

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.4 Release Candidate 1. This is an improvement and stability release for things started during the 5.x cycle. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki4RC1 Thanks -The XWiki dev team

11 years, 7 months

1
1
0 0

[xwiki-devs] Bootstrap 3.1.0 is out

by vincent＠massol.net

Good to know for our new skin: http://blog.getbootstrap.com/2014/01/30/bootstrap-3-1-0-released/ Thanks -Vincent

11 years, 7 months

1
0
0 0

[xwiki-devs] Pb in 5.4RC1

by vincent＠massol.net

Hi devs, I’ve just rebuilt enterprise and started XE (hsqldb+jetty) and found a problem: a migrator is executed even though I’m running the latest version! 2014-01-29 22:49:57,799 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - The following data migration(s) will be applied for database [xwiki] currently in version [53010]: 2014-01-29 22:49:57,800 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - R54000WikiTemplateMigration - http://jira.xwiki.org/browse/XWIKI-9934 This is not normal obviously and would need to be fixed ASAP before 5.4 final. Thanks -Vincent

11 years, 7 months

3
3
0 0

[xwiki-devs] detect the syntax in the context?

by Paul Libbrecht

Hello fellow developers, at curriki we are slowly evolving to xwiki 2.1 (finally!) and it is not too easy. Some of our objects are rendering user-interfaces messages that are expressed in xwiki syntax. To do so, they have the context. But these objects are rendered sometimes in syntax 2.1 or syntax 1.0… Is there a way to tell the "current" syntax in the context object? thanks paul

11 years, 7 months

3
3
0 0

Re: [xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps

by vincent＠massol.net

Hi , On 28 Jan 2014 at 16:27:44, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)) wrote: > Vincent > I agree on Flamingo. I will fetch up JIRA issues start documenting it. I will also like to add few tutorial on customising Xwiki. I think it's good to move on with SASS or Less as Caty mentioned in another thread. I have an observation about Velocity. We used velocity as that time it was best available approach. Now front-end matters a lot, If a front guy think that he also have to get acquainted with Velocity also it may discourage him. > > Is there any other approach we should consider? I know it will be a lot of work shouldn't we think replacing Velocity with CSS/Javascript based layout? Note that Velocity is not front end but back end (it’s executed on the server) and thus doesn’t compete with Javascript per see. Also, note that in the mail below there a full domain about: “ * The way users develop applications in XWiki hasn’t changed much over the past 10 years. Since then there’s been an explosion in the area of JS frameworks. We want to make it super easy to develop modern applications using XWiki (read ajaxy applications with new dev models). Marius agreed to lead this investigation along with the help of Guillaume Delhumeau. Since it’s an important aspect of XWiki and a complex one, they’ll need to drive various discussions and brainstorming with everyone and make some proposals so that we all agree to the directions we wish to go towards and so that we can start implementing it in 6.1. “ This could be discussed during this investigation. Now if you wish to elaborate or if you have some specific proposal to make, you could start a new email thread with your proposal and we would discuss it there. Thanks -Vincent > -arvind > > > On Tue, Jan 28, 2014 at 5:42 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > Hi Arvind, > > > > On 28 Jan 2014 at 12:25:15, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)(mailto:arvind.bernaulli@gmail.com)) wrote: > > > > > +1 > > > > > > Are there any other options to CKeditor? > > > > AFAIK this is the strongest one to evaluate. Is there a better one you have in mind? Note that in the past xwiki was using TinyMCE but we weren’t very successful (could have been caused by our wrong usage of it though). > > > > > I would like contribute with documentation of new features. > > > > Great! Here are some JIRA about missing documentation items: http://bit.ly/M96bin > > > > If you’re interested in documenting something else please send us a mail on the users list for example detailing what you wish to do so that others know about it and we could give you some directions/help. > > > > > Should be consider to have new xwiki.org(http://xwiki.org) design along with new UI? > > > > As Caty mentioned, the xwiki.org(http://xwiki.org) design has already been modified not that long ago. My take is that if we agree to develop Flamingo then it would be a good idea to update xwiki.org(http://xwiki.org) with it. > > > > Thanks > > -Vincent > > > > > > > -arvind > > > > > > > > > > > On Tue, Jan 28, 2014 at 4:23 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > > > > > > Of course this is only the work planned by the committers I mentioned. > > > > > > > > For the other committers, feel free to add stuff you’d like to work on in > > > > 6.0 so that we can add it to our global roadmap. > > > > > > > > Note: I’ll put all this on > > > > http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome in a few days if > > > > people agree about it. > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On 28 Jan 2014 at 11:17:29, vincent@massol.net(mailto:vincent@massol.net) (vincent@massol.net(mailto:vincent@massol.net)) wrote: > > > > > > > > Hi devs, > > > > > > > > XWiki 6.0 > > > > ======== > > > > > > > > As usual here’s a proposal resulting from discussions I’ve had with XWiki > > > > committers who work at XWiki SAS for 6.0. > > > > > > > > * Collaborative Applications (Meeting, Calendar, (new) Forum, Tasks, > > > > Doodle, Photo) - Caty to work on usability and design (she’s started > > > > already at http://design.xwiki.org if you wish to follow the work). > > > > Andrea who’s a contributor is helping on the test + implementation part. > > > > There might be another contributor joining too. This work is currently done > > > > inside xwiki-contrib. > > > > > > > > * New skin! Caty for the design and Guillaume Delhumeau for the > > > > implementation part. We’ve been dreaming about this skin for a while. Caty > > > > has whet our appetite with screenshots from Junco ( > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin and > > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin) and from > > > > Flamingo (http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x). > > > > The idea is to establish new strong foundations for new skins (like > > > > standardizing on bootstrap classes for example) + have a new L&F. Caty and > > > > Guillaume will make proposals on the list about this. > > > > > > > > * At last we agreed to work on identifying performances issues (especially > > > > page load times) and work to fix them! Thomas is in charge of leading this > > > > extra important domain. One idea is to establish some automated tests to > > > > measure current performances and get a baseline so that we can then monitor > > > > our progress and start fixing things (and ensure we keep getting better all > > > > the time in the future). Thomas will send some proposals on the list too on > > > > this to let us know how he plans to tackle performance improvements. > > > > > > > > * Of course we need to keep some time to fix any remaining issues we get > > > > on the major feature we developed in 5.x + some improvements. I’m thinking > > > > about our SOLR search, Multiwiki integration, EM/DW, scalable > > > > import/export, etc. Thomas needs to finish the scalable import feature > > > > which is already well under way (see below). > > > > > > > > * Marius agreed to lead an investigation on CKEditor to see if it would > > > > make sense for us to use it as a replacement of our homemade editor. The > > > > general issue is that maintaining a WYSIWYG editor takes time and this is > > > > not really our core business at xwiki. We have 2 choices basically: have > > > > someone constantly working on improving our WYSIWYG editor or integrate an > > > > existing one so that we can benefit from the work of others. In the past > > > > few years we haven’t added that many features to our editor so it’s time > > > > to evaluate the feasibility and cost of using an external editor such as > > > > CKEditor. > > > > > > > > * The way users develop applications in XWiki hasn’t changed much over the > > > > past 10 years. Since then there’s been an explosion in the area of JS > > > > frameworks. We want to make it super easy to develop modern applications > > > > using XWiki (read ajaxy applications with new dev models). Marius agreed to > > > > lead this investigation along with the help of Guillaume Delhumeau. Since > > > > it’s an important aspect of XWiki and a complex one, they’ll need to drive > > > > various discussions and brainstorming with everyone and make some proposals > > > > so that we all agree to the directions we wish to go towards and so that we > > > > can start implementing it in 6.1. > > > > > > > > * Denis is going to continue working on Script signing as way to replace > > > > the existing Programming Rights which has shown its limitations. Denis has > > > > committed a new Crypto API in 5.x which is a strong base for the script > > > > signing implementation. > > > > > > > > In addition, during those discussions some raised a list of JIRA they > > > > consider important and that would be interesting to tackle if we get the > > > > time: > > > > > > > > - Support 2 roles for users for app within minutes: application creator > > > > and data creator - XWIKI-8757 > > > > - xwiki.cfg & xwiki.properties merging > > > > - Add default column and sort choices in AppWithinMinutes livetable > > > > setting - XWIKI-9659 > > > > - Save & view a section should go to the section anchor instead of the top > > > > of the document - XE-1335 > > > > - Add a message for the Livetable's empty state - XWIKI-7821 > > > > - "Space Templates" should also create the space preferences page - > > > > XWIKI-9712 > > > > - The Wiki UIExtensions should check the rights before executing extension > > > > points - XWIKI-9156 > > > > - Add an explanation next to the fields in user profile - XWIKI-6307 > > > > - When creating a new sub-wiki, pages are listed with guest - XWIKI-9888 > > > > - Cannot remove all panels using the Panel Wizard for space preferences - > > > > XWIKI-9891 > > > > > > > > Please comment if anyone sees a concern or if I have forgotten something! > > > > > > > > XWiki 5.4.1 > > > > ========= > > > > > > > > In addition we identified the need for a 5.4.1 release to: > > > > - finish important issues for the 5.x cycle and any leftover from 5.4. Our > > > > idea is to have usable and stable implementation for the bug items we > > > > worked on in 5.x: SOLR search, multiwiki integration, EM/DW and scalable > > > > export (scalable import has been pushed to 6.0 since we considered it too > > > > dangerous to plug by default in the default import UI in 5.x). > > > > - implement support for IE11 (there are only a few issues open). Marius > > > > agreed to work on the IE11 fixes. The reason we wish to implement this > > > > support is because we’re seeing more and more users reporting issues and > > > > asking for this support. ATM we support IE till IE9 only. IE10&11 are > > > > currently not officially supported at > > > > http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy It > > > > would be nice that after 5.4.1 we could edit this doc and mark them > > > > supported! > > > > > > > > Dates > > > > ===== > > > > > > > > I’m proposing the date of 17 of Feb for the final release of 5.4.1, > > > > assuming 5.4 is released on the 3rd of Feb as currently planned (i.e. 2 > > > > weeks after the release of 5.4). > > > > > > > > For 6.0: > > > > - 5.0M1: 10th of March 2014 (ie 3 weeks) > > > > - 5.0M2: 31st of March 2014 (ie 3 weeks) > > > > - 5.0RC1: 14th of April 2014 (ie 2 weeks) > > > > - 5.0Final: 28th of April 2014 (ie 2 weeks) > > > > > > > > TOTAL: 10 weeks, ie 2.5 months. > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > >

11 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] Members of subwiki migration

by Guillaume "Louis-Marie" Delhumeau

Hi developers! In Workspaces, we used to add global users in the XWikiAllGroup page of a subwiki to indicate that they are members of that wiki. Now, we have an option called "user scope", and we can have both global & local users in a subwiki. That means we have global & local users in XWikiAllGroup. Then, it is a problem because it can not work when XWikiAllGroup is a virtual group [1]. Then, I have proposed to create a new group, called XWikiMemberGroup, that hold the members of the subwiki. (Note: XWikiAllGroup will be a member of XWikiMemberGroup, in order to say "a local user is a member"). So, I have written a migration (again!) [2], to create the new group with the current content of XWikiAllGroup. In this migration, I also changes all existing rights that occur on XWikiAllGroup to make them effective for XWikiMemberGroup. I did not want to duplicate these rights by just adding the sames for XWikiMemberGroup. I think it is easier for the user to only take care of the XWikiMemberGroup. But it looks a bit "magical", and some people don't like it. I would like to have your opinion. +1 for adding XWikiMemberGroup and to "migrate" rights (replace all rights given to XWikiAllGroup by rights given to XWikiMemberGroup). Thanks, Louis-Marie [1] http://jira.xwiki.org/browse/XWIKI-9886 - Enabling virtual XWikiAllGroup breaks wiki membership [2] https://github.com/xwiki/xwiki-platform/compare/feature-wiki-members - Git branch for this proposal

11 years, 7 months

7
18
0 0

[xwiki-devs] WYSIWYG editor menus are behind the editor… how to solve?

by Paul Libbrecht

Hello fellow XWikiers, we are having a bug at Curriki where one positioning of the wysiwyg editor has the following bug: the menus pop-up behind the tool-bar and editor-pane. Other instances of the editor do not have this issue. What should I investigate? Is this z-index (apparently always 12) not dynamically updated depending on the current z-index? paul

11 years, 7 months

2
3
0 0

[xwiki-devs] [Reminder] BFD#51

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 51. We're currently at -63 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that we’re a bit lucky since there was a cluster of bugs that slipped of, thus reducing our bug count from around -120 three weeks ago to -63 now without us closing more bugs than there were creations :) Let’s grab this opportunity to win against the evil bugs! Here's the BFD#51 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11995 Happy BFD! -Vincent PS: Next week I’ll send some proposal for this special day for the 6.x cycle and we can brainstorm about it.

11 years, 7 months

1
2
0 0

[xwiki-devs] [Contrib] New repository for the "Mocca Calendar" Application

by Clemens Klein-Robbenhaar

Hi dev's, I would like to create a repository on xwiki-contrib for the "Mocca Calendar" extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/MoccaCalendar The current Git-Repo is at https://github.com/espresto/xwiki-application-moccacalendar (Of course when moving the groupId in the pom.xml will need to be updated, too) I have the following questions: - Looking at the naming conventions I guess instead of "xwiki-application-moccacalendar" the repo should be named "application-moccacalendar", right? - GitHub user "nedgot" (aka Denis Gotthans, who has actually glued the application together) would like to have write access for that repository, too, if possible. I guess have to make him member of xwiki-contrib at large for that to work, right? - As I have heard rumours that is application might have bugs worth reporting ;) could someone please set up a project on jira.xwiki.org for that? I am not sure what the naming conventions are here, maybe "MOCCACAL" might be a good project name, but I will be happy with anything else that I could point bug spotters too. - Denis Gotthans also has an account on the jira, this time "gotthans" for a change. If the project is set up, could someone give him access to edit issues? Best Regards, Clemens

11 years, 7 months

3
3
0 0

[xwiki-devs] [Brainstorming] Document's Hidden flag behaviour with translations?

by vincent＠massol.net

Hi devs, I’m working to fix http://jira.xwiki.org/browse/XWIKI-9910 but before I can fix it we need to decide something since we have 2 possibilities. - Option 1: The hidden flag is set at document translation level which means when the user check the hidden flag it’s only for the current translation - Option 2: The hidden flag is set at the default document level (not set at translated doc level) which means there’s a single hidden flag ATM the problem with XWIKI-9910 is that when the user checks the hidden flag, it’s set at the translation level but when a translation is displayed the value shown is the one from the default document. Option 1 offers more use cases but: - users may be surprised - users need to be careful to edit the default doc if they wish to set the doc as hidden for all translations I’m not sure what option I prefer. Initially I was more for option 2 but I’m now hesitating and leaning more towards option 1. Note that option 2 means one more DB upate when saving a translated doc. WDYT? Thanks -Vincent

11 years, 7 months

7
12
0 0

[xwiki-devs] help for communication ajax with script velocity

by le bihan matthieu

Hello, For a wiki, I 'd use the ajax but I do not see how it works with velocity . Background: In one of my forms I use two metadata "Database List " type. The first is a list of specialties. The second is a list of people. To make a link between the two lists , I defined a person as follows : specialty_name . Example for a person : his specialty : "test" Name: "toto" The value specified in the second list is " test_toto " My need : Whenever the user changes the state of the form of the first list ( specialty ) I would like to use a velocity script that returns me the list of people associated with this specialty. The parameter passed to the velocity script is the name of the specialty. How do I create the velocity script? You just create a new page , is not it ? If not for the script, there must be specific information to indicate that he must retrieve a value and return a list of users. Regards -- View this message in context: http://xwiki.475771.n2.nabble.com/help-for-communication-ajax-with-script-v… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 7 months

1
1
0 0

[xwiki-devs] [ANN] XWiki 5.2.3 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 5.2.3. This is a bugfix release fixing a security issue allowing unregistered users some access under some circumstances. We recommend anyone using XWiki 5.0+ to upgrade to it, especially if your wiki is a public wiki. 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/ReleaseNotesXWiki523 Thanks -The XWiki dev team

11 years, 7 months

1
0
0 0

[xwiki-devs] Delay 5.4RC1

by Thomas Mortagne

Hi devs, 5.4RC1 is due today but as far as I can see in http://jira.xwiki.org/issues/?jql=fixVersion%20in%20%28%225.4-rc-1%22%29%20… we are quite a bit short on that. I know at least that for XWIKI-9720 and XWIKI-9579 I will need at least several days then there is BFD and ci is not all blue (as always when being close to a release...). We could say it's ok we actually have one more week before final release but I would prefer that Release Candidate to actually be a release candidate for once so I propose to delay all that to 1 week later which would give us: * 5.4RC1: 27th of January 2014 * 5.4: 3rd of Feb 2014 WDYT ? Here is my +1. -- Thomas Mortagne

11 years, 7 months

5
4
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