-
-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XWIKI-19751: Move the "watch" button for a page to the page content menu #3059
Conversation
Did we discuss the addition of a new menu in the page content? I'm asking since this will clutter the UI more (the top menu will still be there and the net effect would be the addition of a new menu), so we need to be careful. |
There's an open proposal on the forum for all this, but no conclusion yet. In any case this PR is a very preliminary draft: the UI will probably change but I need to see the possible actions to test and properly fix the APIs. |
3c17e9d
to
83d0716
Compare
...pi/src/main/java/org/xwiki/notifications/filters/internal/scope/ScopeNotificationFilter.java
Outdated
Show resolved
Hide resolved
33d607e
to
30a9cf9
Compare
76dad82
to
874aeec
Compare
...tform-notifications-ui/src/main/resources/XWiki/Notifications/Code/NotificationsWatchUIX.xml
Outdated
Show resolved
Hide resolved
...xwiki/notifications/filters/internal/scope/ScopeNotificationFilterLocationStateComputer.java
Show resolved
Hide resolved
...c/main/java/org/xwiki/notifications/filters/watch/script/NotificationWatchScriptService.java
Outdated
Show resolved
Hide resolved
...otifications-rest/src/main/java/org/xwiki/notifications/rest/NotificationsWatchResource.java
Outdated
Show resolved
Hide resolved
...t/src/main/java/org/xwiki/notifications/rest/internal/DefaultNotificationsWatchResource.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments primarily on the UI side. I think all translations deserve a closer look to make sure they're easy to understand and make sense for users.
...tform-notifications-ui/src/main/resources/XWiki/Notifications/Code/NotificationsWatchUIX.xml
Outdated
Show resolved
Hide resolved
...tform-notifications-ui/src/main/resources/XWiki/Notifications/Code/NotificationsWatchUIX.xml
Outdated
Show resolved
Hide resolved
#set ($ancestorRef = $ancestorFirstFilter.left) | ||
#set ($ancestorWatchStatus = $ancestorFirstFilter.right) | ||
#end | ||
## FIXME: the different icons should use the icon service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I haven't fixed this yet since I'm not yet 100% sure about the UI and I'd need to introduce new icons in the iconset for being able to use the icon service with current choice.
...tform-notifications-ui/src/main/resources/XWiki/Notifications/Code/NotificationsWatchUIX.xml
Outdated
Show resolved
Hide resolved
#set ($unblockWikiOption = "#_displayOption('unblock-wiki','unblockWiki','unblockwiki','world')") | ||
{{html clean='false'}} | ||
<div class="btn-group" id="watchButton"> | ||
<a href="#" role="button" title="$escapetool.xml($watchText)" class="btn btn-default" data-toggle="modal" data-target="#watchModal"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Buttons should use a button element unless there is a problem with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I reused some existing code for that one. I'll check.
{{html clean='false'}} | ||
<div class="btn-group" id="watchButton"> | ||
<a href="#" role="button" title="$escapetool.xml($watchText)" class="btn btn-default" data-toggle="modal" data-target="#watchModal"> | ||
<span class="fa $watchIcon"></span> $watchText |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The icon should use the icon theme.
...tform-notifications-ui/src/main/resources/XWiki/Notifications/Code/NotificationsWatchUIX.xml
Outdated
Show resolved
Hide resolved
...xwiki-platform-notifications-ui/src/main/resources/XWiki/Notifications/Code/Translations.xml
Outdated
Show resolved
Hide resolved
Regarding the screenshots, I'm wondering if it is really a good idea to explain the options only after selecting them. Also, "that option" sounds strange to me, why not "this option"? Further, why is there no radio button to just not follow the page/use the inherited settings? |
14dd01c
to
4059370
Compare
...-filters-watch/src/main/java/org/xwiki/notifications/filters/watch/WatchedUserReference.java
Outdated
Show resolved
Hide resolved
43f9dea
to
285014f
Compare
Work in progress: remove UI code for watch switch buttons, and start introducing a new UIX for the watch button next to the edit button. Start refactoring API for computing if a page is watched or not to get all info.
* Fix some tests in notification filters
* Start providing REST API for watch pages to simplify operations
* Distinguish more cases for watched / ignored pages to improve UI
* Provide implementation for REST API for watching pages * Improve WatchEntitiesManager API to support more operations * Improve WatchedEntityReference API to use UserReference
* Provide a dedicated page to handle watch settings * Start writing javascript code to handle choices
* Fix issue in WatchedEntitiesManager * Start providing doc / fixing checkstyle * Handle a bit more actions in UI
* Fix a bug in state computer related to the fact that the scoe filter hierarchy is not really a hierarchy * Provide a new API to allow computing the reference of the immediate ancestor of a page for which a filter exists * Improve UI to base possible actions on multiple criteria: current watch status, presence or not of a filter on an ancestor, and check if the page is terminal or not
* Encode all options for the watch settings modal
* Change the URL scheme for the REST API
* Minor improvments
* Provide test for notification rest module
* Put revapi ignores * Start fixing since
* Provide translations and improve UIX code
* Provide page object and fix integration tests
* Ensure to not display the watch status for guest
* Fix a few since and some problems in UIX
* Fix API of WatchedUserReference
* Fix bad escaping
* Better exception handling for creating references * Various improvments in translations (active voice + use of ignore) * Improve a bit the UI
* Improve UI when a page is ignored/followed by an ancestor and check proper rights
* Review available options and improve javascript to allow chaining operations: following space when the page is followed implies to first unfollow the page to not keep unnecessary filters and mess up the UI * Improve translations
* Clean up some unnecessary code
* Make the UI a bit more clear
* Fix some stuff after rebsae
* Slightly improve UX
2b0c10e
to
390cb98
Compare
...xwiki/notifications/filters/internal/scope/ScopeNotificationFilterLocationStateComputer.java
Show resolved
Hide resolved
* | ||
* @since 15.9RC1 | ||
*/ | ||
NOT_SET(false, false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No unstable there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm there's a wrong since on this one I have been fooled because of it I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bad copy/paste it seems I'll fix that.
...ters-watch/src/main/java/org/xwiki/notifications/filters/watch/WatchedLocationReference.java
Outdated
Show resolved
Hide resolved
...ilters-watch/src/main/java/org/xwiki/notifications/filters/watch/WatchedEntityReference.java
Show resolved
Hide resolved
...c/main/java/org/xwiki/notifications/filters/watch/script/NotificationWatchScriptService.java
Show resolved
Hide resolved
* Fix missing unstable * Fix bad deprecated API call
Jira URL
https://jira.xwiki.org/browse/XWIKI-19751
Changes
Description
Goal of this PR is to simplify usage of the watch page feature.
It comes with important changes:
Clarifications
First important changes to review in that PR are the breaking API: they're emphasized in the revapi ignores I added. Most of them are about unstable APIs, but one of them is a real breakage I opened a brainstorming on the forum about it and I'd like feedbacks about it.
Next important change to review is the new APIs I provide:
Then only in the end the UI should be reviewed: first thing to review about the UI is the logic of the different choices available in the modal. We can easily change later where we put the button and which vocabulary we use, but if there's a flaw in the logic it's more difficult to change later at it will probably impacts the API.
Screenshots & Video
Capture.video.du.07-06-2024.10.43.38.webm
Executed Tests
Ran:
xwiki-platform-notifications
:mvn clean install -Pquality,integration-tests,docker
xwiki-platform-legacy-notifications
:mvn clean install -Pquality
Expected merging strategy