uoft-tapp / tapp Goto Github PK

Each time the code base is changed, we can either rebuild the docker image or inject the updated code base into the running container. Currently due to how caching works in docker, because the command that copies the code base into the image comes before the command that installs yarn, if we rebuild after a code base change, all subsequent commands are executed.

The sass Ruby gem has been deprecated: http://sass.logdown.com/posts/7081811 I don't even think we need sass installed on the Ruby side, since our frontend is complied separately. sass-rails and related should be removed from Gemfile and Gemfile.lock

The only way to access the new positions form on the frontend is to hit the tapp/positions/new route. We should add a button or a more intuitive way to access this component from the positions tab.

The scripts depoloy and start_dev should not be in the repo. The README can provide copy-and-pastable versions of these scripts if a particular user wants rerun these tasks a lot, but that shouldn't be part of normal workflow.

We want position to have a relationship with Applicant THROUGH position_preference.

But why do we want Position to have a second has_many relationship with position_preference??

Apologies in advance if this is some rails modeling foible that I should know.

https://help.github.com/en/articles/enabling-branch-restrictions

The owner should lock down the master branch.

This ticket will be used to create a new position page with a similar format to the existing one and for the use of the clients(students). They will be able to select the level of preference in the corresponding column and order the position list by preference.

This app will likely have features involving uploading and downloading files, which will need to work across different components. To prevent repetitive code, a folder lib is created for the /frontend, which will serve as the location, where shared functions go.

Due to the new schema, the old seed data no longer works. So, a new set of seed data needs to be created.

The upgraded ER for the schema also needs to added.

