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
>
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
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 really not confident with the area around those specific
flickering tests here are some other ideas for this kind of Day:
* 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 an issue, 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 !
Hi devs,
For the following XWiki Syntax 2.1 input:
|=head11|=head12
|cell11|cell12
We generate the following XHTML 1.0 output:
<table>
<tbody>
<tr>
<th>head11</th>
<th>head12</th>
</tr>
<tr>
<td>cell11</td>
<td>cell12</td>
</tr>
</tbody>
</table>
I think it would be better to generate:
<table>
<thead>
<tr>
<th>head11</th>
<th>head12</th>
</tr>
</thead>
<tbody>
<tr>
<td>cell11</td>
<td>cell12</td>
</tr>
</tbody>
</table>
Arguments:
* More standard.
* In addition I read I the XHTML spec that "Table rows may be grouped into a table head, table foot, and one or more table body sections, using the thead, tfoot and tbody elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.”
I haven’t checked but hopefully it should relatively painless for our CSS (unless we use a rule for tbody/tr/th instead of tr/th or th). However even if it changes our CSS I still fee it’s the right thing to do with a note in the Release Notes for the unlikely chances that it would break something.
Note tat
I know that for example for the http://extensions.xwiki.org/xwiki/bin/view/Extension/Datatables+Macro extension, we cannot use xwiki syntax because of this issue (this is why the example is using the html macro).
WDYT?
Thanks
-Vincent
PS: our XHTML parser already supports this as can be verified with the following test:
{{groovy}}
def input = '''
<table>
<thead>
<tr>
<th>head11</th>
<th>head12</th>
</tr>
</thead>
<tbody>
<tr>
<td>cell11</td>
<td>cell12</td>
</tr>
</tbody>
</table>
'''
def xdom = services.rendering.parse(input, 'xhtml/1.0')
println "{{{"
println services.rendering.render(xdom, 'xwiki/2.1')
println "}}}"
{{/groovy}}
This could be an idea to replace our aging commons-configuration at some point:
https://github.com/cfg4j/cfg4j
It looks a bit more modern.
WDYT?
Thanks
-Vincent
Hi everyone,
Just wanted to let you know that the XWiki docker image is now an official image on docker hub!
See https://hub.docker.com/r/library/xwiki/
Please try it out and let us know how it goes. That’s probably one of the simplest way to try XWiki now.
It comes configured with filesystem attachment by default and libreoffice configured too for office imports/exports/viewing office docs.
Thanks
-Vincent
Hi devs,
Maintaining something like xwiki-enterprise-archetype is a pain and
really does not worth it IMO since it's probably not used at all. And
as you can see from the history it's never really been maintained
after it's introduction 3 years ago and XE changed a lot since that
time.
We should simply get rid of it IMO. If someone really wants to provide
something like this it can be done in Contrib. In the meantime
copy/pasting XE and modify the few things you need to modify is not
very hard i you want to introduce a new XWiki distribution (and if
flavor is not enough for you).
WDYT ?
--
Thomas Mortagne
Hi devs,
While working on adding extension points to support the replacement of the
current WYSIWYG editor I came to the conclusion that we need to make a
clear distinction between Edit Modes and Editors.
An Edit Mode is basically an HTML *form* that allows you to edit some data
that is associated with an XWiki document. There can be for instance an
edit mode to edit the document title and content, another edit mode to edit
the document objects, another one to edit the document access rights, and
so on. Ideally, XWiki extensions should be able to provide new edit modes.
The current place where we expose the Edit Modes is the Edit Menu. Class,
Objects, Access Rights, Inline Form are well defined edit modes. Before we
talk about the Wiki and WYSIWYG "edit modes" let's define what an editor is.
An Editor is basically a form *field*. Most of the time it is an enhanced
form field, a widget, that allows you to edit a single document field. The
editor obviously depends on the field type. There can be a date editor
(known as date picker), a plain text editor, a rich text editor, and so on.
Ideally, XWiki extensions should be able to provide new editors for
specific data types. For instance an extension could replace the date
picker. Another one could replace the rich text editor.
The relation between Edit Modes and Editors is many to many. An Edit Mode
can use multiple editors and an Editor can be used by multiple Edit Modes.
For instance the rich text editor can be used in the "Content" edit mode
(for document content) but also in the Inline Form edit mode, for TextArea
object properties.
If we agree with this distinction then I think XWiki should have separate
extension points for Edit Modes vs. Editors.
What does this mean for the CKEditor integration? Well, CKEditor is an
editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor
can be used to edit the document content as well as the TextArea object
properties that contain wiki syntax. So there should be no "CKEditor" entry
in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also,
and so on for each Edit Mode that can use the CKEditor.
So I think we should go in the following direction:
* Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry
that will represent the Edit Mode for editing the document title, content
and syntax. I'm not yet sure what name should we use for this Edit Mode.
Let's call it "Content" for now.
* The default edit action (for simple users) will
** open the Inline Form edit mode if the document has a sheet associated
** open the "Content" edit mode otherwise
* The "Content" edit mode will use the Editor configured in the User
Profile, falling-back on the wiki preferences
* The Inline Form edit mode will use for TextArea properties the Editor
specified in the property meta data, falling-back on the User Profile
setting, then on the wiki preferences
* We should have an administration section to configure the default Editor
as wiki level (wiki preferences)
We don't have to implement all this right away. I'd like to start by making
the editor list from the TextArea meta data, User Profile and wiki
preferences extensible, so that CKEditor can add its entry there.
WDYT?
Thanks,
Marius