codeforpdx / dwellinglybackend

Application for property managers to communicate with social workers

Dwellingly App Backend

Looking for the Dwellingly App front end?

Archived:

Thank you to everyone who has put in time and effort in building the backend API for the JOIN (Dwellingly) application. This repo is being archived in preference to have the backend code and frontend code combined into one application/repository. Please go to https://github.com/codeforpdx/dwellingly-app for the dwellingly application.

Description

The nonprofit Join is currently working to help transition people out of homelessness. However, their current system for staying in touch with landlords is currently inadequate. Code for PDX is building the Dwellingly app in conjuntion with Join Organization. Dwellingly will aid property managers in communicating with social workers, and will eventually aid in supporting both tenants and landlords with a more streamlined rental property process.

This app aims to replace the current system with a robust ticketing system to ensure the staff at Join can connect with their landlords and clients seamlessly. This will allow Join to provide support and improve success in transitioning people out of homelessness.

UI Preview

Dwellingly is being built from these FIGMA designs

Specs

The backend is being built with Python, Flask and SQLAlchemy. The frontend is built with React.

Contributing

• Please read and abide by our Code of Conduct

• To learn about our workflow, app architecture, and how to install the project for development. View the CONTRIBUTING.MD doc.

• To learn about how to get a JWT token, use the API for development, and about all our endpoints, please see our API Usage page. (Warning: endpoint info may be out of date)

Contributors

Thank You contributors. No contribution is too small.

I plan to setup the contributor bot to auto add to this. We can also manually add for contributors who contribute in other ways.

About Us

• Code for PDX - Meetup Info
• Code for America
• JOIN Organization

dwellinglybackend's Issues

Adjust user model to include properties for Property Managers

Expected Behavior
When GET /user/:id is called for a Property Manager, the properties they manage and the tenants that belong to those properties should be returned

pseudo-code from Hugh on how to accomplish this:

if role == "PROPERTY MANAGER":
 return user.json w/ properties

Fix tenant archiving logic

Archiving a tenant should NOT be on a toggle switch. When the frontend hits the API with a request it should be deterministic. Currently the backend logic is written in a way that it expects the frontend to know the state of the backend. The update (PUT) action could handle this, but then the return message will be different.

To keep the response the same the delete method should be deleted/modified and replaced with deterministic logic. I believe there are a few different ways this could be done, but basically we want the frontend to be able to make a request and know for certain that they are archiving a tenant even if the tenant is already archived, as it is now they could inadvertently unarchive a tenant when they want to archive a tenant.

Whoever picks this up, Let me know what implementation you think is a good option and we can discuss, or if you need me to provide a couple different options then I can do that too.

Separate Tenant resource out into two separate classes

Endpoints that require an id should be in the class Tenant For example the update and get action
Endpoints that do not require an id should be in the class Tenants for example the POST and GET action

See the app.py file for other resources that follow this style. The actual routes and behavior will not change. Only the code organization. So this is more of a refactor which will remove the conditional in the get action when its done.