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 <[email protected]> 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 <[email protected]> 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

On 11 Feb 2018, at 08:43, Thomas Mortagne <[email protected]> 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 <[email protected]> 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

...

On 9 Feb 2018, at 18:15, Vincent Massol <[email protected]> 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