This project forked from hackforla/peopledepot
A project to setup a datastore for people and projects at HackforLA
Home Page: https://fyliu.github.io/peopledepot/
License: GNU General Public License v2.0
![pre-commit-ci[bot] avatar](https://avatars.githubusercontent.com/in/68672?v=4 "pre-commit-ci[bot]")
We need to update the event table model in django to utilize the practice area table instead of the outdated role table.
The old model issues for this table are
JSON Example:
[
{
practice_area: engineering,
permission_level: practiceLeadProject
},
{
practice_area: pm,
permission_level: practiceLeadProject
}
]
Practice Areas:
Permission Types:
We need to create the [name of table] table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.
A table and a model are the same thing
A table and a model are the same thing
No response
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
Adjust pre-commit settings to resolve some issues
we should unignore this when mdformat does the right thing
set pre-commit.ci to run quarterly from weekly because weekly is too often to update syntax checkers
After changes are made for issues posted by me the API and Cognito implementation documentation needs to be updated
We need to update the event table model in django to utilize the practice area table instead of the outdated role table.
The old model issues for this table are
JSON Example:
[
{
practice_area: engineering,
permission_level: practiceLeadProject
},
{
practice_area: pm,
permission_level: practiceLeadProject
}
]
Practice Areas:
Permission Types:
We need to add documentation for the github actions being used in this repo for the benefit of developers and maintainers so that they can understand how to read the results in the Actions page.
What to include in the documentation
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
We need to create the [name of table] table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.
A table and a model are the same thing
No response
Copied from spreadsheet and checked off according to ERD. Data fields are bolded and relation fields are not. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Copied from spreadsheet and checked off according to ERD (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
We are planning on including row and field-level security for tables. The required permissions need to be tested before implementation. Row and field level READ privileges for certain fields and roles will be implemented to prove feasibility.
| name | test case | requirement |
|---|---|---|
| globalAdmin | Can view and update all user info for all users, can create new users, and can de-activate users | .Can CRUD anything |
| adminProject | Can view and update all user info for users assigned to the project. Can not view users not related to a project which they are assigned. Cannot update users for projects for which they are not a project admin | Can Read and Update anything related to their assigned project |
| memberProject | Can read basic user info for users on the same project. Cannot update information. | Can Read anything related to their project that is visible |
We need better contributing docs so that contributors know what to do and what to expect
hackforla/peopledepot/mainhackforla/peopledepot/main should be runnable.
hackforla/peopledepot/main branch linear, the acceptable PR merging methods are rebase and squash. This means:
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
We need to add seed data for the Permission Type table, because it won't be changing, it's the same for all users of people depot and the information is public
We need to create the role table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.
A table and a model are the same thing
Dictionary of roles
Copied from spreadsheet and checked off according to ERD. Data fields are bolded and relation fields are not. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Copied from spreadsheet and checked off according to ERD (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
We need to create the [name of table] table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.
A table and a model are the same thing
A table and a model are the same thing
No response
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
We need to create an explanation page for the project directory structure so that new devs can understand where everything is and should go.
project_structure.md and lay out and explain the project structureAll the project files (some project-specific content omitted)
├── app
│ ├── core
│ │ ├── admin.py
│ │ ├── api
│ │ │ ├── permissions.py
│ │ │ ├── serializers.py
│ │ │ ├── urls.py
│ │ │ └── views.py
│ │ ├── apps.py
│ │ ├── initial_data/
│ │ ├── migrations
│ │ │ ├── 0001_initial.py
│ │ │ ├── ...
│ │ │ └── max_migration.txt
│ │ ├── models.py
│ │ ├── scripts/
│ │ ├── tests
│ │ │ ├── conftest.py
│ │ │ ├── test_api.py
│ │ │ ├── test_models.py
│ │ │ └── test_permissions.py
│ │ └── utils
│ │ └── jwt.py
│ ├── data
│ │ └── migrations
│ │ ├── ...
│ │ └── max_migration.txt
│ ├── Dockerfile
│ ├── entrypoint.sh
│ ├── erd.png
│ ├── manage.py
│ ├── peopledepot
│ │ ├── asgi.py
│ │ ├── settings.py
│ │ ├── urls.py
│ │ └── wsgi.py
│ ├── requirements.in
│ ├── requirements.txt
│ ├── scripts
│ │ └── convert.py
│ ├── setup.cfg
│ └── tmp.md
├── CONTRIBUTING.md
├── docker-compose.yml
├── docs/
├── LICENSE
├── mkdocs.yml
├── pyproject.toml
├── README.md
└── scripts
├── buildrun.sh
├── check-migrations.sh
├── createsuperuser.sh
├── db.sh
├── erd.sh
├── lint.sh
├── loadenv.sh
├── logs.sh
├── migrate.sh
├── precommit-check.sh
├── run.sh
├── start-local.sh
├── test.sh
└── update-dependencies.sh
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
As an administrator I want to be able to log into People Depot using my SSO account so I don't have to remember the People Depot username and password.
After changes are made for issues posted by me the API and Cognito implementation documentation needs to be updated
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
We need a place for new project team members to annotate their questions so that we can answer them in writing and then update the wiki
questionWe need better contributing docs so that contributors know what to do and what to expect
hackforla/peopledepot/mainhackforla/peopledepot/main should be runnable.
hackforla/peopledepot/main branch linear, the acceptable PR merging methods are rebase and squash. This means:
We should rename the sponsor_partner table to something like affiliate. And the project_sponsor_partner_xref table to affiliation or similar. This would simplify and clarify the ideas behind these tables.
Also more clear would be converting the project_sponsor_partner_xref.is_sponsor field to type. See discussion below.
ERD, spreadsheet, code changes for each of these
sponsor_partner to affiliateproject_sponsor_partner_xref to affiliation. Made part of #65
is_sponsor field name to type and make it a choice or enum. Made part of #65project_sponsor_partner_xref table to affiliation or a more appropriate descriptive term for the relationship.sponsor_partner table to affiliate.is_sponsor is a choice like choose between sponsor or partner, and call it typeMostly simpler naming for these concepts.
Clearer code when working with the relationship and model.
Example to create a project-affiliate relation
Affiliation.objects.create(project="PeopleDepot", affiliate="Code for America", type="partner")
The current way would look like this
ProjectSponsorPartnerXref.objects.create(project="PeopleDepot", sponsor_partner="Code for America", is_sponsor=False)
Originally posted by @fyliu in hackforla#270 (comment)
We should rename the sponsor_partner table to something like affiliate. And the project_sponsor_partner_xref table to affiliation or similar. This would simplify and clarify the ideas behind these tables.
Also more clear would be converting the project_sponsor_partner_xref.is_sponsor field to type. See discussion below.
ERD, spreadsheet, code changes for each of these
sponsor_partner to affiliateproject_sponsor_partner_xref to affiliation. Made part of #65
is_sponsor field name to type and make it a choice or enum. Made part of #65project_sponsor_partner_xref table to affiliation or a more appropriate descriptive term for the relationship.sponsor_partner table to affiliate.is_sponsor is a choice like choose between sponsor or partner, and call it typeMostly simpler naming for these concepts.
Clearer code when working with the relationship and model.
Example to create a project-affiliate relation
Affiliation.objects.create(project="PeopleDepot", affiliate="Code for America", type="partner")
The current way would look like this
ProjectSponsorPartnerXref.objects.create(project="PeopleDepot", sponsor_partner="Code for America", is_sponsor=False)
Originally posted by @fyliu in hackforla#270 (comment)
We are planning on including field-level security for tables. The required permissions need to be tested before implementation.
We are planning on including row and field-level security for tables. The required permissions need to be tested before implementation. Row and field level READ privileges for certain fields and roles will be implemented to prove feasibility.
| name | test case | requirement |
|---|---|---|
| globalAdmin | Can view and update all user info for all users, can create new users, and can de-activate users | .Can CRUD anything |
| adminProject | Can view and update all user info for users assigned to the project. Can not view users not related to a project which they are assigned. Cannot update users for projects for which they are not a project admin | Can Read and Update anything related to their assigned project |
| memberProject | Can read basic user info for users on the same project. Cannot update information. | Can Read anything related to their project that is visible |
As a user I want my information protected by having an administrator in charge of who gets to view my information.
Add this code to views.py:
class IsStaffUser(BasePermission):
"""
Custom permission to only allow staff users.
"""
def has_permission(self, request, view):
# Check if user is authenticated and is_staff is True
print("Debug user", request.user.is_staff, request.user.is_authenticated, request.user.is_superuser, request.user.is_active, request.user.is_anonymous, request.user.username, request.user.email, request.user.first_name, request.user.last_name, request.user.is_staff, request.user.is_superuser, request.user.is_active)
print(request.user.__dict__)
return request.user.is_staff
class IsStaffUserOrReadOnly(BasePermission):
"""
Custom permission to only allow staff users.
"""
def has_permission(self, request, view):
# Check if user is authenticated and is_staff is True
return request.user.is_staff or request.method in SAFE_METHODS
Then change permission_classes[IsAuthenticated] to permision_classes[IsStaffUser]
As a user I want only authorized users to update information so that the information is accurate.
if not request.user.has_perm('core.change_practice_area'):
# If the user doesn't have permission, return forbidden response
return HttpResponseForbidden("You don't have permission to update practice area.")
Similar code can be written for creating and deleting.
As a developer, I want to be able to deploy docker without any fatal errors.
Remove the line that installs postgres. It may not be needed. Otherwise, update 13+225 to an appropiate value.
We need to add documentation for how to combine migrations before merging a PR for the benefit of developers so that they can refer to the guide as needed.
When doing PRs involving django models, sometimes the requested changes cause django to generate more migration files. To keep things simpler, it's recommended to combine migrations as much as possible at the end of the PR process so that there's one or very few migrations to merge. Follow these steps to merge all the PR migrations into one.
Check the new migrations created for the PR
ls app/core/migrations/
Let's say the PR created 0022-0027 in the core app
...
Applying core.0020_rename_is_sponsor_sponsorpartner_is_org_partner_and_more... OK
Applying core.0021_sdg... OK
Applying core.0022_alter_sponsorpartner_table_affiliation_and_more... OK
Applying core.0023_rename_sponsorpartner_affiliate_and_more... OK
Applying core.0024_rename_is_sponsor_affiliation_affiliation_type... OK
Applying core.0025_remove_affiliation_affiliation_type_and_more... OK
Applying core.0026_alter_affiliation_created_at_alter_affiliate_table... OK
Applying core.0027_alter_affiliation_created_at... OK
...Undo the migrations back to before the PR
docker-compose exec web python manage.py migrate core 0021
Delete the migration files
rm app/core/migrations/{0022*,0023*,0024*,0025*,0026*,0027*}
Reset the max_migration.txt back to before the PR branch (assuming that's the current upstream/main)
git checkout upstream/main -- app/core/migrations/max_migration.txt
Generate the combined migration file and apply it
docker-compose exec web python manage.py makemigrations
docker-compose exec web python manage.py migrate
We need to add seed data for the Permission Type table, because it won't be changing, it's the same for all users of people depot and the information is public
We need to add documentation for the github actions being used in this repo for the benefit of developers and maintainers so that they can understand how to read the results in the Actions page.
What to include in the documentation
We are planning on including field-level security for tables. The required permissions need to be tested before implementation.
We need a place for new project team members to annotate their questions so that we can answer them in writing and then update the wiki
questionBriefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
We need to create the [name of table] table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.
"#### Details"
A table and a model are the same thing
A table and a model are the same thing
No response
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
As a user I want only authorized users to update information so that the information is accurate.
if not request.user.has_perm('core.change_practice_area'):
# If the user doesn't have permission, return forbidden response
return HttpResponseForbidden("You don't have permission to update practice area.")
Similar code can be written for creating and deleting.
Briefly describe the purpose of this issue.
If this is a new issue, describe what research and documentation are likely needed.
If this is an existing issue, describe the steps and course of actions. If this is a complex issue, maybe it'd be helpful to divide into separate issues.
Documentation or websites that can be helpful.
This is a knowledgebase requirement to allow synchronization of users table without having to rely on permissions of a user.
We need to add documentation for how to combine migrations before merging a PR for the benefit of developers so that they can refer to the guide as needed.
When doing PRs involving django models, sometimes the requested changes cause django to generate more migration files. To keep things simpler, it's recommended to combine migrations as much as possible at the end of the PR process so that there's one or very few migrations to merge. Follow these steps to merge all the PR migrations into one.
Check the new migrations created for the PR
ls app/core/migrations/
Let's say the PR created 0022-0027 in the core app
...
Applying core.0020_rename_is_sponsor_sponsorpartner_is_org_partner_and_more... OK
Applying core.0021_sdg... OK
Applying core.0022_alter_sponsorpartner_table_affiliation_and_more... OK
Applying core.0023_rename_sponsorpartner_affiliate_and_more... OK
Applying core.0024_rename_is_sponsor_affiliation_affiliation_type... OK
Applying core.0025_remove_affiliation_affiliation_type_and_more... OK
Applying core.0026_alter_affiliation_created_at_alter_affiliate_table... OK
Applying core.0027_alter_affiliation_created_at... OK
...Undo the migrations back to before the PR
docker-compose exec web python manage.py migrate core 0021
Delete the migration files
rm app/core/migrations/{0022*,0023*,0024*,0025*,0026*,0027*}
Reset the max_migration.txt back to before the PR branch (assuming that's the current upstream/main)
git checkout upstream/main -- app/core/migrations/max_migration.txt
Generate the combined migration file and apply it
docker-compose exec web python manage.py makemigrations
docker-compose exec web python manage.py migrate
We need to create an explanation page for the project directory structure so that new devs can understand where everything is and should go.
project_structure.md and lay out and explain the project structureAll the project files (some project-specific content omitted)
├── app
│ ├── core
│ │ ├── admin.py
│ │ ├── api
│ │ │ ├── permissions.py
│ │ │ ├── serializers.py
│ │ │ ├── urls.py
│ │ │ └── views.py
│ │ ├── apps.py
│ │ ├── initial_data/
│ │ ├── migrations
│ │ │ ├── 0001_initial.py
│ │ │ ├── ...
│ │ │ └── max_migration.txt
│ │ ├── models.py
│ │ ├── scripts/
│ │ ├── tests
│ │ │ ├── conftest.py
│ │ │ ├── test_api.py
│ │ │ ├── test_models.py
│ │ │ └── test_permissions.py
│ │ └── utils
│ │ └── jwt.py
│ ├── data
│ │ └── migrations
│ │ ├── ...
│ │ └── max_migration.txt
│ ├── Dockerfile
│ ├── entrypoint.sh
│ ├── erd.png
│ ├── manage.py
│ ├── peopledepot
│ │ ├── asgi.py
│ │ ├── settings.py
│ │ ├── urls.py
│ │ └── wsgi.py
│ ├── requirements.in
│ ├── requirements.txt
│ ├── scripts
│ │ └── convert.py
│ ├── setup.cfg
│ └── tmp.md
├── CONTRIBUTING.md
├── docker-compose.yml
├── docs/
├── LICENSE
├── mkdocs.yml
├── pyproject.toml
├── README.md
└── scripts
├── buildrun.sh
├── check-migrations.sh
├── createsuperuser.sh
├── db.sh
├── erd.sh
├── lint.sh
├── loadenv.sh
├── logs.sh
├── migrate.sh
├── precommit-check.sh
├── run.sh
├── start-local.sh
├── test.sh
└── update-dependencies.sh
Adjust pre-commit settings to resolve some issues
we should unignore this when mdformat does the right thing
set pre-commit.ci to run quarterly from weekly because weekly is too often to update syntax checkers
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.