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

by Vincent Massol

Hello devs, Today is BFD#144: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -49 bugs over 120 days (2 months), i.e. we need to close 49 bugs to have created bugs # = closed bugs # * -5 bugs over 365 days (1 year). * -51 bugs over 500 days (between 1 and 2 years) * +13 bugs over 1600 days (4.3 years) * -633 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 It would be great if today we could at least fix 5 bugs to be even on the 365 day period. But more generally we’ve accumulating some lag recently with -49 bugs over 120 days. So we need to start catching up a bit. Here's the BFD#143 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13896 Happy BugFixing Day, -Vincent

8 years, 3 months

2
1
0 0

[xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

by Thomas Mortagne

Hi xwikiers, Eduard hard the idea of dynamically rename the files names of the packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/ page and use the refactoring to move XE features to a new platform flavor as a good opportunity for this change. In more details the proposal is the following: * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard jetty/hsqldb package (the one which let you choose the flavor you want to install) * name "xwiki-9.5.war" the standard war package * name "xwiki-classic-9.5.xip" the offline package containing XWiki Classic flavor WDYT ? Other ideas ? +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to make it more clear it's not a production oriented package. -- Thomas Mortagne

8 years, 3 months

6
8
0 0

[xwiki-devs] [Proposal][Glossary Application][Phase-1]

by Sarthak Gupta

Hi everyone, I would be working on the proposal 'Glossary Application' in the coming days. The details of the proposal can be found on the Design Page <http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication> . Please tell me if something is not clear. Any suggestions are welcomed. :) I wanted to propose a UI for both the pages ('HomePage' and 'glossary page for each item'). - For the Glossary HomePage: - A search bar will be employed on the top of page, which would search a glossary page(from glossary space) if a user enters the matching words for that glossary items. A search bar will be made using HTML/CSS. - The search results (suggestions) will be displayed on the same page below the search bar along with the location of the glossary item.(considering the fact that two glossary items with the same name may exist). I saw that there is a 'Suggest Widget' for this. Hope I can make it work :P . - On clicking those links, the user will be directed to the matching glossary page. Is this UI ok? - Glossary Page of each glossary item: - It will contain two fields. - First field will be a 'String' which will contain the name of the glossary item. - Second field will be a 'text area' named "Glossary". It will contain the glossary of that item that a user will enter itself on the page, he is on. Is this UI ok? After this I will update my design page and tell you about my next steps.....! Thanks :) Sarthak Gupta [sarthakg]

8 years, 3 months

2
11
0 0

[xwiki-devs] [Gsoc][Update] Red Pen Integration UI

by deshengchuan

Dear all, an update with the activities regarding the red pen integration. Red-pen side implementation: As of now I am unable to establish contact with neither the community and redpen, nor with its creator, Mr. Takahito Ito. Their community seems to be quite silent, unlike ours Hence, I will be beginning preliminary design on the UI. As of now I am planning to create the UI something like the FAQ page. Each entry on the page by the user corresponds to a particular Red-Pen Validator setting which for now would be imported into a Redpen server (As of now I will use my localhost terminal to set up the server). I am dealing with the import of the validators from the ui into the server first, before incorporating the ScriptServices that will call the dependent components which will do the proofreading. What do you think? P.S. Sorry for the absence over last week, by some bad coincidences I had 2 48-hour hackathons back to back. -- View this message in context: http://xwiki.475771.n2.nabble.com/Gsoc-Update-Red-Pen-Integration-UI-tp7604… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 3 months

2
6
0 0

[xwiki-devs] Status on jenkins work and experimentations

by Vincent Massol

