Hi devs,
I think we are now satisfied with our experimentation with the "users"
mailing list on discourse. I propose you to move the "dev" ML too.
My main point is that it allows advanced formatting (which is good when you
have complex proposals), meanwhile the formatting is lost with our
archiving tool like markmail (it's plain text).
Here is my +1.
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi everyone,
I was checking our list of flickering tests in JIRA
(https://jira.xwiki.org/issues/?jql=labels%20%3D%20flickering%20AND%20status…)
and I noticed that we had somehow old flickering test issue concerning
test that I've never seen failing.
So I propose we close some of them as inactive: the ones that we don't
remember having seen for a while. The ideal would be to have a mechanism
to update the issue when the CI fails on a flicker, but it takes time to
do properly and it's not a priority.
On the contrary I propose to trust our memory: if we're wrong because we
have closed a flicker that is still happening, it will allow us to
remind that we have this flicker to fix and we can easily reopen the issue.
As Thomas mentioned on the chat, we should also update the release plan
to include the inactive flickers in the list of issue to check.
So for now I propose to close the following list of issues as inactive:
* XWIKI-14399: AddRemoveTagsTest#addAndDeleteTagFromTagPage is
flickering (https://jira.xwiki.org/browse/XWIKI-14399)
* XWIKI-14396: AnnotationsTest#addAndDeleteAnnotations is flickering
(https://jira.xwiki.org/browse/XWIKI-14396)
* XWIKI-14394: SectionTest.testSectionEditInWikiEditorWhenSyntax2x
(xwiki-enterprise-test-ui) is flaky
(https://jira.xwiki.org/browse/XWIKI-14394)
* XWIKI-14386: appwithinminutes.AppsLiveTableTest.testEditApplication
is possibly flaky (https://jira.xwiki.org/browse/XWIKI-14386)
* XWIKI-14835:
DeletePageTest#deletePageIsImpossibleWhenNoDeleteRights is flickering
(https://jira.xwiki.org/browse/XWIKI-14835)
* XWIKI-14860: LoginTest#testDataIsPreservedAfterLogin is flickering
(https://jira.xwiki.org/browse/XWIKI-14860)
And I propose in general to close the flickers we don't remember having
seen after a cycle as inactive.
WDYT?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
Hi everyone,
Hope all of you are doing great.
About Me
I am Fawad Ali, selected as a student for Google Summer of Code. Currently
enrolled in the 6th semester at University of Engineering and Technology,
Taxila. I am a resident of Pakistan currently living in the city of
Rawalpindi.
It is a great honor to have been selected and have a chance to work with
XWiki. :)
*Profiles*
GitHub - https://github.com/9inpachi
LinkedIn - https://www.linkedin.com/in/fawadaliq/
Riot - @ginpachi:matrix.org
I will be presenting my project "Map Application" to all of you. Following
are the relevant details.
Map Application
*Mentors: *Stéphane Laurière, Ecaterina Moraru
*Technologies:* JavaScript, Velocity, Java, Leaflet, other if required
Overview
This project is about the development of interactive maps in XWiki.
Creation of an application within XWiki that will allow users to generate
interactive maps which support collaboration and are easy to create so that
locations can be shared, and areas can be associated with structured data.
This application will open several possibilities that can be utilized
within XWiki and broaden the overall scope by allowing map rich wikis where
locations and areas can be presented in a way that will increase the
understandability of data.
It will also allow for the sharing of custom map related data which would
be very helpful since users and admins will be able to present locations in
an information rich map environment which will be interactive.
Features
> *Markers and popups* - Place markers anywhere on the map and associate
popups with them.
> *Path between two points* - A path will be generated by the application
linking two points of interest.
> *Location search* - Search any location on the map.
> *Filtered list maps* - Allow the user to search for a specific kind of
place (e.g. restaurants) and get a list of locations to choose from.
Through the content available and binded to a location, the user will be
able to learn some aspects of the location.
> *Custom shapes* - Custom shapes can be used to highlight a specific area
for representation. The content associated with these shapes can give
useful information about the area.
> *Indoor maps* - Such maps will be able to describe the internal structure
or fair plan of a building or structure. They can be used to guide users in
a big building and locate point of interests.
> *Maps on mobile* - Special design arrangements will be made for easily
viewing of maps and availing all the features of the application on mobile
devices.
> *Custom map backgrounds* - Custom backgrounds will make the environment
of interactive maps much suitable for a specific purpose
If you have any features in mind that will make the Map Application better
please feel free to reply to this mail.
This is all for the summary of the project, if you want to have a more
deeper insight, please check out the full proposal.
*Project Proposal: *
https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr
Thanks for reading through the mail. I will be looking forward to your
guidance through this summer and your contributions to the project.
If you have any questions or suggestions, please feel free to reply to this
mail.
Au revoir. :)
Best,
Fawad Ali
Hi devs,
tomcat9 package is now available in Debian repositories so I would
like to start providing xwiki-tomcat9-* Debian packages of XWiki.
Nothing complex so far but it if we provide an official tomcat 9
oriented package it would also make more sense to add Tomcat 9 in
https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletConta…
(only Tomcat 8 right now).
Another argument is that it's the current recommended stable version
from Tomcat point of view so people will use it more and more.
WDYT ?
Here is my +1
--
Thomas Mortagne
The XWiki development team is proud to announce the availability of XWiki
11.6.
This release brings new security features related to user authentication
and management, a new way to see document changes closer to the WYSIWYG
edition and a new macro to define part of a document that should be
asynchronously loaded for better performance.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.6/
Thanks for your support
-The XWiki dev team
Hi devs,
Here’s a proposal for 11.7:
To finish for XWiki 11.6 (in progress)
====================
July
* Finish Visual diff (on HTML and not markup) - Marius
* Editor Selection For TextArea Fields When Editing XObjects - http://jira.xwiki.org/browse/XWIKI-15753 - Marius
* Add UI to activate/deactivate users - https://jira.xwiki.org/browse/XWIKI-12654 - Simon
XWiki 11.7
==========
August:
* 11.7-rc-1: 19th of Aug
* 11.7 final: 26th of Aug
* Merge conflict: allow choice by chunks and custom fixes - https://jira.xwiki.org/browse/XWIKI-16464 - Simon
* Security: not be allowed to set a right you don't have (min) - https://jira.xwiki.org/browse/XWIKI-16266 - Thomas
* Async rendering improvements - Thomas
* Better handling of user removal and transfer of rights - http://jira.xwiki.org/browse/XWIKI-12142 - Marius (usability)
Thanks
-Vincent
Hi everyone,
I'm currently working on improving security on XWiki comments. We
already use a restricted mode in our comments but that does not cover
every possible case. In order to improve it we should also filter out
some part of the html when using the html macro.
I propose:
(a) that we use a configurable whitelist of HTML attributes that
would be allowed in the output HTML: all the other attributes would be
filtered out.
(b) that the HTML macro is put in restricted mode for users who do
not have scripting rights.
For (a) I'm hesitating between a whitelist or a blacklist: I assume a
blacklist would be shorter but there's also more risk of missing
something. On the contrary a configurable whitelist doesn't prevent
administrator to accept more than what we give in standard.
A first whitelist could be (taken from:
https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b15…)
alt, class, height, id, name, rel, scope, style, target, title, width
Note that href is not included in this list for example.
WDYT?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
The XWiki development team is proud to announce the availability of
XWiki 11.6RC1.
This release brings new security features related to user authentication
and management, a new way to see document changes closer to the WYSIWYG
edition, and a new macro to define part of a document that should be
asynchronously loaded for better performance.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.6RC1
Thanks for your support
-The XWiki dev team
Hi everyone,
Thanks for having me here
About Me
I am Ashish Sharma, selected as a student for Google Summer of Code. I am
final year student enrolled in Guru Gobind Singh Indraprastha University,
Delhi. I am a resident of India.
Profiles
GitHub - https://github.com/ashish932/xwiki-helm-chart/
LinkedIn - https://www.linkedin.com/in/ashish932/
Riot - @ashish932:matrix.org
I will be presenting my project "Helm Chart for XWiki" to all of you.
Following
are the relevant details.
Helm Chart for XWiki
Mentors: Shubham Jain, Neha Gupta
Technologies: Kubernetes, Docker, other if required
Overview
The proposed project is a helm chart that would deploy xwiki as highly
available and reliable. It should be configurable with different
databases(either a standalone database or a clustered one) that are
configurable with xwiki. It would give the option to either configure solr
externally (standalone or clustered) or managed within the container. It
should deploy the app on a shared file system like a rook. It should
support Istio virtual services, istio matrix, and istio distributed tracing
and should be a secured system with RBAC and security credential rotation.
The chart should be easily deployed on GKE and amazon EKS.
Features
-> Support for different Databases
-> Choice between using an external database, a single node DB or a
multi-cluster DB setup
-> Support for shared file system
-> Support for istio and it's services
-> RBAC, SSL and other security methods
If you have any features in mind that should be added please feel free to
reply to this mail.
Some Design Questions?
-> Which Databases should be supported?
-> As we have to detach solr out of the docker container(run it in an
independent container) would be there a requirement for a code change, and
we should approach it?
-> Apart from solr is there any other stateful service that could or should
be detached from the docker container?
Here is my current repository which deploys XWiki for MySQL database using
official XWiki docker container:-
https://github.com/ashish932/xwiki-helm-chart/
Thank You
Ashish Sharma