stephengtuggy / job-history Goto Github PK

Describe the bug
Of the JobTimePeriod fields start_year, start_month, start_day, end_year, end_month, and end_day, only start_year should be required. Yet the admin UI makes it so that all 6 of these fields are required.

To Reproduce
Steps to reproduce the behavior:

1. Log into the jobHistory app.
2. Click on 'Enter Data.'
3. Go to 'Positions.'
4. Enter a Position start date without an end date.
5. Try saving.
6. See validation message that the end date fields are "required."

Expected behavior
Start Month should be required only if Start Date is entered. End Month should be required only if End Date is entered. End Year should be required only if End Month is entered, or if Current Position is unchecked.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Ubuntu 20.04 LTS
• Browser: Firefox
• Version: 79.0 64-bit

Additional context
It looks like the validation behavior is determined by the blank field property, not the null property. I will need to fix this.

Is your feature request related to a problem? Please describe.
I don't currently provide enough guidance to potential contributors on what to put in the description of their PRs.

Describe the solution you'd like
Create a Pull Request Template that fills this need.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
At the moment, the user can enter multiple Position records with the same title and the same Employer. This should not be allowed.

Describe the solution you'd like
Both the app and the database should enforce that Position records are unique, by Employer PK and title. If the individual held the same position at the same company more than once, they should enter multiple JobTimePeriod records for the same Position.

Describe alternatives you've considered
Can't think of any, really.

Additional context
N/A

Is your feature request related to a problem? Please describe.
Currently, you can set a position to be your current position AND set an end year, end month, and end day. The latter will quickly get out of date, while the former remains relevant for a longer period of time.

Describe the solution you'd like
Use two CheckConstraints (probably). One will be exclusive: If is_current_position is true, then none of the end date fields (year, month, day) can be set, and vice versa. The other CheckConstraint will require that either is_current_position is true, OR end_year is set.

Describe alternatives you've considered
I could require that end_month be set as well, but I don't think I will. I could do the same with end_day. Again, I don't think I will. These should always be optional.

Additional context
https://docs.djangoproject.com/en/2.2/ref/models/constraints/#django.db.models.CheckConstraint.check

Describe the bug
If you manually enter the login URL without specifying a URL to redirect to afterwards, you'll get a 404 error after you log in.

To Reproduce
Steps to reproduce the behavior:

1. Go to http://localhost:8000/registration/login/
2. Log in as usual
3. See error

Expected behavior
When the user logs in without specifying a page to go to afterwards, they should automatically be taken to /jobHistory/

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu 20.04 LTS focal
• Browser: Firefox
• Version: 79.0 64-bit

Smartphone (please complete the following information):

Additional context
See https://docs.djangoproject.com/en/2.2/ref/settings/#login-redirect-url

This project needs community guidelines to encourage constructive behavior. I am thinking of adopting Contributor Covenant 2.0. I would appreciate feedback from others on this proposal.

Is your feature request related to a problem? Please describe.
At the moment, a user can enter multiple JobTimePeriod records for the same Position and the same start and end date. This should not be allowed.

Describe the solution you'd like
JobTimePeriods should be unique by Position PK; start date; whether or not they are the current position; and, if so, end date.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
At the moment, if someone wants to contribute to this project -- whether in the form of Issues, Pull Requests, or something else -- they have very little guidance on how to do that.

Describe the solution you'd like
A document named CONTRIBUTING.md needs to be created at the root of the repo, with suitable and well-thought-out contents.

Describe alternatives you've considered
The document could perhaps be placed under docs/, but I think it will be more visible in the root folder.

Additional context
This is one of GitHub's community recommendations.

Is your feature request related to a problem? Please describe.
I no longer want to use AWS RDS for this.

Describe the solution you'd like
Host the Postgres database in a second Docker container within the same docker-compose setup, with a private network between the two containers.

Describe alternatives you've considered
I hosted the DB on AWS for a while, but that got too expensive.

Additional context
CircleCI still does it this way. I can probably just have docker-compose.yml imitate docker-compose.circleci.yml, more or less.

Is your feature request related to a problem? Please describe.
Right now, there are no actual CI tests for the project, other than spinning it up and making sure it doesn't bomb out during startup.

