jawrainey / gabberapi Goto Github PK

This may become annoying at scale, therefore we must also have an 'opt-out' feature for these specific emails. Alternatively, a nightly mid-day email could be fired to give you a summary of peoples contributions to your conversations.

When creating a project, it should be possible to upload an image, which will be used to represent the project visually within the mobile application.

Note: This enhancement is in relation to changes in GabberMobile#2.

When users register or a new participant is added (/upload), we must add details of the following as outlined in GabberMobile#12

1. Which National Society are they a member of?
2. Their role in the Red Cross Red Crescent
3. Their Gender
4. Their age

When creating a new account, we must accept the language chosen by the user, which will require validating that we support that language on the website and applications.

This requires creating a new top-level endpoint (/languages/) that returns the list of supported languages by language-code and their native language:

{
    'en': 'English',
    'it': 'Italiano'
}

Relates to Mobile#4 and Web#2

We currently use sendgrid to send emails, however, this requires hosting out templates on their service and emails are often flagged as SPAM. We should move to MailGun and use their REST API to send and receive emails to overcome these issues.

The project.upload POST endpoint (here should accept a new language argument and the database should have a new field that holds a pointer to the preferred language (in the new language table create in (#2)).

This will also require returning the spoken language code (e.g. en) for each session such that they can be filtered, etc.

Mobile and website users should be able to update their preferences (language, name, email, etc), which will require creating a new endpoint( PUT on /auth/me/).

All email content should be reviewed, simplified and update prior to being translated into the languages supported by Gabber. We can then send emails directly to users in their preferred language.

It's worthwhile to consider how we might also send the translated versions of the language should the user want to read it in English, for example, by having a link in the bottom of the mail: English | Español | Français

Blocked by #2 and #4

Gabber currently supports six languages, and chooses the language based on the preference of the users device. All mobile and web content is stored in string resources, however, as content about a project is dynamic, it does not currently change depending on language set, such as the users preferred language. To support such a change, we must remodel how projects and topics are stored and delivered through the API.

Storing

Currently, a project can have many topics (one-to-many), however, to support multiple languages we must abstract the project content (description, title, slug) and topics text to two other tables (as illustrated below); a project has many project_languages, and a project has many topic_languages.

project_languages

topic_languages

Output from API

Now we have changed how a project is represented, anywhere that returns a project must be revisited, and fundamental to this is creating and updating a project. This will require updating the ProjectSchema's to return all written content (title, description, topics) contained in a content dictionary where each item has a key representing by a language code (en, ru, it) that can be used to lookup the relevant content.

(The creation of this feature is blocked by #2 and will ensure Mobile#11 is possible)