XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI #2981

Sereza7 · 2024-03-13T12:51:24Z

Jira URL

https://jira.xwiki.org/browse/XWIKI-16216

Changes

Description

Added user preferences for most shortcuts
Added tests for this new feature
Only display view shortcuts in the preferences when the user can actually use them (usertype = advanced)

Clarifications

Some shortcuts are hard-coded, making it impossible to change them easily. They aren't supported in our documentation about changing shortcuts, so I made the choice to not include them in this solution either. They can be added later as an improvement :)
Tests don't check every single shortcut, but only the most important use cases on a couple of them.
For now, only a simple shortcut syntax is supported. I don't think it's essential to provide a way to input key combo shortcuts (such as x+x+x+a). However this could be an improvement implemented later on.
If this PR is merged as is, I'll create tickets for both improvements mentionned above.

Screenshots & Video

16216-demo.mp4

Side note: this video was taken before the last commit that fixed the title attribute on edit action buttons to match the shortcut value whatever the situation.

Executed Tests

Extensive manual tests (see video above).
Passed mvn clean install -f xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-profile/ -Pquality,integration-tests,docker
Passed regular builds for the various packages where there's changes.

Expected merging strategy

Prefers squash: Yes
Backport on branches:
- None, changes are pretty widespread and not the safest.

…ile UI * Added the parameters in the backend * Added a tab with some default content TODO: * Use the backend values when defining shortcuts e.g. in menus_content.vm * Add the template to view/edit the values of each options. Note that the organization in XWikiPreferencesDocumentInitializer.java can be used as a skeleton for the architecture of the section. * Add translation keys for all the fields * Add explanations and a link to xwiki.org doc in the template

…ile UI * Started using the backend values when defining shortcuts e.g. in menus_content.vm

…ile UI * Reverted the addition of a category

…ile UI * Updated preference sheet and translations

…ile UI * Removed unwanted changes from ImageIT * Moved the backend preferences from wiki administration to user preferences... * Added use of those preferences everywhere where we used some translations * Improved the template for the shortcut preferences

…ile UI * Updated some tests, not tested yet...

…ile UI * Improved and fixed tests

…ile UI * Fixed the developer shortcut to use the same kind of shortcut as others... highlighted a limitation of this system * Fixed a typo in translation key * Added a condition to display view shortcuts only when they are usable (user is advanced).

…ile UI * Fixed some translations

…ile UI * Fixed unwanted change

…ile UI * Updated tests TODO: Make sure the changeShortcutInformation test passes. The first one should be good

…ile UI * Updated tests

…ile UI * Updated a parameter name to fit the shortcut identifier * Matched the edit action button titles with their new shortcuts

…ile UI * Fixed code style and imports

michitux

I'm wondering if it wouldn't be better to introduce a script service or at least a Velocity macro to get a keyboard shortcut to avoid these many if/else statements in Velocity.

Regarding the translation keys, all of them start with "Key" even though some of them could clearly be several keys. I would try to find a more generic formulation for this.

For all keyboard shortcuts, the UI should display the default values both in view and edit mode, this would dramatically improve the usability and value of this UI.

I'm wondering if it really makes sense to introduce so many properties in the user class. Sure, it seems like the easiest solution for now, but it hardly scales if, e.g., an extension wants to add another keyboard shortcut that should be configurable. I wonder if it wouldn't make more sense to have one XObject per customized keyboard shortcut on the user profile and a management Java class that provides the list of available keyboard shortcuts and allows querying their values (both with/without user customization to display the global default that could also be customized through a custom translation document) and that provides a way to extend them.

Was there any proposal on the forum for this feature?

...m-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/macros.vm

...flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/docextra.vm

...-profile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/UserProfileTranslations.xml

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

…ile UI * Updated default translation value Co-authored-by: Michael Hamann <michael@content-space.de>

…ile UI * Fixed missing escaping

…ile UI * Refactored the way to get the shortcut values. * Tested the new velocity macro in all its application contexts, everything still works properly (there has been issues with newlines instead of an empty result. Moreover testing on a live distrib was a bit of a pain because of caching and javascript bundling).