Describe the solution you'd like
Some specific, actual tests need to be added. They need to run in CircleCI whenever code is pushed. Or at least on Pull Requests, merges, and releases.

Describe alternatives you've considered
The primary alternative is manual testing. That's fine in its own right, but automated tests would be really nice to have as well.

Additional context
Use Django's built-in test framework, if possible.

Describe the bug
The Issue Templates aren't quite right. They need a 'bug' or 'enhancement' label, respectively. In addition, the "Bug report" template needs a colon (:) after each item under Desktop and under Smartphone.

To Reproduce
Steps to reproduce the behavior:

1. Click New Issue in this GitHub repo.
2. Choose an issue type.
3. Notice that the new issue doesn't have any labels by default. Also notice that, if you chose "Bug report", you have to add colons to the "Browser" and "Version" sections yourself.

Expected behavior
Each of these items should be provided by the item templates themselves.

Describe the bug
Django 2.1 is no longer supported.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://docs.djangoproject.com/en/2.1/topics/settings/
2. Notice the warning banner across the top of the page: "This document is for an insecure version of Django that is no longer supported. Please upgrade to a newer release!"

Expected behavior
Need to upgrade to either Django 2.2.15 or Django 3.x.

Desktop (please complete the following information):

• OS: Any
• Browser: Any
• Version: Any

Smartphone (please complete the following information):

• Device: Any
• OS: Any
• Browser: Any
• Version: Any

Additional context
Django 2.2 is an LTS version. I'll probably go with that.

Is your feature request related to a problem? Please describe.
At the moment, the user can enter multiple Employer records for the same employer, with the same name and short_name. This should not be allowed.

Describe the solution you'd like
The app and the database should both enforce that short_name, at least, and possibly long_name, are unique. If the individual worked for the same company during multiple time periods, and/or held multiple positions at the company, those should be handled by the one-to-many relationship from Employer to Position, and by the one-to-many relationship from Position to JobTimePeriod.

Describe alternatives you've considered
Can't think of any.

Additional context
N/A

Is your feature request related to a problem? Please describe.
Currently, the UI is written in U.S. English, with no real support for translating UI elements.

Describe the solution you'd like
Use the Django i18n library to make every fixed UI element translatable, as much as reasonably possible.

Describe alternatives you've considered
The main alternative would be to keep the app just in U.S. English. But I don't want that. I want as many people as possible to be able to use the job-history app.

Additional context
https://docs.djangoproject.com/en/2.2/topics/i18n/translation/#specifying-translation-strings-in-template-code

Is your feature request related to a problem? Please describe.
At the moment, I believe it is possible to set start_day for a JobTimePeriod without setting start_month. This doesn't make sense from a resume perspective.

Describe the solution you'd like
Use a CheckConstraint to enforce the above.

Describe alternatives you've considered
This seems to be the only way to do it in Django 2.2.

Additional context
N/A

Is your feature request related to a problem? Please describe.
At the moment, I believe it is possible to set end_month or end_day for a JobTimePeriod without setting end_year. This doesn't make sense from a resume perspective.

Describe the solution you'd like
Use CheckConstraints to enforce the above.

Describe alternatives you've considered
This seems to be the only way to do it in Django 2.2.

Additional context
N/A

Describe the bug
The non-admin pages of the app have no CSS whatsoever!

To Reproduce
Steps to reproduce the behavior:
...

Expected behavior
The non-admin pages of the job-history app should be styled appropriately with CSS, much like the admin pages are.

Desktop (please complete the following information):

• OS: Any
• Browser: Any
• Version: Any

Smartphone (please complete the following information):

• Device: Any
• OS: Any
• Browser: Any
• Version: Any

Additional context
N/A

Describe the bug
If you are creating or editing a Position, with its associated JobTimePeriods, and you save data that violates the database's validation rules, you will get a debug error page.

To Reproduce
Steps to reproduce the behavior:
...

Expected behavior
The admin UI should simply redisplay the same edit page again, with a red validation message at the top.

Screenshots
...

Desktop (please complete the following information):

• OS: Ubuntu 20.04 LTS focal
• Browser: Any
• Version: Any

Smartphone (please complete the following information):
(Would happen on any supported smartphone as well, presumably)

Additional context