ILIAS-eLearning
Feature: Add Support of Push Notification to the notification component
@kergomard This feature adds a new setting to the users personal settings to provide OPT-IN handling of push notifications based on a user interaction. Please have a look at the changes within the UserService
Greetings, @iszmais
@chfsx i would like to add another HTTP StatusCode to the interface: 429 - Too many requests
This Code rarely appears on Web Push Notifications when they are "spammed". I would appreciate you approval on this addition.
Greetings, @iszmais
Hi @iszmais ! The additional status code is fine, thanks! I removed myself from the list of reviewers since I cannot review the whole PR.
@mjansenDatabay @kergomard
I finalized this PR and implemented the feedback as well as catches for browser-specific "oddness's". Please have a look and leave me some feedback or hopefully approval.
Greetings, @iszmais
(I have no idea why the pipeline is failing from a precondition and I could not reproduce this in any environment. I assume this is caused by the "reduced" pipeline processing and therefore of no concern)
@klees Could you have a look at the small changes made to "Init" to introduce a neutral service worker to ILIAS? I would highly appraciate your feedback and/or approval here.
Hi @iszmais ,
we'll need an event listener which handles the deletion of users.
Hi @iszmais,
I can sure have a look. I also have a question as a fellow dev: This is supposed to offer some service, if I understand correctly, to the rest of system. Is there any documentation for possible user of this service?
Kind regards!
@mjansenDatabay i added the missing event listener and your feedback. Pls have another look.
@klees The general possibilities of the service worker are documented in its API documentation (e.g. here). In general a service worker can provide a limited way to communicate with a user (meaning her/his hardware device) without the requirement of an active connection to the webserver via a website call etc. Through this the worker provides basic events to send messages to the device, to fetch data from it and to sync states. These events can be used for multiple occasions and are not restricted to any usecases beside legal obligations (concerning data security etc.).
In the current state the SW can only push messages of the type notification to the hardware device and handle clicks on such messages. But since its potential exceeds the notification purposes, and since a host is restricted to one service worker per scope we wanted to place it in a neutral environment to not imply any claim to it for the notifications.
Greetings, @iszmais
@klees Shortly: Yes, if you mean "expect" in an observational context and not as a requirement.
No developer is obliged to use the service worker. Outside the notification context this only provides an entrypoint on which other services can add their event-handling if it fits the conceptional purpose of their features. Since the service worker is an external component outside the scope of the server and client (or at least the part of the client we have access to) I assume its best approach is to be as plain as possible IMO.
Greetings, @iszmais
@iszmais Hallo Ingmar, wenn ich als Noobie-ILIAS Entwickler jetzt eine Push-Nachricht schicken lassen wollte, wenn z.B. bei einem Test ein Feedback gegeben wurde (also Nachricht an die Person, die das Feedback erhalten hat). Wo muss ich schauen, wie ich das korrekt umsetze? Schaue ich da in die Mozilla Doku?
Hi @iszmais,
I feel we are talking past each other. The title of this PR announces a "ILIAS Push Notification Service". Where can I find a documentation how I could use this service?
Kind regards!
@klees @dsstrassner Thank you for your further elaboration (I indeed thought you referring to services outside the notifications aka. extendability).
Notifications can be sent through the implementation of the PushProviderInterface and usage of such.
I added a more detailed section into the Readme.md of notifications to clarify that. But we will also provide some external "tutorials" in near future.
Greetings, @iszmais
Hi @iszmais ,
thanks for the latest changes. I have one addition.
Could you please add a minimal PRIVACY.md file to the Notifications component that outlines the user-related data being stored, exported, and (if applicable) deleted? I’m aware that the component currently doesn’t have a PRIVACY.md, but since this PR introduces a new database table referencing a usr_id, I recommend including the file now.
Best regards, Michael
@mjansenDatabay I added privacy informations concerning the push notifications. Pls have a look!
Sorry @iszmais that I missed the request for a review here!
Additionally I'm also sorry, that I cannot greenlight this right now. While working on Split-Up Standard Fields Table and Move to DataTable I came to the conclusion that all these settings are more of a mess than I had anticipated. Everybody seems to have added settings here however they wanted. I will need to get some structure into this. So I kindly ask you for a little bit of patience, I will work as quickly as I can and this is my current to do.
Best, @kergomard
Thank you @kergomard for your feedback.
Then I will postpone this for a while and await your response on the current state. I assume this will also affect the conceptual plan for UI Modifications of the FR, but I don't see any sense in adapting that now on a WIP concept. Therefore, I will leave a comment in the FR to postpone that too.
Please let me know as soon as the "new" User setting are ready for intgegrations!
Greetings, @iszmais
@kergomard Can you give a short update on your progress and, maybe, when we can assume to proceed here?
@kergomard Thank you for your refactoring!
Since the new approach on user settings does not require any approval from the authority i will remove you as an mandatory reviewer. Of course you are still invited to contribute your opinion and change requests on this if you want too!
Greetings, @iszmais
@mjansenDatabay @klees I refactored the user settings and update the documentation.
Please leave me some feedback and, hopefully, approval.
Greetings, @iszmais
Hi @klees
Thank you for your Feedback! I totally agree with your concerns about the JS integration. But yeah, this seems to be the best practice ATM to handle it (which doesn't mean it's a good practice...).
I can, however, spread a bit of hope that this particular issue will be tackled in the near future to provide a better entrance for "Non-PHP"-Data into ILIAS Workflow. (Keeping it vaguely here since this is still in preconception).
Greetings, @iszmais
@mjansenDatabay Thank you for your feedback, too!
I share your concerns that these topics should be tackled in the future. I'm sure that the implementation itself, even if not perfect at the moment, will support those improvements by portraying more specific use case to identify such an issue and will therefore help to take those issues to public to accelerate their resolvement process.
Greetings, @iszmais