Hi devs, I wanted to share with you what’s been done and what’s next, related to the CI improvements and especially jenkins pipelines. Done: ===== * A) Share pipeline script is configured on ci.xwiki.org and available at https://github.com/xwiki/xwiki-jenkins-pipeline * B) Contrib projects are using a Jenkinsfile and a Github Organization job is set up on ci.xwiki.org (automatically create and remove jobs based on branches and PRs) * C) The share pipeline script now supports screenshot attachment to the job test report page + avoids false positives emails Ongoing experiment: ================ * D) I started moving the commons/rendering/platform/enterprise jobs to use our pipeline script but this is not possible right now because there’s an important missing feature ATM in pipeline: the ability to have incremental maven builds (ie only rebuild the module touched by the commit and its dependencies). Without this we would rebuild the whole repo which would lead to more load on the agents and slower feedback times. What I’m planning to work on next: =========================== * E) Create a new pipeline script to perform releases of XE (commons + rendering + platform + enterprise). The idea is to move part of our release script into a pipeline that would get executed either at each commit (if we have enough agents) or once per day or more. The idea is that once we’re ready to cut the release we could just promote the pre-built release and win several hours on our release process. This is what’s left to do in order to be able to do this IMO: ** Set the “xwiki.compatibility.previous.version” automatically in the script if not correct (this is step 1 of the release plan) ** Move the translation script into the pipeline script and only apply translations for non bug fix releases. Note that the RM would still need to validate visually that no spam was introduced in translations at release time by reviewing the job logs. ** Create a flickering “database”, either in jira or in xwiki.org (my proposal is to use xwiki.org and have an XObject per flicker), and in the pipeline script verify automatically that any failing test is part of the flicker database or fail the release otherwise. ** Execute the release:prepare and release:perform goals in the pipeline script and release to a staging nexus repo on nexus.xwiki.org. The RM would just need to release from this repo at release time ** Have some nexus scheduled task to remove non-released staging repos, or do this using the nexus REST API inside the pipeline script if need be (or do this manually by the RM initially) * F) Experiment using the docker pipeline feature to run XWiki functional tests inside docker. The goal is to be able to test xwiki in various setups (various DBs, with LibreOffice server, ideally clustering but that’s harder, etc). ** For this I think I’ll need to develop a new docker image that doesn’t include XWiki and map the local directory where the XWiki distribution has been created by the packager plugin into the docker image. If you have any remarks please let me know and if someone is interested in participating let me know too :) Thanks -Vincent

8 years, 3 months

1
0
0 0

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

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 not confident with the area around those specific flickering tests here are some other ideas for today: * 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 a Jira issue (sure you can create a jira issue for adding new tests this time :)), 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, 3 months

2
3
0 0

[xwiki-devs] Tables and their export

by Paula Patachi

Hi, I have a question about tables: how can I create a table in XWiki?I want to create a table in which i can introduce data and I want to export that table (the content of the table) as a PDF document (but if is posible, in that pdf the exported content to be display as a table,to look good).How can I do that? Thank you,Paula P.

8 years, 3 months

2
1
0 0

[xwiki-devs] Using tables and classes

by andreea avram

Hi, I created a xclass with more attributes which represent the columns of a table. I need to write data in that table and also to get data from the table such that i will can compute an average for example (with that values) and after that i want to put/write the result in the same table. The page I have created using the xclass contains the attributes of the xclass, which I can modify, but I need the table. So, my question is: How can I make the table such that I will can write in it and get data from it? Also, how can I export that table as pdf document?Thank you! | | Virus-free. www.avast.com |

8 years, 3 months

2
1
0 0

[xwiki-devs] [GSoC] More extension repositories

by Krzysiek Płachno

