[FEATURE] Adds option to send update messages to users

[TiBiBa]

First, provide a one line summary of your changes in the Title of the PR

Now fill out the remainder of this template by replacing all italic content

Description

Changes in detail

For example: "Adds translations of levels 1 to 12 to Polish" (note the use of present tense!)

Fixes This PR fixes #3001.

How to test

• If this is a UI change: describe how to run your code to see it in action. See this https://github.com/Felienne/hedy/pull/880#issue-1016304308 for an example
• If this is a language change: add a few tests showing the difference

Checklist Done? Check if you have it all in place using this list:*

• [ ] Describes changes in the format above (present tense)
• [ ] Links to an existing issue or discussion
• [ ] Has a "How to test" section

If you're unsure about any of these, don't hesitate to ask. We're here to help!

[Felienne]

Hi @TiBiBa!

What is the state of this one, it is a lot behind now of course, do we want to pursue this one or make a new one (or give up on this idea for now?)

[TiBiBa]

Hi @TiBiBa!

What is the state of this one, it is a lot behind now of course, do we want to pursue this one or make a new one (or give up on this idea for now?)

Missed this one! I like the idea of us being able to push some exciting updates to users, but we should have a clear scope before I start working on this. We current support class invitations (I do think they are not used that much though). We can implement something similar, but on a new table messages. But how do we want to efficiently handle the user interaction? Two possible solutions:

Easy options

• Store all messages in the new messages table
• Add a new attribute to the user profile called messages as well
  • Let this attribute contain a set of ids of the unread messages
  • When read -> remove from set
  • Big downside is that we have to update all users when we sent a message

Safer option

• Create two new tables messages and interactions
• On messages store the actual messages
• On interactions store a message id-username combination and a read attribute
• When a user calls their profile -> also get their messages
• Much safer as we only handle the interactions table when updating / reading

The safer solution would look a bit like this:

"messages" {
  "id": 1,
  "message": "This is a test message",
  "timestamp": "12345678"
}

"interactions" {
  "id": 12345,
  "message_id": 1,
  "username": "tibiba",
  "read": False
}

Then we can make the interactions table with index key username and sort key read. We do, of course, want the messages to be received by the user in chronological order as well. We might have to keep track of two timestamps or simply sort them by message id if we give these an incrementing value.

[Felienne]

Missed this one! I like the idea of us being able to push some exciting updates to users, but we should have a clear scope before I start working on this. We current support class invitations (I do think they are not used that much though).

Probably because they stem from before teachers could create accounts?

We can implement something similar, but on a new table messages. But how do we want to efficiently handle the user interaction? Two possible solutions:

Easy options

• Store all messages in the new messages table

• Add a new attribute to the user profile called messages as well

  • Let this attribute contain a set of ids of the unread messages
  • When read -> remove from set
  • Big downside is that we have to update all users when we sent a message

Safer option

• Create two new tables messages and interactions
• On messages store the actual messages
• On interactions store a message id-username combination and a read attribute
• When a user calls their profile -> also get their messages
• Much safer as we only handle the interactions table when updating / reading

Safer option seems better indeed! Will that be a lot of work?

[TiBiBa]

Safer option seems better indeed! Will that be a lot of work?

Should be do-able today I think! We do have to think about the message retrieval as make a db call on each request is a bit server heavy. Maybe only check for new messages on login and when loading the my-profile page? We also have to make some changes to the database structure. And another big bottleneck:

• When sending a message we have to make an interaction entry for each user. But as we can't load all users at once (as we are still struggling with #2994) this has to have some work around. Also: do we only want to support global messages send by the admin or also, for example, class messages?

[TiBiBa]

This also still doesn't allow us to localize messages. We first have to add some layer to enable contributors to translated them and then sent the message to the end-users. Should all be possible, but might be quite some work.

[Felienne]

This also still doesn't allow us to localize messages. We first have to add some layer to enable contributors to translated them and then sent the message to the end-users. Should all be possible, but might be quite some work.

Ah good point! Not sure that is feasible though, if we want to push info about a new feature we can't wait for all languages to be updated. Can we do it with gettext, so we can add En and Nl?

[Felienne]

• When sending a message we have to make an interaction entry for each user. But as we can't load all users at once (as we are still struggling with [PERFORMANCE] Change users table structure to enable pagination and filtering #2994) this has to have some work around. Also: do we only want to support global messages send by the admin or also, for example, class messages?

Maybe this is naive but can't we check on login and add a record in interactions when someone has seen it (rather than when they have seen it)?

[TiBiBa]

• When sending a message we have to make an interaction entry for each user. But as we can't load all users at once (as we are still struggling with [PERFORMANCE] Change users table structure to enable pagination and filtering #2994) this has to have some work around. Also: do we only want to support global messages send by the admin or also, for example, class messages?

Maybe this is naive but can't we check on login and add a record in interactions when someone has seen it (rather than when they have seen it)?

This is also possible! But only when we aim on supporting global messages, otherwise we wouldn't know what message is aimed for what user. We do have some increase in database call in this scenario:

• Retrieve all messages
• Retrieve all interactions from the current user
• If there is a message without an interaction entry -> show

[Felienne]

This is also possible! But only when we aim on supporting global messages, otherwise we wouldn't know what message is aimed for what user.

I think that is ok, it is meant for us to notify users of new features. Teachers have enough ways of reaching their students. Maybe we can differentiate one thing: between messages for normal users and those for teacher users (or for both)

We do have some increase in database call in this scenario:

• Retrieve all messages
• Retrieve all interactions from the current user
• If there is a message without an interaction entry -> show

That is ok I think if it just happens as login

[TiBiBa]

Getting there...