uoft-tapp / tapp Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
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 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.
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
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.
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:
You may want to change the name of the component 'PositionsApplied' to something that reflects a list of position advertisements.
https://help.github.com/en/articles/enabling-branch-restrictions
The owner should lock down the master branch.
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.
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.
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.
tapp/api/app/models/application.rb
Line 8 in 726a3ec
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.
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.
Steps to reproduce:
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.
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.
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.
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.
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.
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.
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.
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.
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.
This involves creating tables, routes, and UI for contract presentment (CP).
For the table, the following tables was created:
assignment
applicant_id
: foreign keyposition_id
: foreign keyhours
: intpay1
: floatpay2
: floatstart_date
: dateend_date
: datestatus
: unsent
(0), sent
(1), accepted
(2), rejected
(3), withdrawn
(4)offers
assignment_id
: foreign keyhours
: intpay1
: floatpay2
: floatstart_date
: dateend_date
: datestatus
: unsent
(0), sent
(1), accepted
(2), rejected
(3), withdrawn
(4)For the routes, the following routes was created:
/api/v1/assignments
: returns all assignments/api/v1/assignments/{id}
: returns assignment with id
/api/v1/assignment
: create a new assignment with position_id
, applicant_id
, hours
, pay1
, pay2
/api/v1/assignment/{assignment_id}
: can modify the attributes in assignment/api/v1/offers
: returns all offers/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.
tapp/api/app/models/assignment.rb
Line 7 in 726a3ec
It looks like this got lost in implementation of schema
Add some basic styling to the application form and also learn about sass.
The old version ajv is causing problems when we do the docker-compose up. Update the ajv version in the package.json.
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.
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.
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.
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.
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).
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
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 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.
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:
Steps to reproduce:
Currently seed data is hard-coded in seed.rb. Would be nice to refactor seed into json files
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.
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.
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.
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.
We have a few small issues pertaining to the readme that should be updated:
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.
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
.
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.
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 ?
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
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
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.
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.
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.
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.
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.
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.
Flesh out the Application model in rails and create api endpoints to handle CRUD operations.
This will be a long one, but I really believe it's worth our time, we only need to agree on this once.
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:
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:
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.
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
[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.
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.
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.
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.
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.