GSoC Coding Part Finally starts tomorrow, so the highest time to get down to work. I created modest design page where I put summary of general idea of my project: http://design.xwiki.org/xwiki/bin/view/Proposal/Moreextensionrepositories To start coding I need: 1. A confirmed naming pattern for the extensions that I will develop. My suggestion is "..... Integration" e.g. "Pypi Integration" "Bintray Integration" Imho, the names of possible repositories are popular and verbose enough to impy that the integration is about extension repository. What do you think? 2. Repositories on https://github.com/xwiki-contrib One per each extension (i.e. external) repository: Bintray, Pypi, NPM. Is it enough if I ask for it here or should I create some official request? 3. Some space somewhere in XWiki ecosystem where I would be able to document progress and decisions made - things much more detailed and low-level that are normally presented on design pages or http://extensions.xwiki.org/xwiki/bin/view/Extension/ pages. Best, Krzysztof Płachno

8 years, 3 months

2
5
0 0

[xwiki-devs] [Brainstorming] Notifications sending email

by Guillaume Delhumeau

Help me to decide! TL;DR: * I need to know if performing a query on the database for each user who want to receive an email with all the notifications, is a scalability issue (in a job context). * If it's not an issue, I can implement the "naïve" solution which requires less development. Full message: Status: * notifications are displayed on the top menu when you browse the wiki. * notifications are displayed differently for each individual user according to their preferences (filters on event type, on locations, etc...). * similar notifications are grouped together into "composite notifications". * there is only a few notifications displayed (5 by default). Objective: * send an email periodically (every hour, every day, every week) according to the user preferences with ALL events that happened during the last period of time, but still according to the user preferences. Inspiration: * the watchlist gets ALL events that happened during the last period of time * then, for each user, remove the events which the user is not interested in * Benefit: only one query to get the events from the database for all users Problems: * in the notifications, I have introduced a NotificationFilter role the make possible to inject some SQL in the query to get the events according to the user preferences. I call this "pre-filters". ** it means we generate a unique request for each individual user, so if we send a mail to 1000 users, we will have 1000 requests to the database. I wonder if it's a non-problem or a big scability issue. Because even if the whole job that send emails take ~10 minutes, it does not matter. It's not a realtime thing. For the records, NotificationFilter have "post-filters" too, that perform check on the event itself (for example checking the permissions, etc...). Alternatives: * just like the watchlist, perform a very generic query on the database to get all the events that happened during the last period of time * then for each user, use only the "post-filters" to remove events the user don't care of Problem: * it means the pre-filters that make sense in the notification use-case cannot be used for emails. Developers must be aware of this. * it requires some refactoring of the code that group similar notifications. Question: Should I go with the "naive" solution, ie for each user get all notifications and send a mail, or should I go with the "only 1 query to the database for all users" version? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 3 months

3
10
0 0

[xwiki-devs] [Brainstorming] Make it more visible that XWiki can be deploy easily in the cloud

by Vincent Massol

Hi devs, I was checking the download page of jenkins at https://jenkins.io/download/ and I found that it’s easy to find the install/download that matches the user’s need since all options are listed on that page (deploy on azure, get a docker image, etc). On xwiki.org we have 2 buttons: Try Now + Download. I’m under the impression that the “Try Now” is not very appealing for users who want to install XWiki or get it in the cloud. I have the feeling that having a single Download button listing all options would be a better thing. In addition I also have the feeling that it would better to let the user choose the packaging before choosing the XWiki version since right now users need to choose the version before being offered the different packagings. WDYT? Thanks -Vincent

8 years, 3 months

1
1
0 0

Re: [xwiki-devs] [xwiki-notifications] Xwiki

by Vincent Massol

Hi, Please don’t post on the notifications and devs mailing lists. Those are reserved mailing lists. Please repost on the forum instead, see http://dev.xwiki.org/xwiki/bin/view/Community/Discuss Thanks -Vincent > On 30 May 2017, at 19:34, andreea.avram22 <andreea.avram22(a)yahoo.com> wrote: > > > Hi, > I created a class with more attributes which represent the columns of a table. I need to write data in that table and also to get data from the table such that i will can compute an average for example (with that values) and after that i want to put/write the result in the same table. > The page I have created using the class contains the attributes of the class, which I can modify, but I need the table. > So, my question is: > How can I make the table such that I will can write in it and get data from it? Also, how can I export that table as pdf document? > > Thank you! > > Trimis de pe smartphone-ul meu Samsung Galaxy.

