Skip to content
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

System Wide Notify (e.g. admin to user messages) #19152

Closed
MTRichards opened this issue Sep 18, 2015 · 21 comments
Closed

System Wide Notify (e.g. admin to user messages) #19152

MTRichards opened this issue Sep 18, 2015 · 21 comments
Labels
feature:notifications overview p2-high Escalation, on top of current planning, release blocker
Milestone

Comments

@MTRichards
Copy link
Contributor

Push System Notifications: As an admin, I want to be able to send out notifications of system wide messages from the ownCloud admin window, so that I can inform users of this information
Acceptance Criteria

  • Notifications are shown in the top of the web interface until user clicks ok button
  • If a response is required, (future versions) the buttons appear for a response
  • In the future, apps can be written to tabulate and track responses to notifications
  • Notifications should appear in the desktop and mobile clients as well, with the same accept (and in the future yes/no) functionality
  • an API is needed to send notifications to (and receive responses from)clients

Much of this should be in 8.2, but this may require a little polish to get it working (?).

@MTRichards MTRichards added this to the 9.0-next milestone Sep 18, 2015
@PVince81
Copy link
Contributor

PVince81 commented Oct 5, 2015

@nickvergessen @cmonteroluque

@MTRichards MTRichards changed the title System Wide Push Notify (e.g. admin to user messages) System Wide Notify (e.g. admin to user messages) Oct 5, 2015
@MTRichards
Copy link
Contributor Author

To clear up a few things:

  • Changed title to reflect not a push, it isn't really a push, it is a pull.
  • The acceptance criteria was modified to have notifications and responses both for 9.0.

Add to acceptance criteria:

  • Every use has their own notification list - from one user to one user; apps implement this
  • Admin notification can be done one to many, but is essentially flattened to one to one
  • Need to migrate API to the OCS API in the app
  • It is an app, it can be disabled - if it is disabled, notifications don't work, but the system still functions
  • Need to add a sequence ID to the API for getting a result
  • There is no expiration or state for notifications
  • Can't do mobile or desktop until OCS API is needed
  • Callback URLs are used for the client/mobile responses
  • Tracking and tabulation or action based on the result of a notification must be done on an app by app basis (for example, accepting a share would use a callback URL that accepted the share, but that is handled in the sharing app)

@nickvergessen nickvergessen self-assigned this Oct 5, 2015
@PVince81
Copy link
Contributor

Okay, so this one is for system-wide messages, and I just found this other ticket #16772 for user messages

@nickvergessen
Copy link
Contributor

  • Notifications are shown in the top of the web interface until user clicks ok button
  • If a response is required, (future versions) the buttons appear for a response
  • Notifications should appear in the desktop and mobile clients as well, with the same accept (and in the future yes/no) functionality
  • an API is needed to send notifications to (and receive responses from)clients
  • Every use has their own notification list - from one user to one user; apps implement this
  • Need to migrate API to the OCS API in the app
  • It is an app, it can be disabled - if it is disabled, notifications don't work, but the system still functions
  • Need to add a sequence ID to the API for getting a result => only required for syncing, different approach is implemented.
  • There is no expiration or state for notifications

Done with notifications app

  • Admin notification can be done one to many, but is essentially flattened to one to one

There is an community app for this: https://github.com/nickv-oc/announcementcenter

  • In the future, apps can be written to tabulate and track responses to notifications
  • Callback URLs are used for the client/mobile responses
  • Tracking and tabulation or action based on the result of a notification must be done on an app by app basis (for example, accepting a share would use a callback URL that accepted the share, but that is handled in the sharing app)

This is the task of each app adding a notification.

Therefore I'd say this issue is "completed" and can be closed?
@MTRichards @DeepDiver1975 @PVince81

@PVince81
Copy link
Contributor

PVince81 commented Dec 1, 2015

We need a decision regarding the community app from @nickvergessen that fulfils the requirements @cmonteroluque @karlitschek @MTRichards.

@karlitschek
Copy link
Contributor

So what exactly do we need to decide? :-)
It is super AWESOME that @nickvergessen did this app. And I think it does what we want.
Moving it into the owncloud github organisation would be nice but this is the decision of @nickvergessen of course.
So what exactly is the question? ;-)

@PVince81
Copy link
Contributor

PVince81 commented Dec 1, 2015

The question is whether we want to bundle this app (and then move it or fork it into the orga repo) or whether we tell people to go to the app store and install it themselves.

@MTRichards @karlitschek

@ghost
Copy link

ghost commented Dec 1, 2015

@PVince81 @karlitschek @MTRichards @nickvergessen This is in the roadmap and the plan for 9.0. The decision to bundle it, I thought, was already done when we added it to the release (yes, we do), or I thought so!

@MTRichards
Copy link
Contributor Author

Concur @cmonteroluque Bundle it.

@nickvergessen
Copy link
Contributor

I'm fine with bundling the app from my repo

@karlitschek
Copy link
Contributor

That's not so easy guys. EE vs. community. Also the strategic decission to not make our releases bigger but distribute apps via app store. We have to talk about this.

@MTRichards
Copy link
Contributor Author

Perhaps we need to clarify what we mean by bundling.

I was thinking we treat it like the anti-virus app, which is in the app store for CE, and in the package for EE.

@karlitschek
Copy link
Contributor

Yes. We should do it like that. separate repo in the ownCloud organization. Releases as app on app store for server. Include it into the EE packages same as antivirus.

@ghost
Copy link

ghost commented Dec 2, 2015

OK, that makes sense to me. I thought it would be included into at least the EE.

@PVince81 PVince81 added the p2-high Escalation, on top of current planning, release blocker label Dec 11, 2015
@PVince81
Copy link
Contributor

PVince81 commented Jan 8, 2016

From what I see the repo has been created here: https://github.com/owncloud/announcementcenter

The response part is a separate ticket owncloud/announcementcenter#9 and as I understand was specified as "future", so something for 9.1 ?
This is likely non-trivial because it needs a DB table or such to keep track of user responses.

  • make sure the app is bundled in CE/EE (?)

@MTRichards
Copy link
Contributor Author

Responses are a future (so the 2-way communication is future) but the 1 way push of a message to desktop clients, that is intended for 9.0.

@PVince81
Copy link
Contributor

PVince81 commented Jan 8, 2016

@nickvergessen can you link the ticket about the OCS Notification API (if applicable), I can't seem to find it. Or is the API ready already ? (can't remember, sorry)

@nickvergessen
Copy link
Contributor

It's ready since early november

@nickvergessen
Copy link
Contributor

And by that I mean, the server part. Desktop and mobile clients don't check the endpoint yet, from my understanding.

@nickvergessen nickvergessen removed their assignment Jan 11, 2016
@PVince81
Copy link
Contributor

Raised https://github.com/owncloud/enterprise/issues/1090 for bundling

@lock
Copy link

lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature:notifications overview p2-high Escalation, on top of current planning, release blocker
Projects
None yet
Development

No branches or pull requests

4 participants