The XWiki development team is proud to announce the availability of XWiki
8.4.
This version brings a lot of usability improvements. The WYSIWYG editor (
*CKEditor*) has been upgraded and proposes a better dialog for the creation
of links. It is also possible to configure it from the administration.
Application Within Minutes does not enforce anymore the location where the
application's entries must be created, but proposes to the creator the
places *where* and *from where* these entries should be. We have also get
rid of the Data page where the entries where created before.
The default values of the user preferences are now better exposed to the
users. The order of the applications in the application panel can now be
changed by the administrator. And the users now have the ability to filter
the page types when they create a page.
As usual plenty of less noticeable improvements are proposed, and 45 bugs
have been fixed since XWiki 8.3.
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/8.4/
Thanks for your support
-The XWiki dev team
Hello,
It is strange because my emails have a DKIM signature like here (piece of header from a mail I sent from my xwiki email to myself at another adress).
Is it sympa who's altering this signature?
Can I fix it (if it is "my fault")?
Thxs
Pascal
----------------------------------
Received: from nm43-vm5.bullet.mail.gq1.yahoo.com (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220])
xxx
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1478593132; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=N6C8UltuP6jp4mZaWG43Y1ngel4R75RdftqTuXxYHngnseuGe5/2k2/H5pwVcJVe34gjtB33vMZm1j4yZ56M8++zNl4Asb4xV/6wwF+JL+ZGlcXTmfJdGlx5+GdukOzN6bX9Dz9Lvp5GpsYHZnWE8eANw0SeJ9t9wcvzKmNOYW+t9S53N27nfRfjYAwm7iZVmUsgbbZlpnW3NYrPOLoBGZX67aq6gsq877LKUyLLgLP5oszQnx3cUZAsgmjRuSYIIzjF42vfzjVjs7rOoO7royNl5O8BeFlgpevF/BDk2g2K7KXRTkkKtmDMxxxx
--------------------------------------------
En date de : Lun 7.11.16, Sergiu Dumitriu <sergiu(a)xwiki.org> a écrit :
Objet: Re: [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists
À: "XWiki Users" <users(a)xwiki.org>, "XWiki Developers" <devs(a)xwiki.org>
Date: Lundi 7 novembre 2016, 15h40
By the way, all of
Pascal's and Julio's emails (and other yahoo
users)
end up in my spam folder because of
the broken DKIM signatures.
On
11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
> This is partially XWiki's
infrastructure fault, too.
>
> DMARC doesn't work well with mailing
lists, since they tend to break
> DKIM
signatures. The only way to fix the problem (at least for
the
> majority of emails) is to remove
the footer from the configuration.
>
> So, options:
>
> - remove the footer, which means that
"incompetent" users will have a
> hard time finding information about
unsubscribing, but allows users from
>
modern email providers to subscribe
> -
keep the footer, which makes it harder for legitimate users
to stay
> subscribed
>
This is partially XWiki's infrastructure fault, too.
DMARC doesn't work well with mailing lists, since they tend to break
DKIM signatures. The only way to fix the problem (at least for the
majority of emails) is to remove the footer from the configuration.
So, options:
- remove the footer, which means that "incompetent" users will have a
hard time finding information about unsubscribing, but allows users from
modern email providers to subscribe
- keep the footer, which makes it harder for legitimate users to stay
subscribed
On 11/02/2016 07:57 AM, Vincent Massol wrote:
> Hi everyone,
>
> Just to let you know that on the 28th of October, there were 234 members of the xwiki users list who’ve been automatically disabled (ie they’re not going to receive mails). This is apparently caused by a change in Yahoo’s email policy:
>
> <gumush(a)gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said:
> 550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
> 550-5.7.1 domain's DMARC policy. Please contact the administrator of
> 550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
> 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about
> the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
> end of DATA command)
>
> So if you’re in that case, please contact Yahoo as mentioned in the message above.
>
> Thanks
> -Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu
Hi devs,
I'm proposing to add this new property to the *XWikiPreferences* class
since there are many authenticators, listed on
http://platform.xwiki.org/xwiki/bin/view/Features/Authentication and most
of them require the overriding of the *xwiki.authentication.authclass*
property in the *WEB-INF/xwiki.cfg* file and the restart of the wiki. So
the *authclass* is meant to keep the value of the
*xwiki.authentication.authclass
*property*.*
Please keep in mind that *xwiki.cfg* was the historical file containing the
configuration options, we're moving away from it and this can be the moment
to improve this functionality by removing the *restart wiki* step which is
often a pain for the user.
Thanks,
Alex
Hi Guillaume,
Thanks for starting this thread.
----------------------------------------------------------
Current Drawer analysis:
Languages ( L / G )
---
Home ( G ) [N]
---
Administer wiki ( L ) [A] [W]
---
Wiki Index ( G ) [I] [W]
Page Index ( L ) [I]
User Index ( L / G ) [I]
Applications Index ( L) [I]
---
Create wiki ( G ) [A] [W]
---
Delete wiki ( L ) [A] [W]
L = Local/Wiki setting/action/effect
G = Global/Farm setting/action/effect
N = Navigation
A = Action
W = Wiki entity
----------------------------------------------------------
Some examples of grouping:
1. Local / Global effect grouping (ex. Main/Subwiki actions should be
grouped)
2. Entities grouping (Wiki related actions should be grouped: create,
administer, delete, etc.)
3. Index grouping (group all index applications together)
4. Navigation grouping (to Main wiki or other wikis)
5. Actions grouping
6. other?
So the main question is what grouping would we want to prioritize first:
1-5?
----------------------------------------------------------
Some things to consider:
A. Naming consistency:
A1. Across wiki: we need to consider the terms usage. For example Home vs.
Homepage; Wiki vs. Subwiki; Settings vs. Administration; Wiki Index vs.
Browse all wikis vs. Show all wikis
-- We need to align these usages and pick the one most relevant for the end
user and correct as terminology
A2. Across the menu: this implies having all entries plural/singular or
having the same additional text (ex. do we mark Indexes the same way?
Administer wiki / Delete this wiki / Create a new wiki, etc.)
B. Explicit (vs. Cryptic)
-- how explicit should we make the labels vs. icons usage
C. Quick access to local actions
-- in subwikis we should optimize for local actions and try to display them
first, since some teams might have dedicated wikis and the main wiki could
be used just as a portal or as a farm
D. Order most used actions first
-- for example 'Delete wiki' is not a very used action
E. Navigation vs. Actions grouping
E1. Actions removal
-- for example we could even remove 'Delete wiki' action and consider that
the wiki management actions can be accessed just from Wiki Index
-- this would mean that 'Administrate wiki' would be removed too, and we
use that action a lot in the initial configuration phases, so that would
increase the time to reach Administration
E2. Adding more wiki navigation
-- For example http://jira.xwiki.org/browse/XWIKI-12538 talks about having
a way to add quick access to other subwikis (ideally as favorites, since
listing all wikis does not scale)
----------------------------------------------------------
Proposals grouping feedback:
Current. -1 (Local/Global), -2 (Wiki grouping), +3 (Indexes), partial 4
(Navigation), -5 (Actions) || +A2 (Naming consistency), -C (Quick access)
P1. -1 (Local/Global), partial 2 (Wiki grouping), +3 (indexes), partial 4
(Navigation), partial 5 (Actions) || +A2 (Naming consistency), -C (Quick
access)
P2. partial 1 (Local/Global), -2 (Wiki grouping), partial 3 (Indexes), -4
(Navigation), -5 (Actions) || +A2 (Naming consistency), +C (Quick access)
P3. partial 1 (Local/Global), -2 (Wiki grouping), +3 (Indexes), -4
(Navigation), -5 (Actions) || +A2 (Naming consistency), +C (Quick access)
P4. -1 (Local/Global), partial 2 (Wiki grouping), +3 (Indexes), -4
(Navigation), +5 (Actions) || +A2 (Naming consistency), partial C (Quick
access)
----------------------------------------------------------
The problem is that when you approach an usability problem using these kind
of grouping / grading it's very easy to fall in the 'technicalities' trap
and not think about the user perspective.
So although I understand why I proposed P1-4, for users it will not make
sense. That's why I like P5, because the grouping comes natural and is more
explicit, although is not using the consistent terminology.
P5: +1 (Local/Global), -2 (Wiki grouping), -3 (Indexes), partial 4
(Navigation), -5 (Actions) || -A2 (Naming consistency), -A1 (Across wiki),
+B (Explicit), +C (Quick access to local), ? D (Most used actions)
Things to fix for P5:
- Think where to fit the "Languages"
- A1 + A2: we need to think about the naming of Indexes (especially Wiki
Index in this case) and fix them in drawer and across; replace Settings
with Administration; fix the "Go to ..."; consistent actions naming.
Additionally we should fix A1 (see http://jira.xwiki.org/browse/XWIKI-9363)
----------------------------------------------------------
Before starting this thread I tried to rethink about a new solution and I
came up with
P6: -1 (Local/Global), +2 (Wiki grouping), +3 (Indexes), +4 (Navigation),
+5 (Actions) || +A2 (Naming consistency), -A1 (Across wiki), -B
(Cryptic/Iconography), -C (Quick access), ? D (Most used actions), +E2
(More navigation)
i) Having Indexes listed before local actions (will give a -C for quick
access), but the advantage is that the menu composition will change less if
we visit main wiki vs. subwikis. P5 also have this propety.
ii) I've grouped and added more navigation by providing the list of wikis.
There are several problems with this approach:
ii.1 - not scalable for large number of wikis (even though I've put an
accordion there)
ii.2 - cryptic actions (icon usage for Create, Administration, Delete wiki)
ii.3 - mobile issues (because the icons are very small and we will need a
different layout for mobiles or we might have problems with large wiki
names)
----------------------------------------------------------
Thanks,
Caty
On Wed, Oct 26, 2016 at 11:42 AM, Miroslav Galajda <
miroslav.galajda(a)gmail.com> wrote:
> Hi, I vote for P5 proposal.
>
> Mirec
>
> On 26 October 2016 at 10:28, Guillaume Delhumeau <
> guillaume.delhumeau(a)xwiki.com> wrote:
>
> > No opinion?
> >
> > 2016-10-24 18:09 GMT+02:00 Guillaume Delhumeau <
> > guillaume.delhumeau(a)xwiki.com>:
> >
> > > Hello dear developers and XWiki users.
> > >
> > > I would you to take a look at the issue http://jira.xwiki.org/browse/
> > > XWIKI-13070.
> > >
> > > The problem is that the current order (that I have implemented based on
> > my
> > > intuition) seems to not be clear for our users. The main point is that
> > the
> > > menu mixes up global items (Home wiki, Wiki Index) and local ones
> > > (Administer Wiki, Page Index, Delete wiki, etc...).
> > >
> > > Caty and Oliver have made some proposals that you could find in the
> > issue.
> > >
> > > They are called P1, P2, P3, P4 and P5.
> > >
> > > I propose you to express your preferences so we can implement it based
> on
> > > a consensus.
> > >
> > > Here are mine:
> > >
> > > P1: There is a logical order and separation between item. However, it
> > > seems the more used actions (Wiki Index, Page Index) are less visible
> > than
> > > some other (Delete Wiki, Create Wiki...)
> > >
> > > P2: The order and the separation are logic. The "delete wiki" action is
> > > still very visible but all other items are good.
> > >
> > > P3: Same than P2. Except that having "Wiki Index" along with "User,
> Page
> > > and Application Index" mixes up local and global items.
> > >
> > > P4: Why not, but maybe the 3 first actions should be placed after the
> > > other ones, since they would be less used. Same remark about the mixing
> > of
> > > local and global items.
> > >
> > > P5: A clear distinction between local and global scope. More used items
> > > are located first. This is my favorite one.
> > >
> > >
> > > So +1 for P5, +0 for the other options so far.
> > >
> > > Now, what about you?
> > >
> > > Thanks,
> > > Guillaume
> > >
> > > PS: I send this message to both devs and users mailing lists, because I
> > > think users are directly concerned by this topic.
> > >
> > > --
> > > Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
> > > Research & Development Engineer at XWiki SAS
> > > Committer on the XWiki.org project
> > >
> >
> >
> >
> > --
> > Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> > _______________________________________________
> > users mailing list
> > users(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
The XWiki development team is proud to announce the availability of XWiki
8.4 Release Candidate 1.
The highlights of this release are the new page type filter from the Create
Page form and the new configuration section for the CKEditor. Changing the
supported languages from the administration has been made easier with the
new language picker. Ordering the Application panel items is now possible
with simple drag & drop. Sub-wiki initialization is now asynchronous. As
usual the release also includes many bug fixes and smaller improvements.
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/8.4RC1/
Thanks for your support
-The XWiki dev team