*TL;DR*
- Add a button in each page that will allow you to subscribe to all
events that happens to that page.
- When you subscribe to a page with this "in-context" bell, it must not
affect your other preferences regarding notifications.
*Full Post*
Hello developers,
With Clément Aubin, we are implementing new features in the Notifications
Application in order to be able to remove the Watchlist Application.
*Status*
Currently, a user can subscribe to different kinds of events (ex: "update",
"comment", "blog published", etc...). Recently, we have also added the
ability to restrict on which locations we are interested in, for each kind
of events. For example, we are now able to say, "for the *update* event,
show me notifications only about the wiki ABC and for the *blog post*
event, show me notifications only about the space XYZ".
If you have no restriction (a.k.a "filters") on an event type, then you
receive notifications for every event matching the event type in the wiki,
no matter the location of the entity it concerns.
*Objectives*
In the Watchlist Application, we had 3 switches on the top menu that was
displayed on every page, and these switches were "watch this wiki / watch
this space / watch this page". That would be great if we could have the
same for the notifications.
*Proposal*
- Add the ability to subscribe to all events that happen in a given
location, no matter their type (≈ what the watchlist does).
- In each page, add a button to subscribe to the current location:
https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
- Problem: if you previously had no restriction, you suddenly add a new
one that will prevent you to receive any notifications
concerning the other
locations. A bit like the rights module: adding a right to
someone at some
level will dismiss rights for all other people. I guess we all
agree it's a
problem on the User Experience point of view.
- Proposition: the restriction added by the "in-context" button
should be *inactive if there is no other restriction enabled manually
via the notification preferences UI*.
- Rational:
- When you are on the notifications preferences, you can actually
see all restrictions, so you can understand that creating
one will make you
lose all notifications that do not honor the restrictions.
- However, when you are on a page, you don't see all the
restrictions. If you click on the "subscribe" bell
naively, you might not
expect it will impact all other notifications. It would
actually be very
confusing.
- In addition: if we add an "auto-watch" option, that add the
page you just saved to the list of locations you are interested in, we need
to have this feature too. Otherwise saving a document will make all other
notifications silent.
That is our plan. Cast you ideas!
Thanks,
Guillaume
Hi Sascha,
Thanks for filling out this form, this help us! :)
See below
> On 3 Aug 2017, at 20:05, Response Report <report(a)formassembly.com> wrote:
>
> Your form "Downloading XWiki (xwiki.org)" has received the following response:
>
> Submitted on: 03/08/17 20:05:15
[snip]
> Would you like to get into details?
> Q. Suggest Improvements
> R. Dashboard Design - Ready to start designs / Templates - improvement in navigation
> Missing features: Professional project management with milestones, deadlines, effort, time measuring, UML diagram support
Let me try to explain what exists and you can tell me if it’s enough or not, ok? :)
* "Dashboard Design". We have this: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard%20Application (and http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard%20Macro). You can drag and drop widgets to move them around, add columns, etc. What’s missing?
* "Ready to start designs / Templates”. We are bundling these templates: http://extensions.xwiki.org/xwiki/bin/view/Extension/Templates%20Applicatio…. Is that good enough?
* " improvement in navigation”. Could you give some examples/more details?
* "Missing features: Professional project management with milestones, deadlines, effort, time measuring”. Indeed but it’s not the goal of XWiki to provide a professional project management tool; there are plenty of (web)apps that do this much better already :). We do have a lightweight version though: http://extensions.xwiki.org/xwiki/bin/view/Extension/Generic%20Project%20Ma…
* "UML diagram support”. We do support this through several macros.
- http://extensions.xwiki.org/xwiki/bin/view/Extension/PlantUML%20Macro
- http://extensions.xwiki.org/xwiki/bin/view/Extension/YUML%20Macro
- http://extensions.xwiki.org/xwiki/bin/view/Extension/Sequence%20Diagram%20M…
WDYT? I’d love to know more from you and to understand what we’re missing.
Thanks
-Vincent
XWiki committer
>
> Q. Anything else
> R.
>
>
> Where should we send the data?
> Q. Send to
> R. - Keep the data anonymously on XWiki.org
>
>
> Who are you?
> Q. Name
> R. Sascha Wichert
>
> Q. Email
> R. Wichert(a)inztitut.de
>
> Q. Job Title
> R.
>
> Q. Country
> R. Germany
>
>
>
>
>
>
>
Hi, devs,
During a hackathon session, I have done a refresh on XWiki's code viewer
("code.vm") and integrated the Blame API [1] developed by Denis to add
line-by-line blame information, just like GitHub's blame feature.
Please see the associated Jira issue that also includes before and after
screenshots:
https://jira.xwiki.org/browse/XWIKI-14578
The Blame API module is a commons module since 2014 but not bundled neither
in the WAR nor in the flavor, so, in order to go along and merge my work,
I'd need it to be available as a core extension (to be also usable by
code.vm).
I have not studied it deeply, but the module seems to be doing its job well
and the result is very nice and it is very generic.
Being able to perform a blame analysis builds upon the diff module and both
are features of XWiki's versioning capabilities, so, IMO, both should be
considered core extensions (and not only the diff module, which already is
core).
The PR is available at https://github.com/xwiki/xwiki-platform/pull/605
Here is my (obvious) +1 to bundle the blame-api and merge the PR which
includes the UI.
Thanks,
Eduard
----------
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module
Hello XWikiers,
Starting from the version 9.4 of the Blog application we introduced the
notion of blog post layouts (see details here: http://extensions.xwiki.org/
xwiki/bin/view/Extension/Blog%20Application).
Currently when a user creates/edit a blog he has the possibility to select
the layout of the blog posts, 2 layouts are available FTM: the Calendar
layout (default) and the image layout.
The image layout uses an image thumbnail in order to allow a more visual
and appealing display of the blog posts this is why an image selector was
added to the blog post form.
Because the default layout is 'Calendar' the image selector on the blog
post form can be confusing for the user because the uploaded image doesn't
appear anywhere.
This proposal is about changing the default blog posts layout from
'Calendar' to 'image' in order to avoid the confusion.
I propose to:
- Change the default post layout to 'image' layout for new blogs
- Change the layout of the default Blog to 'image' layout
- Add an image to the introduction blog post created when installing the
blog app. Find attached some examples of images that can be used on the
introduction post.
- On the blog post form add a short description to the image selector to
explain the objective of the image.
*Introduction blog post images*
*1) *
*2)*
*3) *
*4)*
**
WDYT?
Thanks,
Mohamed
Hey!
I'm happy to announce that Extension Repository Connector - Pypi is
released -
http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository…
XWiki has possibility to scirpt on its pages in Python. Under the hood it's
Java Scripting API and Jython that takes care of running this script and
returning result to page. Jython has implementation only for standard
libraries. That's why Extension Repository Connector - Pypi is created - to
be able to import to XWiki other (non-standard) python packages that are
hosted on pypi: https://pypi.python.org/pypi.
I'd be grateful for any feedback :)
Best,
Krzysztof
Hi all,
I’m pleased to announce that the XWiki Core Committers have voted 2 new committers:
* Alex Cotiuga
* Clement Aubin
Congrats guys! You’ll now have the pleasure of being able to commit without waiting for someone else to apply it. Note that when you’re not sure and want to request a review, you can still do PRs if you want. It’s now your choice :)
I’ve sent you invitations for the XWiki Github org.
I’ve also added you to the committers group on xwiki.org.
Make sure to read http://dev.xwiki.org/xwiki/bin/view/Community/Committership :)
Last but not least, I’ve added you to the Release Manager roster:
http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/#HNextReleaseManagers (let me know if you really don’t want to be a RM and I’ll remove you!).
Thank you very much for your interest in making XWiki progress and be better every day.
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki 9.6.
This release brings improvements to Notifications, like live email
notifications, the ability to get notifications through RSS feed or to
override their default display. It is now possible also to generate
table of content for another page, or to define recommended extensions
versions and optional extension dependencies so they can be
uninstalled by the Extension Manager.
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.6
Thanks for your support
-The XWiki dev team
Hi Mohamed,
Obviously, I am +1 for the new default, since it is also my proposal. Regarding the image for the introductory blog post, I would use a more photo like an image, to be more demonstrative, illustrating blogging, writing, office or whatever, maybe with an X in it somewhere. Be careful about the copyrights of the image, of course.
Thanks,
--
Denis Gervalle
SOFTEC sa - CEO
On Sun, Jul 23, 2017 at 14:55, Mohamed Boussaa <mohamed.boussaa(a)xwiki.com> wrote:
Hello XWikiers,
Starting from the version 9.4 of the Blog application we introduced the
notion of blog post layouts (see details here: http://extensions.xwiki.org/
xwiki/bin/view/Extension/Blog%20Application).
Currently when a user creates/edit a blog he has the possibility to select
the layout of the blog posts, 2 layouts are available FTM: the Calendar
layout (default) and the image layout.
The image layout uses an image thumbnail in order to allow a more visual
and appealing display of the blog posts this is why an image selector was
added to the blog post form.
Because the default layout is 'Calendar' the image selector on the blog
post form can be confusing for the user because the uploaded image doesn't
appear anywhere.
This proposal is about changing the default blog posts layout from
'Calendar' to 'image' in order to avoid the confusion.
I propose to:
- Change the default post layout to 'image' layout for new blogs
- Change the layout of the default Blog to 'image' layout
- Add an image to the introduction blog post created when installing the
blog app. Find attached some examples of images that can be used on the
introduction post.
- On the blog post form add a short description to the image selector to
explain the objective of the image.
*Introduction blog post images*
*1) *
*2)*
*3) *
*4)*
**
WDYT?
Thanks,
Mohamed
Hi devs,
Needs:
* We need some “Deprecated” macro category so that users understand when a macro is deprecated and are less tempted to use it
* We need to not show “Internal” macros by default to not “pollute” the Macro list by default
Proposal:
* When the “All Macros” is selected display all macros *except* those from 2 categories: “Deprecated” and “Internal”.
* If the user needs/wants to use those macros, he’ll need to explicitly select those categories.
* When we want to deprecate a Macro we move it from its category to the “Deprecated” category, before removing it further in the future (when is to be defined on an adhoc basis)
Technical details:
* Change https://github.com/xwiki-contrib/application-ckeditor/blob/master/plugins/s… to implement this new behavior
WDYT?
Thanks
-Vincent
Hi devs,
https://github.com/xwiki-contrib/ is starting to be crowded with
archiving purpose repositories so it would be nice to move them
somewhere else to have less noise.
"attic" naming refer to https://attic.apache.org/
Here is my +1
--
Thomas Mortagne
Hi devs,
I’d like to propose that we bundle the Syntax Highlighting Extension in the Standard flavor, starting with XWiki 9.7RC1.
Rationale:
* No impact for simple users (ie the default)
* For advanced users, it makes editing pages using the wiki editor much nicer
* It’s already a recommended extension on e.x.o and I’m willing to continue supporting it (and I’m sure Edy is interested in doing that too - Right Edy?)
See http://extensions.xwiki.org/xwiki/bin/view/Extension/Syntax%20Highlighting%… for more details.
TBH I don’t really understand why we haven’t bundled this a long time ago.
Does anyone see any issue in bundling it?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
9.6 Release Candidate 1.
This release brings improvements to Notifications, like live email
notifications, the ability to get notifications through RSS feed or to
override their default display. It is now possible also to generate Table
of content for another page, or to define optional extension dependencies
so they can be uninstalled by the Extension Manager.
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.6RC1/
Thanks for your support
-The XWiki dev team
Good day to all.
First, a quick update on the current status of the redpen extension:
It is now renamed as Content Checker, in consideration of implementing other
document checking technology in the future. Also content checker's results
are currently shown as logs, and the messages are split into warnings and
errors. Also, during automatic validation of a document on save, if an error
exists, the save is canceled.
Next, I am in the middle of adding most of the available validators from
redpen as a configurable setting. However there are validator settings that
require a dictionary i.e. Invalid words, suggested words and expressions. To
this end, I plan to reformat the application homepage, to add a select field
before the user enters into the text input fields, indicating whether the
entry for invalid words or for suggested words and expressions.
Further, I have been looking for a way to extract the live table data within
Java, but have been unable to. Is there a way to do it?
Lastly, as the number of validation settings pile up, I plan to reformat the
UI of the configurable class of my app to one that is tabbed, like the
WYSIWYG configurable class in the administration wiki, to achieve a cleaner
look.
I would greatly appreciate any comments on the above implementation plans,
thanks!
--
View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-4-Design-RedPen-Integration-t…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
We’ve been having 3 persons in the community who help test XWiki every day and who report jira issues: Ilie, Gabriela and Manuel. Manuel has been doing this over 4 years now (close to 5 actually)!
They’re important and they help XWiki get better every day and release over release.
I think we should recognize them more in the project.
I have 2 ideas:
* Mention this role of QA engineer on http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame and make it more “official"
* Make them visible in the RN. Right now in the RN we mention everyone who contributed code. I think we could also mention everyone who created a JIRA issue that got fixed during that release.
WDYT? Any other idea?
Thanks
-Vincent
PS: I forgot if I already sent a mail on this topic or not (couldn’t find one but it vaguely rings a bell). Anyone remembers? :)
Hi everyone,
I just implemented https://jira.xwiki.org/browse/XCOMMONS-1229 which
allows to indicate that a dependency will be installed by default but
does not have a string dependency link with the extension, meaning
that uninstalling it won't impact the backward dependencies (so they
are not really backward dependencies in that case :)).
Now we need to decide what exactly is optional in Standard flavor.
Here are some ideas:
* application-help-center
* xwiki-platform-menu-ui
* xwiki-platform-wiki-ui-mainwiki
* xwiki-platform-office-ui
* xwiki-platform-invitation-ui
* xwiki-platform-appwithinminutes-ui
* xwiki-platform-linkchecker-ui
* xwiki-platform-sandbox
* xwiki-platform-sharepage-ui
* xwiki-platform-distribution-flavor-tour
* application-templates-ui
I did not actually tried to uninstall those so it's possible it's not
a good idea to uninstall some of them right now (hardcoded use
somewhere maybe).
WDYT ?
--
Thomas Mortagne
Hi devs,
We’ve moved the register/login buttons inside the drawer. However one consequence is that users don’t notice it anymore.
I’d like this thread to be a brainstorming about what we could do about it and whether you agree it’s an issue that we need to fix.
Ideas?
One idea could to reuse the Avatar image location to have some icon to register/login when not logged in.
WDYT?
Thanks
-Vincent
Hi devs,
So we now have the concept of optional dependencies at Extension
Manager level. This are dependencies that are installed by default
(but if they fail they don't fail the whole install) and which can be
uninstalled without any impact on what is no longer it's backward
dependency.
On Maven -> EM side what I did is reuse <optional>true</optional>
mostly the following reason: there is no way in pom.xml to put custom
stuff in <dependency> so it would be a huge pain to maintain a list of
optional dependencies from a property at general pom level.
The issue is that the behavior of this <optional> is not exactly the
same in EM and Maven: in Maven those dependencies are NOT triggered by
default. Still, apart from this it's supposed to be the same meaning
and it should not be an issue to install this dependency (if it is
then it means you should have used something else like
<scope>provided</scope>) but as usually since there is no official way
in Maven to say "I just want to use that during the build and it does
not make any sens to get this dependency" some projects may have used
it that way.
So do you think it is OK ? It's not acceptable and we absolutely need
to move this kind of information in some general property in the pom
<properties> ?
--
Thomas Mortagne
Hi devs !
Currently working on
[XWIKI-14353](https://jira.xwiki.org/browse/XWIKI-14353), I think that
the live e-mail notification system could be implement as 2 different ways :
1. In its notification preferences, a user can select if he wants a mail
daily, hourly or weekly (that’s already in place). We could add a new
"live" option that does exactly what is expected : it sends a mail as
soon as a document has been updated.
2. We could also provide a completely different option that sends live
e-mails, but regular notification mails are still sent depending on the
user preference and acts as a hourly / daily or weekly "digest".
Finally one idea would be to use the same system that is implemented in
discourse : a mail is sent approximately 10 minutes after an event is
triggered, this means that if a user A is subscribed to the events
coming form a document X, if this document is updated by someone else,
the updates coming from the document in the next 10 minutes will be
grouped in a single mail that will be sent to A. This could potentially
be more scalable as less mails are sent to the users.
WDYT ?
Thanks,
--
Clément Aubin
Web Developer Intern @XWiki SAS
clement.aubin(a)xwiki.com
More about us at http://www.xwiki.com
Hi all!
This is the third update regarding the progress of the Redpen integration
project.
Some of the info can also be accessed in the design page over here:
<http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration>
I have created a UI on XWiki. The two main parts are such:
First, the application homepage will allow users to key in possible spelling
and expression errors, and their recommended corrections. I have not started
on building the backend in Java to process this database yet, but I'll start
on it within the next couple of weeks.
Second, there is a setting page within the global administration wiki that
allows the user to key in basic settings parameters e.g. setting maximum
sentence length.
The functionality is still restricted to validating a wiki page on document
save, but I will be implementing the function to run redpen validation as a
Job next, right after i finish fixing and stabilising some issues within the
code.
Any comments?
--
View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-3-RedPen-Integration-tp760425…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Sarthak,
> On 28 Jun 2017, at 20:35, Sarthak Gupta <sarthakgupta072(a)gmail.com> wrote:
>
> Hello Vincent,
>
> On Wed, Jun 28, 2017 at 1:30 PM, Vincent Massol <vincent(a)massol.net> wrote:
> Hi Sarthak,
>
> > On 27 Jun 2017, at 14:58, Sarthak Gupta <sarthakgupta072(a)gmail.com> wrote:
> >
> > Hi all,
> > This mail is regarding the status of the project Glossary Application.
> > I have developed the basic UI for the application which enables a user to
> > add a glossary application and also search the already existing glossary
> > item in the glossary space. The UI is still not very user-friendly as I had
> > decided to finish off the leftover designing part after adding more
> > features and just before the release of the first version.
> >
> > The next part of the project was "adding transformations". I have written
> > the code for basic transformation but still facing some errors in it. Hope
> > the errors may be rectified after some code review.
> >
> > The task that will be left before releasing the first basic version will be
> > "the ability to add glossary items from the wiki pages by selecting the
> > words on Wiki pages". More details on
> > http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication
> > <http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication>.
> >
> > Also, tests are to be written for each fo the above.
> >
> > Rest of the features which are to be added (See Design Page) will be
> > implemented after the release of the first version. :)
>
> Thanks for the update.
>
> Some general comments first: I found that the work is going too slow and I’m a bit disappointed by the progress. At this stage you’re actually less advanced than the FAQ application and the Glossary app is really just a copy of that (the part located in wiki pages). You should have finished both the UI and the Transformation at this point. TBH the work done shouldn’t amount for more than 2-3 days of work for someone new to XWiki.
>
>
> Yes, I totally agree and deeply regret that the work done is too less than expected. The main reason for this was that I was basically facing problem with the language. I was hearing some things for the first time in my life, I used to google them a lot but because of having a very less experience in programming(1 year roughly), I was finding difficulty to relate things with each other thus not able to find the right resources to understand the concepts properly, so used to get stuck on them for days. I still face these things but certainly I am better now and will try to catch up. :)
>
> Some more specific comments on the code of what I’ve reviewed:
> * The POMs have plenty of errors and you haven’t used the information that can be found http://contrib.xwiki.org nor the FAQ application’s POM as I have explained a few times (missing licenses, missing metadata, etc), incorrect README.
> * You committed IDE files in the SCM (see the rules from http://dev.xwiki.org).
>
> * Would be better to use nested pages and put the Code space under the Glossary space.
>
> Could you please explain the one point above. Not getting it.
See http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… and especially:
"Technical pages must be put in a subspace named Code”
Would be great if you could review those best practices btw.
XWiki supports nested pages, see http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization/ for more details.
>
> * You’re using the wrong package for your java class (it should be in org.xwiki.contrib and not org.xwiki.rendering): https://github.com/xwiki-contrib/application-glossary/blob/master/applicati…
> * Would be great if you could add some unit tests for the transformation (again check the wikioword transformation which has tests). Without it, it’s hard to test and I can’t help you without that (would take too long to debug in XWiki).
>
> I will correct all the above errors ASAP.
>
> * Note that you haven’t implemented yet a cache in the transformation and tight now your transformation would simply slow down the whole XWiki :)
>
> Could you provide some pointers on this?Some example or guide that I can refer to?
This means implementing an Event Listener that listens to glossary xobjects addition/deletion/updates and updates a cache of glossary keys and document references. A cache can be a simple structure such as a Map.
You can google “xwiki event listener” for more info on that. There are also several examples in xwiki-platform. Check classes implementing the EventLiostener interface.
Thanks!
-Vincent
>
> Maybe you need to catch up technically on several technologies and that’s why the progress is a bit slow. I hope you’re learning a lot which would be good!
>
>
> That's right! I am learning a lot.. :)
>
> Thanks
> Sarthak Gupta
>
> Thanks
> -Vincent
>
> >
> > Thanks
> > Sarthak Gupta
The XWiki development team is not so proud to announce the
availability of XWiki 9.5.1.
This version fix important bugs found in 9.5: broken flavor picker in
the Distribution Wizard, broken sub wiki template creation and missing
extensions notifications in the profile.
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.5.1
Thanks for your support
-The XWiki dev team
Greetings everyone!
I’m really excited to announce the First Milestone version of the DokuWiki importer extension!
Available in the Extension store: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/Text/
Notes:
This version can recreate the DokuWiki pages and spaces in XWiki.
Milestone 2 is expected to have a syntax parser for importing the page content. (release next month).
Requires the 'Filter Streams Converter Application’.
Requires the ‘data’ folder of the DokuWiki instance packaged as a TGZ, and Voila!
Would love to know your thoughts/reviews! :)
Thanks!
Shubham Jain
(slayerjain)