8 years, 3 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 9.4 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.4. This releases is mostly focused on usability improvements. It adds support for batch restore of deleted pages from the recycle bin. The content menu has received some polishing. The live notification system has been improved to group similar notification messages and to show notifications for page comments. The history of an extension page now includes a special revision that corresponds to the extension version so it is easier to "reset to factory defaults". Finally, the Help Center and the Menu application are now part of the default XWiki distribution. As usual, this version also brings bug corrections. 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.4/ Thanks for your support -The XWiki dev team

8 years, 3 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Move the events RSS feed management from ActivityStream to the EventStream extension

by Clément Aubin

Hi everyone ! By working on XWIKI-14289 (https://jira.xwiki.org/browse/XWIKI-14289), I found out that the WatchList extension currently uses deprecated features of the ActivityStream extension such as ActivityStreamPlugin and ActivityStreamPluginApi in order to render events as a proper RSS feed. As using deprecated APIs isn’t the perfect way to extend the platform features, I was thinking about adapting the RSS feed management capabilities currently present in the ActivityStream to the EventStream extension. This would allow us to progressively move the internal event management of the platform to the EventStream. What do you think ? FYI, the question of "What should we do of the ActivityStream extension ?" has already been raised here : http://xwiki.475771.n2.nabble.com/Proposal-Implement-a-Notification-Center-…, but didn’t came to a clear conclusion. It could also be nice to finally decide how we want to share the platform event management system between the EventStream and the ActivityStream. Thanks, -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin(a)xwiki.com More about us at http://www.xwiki.com

8 years, 3 months

1
0
0 0

[xwiki-devs] XWiki Development Question

by Stefan Platon

Hello. I've made a class with some properties and some pages as well, following the steps in the documentation. Now I want to access those pages and their properties (which have values) from another page and I can't figure out how. I tried the code from http://platform.xwiki.org/xwiki/bin/view/DevGuide/APIGuide#HAddobjectstoapa… but it doesn't seem to work (it can't find the object or see the values). I also don't quite grasp the difference between space, page, document and object.

8 years, 3 months

2
1
0 0

[xwiki-devs] Xwiki Development Question

by Stefan Platon

Hello. Could you tell me how can I take some values from an html form and set them to a xwiki class' attributes? Thank you.

8 years, 3 months

3
2
0 0

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

by Alexandru Cotiuga

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

8 years, 3 months

1
1
0 0

[xwiki-devs] [Proposal] GitHub code reviews and protected branches

by Sergiu Dumitriu

Hi devs, A while ago GitHub introduced several features that I think can help boost even more the code quality, reduce the bus factor, and make it more attractive to contribute to the project. = Protected branches = Branches can be configured as protected in several ways: * Require pull request reviews before merging ** no direct commits are allowed, everything must go through a pull request ** a pull request must be reviewed by at least one other trusted committer before it is allowed to be merged * Require status checks to pass before merging ** pull requests must pass automated checks, for example by being successfully built by a CI service * Restrict who can push to this branch ** official branches (master + stable-x.y) could be restricted to approved committers, but we could grant write access to all other interested developers more easily = Reviews for pull requests = Comments on all commits as well on pull requests have been supported since the early days of GitHub, but more recently it is easier to submit (and request) actual reviews for pull requests. Instead of simply commenting, and changing that special field on Jira, an official pull request status is supported, with three states: - review required - changes requested - approved PR authors can either await for reviews from anybody, or request someone in particular for a review. Committers can filter PRs by their status, and they can also show only the PRs that require their review. = Getting more eyeballs on the code = As Linus' Law states, "given enough eyeballs, all bugs are shallow". We've been experimenting with mandatory pull requests for a while in my other XWiki-based project, with great success so far. So here's a proposal for a different development workflow: 1. Set up 2 teams, one with master (senior) committers, fully vetted committers that have proven they understand the XWiki code, as well as the XWiki product, and one with junior committers 2. Protect the master branch. Require pull requests and reviews before any code is merged in it. Restrict push only to the master committers. 3. Everybody works on separate branches 4. Once the code is almost done, make a pull request and require reviews from two junior committers 4a. Or, instead of requesting, let committers volunteer themselves, but it's less likely that someone will volunteer on time 5. The junior committers must then carefully review the code, and either require changes, just comment, or approve the pull request 6. Once the junior committers have approved the pull request, the PR author must request review from a senior committer 7. The senior committer can either approve and merge the pull request, or send it back to step 3. e. We can define allowed exceptions: don't require PRs from senior committers if the fixes are really small and obvious, like fixing typos, or small and important bugfixes that must be merged quickly, but these should really be rare exceptions While it does sound like more work for an already overworked team, this has many benefits: * the code will have better quality * awareness of: ** what's new / changing ** how others are approaching a problem (especially juniors learning from seniors by being exposed to more code) ** the existing code, since the codebase is large and otherwise people have few occasions to look at many of the parts of XWiki * this means a larger bus factor for new code, and slowly increasing it for existing code that's being touched by one and reviewed by many * theoretically, less time spent doing reviews, since all committers should look over every commit anyway, but this way they are explicitly told when they should look, instead of wasting time reviewing work in progress * larger community, since people can more quickly become junior committers instead of having to invest many months of years of forkwork before committership * easier collaboration on code, since it's very hard to work on someone else's fork branches, but easy to work on an origin branch So, what do you think? -- Sergiu Dumitriu http://purl.org/net/sergiu/

8 years, 3 months

5
5
0 0

[xwiki-devs] [Proposal] Removed deprecated "Panels.SpaceDocs", "Panels.Spaces", "Main.Spaces" and "Main.SpaceIndex"

by Vincent Massol

Hi devs, We have this jira issue I created a while ago and I’d like to move forward: https://jira.xwiki.org/browse/XWIKI-13101 I have one question: Should we move the 4 pages into a legacy module in platform and bundle it in XE or just remove them? My POV: We could consider the pages as APIs I guess and use the API strategy of moving deprecated APIs to legacy. WDYT? Thanks -Vincent

8 years, 3 months

4
23
0 0

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

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 9.4 Release Candidate 1. This release adds support for batch restore of deleted pages from the recycle bin. The content menu has received some usability improvements. The live notification system has been improved to group similar notification messages and to show notifications for page comments. The history of an extension page now includes a special revision that corresponds to the extension version. The Help Center and the Menu application are now part of the default XWiki distribution. 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.4RC1/ Thanks for your support -The XWiki dev team

8 years, 3 months

1
0
0 0

[xwiki-devs] Ways to see changes on xwiki instance?

by Sarthak Gupta

Hi, I recently made some changes in the the XWiki platform repo to solve the following bug: https://jira.xwiki.org/browse/XWIKI-12869?jql=Difficulty%20%3D%20Easy%20and… Although the changes seemed obvious, but I was not able to verify those changes on my running XWiki instance. As far as I know, if I make some changes to an application (for eg 'Blog Application') on my computer, and then build it, then a '.xar' file is generated which can be imported to my local XWiki instance and I can verify visually whether those changes took place or not. In my present case I made changes in 'xwiki-platform/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/editclass.vm'. I thought a xar file of xwiki-platform-flamingo-skin will be generated if I build xwiki-platform-flamingo, but it didn't take place. Is there any way in which I can verify these changes on my local XWiki instance? Thanks :) Sarthak Gupta

8 years, 3 months

3
2
0 0

[xwiki-devs] Maven 5

by Vincent Massol

Hi, Just discovered that there are discussions about Maven 5. I found the following information: - https://jaxenter.com/apache-maven-5-jigsaw-criticism-134174.html - https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 Right now it seems to be just a wish and I don’t know if anyone is working actively about it. Thought I’d share this… If you have more info please add to this thread… Thanks -Vincent

8 years, 3 months

1
0
0 0

[xwiki-devs] [Brainstorming] Remaining Help Application decisions

by Vincent Massol

Hi devs, We have 2 topics to decide: * Topic 1: Right now we have 2 help applications. We need to decide if we merge them or not. * Topic 2: Decide if we keep the Help Center app in contrib or if we move it in platform. * Topic 3: Decide if we fold the Sandbox into the Help Center * Topic 4: Decide how we handle data created/modified by users when we upgrade or for newcomers. Re topic 1, my preference goes to having a single help application and fold what’s currently in the platform help app into the Help center. There’s no reason that knowing how to edit a page would be more or less core than knowing the syntax markup or the Tips Panel. Re topic 3, I don’t think that the sandbox app is really that useful as a standalone app and I would be for merging it into the Help application. Re topic 4, there are 2 issues I can think of: - when new users come in, if the pages that are supposed to be modified (sandbox + the 2 bundled AWM apps) have been heavily modified, then newcomers won’t see the default content and could just be seeing defaced content. - if the pages have been modified by the user + by the help app then on XWiki upgrade there’ll be conflicts. One idea for topic4 is to have the Help app spawn new pages (ie pages not bundled by the Help app itself) for users to try them out, by having some “try it out” button. Re topic 2, the issue with keeping the help center app outside of platform is that we need to support documentation for multiple versions of XWiki. For example, we modified the page menu in Xwiki 9.4 and there are over 10 screenshots to update. However users of XWiki 8.4 (for ex) can also install this app and if they get the new documentation, it won’t match what they see in their wiki. The same can be said with the new notification feature for example. The advantage of moving it in platform is that it’s in sync with the platform (ie less work) but we should only document platform features in it. It also means longer release times since it’s linked to the release of platform. Note that the rationale for having it in platform would be that platform help is a core feature. We could (and probably should) offer some places in the Help Center so that Extensions could plug their help. And we could probably refactor a bit the current content of the help center to move help for feature in the extension UI part of those extensions. Considering all aspects I think my preference goes to having it in platform since I don’t think we have the manpower to maintain doc for all versions of XWiki. WDYT? Thanks -Vincent

8 years, 3 months

3
5
0 0

[xwiki-devs] [XWIKI-14119] Propositions about in-page notifications design

by Clément Aubin

Hi everyone, I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119). In this context, I wanted to know your thoughts about what properties should be proposed by this XObject. Currently, here is my proposition : - The application name (applicationName) : the event application name - A unique ID for the event (eventId) - An event «pretty» name / description (eventPrettyName) - An event icon, mainly displayed in the user notification preferences pane (eventIcon) - An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent) - An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification - A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds. - A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context». What do you think ? Thanks, -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin(a)xwiki.com More about us at http://www.xwiki.com

8 years, 3 months

4
16
0 0

[xwiki-devs] [ANN] New XWiki forum: https://discourse.xwiki.org

by Vincent Massol

Hi XWiki users, In order to make it simpler and more modern for users to participate to XWiki discussions, we’ve set up a new forum based on Discourse: https://discourse.xwiki.org Please start using it instead of the XWiki User Mailing list. This mailing list will become read only in a few days so please start moving to the forum ASAP. Note that you can subscribe to receive all forum posts as email notifications if you wish (it’s configurable in your user profile). Also note that for the moment it’s not possible to reply to the mails (we’re still trying to configure this). We hope that you’ll appreciate this move :) Thanks -Vincent PS: For the moment the XWiki Devs mailing list remains. It’s possible that it could be moved to a forum too in the future but nothing is decided and we’re migrating the users list first.

8 years, 3 months

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