Sereza7 · 2024-06-18T15:00:20Z

@michitux

I'm wondering if it wouldn't be better to introduce a script service or at least a Velocity macro to get a keyboard shortcut to avoid these many if/else statements in Velocity.

Done in d7fa7e1 👍

Regarding the translation keys, all of them start with "Key" even though some of them could clearly be several keys. I would try to find a more generic formulation for this.

I wanted to keep things simple in those descriptions, because there's a lot of them, and most of the important information to understand those would be repeated. This info is found in the hints for each section (see the video in the PR starting message).
IMO the issue with composite shortcut or key combo is that some people would understand that we rule out simple keys from there. Starting every hint with Simple or composite key combo is a bit too heavy for the improved clarity we get IMO.
The primary use case is still a simple keystroke, so I decided to go with Key.

For all keyboard shortcuts, the UI should display the default values both in view and edit mode, this would dramatically improve the usability and value of this UI.

It seems like we'd need to update/extend the form generation template on the user profile to do so. IMO it's not necessary for a first release of the feature but it'd be a nice improvement. If you're okay with leaving this out of this PR, I'll open a ticket to record this possible improvement.

I'm wondering if it really makes sense to introduce so many properties in the user class. Sure, it seems like the easiest solution for now, but it hardly scales if, e.g., an extension wants to add another keyboard shortcut that should be configurable. I wonder if it wouldn't make more sense to have one XObject per customized keyboard shortcut on the user profile and a management Java class that provides the list of available keyboard shortcuts and allows querying their values (both with/without user customization to display the global default that could also be customized through a custom translation document) and that provides a way to extend them.

I agree that it's not the best. I'd rather keep it simple for now and create a more complete/complex shortcut management system later if there's a need for it. Do you know of extensions that are out of the standard flavor that use shortcuts for common use cases?
Note that the main point of this PR is to improve the accessibility state of the standard flavor.

Was there any proposal on the forum for this feature?

There was https://forum.xwiki.org/t/shortcut-settings-position/14116 for the UI side of things.

…ile UI * Removed unrelated format changes

…ile UI * Added an indication for unbound shortcuts in the view mode

…ile UI * Added a margin between the hint and the list of shortcut preferences * Escaped characters for XML

Sereza7 · 2024-10-08T15:11:50Z

