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

[xwiki-devs] [XWiki Day] BFD#137
by Alexandru Cotiuga 03 Mar '17

03 Mar '17

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

1 1

[xwiki-devs] [myxwiki] XWiki Enterprise 9.1.1 Upgrade
by Thomas Mortagne 03 Mar '17

03 Mar '17

Hi everyone, myxwiki.org has been upgraded to XE 9.1.1. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

1 0

[xwiki-devs] [ANN] XWiki 9.1.1 released
by Thomas Mortagne 01 Mar '17

01 Mar '17

The XWiki development team is proud to announce the availability of XWiki 9.1.1. This version fix a bug that makes the Distribution Wizard always automated. 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.1.1 Thanks for your support -The XWiki dev team

3 2

[xwiki-devs] Page Complexity limiter
by ktc 01 Mar '17

01 Mar '17

Devs, In MediaWiki there are preprocessor limits <https://en.wikipedia.org/wiki/Wikipedia:Template_limits> that track how complex a page is so that rendering can gracefully bail out if any of these limits are broken to keep the server stable. MediaWiki will include this information in a comment in the rendered page like:  We have cases where our users will want to include pages as templates into other pages and these can get pretty deeply nested as well as contain some complex content that is expensive and/or takes a long time to render. We want to make sure that a user cannot bring our servers down accidentally or intentionally due to using too many expensive/long running inclusions on their pages. Testing this on our instance of XWiki is showing that XWiki will run until a) the page is finally able to render which could be minutes in some cases or b) the server runs out of memory and falls over. I have been looking but have been unable to find if XWiki has this sort of feature to turn on and configure. I was also unable to find it in the XWiki Jira or in this forum so I wanted to ask the Devs directly. Does this sort of limiting exist on XWiki? And if so, how can I turn it on? Thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/Page-Complexity-limiter-tp7602880.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 4

[xwiki-devs] [ANN] XWiki 9.1 released
by Vincent Massol 28 Feb '17

28 Feb '17

The XWiki development team is proud to announce the availability of XWiki 9.1. This version contains mainly CKEditor integration, HTML export and Job REST API improvements. In addition the Page deletion UI has been made safer to prevent accidental deletion of extension pages. 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.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Implement a Notification Center
by Guillaume Delhumeau 23 Feb '17

23 Feb '17

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

2 2

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements
by Ecaterina Moraru (Valica) 23 Feb '17

23 Feb '17

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

1 0

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements
by Ecaterina Moraru (Valica) 23 Feb '17

23 Feb '17

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 >

1 0

[xwiki-devs] [ANN] XWiki 9.1 Release Candidate 1 released
by Thomas Mortagne 21 Feb '17

21 Feb '17

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

1 0

[xwiki-devs] [UX] Administration Improvements
by Ecaterina Moraru (Valica) 21 Feb '17

21 Feb '17

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

1 0