gerilife/companionship

Promoting companionship and well-being for everyone.

companionship's Issues

Add test-coverage report to continuous integration pipeline

We are currently using CodeClimate for quality review in our pull requests. CodeClimate can monitor test coverage if we configure our project correctly.

Task

• enable project test coverage auditing with coverage.py
• configure the necessary environment variable for CodeClimate "reporter ID" (done by. @brylie)
• follow the CodeClimate instructions for setting up GitHub Actions to generate a coverage report - with adaptations for Python

Example configuration

Something similar to the following may be all that is needed to enable test reporting in our project.

coverage:
    needs: [ test ]
    name: coverage
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - uses: actions/setup-python@master
      with:
        python-version: '3.10'
    - run: poetry install
    - run: coverage run -m pytest

Add Finnish localization

Since we are developing this project in Finland, we can start with the Finnish locale.

Task

• translate UI text into Finnish language
• if still disabled, enable the language select dropdown on the navigation menu

add EditorConfig

Task

• add a .editorconfig file to the root directory of this project with the following contents
• add a note to the CONTRIBUTING guide about configuring .editorconfig support for VSCode and PyCharm

# http://editorconfig.org
root = true
[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true
[*.py]
indent_size = 4

enable `watchman`

Consider adding Watchman and pywatchman to this project as optional developer dependencies. Make sure to update the CONTRIBUTING guide as necessary.

Extend Caregivers app

Add the following to the caregivers app, potentially as separate issues:

• specializations
• certifications
• location (to city-level granularity)

Add data export feature

Care coordinators may want to export data from their person-centric care groups. For the minimum-viable feature, we can allow a single care-group (Person) data to be exported.

Task

• determine how best to export all data related to a specific Person
  • activities with participants and all attributes
  • companions list
• add a data-export feature to the Person page creating an export in a common format

Hide "caregivers" app until it is more mature

The "caregivers" app is currently a work-in-progress. It should be hidden from normal users until it is ready for use.

configure mypy with django-stubs

Task

• add mypy support in this project with the command poetry add mypy --group dev
• add django-stubbs with the following command poetry add --group dev django-stubs[compatible-mypy]
• add the following configuration to our pyproject.toml
• depending on issue #92, enable mypy in our pre-commit settings

[tool.mypy]
plugins = ["mypy_django_plugin.main"]

[tool.django-stubs]
django_settings_module = "myproject.settings"

Add user profile

Add a user profile feature to allow people to set/change their first name and password. Consider removing the last name field for privacy. Consider whether to add avatar support (possibly as a subsequent feature).

iCal feed

Users may want to add the upcoming activities to their calendar. One common way to integrate event information into a calendar is the iCal format.

Task

• add an iCal feed for each Circle
• the URL should be circle/{ circle_id }/calendar.ical
• view should return a properly formatted ical feed

disable auto-named migrations

Task

• create a file project/core/management/commands/makemigrations.py with the following content

from django.core.management.base import CommandError
from django.core.management.commands.makemigrations import (
    Command as BaseCommand,
)


class Command(BaseCommand):
    def handle(self, *app_labels, name, dry_run, merge, **options):
        if name is None and not dry_run and not merge:
            raise CommandError("-n/--name is required.")
        
        super().handle(
            *app_labels,
            name=name,
            dry_run=dry_run,
            merge=merge,
            **options,
        )

Initial mobile notification app (Android and iOS with Flutter)

Related to #36

We want to create a minimum-viable notification app that runs on mobile devices (Android and iOS). The application should, at a minimum, display a notification text to remind the user of the tasks for which they are responsible. The notification should be scheduled and delivered on a timely basis. Notifications should be created by the "backend" app and somehow scheduled on or delivered to the mobile app.

Task

• research options for mobile notifications (using Flutter and related notification services)
• document the findings and choose an initial architecture
• create an initial Flutter app with example notification UI/UX (e.g. an app screen with a message and confirmation button)
• extend the Flutter app to support scheduled/overlay notifications
• develop the related backend notification architecture including integration with external service(s)
• integrate the Flutter app with the backend, making changes as necessary on both codebases

Ability to remove companions

Some companionship relationships may be temporary. As such, the care coordinator may need to remove existing companions.

Task

• allow care coordinators to remove existing companions from a person's page

Specification

• add a small "remove" button next to each companion on the person's page
• only organizers can see button/remove companions
• organizers cannot remove themselves
• "remove" button links to CompanionDeleteView, based on the Django generic View class-based view
• CompanionDeleteView takes only a post request
• CompanionDeleteView validates that user one of Person's organizers or throws NotAuthorized error
• after deleting companion, for authorized user, the CompanionDeleteView post method will redirect to the PersonDetailView for the relevant person

Example code

The following code snippets may be useful as examples related to this task.

Checking if request User is one of Person's organizers
https://github.com/GeriLife/companionship-care/blob/d7cdcdc1a37e5bd08f9c7b6a26a8116b9571ce5e/project/people/templates/people/person_detail.html#L104

Preventing a user from removing themself by checking equality (in our case, it should be !=)
https://github.com/GeriLife/companionship-care/blob/d7cdcdc1a37e5bd08f9c7b6a26a8116b9571ce5e/project/people/templates/people/person_activity.html#L70

Linking to a specific view, using the view name and optional arguments
https://github.com/GeriLife/companionship-care/blob/d7cdcdc1a37e5bd08f9c7b6a26a8116b9571ce5e/project/people/templates/people/person_detail.html#L130-L132

Ensuring only a Person's organizer can perform database operations related to that person
https://github.com/GeriLife/companionship-care/blob/d7cdcdc1a37e5bd08f9c7b6a26a8116b9571ce5e/project/people/views.py#L130-L137

Redirect to Person's detail view after removing the companion:
https://github.com/GeriLife/companionship-care/blob/d7cdcdc1a37e5bd08f9c7b6a26a8116b9571ce5e/project/people/views.py#L154

Automatically log in user when registering

Currently, when a user registers, they must then log in.

Context

While we are in an early stage of testing, we can make things as easy as possible for new users. Even as the project matures and we want to start validating emails, it may be nice for new users to automatically log in during an email validation grace period.

Proposed solution

When a user registers, automatically log them in.

Limit maximum number of Caring Circles to 1 per user (default)

In preparation for a tiered service offering, we will limit the maximum number of Caring Circles to 1 per user.

Acceptance criteria

• users can only create one Circle
  if a user has created a Circle:
• the "create circle" button will not be displayed on the Circles page
• the "create circle" view will redirect to a friendly page explaining the one Circle limit
• any related UI texts will be internationalized

Caregiver notifications (MVP)

We would like to send reminder notifications to caregivers so they remember the tasks they have agreed to take. These notifications can be:

• email
• text message
• mobile-app notification
• a combination of the above

Task

• determine which type(s) of notifications to support initially
• research how to implement the related notifications using Django and other related services
• document the desired design
• indicate which notification type(s) might be added later in the roadmap by creating relevant GitHub issue(s)
• implement the initial notifications

add `django-debug-toolbar`

Task

• install django-debug-toolbar with the command poetry add django-debug-toolbar --group dev
• follow the remaining installation instructions

Smooth invitation flow

Currently, when an unregistered user clicks an invitation link, they are prompted to register but are not redirected to apply for membership in the caring circle. Ideally, the application would automatically submit when a person registers or logs in with an invitation link. When a person is already logged in, the application would also be submitted.

TODO: consider whether the application should be auto-submitted or the user should click one more button to apply when viewing the application page.

add development fixtures

Task

• add factory_boy to this project with poetry add factory_boy --group dev
• define the initial factory_boy factories

Hide care group photo when not provided

By default, users can create care group profiles without uploading a profile image. When the image isn't provided, an empty box is displayed:

Task

• only display care group photo when one is provide
• optionally, display a generic placeholder when no photo is provided, for consistency

Consider using sequential ID with base64 encoded URLs for Person model/URLs

The Person model currently contains an id field which uses UUIDfor unique values. The reason UUID was chosen was so sequential IDs could be avoided in URLs. However, the UUID URLs are quite lengthy.

There may be a way to use the default, sequential ID field for users while adding Base64 encoding for URL parameter. The key functionality is that the URL should not be easy to guess from any given URL.

References

• https://dev.to/earthcomfy/django-reset-password-3k0l
• Similar to default auth URLs: https://docs.djangoproject.com/en/4.1/topics/auth/default/#using-the-views

Render fewer modal dialogues to Person Activity template

The Person Activity template currently renders several modal dialogues. This means that for each scheduled activity, there is a lot of repeated code. Rather, it would be better to instantiate the dialogue via JavaScript or somehow render a single instance of each relevant dialogue to which we can pass the necessary arguments.

• delete activity
• edit activity
• add activity participant

Task

• determine how to refine our use of Bootstrap modals, so there is at most one instance of each modal present on the Person Detail page
• remove the redundant code

Add remaining permissions for Activity views

There is currently only one view in the Activities app that uses permissions to verify user access. Add related permissions to the remaining views, using the UserPassesTestMixin as seen in the 'ActivitySetDoneView`.

Task

• Ensure that all views in the Activity app have appropriate permissions via the UserPassesTestMixin

Users should be redirected to People or their default Caring Circle upon login/register

People who log in and register may see a primarily empty front page. It would be more convenient if they were redirected to one of the following.

• "people" page when they can create more than one caring circle
• "add person" when they have not yet created a Caring Circle
• their default Caring Circle when they have created one and cannot create any more

After some more consideration, I think a solution would look like:

• anonymous user sees a welcome message on the home page (working now)
• redirect all users to the "people" page when logging in
• redirect users to "people" page when signing up
• if a user has not created a Caring Circle, they will see the button "add Person" or "Create Caring Circle"
• if a user is a member of a Caring Circle, it will be listed on the people page (working now)

Add DX improvements

The book Boost Your Django DX contains many improvements for healthy and fun Django project development.

Epic

Implement the following DX improvements

• #97
• #98
• #99
• #100
• #101
• #102
• #92
• #103
• #104
• #105
• #106

Add error page templates

We don't currently have error page templates. The default error pages are confusing and don't render in our site base template.

Task

• add error templates that render using our site base theme
• template message should be user friendly
• text should be internationalized

Resources(s)

• https://docs.djangoproject.com/en/4.1/ref/views/

Configure pre-commit and Pre-Commit CI for project

The pre-commit script can help enforce good code practices. Similarly, Pre-Commit CI can auto-check pre-commit rules on pull requests.

Task

• configure pre-commit for this project
• choose some useful hooks: https://pre-commit.com/hooks.html
  • black
  • isort
  • flake8
  • pyupgrade
  • django-upgrade
  • curlylint
  • dhjhtml
• optionally, consider enabling Pre-Commit CI on this repo

Resources

• https://pre-commit.com/
• https://github.com/asottile/pyupgrade
• https://pre-commit.ci/
• https://pycqa.github.io/isort/docs/configuration/pre-commit.html
• https://github.com/asottile/pyupgrade

Error when accepting an application

When a care coordinator accepts a caregiving membership application, the following error displays

'QuerySet' object has no attribute 'add'

Redirect user to "people" view on login

When logging in, users are currently redirected to the "home" page. Instead, we can redirect them to the "people" page to save a click.

Task

• change login view redirect to use "people" view

Companion invitations feature (MVP)

Once we have refactored the project to have Person and Companion models #16, we can add companion invitations. For the MVP, we should keep the invitation system very simple. We don't want to introduce any dependencies such as a mail service.

Rather, allow care coordinators to copy an invitation link that they can email to other companions. When a person clicks the invitation link, they need to be signed in and then can click an "apply" or "join" button. The care coordinator must also verify the companionship applications, to reduce the likelihood of abuse.

Task

• create companionship invitation feature

Set up CI to run tests on commits

We don't currently run any CI jobs to verify that commits pass tests, for example.

Task

• set up a GitHub action to run the following on commits
  • project tests
  • lint / formatting check (black and autopep8)

TODO:

• rename format pipeline to lint (since it is only checking lint)
• move autopep8 check from test pipeline to lint
• run pytest unit tests in test pipeline (since they are the actual tests)
• optional, add test coverage report #62

Alternatively

• rename format to lint_and_test with a useful alias like "Lint and test"
• move the autopep8 task to lint_and_test
• run python project/manage.py test in format_and_test as a job called test
• remove the separate test flow, since it contains redundant steps

At some point, we may look into more efficient use of these runners. For now, a single runner is fine, since they share dependencies.

Set up project localization

We want to support multiple languages. There are several steps we need to complete in order to enable project localization.

Task

• ensure all current templates/code have good internationalization coverage
  • templates
  • views
  • models
  • forms
• generate language file(s) for initially supported language(s)
• add a language chooser widget to the navigation menu
• Set up a project on POEditor so we can translate the UI texts for this project. Initial languages may include:
  • Finnish
  • Dutch?

Error when adding activity: Cannot resolve keyword 'companions' into field

When adding an activity, the following error displays

Cannot resolve keyword 'companions' into field. Choices are: activities, companions_through, display_name, email, groups, id, is_staff, is_superuser, join_requests, last_login, logentry, password, user_permissions

Add UI to allow group organizer to edit companion settings

The group organizer may need to edit companion settings, such as removing a temporary companion #28 or designating a companion as a care organizer.

Task

• add a "settings" UI for individual companion settings, including ending the companionship and promoting to organizer
• consider a modal dialogue that can be re-used across all companions on the person's page
• ensure only the organizer can access and save the settings

Add ability to change password

Currently, there is no way for users to change their password.

Task

• add a password change page
• add a link in the navigation menu to a "change password" page

When possible, move templates for the reset password flow to the registration directory

By convention, Django defines accounts templates in a registration directory. However, due seemingly to a bug, Django is not detecting templates in the registration directory, even when following the documented naming conventions:

https://code.djangoproject.com/ticket/34003

At some point if possible, try to move the templates for the Django default Auth views to a registration directory within project/accounts/templates

use `ipython` for dev shell

Task

• install IPython with the command poetry add ipython --group dev

add `django-browser-reload`

Task

• follow the installation instructions to enable django-browser-reload for this project

Add password-reset feature

Currently, if a user forgets their password they cannot request a password reset.

Task

• determine possible solutions for a password reset flow (email-based)
• choose the best solution given the known trade-offs
• implement the password reset feature

Change to a person-centric data model

Our data model currently defines a Group model, which represents a care group for a particular person. Rather than the Group model being the primary entity, it would align more with our conceptual model and vision to have a Person model be the central entity.

Task

• Replace the Group model with a Person model
• Replace the Member model with a Companion model
• ensure all functionality still works with the Person model
• ensure UI texts are updated to reflect the person-centric nature of the application

Dark theme

The default theme is quite bright on the eyes. It may be nice to provide an alternative dark theme.

Use either "care organizers" or "care coordinators" consistently

We are using "care organizers" and "care coordinators" interchangeably through the code and UI. Choose one form, "coordinator" or "organizer", and update the code so it is consistent throughout the app.

Allow users to set "display name" field during registration

The app currently sets a default value for the "display name" field. Rather than use the default value, it would be better if users could set their given name when registering for the app.

Only companions and coordinators should be able to view person/add activities

Currently, anyone with the link to a person's page can view the person's details and add events.

Task

• ensure only companions can view person page and add activities

Add "done" feature for activities

Currently, users have no way to indicate that an activity was completed, such as doing housework. The assumption is that all past activities were completed, but that may not be the case.

Task

• add a "done" feature to activities
• all activity coordinator or participants to mark the activity as done

Add comments feature

It would be useful for people to add comments to an activity.

enable Rich terminal output

Task

• add Rich to this project with the command poetry add rich --group dev
• follow the Rich configuration instructions
• add the following code to the LOGGING = {...} configuration in the project settings

"formatters": {
    "rich": {"datefmt": "[%X]"},
},

"console": {
    "class": "rich.logging.RichHandler",
    "filters": ["require_debug_true"],
    "formatter": "rich",
    "level": "DEBUG",
    "rich_tracebacks": True,
    "tracebacks_show_locals": True,
},

Add pagination to upcoming events list

The upcoming events list may grow to many items. A common pattern for long lists is to add pagination, allowing the user to view only a few items at a time.

Task

• determine whether pagination is the minimum-viable approach to limiting the number of upcoming events visible at any given time
• identify alternatives
• if suitable, implement pagination for the upcoming events list

Add `note` field to `Activity` model

Users may want to add a brief note to an activity, such as to provide a bit more information for participants. However, we should be careful about the amount ant type of information users are encouraged to store. Hence, the note field should be limited to around 50 characters and should warn the user about privacy concerns.

Task

• add note field to the Activity model (50 char max)
• add help text to the note field warning about privacy concerns

Ability to delete scheduled activities

Sometimes activities get cancelled for various reasons. Allow care coordinators to delete scheduled activities.