milindl / leaderboard Goto Github PK

As of now, the typeof ticket is a text field, and I've simply suggested that you should fill up 'ML' or 'Open Source' or whatever. What would be ideal is to have a select menu there, with options:

• Open Source
• PClub Activity
• Competitive
• Machine Learning
• Other

And on clicking 'other', a text field pops up.

To know more, take a look at form helpers.

Depends on #3

Several sort of unit tests need to be written, with sufficient discussion for each. Some, however, are clear.

1. Model validity tests. Each model validates its data before saving, We should write tests to make sure that invalid model objects give the necessary error, while valid ones pass. This includes the CC login tests, for which we require the endpoints mocked up as seen in #3
2. Controller tests. Each view should be rendered when we get it. Any helpers associated with the model should also be tested with both positive and negative values.

Multiple people can work on this issue.

This may help: https://docs.docker.com/compose/rails since we will also use a rails+postgres setup in the final setup.
Needs discussion, I'll mostly be doing it myself. @yashsriv

A small number of design changes seem to have missed these two pages. This should be a really easy bug

Monthly ranks need to be represented, at least internally, since we need to give out special titles and/or goodies based on that.

It would be nice to have a :scope to do that. Having :scopes would clean up a lot of clutter in a few controllers as well.

There are several steps to this issue:

1. Add rubocop requirement to Gemfile for test and development environment.
2. Write a reasonable rubocop.yml file to validate only the code we have written (in app/ and in tests/ etc, but not in lib/). example
   This can be done as one commit.
   The second changeset can be:
3. Fixing the errors we have. This is easy but time consuming.
4. The last step would be adding a check to CircleCI, which I will do after the above two changesets are added.

Inside a single user X's X.tickets.all, there should be no repetition. In other words, the tuple (link, status) should not be the same.

What this means is that the user should not be able to submit an identical link when a previous request with the same link is still pending. On the other hand, maybe we should not allow the same link at all. However, this is a bit tricky for competitive coding, where we may allow points based on the rank , which is on the same page so the link doesn't change. Alternatively, allowing the scoring to be based on various contest results (?) may work here.

Competetive coders, feel free to pitch in with ideas.

Explain the ticketing system (you submit a ticket, it gets reviewed by us, then it gets added to your points and you get a shirt - you know what we discussed!). In case of doubts feel free to comment below.

Use WebMock and mock up the end points for the application. I am using 2 endpoints, namely

1. https://dashboard.pclub.in/api/user/login
2. https://search.pclub.in/api/student?username=(cclogin).

I am posting to the first and getting the second one. This may take some time and it pretty important (I think I won't release without this), so unless someone picks this up fairly fast, I will do it myself.

Need to make nice icons for each of the links, and add a link to the slack also probably.

Along with each score, there is a title associated. We have decided to go with a star wars theme this time. You need to do 2 things:

1. decide on the points-title mapping with @yashsriv
2. code the mapping in a helper function inside the directory app/controller/helpers/user_helpers.rb. You can look at the other helpers for useful hints as to how to do it. Then, put this helper inside the required place inside leaderboard.html.erb.

You can use symbols :pending, :approved, and :deleted to do this.

The point of keeping deleted requests is that you can make sure a person doesn't keep submitting the same request again and again. This potentially leads to a lot of future uses, eg we can provide pointers in the approval page for the admins if such a request has already been approved(no double points for same requests) and so on.

Make a complete custom.scss file in the directory app/assets/stylesheets, feel free to add any classes to any tags in the ERB code. We need to discuss the design idea, and then draw it out so we can style accordingly.

Integration tests [subject to discussion]: there are several things we should test out. Firstly, we should test out the ticket creation process from the side of the user, the ticket approval process from the side of the adminuser, and see whether the leaderboard reflects our changes. I've personally never written complex integration tests however.