When a student wants to apply for TA positions, they need to fill out an application form and select course preferences. As part of a previous PR (#97), Yifang has created a modified positions list that has a drop down for preference selection. This component currently has its own separate redux store, but we want the preference selection component and the application form to share the same redux store so that when the application form is submitted, the course preferences can be sent in the same request.

To do this, we can:

1. move the components in applicant positions into the application directory
2. move and combine the redux actions and reducer from applicant positions with the actions
   and reducer in application
3. connect the redux store in application to the components moved over from applicant
   positions

You may want to change the name of the component 'PositionsApplied' to something that reflects a list of position advertisements.

Create a skeleton application form component, and route it so that it can be accessed. The routing should be changed once we start implementing the authorization code, but for now it can just be /applications/new.

This skeleton application form is expected to have fields/questions added and modified in the future. For now, it will just include basic questions such as Name, Student ID, Year of Study, etc.

We have a few small issues pertaining to the readme that should be updated:

1. One of our prerequisites is listed as "For Linux users only, Docker Compose". Later in the document, we ask that users invoke docker-compose .... I see this being confusing to new members on mac or windows who don't realize that docker-compose comes w/ docker on those OS installations. We could resolve this with a small rephrasing indicating that if the dev is on mac or win, they already have it.

2. Invoking ./script/init-setup.sh out of the box doesn't work out, as the script won't likely have executable permissions. It's nitpicky, but we should write "Run the script with your shell. In bash, for example, invoke bash script/init-setup.sh.

3. Under "Running in a docker container" we first instruct the user to invoke docker-compose up. This will fail if docker isn't actually running on the users machine, we should specify to make sure it's running first.

4. The information under "Accessing Docker Images through a shell command" seems to be both somewhat redundant and at odds with the earlier mention of using `docker-compose exec tapp sh' to run the tapp container and access the app. Why do we advise docker in one case and docker-compose in the other ?

5. There are grammatical errors throughout the document, mostly related to sentence structure and word choice.

At the time of writing, we're also experience an issue w/ psql invocations. That's being tracked in #40

We should drop the convention to mention issue numbers with a hashtag, since this is the token for comments in GIT. If someone needs to find an issue linked to some commit, they can do so by looking in the associated PR.

Currently seed data is hard-coded in seed.rb. Would be nice to refactor seed into json files

The applicant_data_for_matching table wasn't added in PR #122 by accident.

Some instances of the deleted table, preferences, were not completely removed from the other model files.

In the edit position popup, there is a delete button that allows the user to delete the position. However, the redux action for this delete is not implemented correctly, and raises an error when clicked. We need to complete the implementation:

- make a request to the rails api to delete the position
    - if the request was successful, pass dispatch a deletePositionSuccess action
    - else, log the error and notify the user

Dependabot couldn't find a package.json for this project.

Dependabot requires a package.json to evaluate your project's current JavaScript dependencies. It had expected to find one at the path: /package.json.

If this isn't a JavaScript project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

The README is getting a bit long and hard to navigate. Section headings should be re-thoughtout. Parts of the README that are not of high importance can be hidden using a collapsible view (note, this does not mean that every subsection of the README should be collapsed).

As it stands, only the backend portion of our app is containerized. To see the frontend code, I need to navigate manually into the frontend directory, perform a yarn install and yarn start.

It would be nice if I could perform a single invocation to run the container, spawning both the backend server and the frontend server at the same time.

At the moment, if you load the positions view in our frontend with no positions in the database, the "no rows found" message renders over the table header.

It would be nice if:

• The message was more descriptive (i.e. read "no positions found" instead of "no rows found"
• The message aligned properly under the table

Screenshot:

Steps to reproduce:

1. Make sure there are no positions in your local database instance
2. Run the front and backend, and navigate to the "Positions" tab.

Right now, the project's top level directory is set like a traditional rails app. This feels a bit awkward, as our frontend code is just sitting there among it, even though our rails code does not interact with it directly. As discussed in our Wednesday meeting, it would be nice if we could reorgzanize the directory structure as follows:

docker-compose.yml
frontend
api

Where api will be the rails app.

There are a lot of routes that are unused in Rails such as:
GET /api/v1/applicants/new
GET /api/v1/applicants/edit
They need to be removed.

It's been discussed in this week's meeting that the table name will be changed to a more descriptive one. So, this table will be removed until a consensus is reached on the new table name.

My last piece of work to refactor the db and drop the rounds table neglected to push a new version fo schema.rb.

I believe this arose in the period of confusion surrounding whether we should be tracking it at all with git.

I've run into some trouble using the rails developer tools, and some online investigation has suggested that I update my binstubs by regenerating the project's bin folder. I noticed that a few things in there could use an update as well, so I figure I should make the change more permanent.

Add some basic styling to the application form and also learn about sass.

This should be blocked until issue #66 is complete. For this ticket, implement the code that will send form data to the api and reflect the status of the application to the user based on the api response.

rails-erd is a gem that can generate the ER diagram of the model without relying on external tools such as RubyMine (IDE) or other online tools. Furthermore, unlike railroady, which requires a separate command to generate the diagrams, this gem can be configured to auto-generate the diagram whenever rake db:migrate is called.

Currently the project run in development through two docker containers
- a container that runs the rails api server
- a container that runs webpack-dev-server which serves the react app and enables hot
module reloading

In production, the the frontend will not be served by webpack-dev-server. Instead, we need build the frontend with webpack, and then serve the javascript bundle and static assets ourself. There are a few different ways of doing this.

1. We can serve the frontend with our rails api server, which involves using gems like webpack and rails-react. This means that we will only need one container to run the app in production, and all requests will hit the api server instead of the react app.

2. We can serve the frontend with a light node.js server. This allow us to disentangle the frontend and the backend, however we will need to run two containers/services in production, and setting up the network for the two to communicate through docker could be tricky.

At this point I am not sure what kind of server we will be deploying the app to. There are guides online for deploying projects that are similar to TAPP (rails backend and react frontend), but most of them are for Heroku.

The instructions for using TAPP in a container eventually states that the user should first invoke rake db:setup to initialize the db, then psql tapp_development tapp to interact with the database.

Performing these steps as described leads me to the following error:

sh: psql: not found

The old version ajv is causing problems when we do the docker-compose up. Update the ajv version in the package.json.

The ApplicationForm component renders a list of question and answer fields in a div, but this div gets overlapped by the footer. I added a few br tags at the end of the div so that you can't see the overlap, but we should find a proper way of dealing with it. To reproduce the issue, remove the br tags in the ApplicationForm component and render the page at localhost:8000/application.

I think we should be wrapping the div in a Grid tag that can be imported from react-bootstrap, you can take a look at how the positions table is rendered for reference.

We need to find a way to mock authentication when we are developing to continue with the implementation of the authentication and authorization system for TAPP.

Issue #121 / PR #122 created a new schema, so the rspec tests needs to be updated accordingly.

Currently, when you try to add a new position, the dropdown interface that allows you to do so lingers after redirection. This should disappear after the redirection occurs.

Screenshot:

Steps to reproduce:

1. Run the frontend
2. Click on the "Tools" dropdown and select "new position"
3. The view will be redirected, but the dropdown will persist

It looks like this got lost in implementation of schema

Since we make a point of adding a git precommit hook for ruby linting via rubocop, it might not be a bad idea to do the same thing for the apps frontend, mostly to help maintain consistency and catch small errors that tend to slip through code review.

I realized I made a mistake with my previous work adding eslint as our default JS linter for the project. Namely, it appears to be the case that react-scripts (which our project uses) includes a version of eslint already. Installing a newer version separately causes the frontend to crash when we deploy, since the react community has decided that they dont think the risk is worth taking.

Ill modify the precommit hook to use react-scripts version of eslint, and de-install the other one.

A docker entrypoint file was created to auto run migrations every time the api container is spun up, but this entrypoint file is not getting picked up automatically by docker-compose. Adding an entrypoint field into docker-compose should fix this.

Dependabot couldn't find a Gemfile for this project.

Dependabot requires a Gemfile to evaluate your project's current Ruby dependencies. It had expected to find one at the path: /Gemfile.

If this isn't a Ruby project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

The new route will receive the data from the frontend, verify the validity of data and do a save once it is verified. If the data record already exists in the database, the route shall update its fields. If not valid, then show a notification to remind the user of the corresponding errors.

This will be a long one, but I really believe it's worth our time, we only need to agree on this once.

Overview

I've looked over the various repositories under uoft-tapp and found quite a bit of disorganization regarding how issues are tracked and handled, as well as how commits their associated PR's are described. The main issue here is consistency. Given that this project is going to see a lot of team switches, typically over four month intervals, I think it is in everyone, especially future dev's, best interests that we agree on a simple standard for the following:

• How issues are names, labelled, tracked and closed
• How commits are labelled and describes
• How PR's are named, reviewed, approved and closed

I like the format @George334456 has followed his his commits (example here), but we need to push things further, as the details are not documented anywhere and might not be immediately comprehensible to a new team member.

I've worked on a number of open source projects over the last two years, so I'll propose what I've found to be most effective in my own experience. I'll present this in a slightly unintuitive fashion, please bare with it until the end:

Commits

• Scope An individual commit should always track the smallest unit of work possible, within reason. This is both so that we can easily debug issues, easily read through our git logs incrementally and so that both PR reviewers and devs don't get confused searching through big chunks of code serving different purposes.

• Structure I've used a tool called commitizen in the past. Whether we choose to use it or not is unimportant, but the format it proposed is very valuable. Commit's should always follow this format:

[purpose] Short description, no more than 80 chars

Short body, if necessary
Resolves [Associated issue number]

example:

[feat] Allow users to change their name

Allows users to change their name by visiting their profile settings.

Revolves #12345

Borrowing from commitizen, purposes include:

feat: A new feature
fix: A bug fix
refactor: A code section refactor
style: A purely stylistic change to the code
test: Any change to or addition of tests

I personally don't think the other purposes bring that much value. We can debate whether chore would be worth incorporating as we discuss deployment more.

Issues

• Scope Everything we do, no matter how insignificant, should always start with a new issue. The scope of these problems can be quite broad, but I think we should be reasonable. If something seems like it would involve more than a weeks work, it is worth breaking down into several issues collected under a single one.

• Structure Since the answer to an issue might involve several commits, I don't think they need to include the same purposes in their headers as before. That said, we should at least use our labels to capture the ideas of refactoring, bugs features (keep in mind that these might involve several refactor, bug or features commits). We should also allow for "special issues":

Proposal: like this issue, these should be created for any changes regarding our team's structure, documentation and workflow.

Question: these are appropriate for anything a team member thinks is worth discussing or implementing, but that they are unsure of how to move forward with.

Going on the previous example, we might have the issue:

Title: Users should be able to add change their account names

It would be nice if users were able to change their names under their account profile settings. This might be relevant to anyone who accidentally entered a typo to their name upon registration.

Labels: feature

Pull Requests

• Scope Every non proposal or question issue should have an associated PR. We should always mention the PR with its hashtag, as Github will automatically link it. This doesn't need to do much other then mention the issue number and brief description in the title, as follows:

[Issue Number] Description

More description, if needed.

Example:

[#12345] Give users ability to change name

The commits in this PR allow users to change their name under their profile settings. 

Ideally, every PR would have at least one reviewer who eventually approves and merges it. For reviewers, please make sure to not only read the code but check it out and attempt to interact with the new feature, if possible. This prevents us from accidentally ending up with a broken build. We should never merge a PR containing commits that do not follow the agreed format.

When a PR is successfully closed, it is the responsibility of the person submitting the PR to go and close the issue, not the reviewer or issue creator.

Summary

Thanks for taking the time to read this this proposal. I know it's long, but I cannot overstate how valuable I think adopting this would be; even an imperfect structure is leagues better than none at all. Ideally, we can agree on something and write it up in the project's README or contributing file.

It's been decided in this week's meeting that the pay1 and pay2 attributes will be moved to a new table for keeping track of the rates in the assignments and offers. So, these attributes will be removed as unused attributes.

The current API for the backend provides endpoints for receiving PUT and POST requests.

Based on how the application form works in the frontend, we would need to introduce unnecessary business logic to the frontend so as to make use of both these endpoints. Instead, we should refactor the backend to drop PUT requests, and have POST handle everything. We should customize the response so that the user has some visibility about whether they have created a new DB record or updated a pre-existing one.

This involves creating tables, routes, and UI for contract presentment (CP).

For the table, the following tables was created:

• assignment
  • applicant_id: foreign key
  • position_id: foreign key
  • hours: int
  • pay1: float
  • pay2: float
  • start_date: date
  • end_date: date
  • status: unsent (0), sent (1), accepted (2), rejected (3), withdrawn (4)
• offers
  • assignment_id: foreign key
  • hours: int
  • pay1: float
  • pay2: float
  • start_date: date
  • end_date: date
  • status: unsent (0), sent (1), accepted (2), rejected (3), withdrawn (4)

For the routes, the following routes was created:

• GET /api/v1/assignments: returns all assignments
• GET /api/v1/assignments/{id}: returns assignment with id
• POST /api/v1/assignment: create a new assignment with position_id, applicant_id, hours, pay1, pay2
• PUT /api/v1/assignment/{assignment_id}: can modify the attributes in assignment
• GET /api/v1/offers: returns all offers
• GET /api/v1/offers: returns offer with id

For the UI, the design should follow that of the old CP and new ABC view for reference.

The design of the new schema follows the following diagram:

In our last meeting, we decided to drop the notions of "rounds" from our database schema. This will have to be refactored out of the backend code.

The db container has permission issue on Windows 10 because the postgres directory has no permission to access tmp/data. To fix this, Docker has to know the PGDATA=/tmp as its environment variable.

For this ticket, we should create a button to upload .csv file locally, and read the data from that file, and feed it into the input box of related areas.

Flesh out the Application model in rails and create api endpoints to handle CRUD operations.