[xwiki-devs] [Proposal] Switch to USER for the default visiblity for translations + extend to all component-based pages
9 Feb
2018
9 Feb
'18
6:15 p.m.
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki or
Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
9 Feb
9 Feb
7:42 p.m.
Looks like you missed https://jira.xwiki.org/browse/XWIKI-15013.
IMO the safest is more ON DEMAND (which is a concept that does not
exist for macros).
On Fri, Feb 9, 2018 at 6:15 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
--
Thomas Mortagne
9:49 p.m.
Yes I had missed it. I wanted to implement it but first wanted to make sure we agreed
before doing anything, hence this email.
I really disagree about using ONDEMAND as the default since it’s an important usability
regression as it wouldn’t work OOB and the translations are not going to be applied and do
anything useful.
Thanks
-Vincent
On 9 Feb 2018, at 19:42, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Looks like you missed https://jira.xwiki.org/browse/XWIKI-15013.
IMO the safest is more ON DEMAND (which is a concept that does not
exist for macros).
On Fri, Feb 9, 2018 at 6:15 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
--
Thomas Mortagne
10 Feb
10 Feb
12:13 a.m.
BTW I’ve noticed that the documentation is missing ONDEMAND + explanations about required
permissions at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Localization/#HRegiste…
Thanks
-Vincent
On 9 Feb 2018, at 21:49, Vincent Massol
<vincent(a)massol.net> wrote:
Yes I had missed it. I wanted to implement it but first wanted to make sure we agreed
before doing anything, hence this email.
I really disagree about using ONDEMAND as the default since it’s an important usability
regression as it wouldn’t work OOB and the translations are not going to be applied and do
anything useful.
Thanks
-Vincent
On 9 Feb 2018, at 19:42, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Looks like you missed https://jira.xwiki.org/browse/XWIKI-15013.
IMO the safest is more ON DEMAND (which is a concept that does not
exist for macros).
On Fri, Feb 9, 2018 at 6:15 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
--
Thomas Mortagne
12:07 p.m.
General pros of cons for visibility of any component-based xobject (IMO):
* ONDEMAND
** (-) Hardest to use since it requires scripting. Lowest on usability score. Should be
reserved for very special use cases.
* USER
** (+) Safe since only the current user sees it
** (+) Usable since works OOB and for all users with any permissions
** (-) User may believe it works for everyone but other users won’t see it
* WIKI
** (+) Works for everyone on the wiki
** (-) Everyone sees the change you make and you cannot validate it before making it
visible to all
** (-) Requires Admin rights and thus may not work
** (-) Fragile: If a user without admin rights resave the page it breaks it
* GLOBAL
** (+) Works for everyone on the farm
** (-) Everyone (including subwikis) sees the change you make and you cannot validate it
before making it visible to all
** (-) Requires PR and thus may not work.
** (-) Not very usable: For example will fail for local admins
** (-) Very fragile: If a user without PR resave the page it breaks it
** (-) Very fragile: If a local admin upgrades his wiki and a new version of the page is
available, then it breaks the feature
I’m still hesitating between USER and WIKI but I think USER is the best, at least until we
have dynamic defaults (in which case WIKI could be a good default, and if the user doesn’t
have Admin rights, then don’t allow him to save the page by having a verification check +
make USER the default if user doesn’t have Admin right).
Thanks
-Vincent
On 9 Feb 2018, at 18:15, Vincent Massol
<vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
11 Feb
11 Feb
8:43 a.m.
For me what is good with ON DEMAND is exactly what you don't like
about ON DEMAND :)
* you don't pollute anyone when you save (same as USER)
* since you won't see the result right away you have to think about
scopes and which one you want. What made you send this mail in the
first place is people (and here it's core team devs so not really the
beginner contrib extension author kind) keeping the default GLOBAL
without really thinking about it because it was working for them and
the exact same thing will happen with USER until someone has to report
to them it does not work
On Sat, Feb 10, 2018 at 12:07 PM, Vincent Massol <vincent(a)massol.net> wrote:
General pros of cons for visibility of any
component-based xobject (IMO):
* ONDEMAND
** (-) Hardest to use since it requires scripting. Lowest on usability score. Should be
reserved for very special use cases.
* USER
** (+) Safe since only the current user sees it
** (+) Usable since works OOB and for all users with any permissions
** (-) User may believe it works for everyone but other users won’t see it
* WIKI
** (+) Works for everyone on the wiki
** (-) Everyone sees the change you make and you cannot validate it before making it
visible to all
** (-) Requires Admin rights and thus may not work
** (-) Fragile: If a user without admin rights resave the page it breaks it
* GLOBAL
** (+) Works for everyone on the farm
** (-) Everyone (including subwikis) sees the change you make and you cannot validate it
before making it visible to all
** (-) Requires PR and thus may not work.
** (-) Not very usable: For example will fail for local admins
** (-) Very fragile: If a user without PR resave the page it breaks it
** (-) Very fragile: If a local admin upgrades his wiki and a new version of the page is
available, then it breaks the feature
I’m still hesitating between USER and WIKI but I think USER is the best, at least until
we have dynamic defaults (in which case WIKI could be a good default, and if the user
doesn’t have Admin rights, then don’t allow him to save the page by having a verification
check + make USER the default if user doesn’t have Admin right).
Thanks
-Vincent
--
Thomas Mortagne
On 9 Feb 2018, at 18:15, Vincent Massol
<vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
6:26 p.m.
On 11 Feb 2018, at 08:43, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
For me what is good with ON DEMAND is exactly what you don't like
about ON DEMAND :)
* you don't pollute anyone when you save (same as USER)
* since you won't see the result right away you have to think about
scopes and which one you want. What made you send this mail in the
first place is people (and here it's core team devs so not really the
beginner contrib extension author kind) keeping the default GLOBAL
without really thinking about it because it was working for them and
the exact same thing will happen with USER until someone has to report
to them it does not work
Ok I undertand that but it’s going to be worse than before: nobody will make it work since
suddenly you increase the usability aspect by an order of magnitude.
And for me our focus has to be on usability. And especially usability for the person who
uses the feature the 1st time.
So ATM I’m still opposed to ONDEMAND which is 1) the hardest to use and 2) requires
scripting knowledge.
If you want to make the user choose a level voluntarily then we need to *not* have a
default selected and have validation to prevent user from saving without choosing a level.
Putting the most complex level by default is a bad idea IMO. We would also need some
help/hint on the page to describe the different levels since otherwise it doesn’t help to
not have a default.
I’m still of the opinion that we should one of the following:
A) Quickly (do it now before the next release)
- Revert the change done by Thomas ASAP (and before any release ofc)
- Move to USER to make it the default FTM, and be consistent across the board (we already
use USER for wiki Macros)
B) Later on (when someone has time to work on this)
- provide hints to explain the various visibilities and the conditions to use them
- have validation so that we check that the chosen visibility matches the user’s
permissions and use JavaScript to prevent saving the page is the level doesn’t match
permissions
- Display a warning when a visibility is selected to explain the limitation. For example
— For USER, mention that other users won’t see it
— For WIKI, mention that other subwikis won’t see it
— For ONDEMAND, mention that it requires scripting to explicity activate it
- Choose a default depending on the current user’s permissions:
— If current user is admin, choose WIKI by default
— If current user is not admin, choose USER by default
Thanks
-Vincent
On Sat, Feb 10, 2018 at 12:07 PM, Vincent Massol
<vincent(a)massol.net> wrote:
General pros of cons for visibility of any
component-based xobject (IMO):
* ONDEMAND
** (-) Hardest to use since it requires scripting. Lowest on usability score. Should be
reserved for very special use cases.
* USER
** (+) Safe since only the current user sees it
** (+) Usable since works OOB and for all users with any permissions
** (-) User may believe it works for everyone but other users won’t see it
* WIKI
** (+) Works for everyone on the wiki
** (-) Everyone sees the change you make and you cannot validate it before making it
visible to all
** (-) Requires Admin rights and thus may not work
** (-) Fragile: If a user without admin rights resave the page it breaks it
* GLOBAL
** (+) Works for everyone on the farm
** (-) Everyone (including subwikis) sees the change you make and you cannot validate it
before making it visible to all
** (-) Requires PR and thus may not work.
** (-) Not very usable: For example will fail for local admins
** (-) Very fragile: If a user without PR resave the page it breaks it
** (-) Very fragile: If a local admin upgrades his wiki and a new version of the page is
available, then it breaks the feature
I’m still hesitating between USER and WIKI but I think USER is the best, at least until
we have dynamic defaults (in which case WIKI could be a good default, and if the user
doesn’t have Admin rights, then don’t allow him to save the page by having a verification
check + make USER the default if user doesn’t have Admin right).
Thanks
-Vincent
--
Thomas Mortagne On 9 Feb 2018, at 18:15, Vincent Massol
<vincent(a)massol.net> wrote:
Hi,
Right now we have:
xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE,
"Scope",
"GLOBAL|WIKI|USER|ON_DEMAND”);
However for wiki macros for example we have:
xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1,
false,
"Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT,
PROPERTY_PIPE);
The rationale is that it’s safe to use USER first to try out and then to extend to Wiki
or Global if it’s working fine.
So I’d suggest to change the default visibility for wiki translations to USER and more
generally to do this for all component-based xobjects.
WDYT?
Thanks
-Vincent
2409
days inactive
2411
days old
6 comments
2 participants
participants (2)
-
Thomas Mortagne -
Vincent Massol