@tkrieck
Because we use regular text inputs, I changed a bit the look of the UI from the wireframe you shared. The view mode is way more compact (it was the default but I quite like it -- there's not much to do for the user here anyways). Here is a video to showcase how it's displayed on different screen sizes and zoom levels:
https://github.com/user-attachments/assets/397a988f-b5f2-4967-9a09-0a9c49576773

After this video I added a small change (margin between the xHint and the table for shortcuts). Here is the final look (100% zoom on a 2k screen):
Simple user view

Advanced user view

Advanced user edit

Does it look okay to you?

PS: Created https://jira.xwiki.org/browse/XWIKI-22558 to keep track of progress on the design improvements for the fields.

tkrieck · 2024-10-22T16:28:49Z

@Sereza7 Thank you very much for the changes. From viewing the final layout, we can improve it a little bit to make reading the page faster. Could please test three other changes?

Provide a line between fields. This way is easier for the eye to read the name of the command and follow the lines to its hotkey. Maybe you will need to space each line a little bit on view mode, otherwise it can look cramped. A rule of thumb you can follow for this is to make each line the same height on view and edit modes.
User bold text to separate sections ("Edit modes", "View Page Information", etc). This way, it is easier to scan the whole content and look for the section that might correlate with a given shortcut. Another alternative is to use the appropriate <H#>...</H#> tag.
Give the edit input a narrower size. When declaring sole keys (a, h, e...) the field is much bigger than it needs to be, but ofc we need to give it sufficient space to view a combination of keys also (alt+shift+e) so I guess a good compromise would be half of the size that you are currently using.

…ile UI * Improved performance of the shortcut preference retrieval

…ile UI * Improved preference UI mostly for the view mode.

Sereza7 · 2024-10-23T12:57:27Z

@tkrieck
Here's two quick screenshots of the updated UI at 100% zoom on a 2k monitor:

I wasn't sure what kind of line to go for. With the old colortheme variable as far as I can see (AFAICS) we don't have a very low contrast grey. I used a dashed line so that it wouldn't clutter the UI too much. I hard coded the height of the lines to be the exact same in view and edit mode.
👍 It's a bit tricky since this part of the UI uses a bold that's not standard for XWiki. I tried to strike a better balance, but now it's a bit more difficult to distinguish between h2 "Keyboard shortcut preferences" and h3s.
I went with 10em. It sounded correct to use it: 1em is the size of 1 character in the context of the block. 10em would fit 10 characters whatever the zoom level or user preferences.

All of those changes were brought in fbcd0f6

Sereza7 · 2024-10-23T12:59:27Z

Both presentation and performance questions have been answered, opening this PR back for reviews.

tkrieck · 2024-10-23T14:33:39Z

I wasn't sure what kind of line to go for. With the old colortheme variable as far as I can see (AFAICS) we don't have a very low contrast grey. I used a dashed line so that it wouldn't clutter the UI too much. I hard coded the height of the lines to be the exact same in view and edit mode.

Looks good to me, eventually we will need a very low contrast for these situations, but it can be left for future work.

👍 It's a bit tricky since this part of the UI uses a bold that's not standard for XWiki. I tried to strike a better balance, but now it's a bit more difficult to distinguish between h2 "Keyboard shortcut preferences" and h3s.

It is tricky indeed, you can leave it as it was then. For future work it would make sense to review the CSS of this whole UI. I can see it set its own custom CSS for the headings, I just don't know why.

I went with 10em. It sounded correct to use it: 1em is the size of 1 character in the context of the block. 10em would fit 10 characters whatever the zoom level or user preferences.

Em is about only the height of the font, as far as I know. On non-monospaced fonts, the width of each character will vary ("X" is wider than "I"). Unfortunately, we can't really predict the width of the user chosen font, so we have to eyeball it. https://fonts.google.com/knowledge/glossary/monospaced

…ile UI * Reverted the boldness changes

Sereza7 · 2024-10-23T14:50:34Z

Reverted the change on boldness of the subsection titles 👍

I can see it set its own custom CSS for the headings, I just don't know why.

It's a good example of technical debt :) It was a good change back when it was implemented, but it didn't get properly updated, and now we have abstract styles that do not match our current system and cause extra bugs.

...m-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/macros.vm

michitux

Much better regarding performance I think, just a few small comments.

michitux · 2024-10-25T14:34:04Z

...web/xwiki-platform-web-war/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js

+        'action_inline' : "$escapetool.javascript("#getShortcutValue('core.shortcuts.edit.backtoedit')")",
+        'action_save' : "$escapetool.javascript("#getShortcutValue('core.shortcuts.edit.save')")",
+        'action_propupdate' : "$escapetool.javascript("#getShortcutValue('core.shortcuts.edit.saveandview')")",
+        'action_saveandcontinue' : "$escapetool.javascript("#getShortcutValue('core.shortcuts.edit.saveandcontinue')")"


Just as a suggestion, I think it would be much easier to read if this used $escapetool.json() to serialize one big map from Velocity to a JSON object.

Somehow I just noticed when testing that the crtUser is not properly set when in the context of velocity evaluation of this script. The shortcuts are not properly set here since we use $crtUserDoc... Looking further into it.

My guess is that we need to make sure frequentlyUserDoc.vm is loaded even for this velocity template evaluation. I need to find the place responsible for evaluating this .js file.

Addressed the main topic of this comment and the bug I found in 150f1e6 👍

Note that the solution to the bug is the low level solution. It's not a solution to the fact that the frequentlyUsedDocs template is not in the context of $xwiki.jsfx.use.

Seems like this error I made could be related to https://jira.xwiki.org/browse/XWIKI-19455

michitux · 2024-10-25T14:34:38Z

...form-user-profile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserSheet.xml

+    justify-content: space-between;
+    align-items: center;
+    /* Keep the line large enough to fit an input in both view and edit mode. */
+    height: 38px;


Doesn't this clash with the idea that font size is variable?

Since this is a CSS file, I decided to hardcode this instead of relying on LESS variables.
Using LESS variables, it would have been quite a lot of operations to get this result:
max(@line-height-base*@font-size-base+ 2*@padding-base-vertical + 2*2 + 21 px, @input-height-base + 21 px)
We want to fit both the button and the input in Edit mode, that both use different variables for their height...

The only impact of defining this height is the min-height. With different sizes of font sizes:

Larger font sizes: the edit mode lines are larger than the view mode ones, in order to fit the large inputs.

Smaller font sizes: the input and buttons have more space around them in edit mode.

I changed the style to make it clearer that this is not an upper limit on the height of the lines. If the content is large, the line height will increase to fit this content :)

Those are very small drawbacks to hardcoding. I'd rather keep it hardcoded with a comment rather than spend time trying to get something to work with our current LESS and need to rework it soon.

Can't you use a height based on em?

michitux · 2024-10-25T14:39:22Z

...m-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/macros.vm

+ * @since 16.9.0-rc-1
+ *#
+#macro(getShortcutValue $translationKey)
+#set ($shortcutPreferenceObject = $xwiki.getDocument($xcontext.getUser()).getObject('XWiki.UserPreferenceShortcutsClass', 'translationKey', $translationKey))


While a script service could certainly make things a bit cleaner, the performance should indeed be okay that way. The clone happens only once this way the first time an object is accessed.

michitux · 2024-10-25T14:39:55Z

...lamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/shortcuts.vm

        developerShortcutsRestCall("${request.contextPath}/rest/currentuser/properties/usertype/next",
                "$escapetool.javascript($services.localization.render('core.shortcuts.developer.user.type.error'))");
-    }, {'type': shortcut.type.SEQUENCE, 'disable_in_input': true });
+    }, {'type': #if("$!xwiki.getDocument($xcontext.getUser()).getObject('XWiki.UserPreferenceShortcutsClass', 'translationKey', 'core.shortcuts.developer.user.type')"!='')shortcut.type.SIMPLE#{else}shortcut.type.SEQUENCE#end, 'disable_in_input': true });


Yes, as written above, this looks okay from a performance point of view.

tkrieck · 2024-10-25T16:16:18Z

It's a good example of technical debt :) It was a good change back when it was implemented, but it didn't get properly updated, and now we have abstract styles that do not match our current system and cause extra bugs.

I see, it will be nice to revisit these styles in the future. I will keep a tab on my notes about it. Thank you!

…ile UI * Fixed a bug caused by the recent change of the getShortcutValue macro in actionButtons.js. * Created the map of shortcuts directly in velocity and serialized it directly to JSON.

…ile UI * Updated the style to be a bit more specific

…ile UI * Updated comment

michitux

We're getting there, thank you for the updates! I think the big issues have been solved, there are just a few details left.

michitux · 2024-11-07T09:43:32Z

...flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/docextra.vm

@@ -155,8 +155,9 @@
        ## Override keyboard shortcut (if any)
        ##
        #if ($keyboardShortcutsEnabled && "$!extraShortcut" != "")


Is this condition still correct? It isn't possible to set a shortcut value if $extraShortcut is empty?

I updated this in ac1e5f6 👍
Thank you for noticing, the logic here was off.

michitux · 2024-11-07T09:44:33Z

...flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/docextra.vm

@@ -155,8 +155,9 @@
        ## Override keyboard shortcut (if any)
        ##
        #if ($keyboardShortcutsEnabled && "$!extraShortcut" != "")
-          shortcut.remove("$extraShortcut");
-          shortcut.add("$extraShortcut", function() { XWiki.displayDocExtra("${extraAnchor}", "${extraTemplate}", true); }, { 'disable_in_input':true });
+          #set ($extraShortcutWithUserPreferences = "#getShortcutValue($extraShortcut)")


Are you sure this is correct? From what I understand, #getShortcutValue expects a translation key but as this used directly in shortcut.remove, I assume that $extraShortcut is the actual shortcut and not a translation key. Did you verify this?

Thank you for noticing this 👍
I fixed this implementation in ac1e5f6

I tested this new version locally and it worked properly with unset shortcuts (empty) and regular edited values

michitux · 2024-11-07T09:51:43Z

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

+    #set ($value = $doc.getValue('value', $shortcutPreference))
+    #if ($isEdit)
+      &lt;input type="text" class="shortcutPreference" name="$escapedSelectId" id="$escapedSelectId" size="30"
+        data-translatekey="$translationKey"


I think we should use kebab case here, too, so data-translate-key. Note that in JavaScript, this nicely translates to element.dataset.translateKey, see the dataset documentation.

Wow, that's some nice QoL I wasn't aware of! :D

I'm not very knowledgeable on custom data fields, thanks for the help :)

In the javascript I wrote to leverage those custom data fields, I used JQuery.
I updated it to work with those new fields in 9b4344c

With a quick Ctrl+F on this PR's diff files, I checked that those were the only places where those custom properties for the inputs were used.

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

michitux · 2024-11-07T09:59:28Z

...form-user-profile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserSheet.xml

+/* Preferences */
+/* Shortcut preferences */
+span.xHint:has(+ ul.shortcut-list) {
+  margin-bottom: 10px;


Same as below, shouldn't this be based on font size/em?

michitux · 2024-11-07T10:02:31Z

...form-user-profile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserSheet.xml

+    justify-content: space-between;
+    align-items: center;
+    /* Keep the line large enough to fit an input in both view and edit mode. */
+    height: 38px;


Can't you use a height based on em?

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

michitux · 2024-11-07T10:07:37Z

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

+    &lt;label #if($isEdit)for="$escapedSelectId"#end&gt;$!escapetool.xml($services.localization.render($label))&lt;/label&gt;
+    #if ($services.localization.get($hintKey))
+      &lt;span id="$escapedHintId" class='xHint'&gt;$!escapetool.xml($services.localization.render($hintKey)) ##
+      $escapetool.xml($services.localization.render('userprofile.default')): $defaultValue##


We usually use the approach to follow best practices in new code without changing everything else. Now if this exact pattern is already used, I'm fine to keep it here.

michitux · 2024-11-07T10:39:20Z

...rofile/xwiki-platform-user-profile-ui/src/main/resources/XWiki/XWikiUserPreferencesSheet.xml

+        $.ajax({url: updateUrl,
+          type: "PUT",
+          data: data
+        });


It might be good to handle errors here and maybe also display a notification if the changes have been saved. Otherwise, users have no way to understand that there was an error saving the keyboard shortcuts. See, e.g.,

xwiki-platform/xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war/src/main/webapp/resources/uicomponents/edit/editableProperty.js

Lines 156 to 178 in 05f0ba0

// Show progress notification message.

var notification = new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.inprogress'],

'inprogress');

// Collect the submit data.

var editor = editableProperty.next('.editableProperty-viewer').next('.editableProperty-editor');

// Notify the others that we're about to save so that they have the chance to update the submit data.

editor.trigger('xwiki:actions:beforeSave');

var data = editor.find(':input').serializeArray();

data.push({name: 'language', value: xcontext.locale});

data.push({name: 'comment', value: 'Update property ' + editableProperty.data('property')});

data.push({name: 'minorEdit', value: true});

data.push({name: 'form_token', value: xcontext.form_token});

data.push({name: 'ajax', value: true});

data.push({name: 'objectPolicy', value: editableProperty.data('objectPolicy')});

// Make the request to save the property.

return Promise.resolve($.post(XWiki.currentDocument.getURL('save'), data)).then(() => {

editor.trigger('xwiki:document:saved');

notification.replace(new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.done'],

'done'));

}).catch(response => {

editor.trigger('xwiki:document:saveFailed');

notification.replace(new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.error'],

'error'));

for an example how this is handled in other places.

…ile UI * Fixed the extra tabs shortcuts implementation

…ile UI * Fixed the case on the custom data fields (velocity template and js>jquery that relies on it)

…ile UI * Added a space between the shortcut value and the `(Default)` hint that would be displayed next to it when it has the default value. Co-authored-by: Michael Hamann <michael@content-space.de>

…ile UI WIP

Sereza7 and others added 17 commits February 23, 2024 17:20

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

e540a4e

…ile UI * Started using the backend values when defining shortcuts e.g. in menus_content.vm

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

36df3bf

…ile UI * Reverted the addition of a category

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

48d8e87

…ile UI * Updated preference sheet and translations

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

84e0582

…ile UI * Updated some tests, not tested yet...

Merge branch 'xwiki:master' into XWIKI-16216

32ec4c0

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

37ab413

…ile UI * Improved and fixed tests

Merge branch 'xwiki:master' into XWIKI-16216

147e445

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

204252e

…ile UI * Fixed some translations

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

b2ba4c6

…ile UI * Fixed unwanted change

Merge branch 'xwiki:master' into XWIKI-16216

3e97dd9

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

d395e5d

…ile UI * Updated tests TODO: Make sure the changeShortcutInformation test passes. The first one should be good

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

bacc686

…ile UI * Updated tests

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

124df66

…ile UI * Updated a parameter name to fit the shortcut identifier * Matched the edit action button titles with their new shortcuts

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

a04cfbf

…ile UI * Fixed code style and imports

michitux requested changes Apr 15, 2024

View reviewed changes

Sereza7 and others added 2 commits April 16, 2024 11:51

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

84a9a1d

…ile UI * Updated default translation value Co-authored-by: Michael Hamann <michael@content-space.de>

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

9396c6c

…ile UI * Updated default translation value Co-authored-by: Michael Hamann <michael@content-space.de>

Sereza7 marked this pull request as draft April 19, 2024 08:23

Sereza7 and others added 5 commits April 22, 2024 18:03

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

72af963

…ile UI * Fixed missing escaping

Merge branch 'master' into XWIKI-16216

c894b16

Merge branch 'xwiki:master' into XWIKI-16216

9ee324b

Merge branch 'xwiki:master' into XWIKI-16216

8be9ead

Sereza7 marked this pull request as ready for review June 18, 2024 15:08

Sereza7 added 2 commits June 18, 2024 17:15

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

83be0b8

…ile UI * Removed unrelated format changes

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

3e0960c

…ile UI * Removed unrelated format changes

Sereza7 added 2 commits October 8, 2024 16:45

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

26dfb55

…ile UI * Added an indication for unbound shortcuts in the view mode

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

b67ddc1

…ile UI * Added a margin between the hint and the list of shortcut preferences * Escaped characters for XML

Sereza7 assigned michitux Oct 10, 2024

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

bbc63a0

…ile UI * Improved performance of the shortcut preference retrieval

Sereza7 requested a review from michitux October 23, 2024 10:07

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

fbcd0f6

…ile UI * Improved preference UI mostly for the view mode.

Sereza7 marked this pull request as ready for review October 23, 2024 12:59

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

031d727

…ile UI * Reverted the boldness changes

michitux reviewed Oct 25, 2024

View reviewed changes

...m-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/macros.vm Outdated Show resolved Hide resolved

michitux reviewed Oct 25, 2024

View reviewed changes

Sereza7 marked this pull request as draft October 25, 2024 15:51

Sereza7 added 4 commits October 29, 2024 09:43

Merge branch 'xwiki:master' into XWIKI-16216

2b2ac2e

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

150f1e6

…ile UI * Fixed a bug caused by the recent change of the getShortcutValue macro in actionButtons.js. * Created the map of shortcuts directly in velocity and serialized it directly to JSON.

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

72e7f89

…ile UI * Updated the style to be a bit more specific

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

90f8096

…ile UI * Updated comment

Sereza7 marked this pull request as ready for review October 29, 2024 15:49

michitux requested changes Nov 7, 2024

View reviewed changes

michitux reviewed Nov 7, 2024

View reviewed changes

Sereza7 and others added 4 commits November 8, 2024 17:16

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

ac1e5f6

…ile UI * Fixed the extra tabs shortcuts implementation

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

9b4344c

…ile UI * Fixed the case on the custom data fields (velocity template and js>jquery that relies on it)

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

53b57b4

…ile UI * Added a space between the shortcut value and the `(Default)` hint that would be displayed next to it when it has the default value. Co-authored-by: Michael Hamann <michael@content-space.de>

XWIKI-16216: Allow users to rebind the shortcuts from their user prof…

3edd13a

…ile UI WIP

Sereza7 marked this pull request as draft November 14, 2024 08:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI #2981

XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI #2981

Sereza7 commented Mar 13, 2024

michitux left a comment

Sereza7 commented Jun 18, 2024

Sereza7 commented Oct 8, 2024 •

edited

Loading

tkrieck commented Oct 22, 2024

Sereza7 commented Oct 23, 2024

Sereza7 commented Oct 23, 2024

tkrieck commented Oct 23, 2024

Sereza7 commented Oct 23, 2024

michitux left a comment

michitux Oct 25, 2024

Sereza7 Oct 29, 2024

Sereza7 Oct 29, 2024

Sereza7 Oct 31, 2024 •

edited

Loading

michitux Oct 25, 2024

Sereza7 Oct 29, 2024

michitux Nov 7, 2024

michitux Oct 25, 2024

michitux Oct 25, 2024

tkrieck commented Oct 25, 2024

michitux left a comment

michitux Nov 7, 2024

Sereza7 Nov 8, 2024

michitux Nov 7, 2024

Sereza7 Nov 8, 2024

michitux Nov 7, 2024

Sereza7 Nov 8, 2024

michitux Nov 7, 2024

michitux Nov 7, 2024

michitux Nov 7, 2024

michitux Nov 7, 2024

	// Show progress notification message.
	var notification = new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.inprogress'],
	'inprogress');
	// Collect the submit data.
	var editor = editableProperty.next('.editableProperty-viewer').next('.editableProperty-editor');
	// Notify the others that we're about to save so that they have the chance to update the submit data.
	editor.trigger('xwiki:actions:beforeSave');
	var data = editor.find(':input').serializeArray();
	data.push({name: 'language', value: xcontext.locale});
	data.push({name: 'comment', value: 'Update property ' + editableProperty.data('property')});
	data.push({name: 'minorEdit', value: true});
	data.push({name: 'form_token', value: xcontext.form_token});
	data.push({name: 'ajax', value: true});
	data.push({name: 'objectPolicy', value: editableProperty.data('objectPolicy')});
	// Make the request to save the property.
	return Promise.resolve($.post(XWiki.currentDocument.getURL('save'), data)).then(() => {
	editor.trigger('xwiki:document:saved');
	notification.replace(new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.done'],
	'done'));
	}).catch(response => {
	editor.trigger('xwiki:document:saveFailed');
	notification.replace(new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.error'],
	'error'));

XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI #2981

Are you sure you want to change the base?

XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI #2981

Conversation

Sereza7 commented Mar 13, 2024

Jira URL

Changes

Description

Clarifications

Screenshots & Video

Executed Tests

Expected merging strategy

michitux left a comment

Choose a reason for hiding this comment

Sereza7 commented Jun 18, 2024

Sereza7 commented Oct 8, 2024 • edited Loading

tkrieck commented Oct 22, 2024

Sereza7 commented Oct 23, 2024

Sereza7 commented Oct 23, 2024

tkrieck commented Oct 23, 2024

Sereza7 commented Oct 23, 2024

michitux left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sereza7 Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkrieck commented Oct 25, 2024

michitux left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sereza7 commented Oct 8, 2024 •

edited

Loading

Sereza7 Oct 31, 2024 •

edited

Loading