teknik-eksjo / chronos Goto Github PK

Note: I added this to the second milestone since this isn't part of the app's core functionality.

Rows in the table are painted according to their css when then page initially renders, but when a user searches for users, the rows don't have adjusted colors so every second row get a darker color. Instead the rows keep their initial styling because it's applied to every nth-child(2) of the tbody.

Possible solution:

• apply :nth-child(2) to make every second item have a color but also apply:not('.hidden') to make sure that the styling only works with visible rows

Continuing #38 and #79

In order to make this work, we will have to modify the sliders so that the weekdays displayed before them are not hard-coded text values but properties of the individual sliders. We can then use the sliders 'change' event and some Ajax to make the slider detect changes and compare the new data with the one that's already in the database. If changes are detected, Ajax should then POST the new data in the background to the same /base-schedule URL that will then handle the information and push it to the database.

Some nifty solution to avoid too frequent POST requests might also be needed.

Look at the column header widths

GIF showing the issue

Could this possibly be solved with some custom css that overrides the default bootstrap-table behavior?

Allow admins to create users based on uploaded excel file.

I need a route which returns a json-object. What do you think is the best, place it in a API-blueprint or define a route which returns json on the admin blueprint? @Limpan

We will need some kind of admin UI where principals and administrators can access the user's schedules.

To allow admins to get a overview of an user, we might be able to reuse the summary-template from the teachers' view and just add a few buttons to allow admins to modify/ approve the schedule?

Create the page that allows users to enter their deviation schedule. Depends on #37.

This is a low-priority improvement, but definitely something we should think about to make the app more future-proof. Encryption is getting more and more important even for small projects like this one.

Maybe we could use Let's Encrypt?

https://letsencrypt.org/how-it-works/

• Add support in manage.py for compiling SASS files.
• Add support in dev server for SASS files.

Description

After discussing this with @hugolundin this is what we have come up with

Clicking the delete-button should prompt the user to confirm that they really want to delete the user from the system. Maybe even prompt for the admin password since this process won't happen that often and since a mistake/abuse here could make huge damage to the user losing their data.

Event-handling for buttons in a Flask-app - Might be a good starting point on how to implement the actual data transfer and verification popup in the message.

Take inspiration from the invitation-system in Blaze Penguinz - It implemented the popup-system we want and could pretty easily be modified + restyled to fit our usecase better

Features to implement

• Prompt the admin to confirm (maybe even verify with their password)
• Send a request to the backend using some JS (check out the link to SO above ↑↑↑↑↑)
• Backend auth to check if user is signed in
• Backend process the request
• The backend responds with a result, which is displayed in the client (Popup / Bootstrap notification on top of screen)

Create the page that shows a summary of the current teacher schedule.

Related but not dependent on #46.

I realized that we really did not decide who that should review our pull requests to the repository. Me and Szymon talked about it and thought about a standard code-review process, where everyone are able to merge pull requests, but someone else should have reviewed the code before merge.

Create a few component that can be shown on the dashboard (/admin/-route).

Should we build the application with a different route for each view?

In that case, we could use window.location = "http://www.app.com/next-route" to redirect the user to the next route from the client and I guess a HTTPPOST-handler could do a redirect from the server if we only want it to happen when the user's data is saved in the database.

The following routes should be added to views.py or forms.py:

• /login (might just be the '/'-route?)
• /instructions
• /base-schedule (naming?)
• /deviations (naming?)
• /summary

Before we start coding, let's write down a basic outline of how we plan to work on this project and what we're trying to achieve.

A good place to store the information might be in a GH-wiki for this repository alternatively keep it in some documentation in Sphinx.

1. Gather requirements for the app
2. Discuss how we are going to document the development process and the resulting application.
   • GitHub Wiki
   • Google Docs
   • External markdown-files in the repository in a docs/-folder
   • Keep as many discussions as possible about the project documented in GitHub-issues and PR:s. A searchable alternative where the design-decisions are put in context together with the actual changes to the code and available for future maintainers. (I think this is the best alternative)
3. Discuss the workflow
   • Make use of GitHub issues, tag them with labels and assign them to yourself whenever you work on something
   • Use personal forks and branches with the naming fix/yyyyyyyyy or feature/yyyyyyyyyyyy
   • Use branches in the main repo
     • master for releases
     • develop for in-progress fixes and features
4. Create the app structure and decide what technology stack we're going to use.
5. Start solving the problemzzz

The application lacks quite a few tests. It would be good for avoiding regressions.

• Unit tests for the model.
• Functional tests of the different blueprints.
• Possibly some selenium tests?

Allow admins to add deviations common for all teachers.

This could allow them to make clarifications and help them agree on required changes in the Schedule

Pull request #35 introduced a linting error.

I see three alternatives at the moment:

1. Use jQuery UI Slider

Almost the functionality we need but bad documentation.

2. Custom built solution

Maybe using handle-divs positioned in a "slider-container" and ondrag / ondrop events

3. Modify and extend some library or code-snippet

For example this article looks promising or this snippet

Progress

• Make time range work with minutes
• Fix ticks for time ranges
• Clean up the old code
• Comment ticks code
• Remove slider controllers (add, remove, select type)
• Change the label names
• Test behaviors --> eg. Should not be possible to work longer than 5 hours
• Fix css styling
• Change color slider to red on error
• Fix handle types --> Use work, lunch, leisure
• Translate the slider stylesheet into SASS

Allow admins to manually resend emails.

Create a data model that supports teacher schedules (two parts, base and deviation) and periods.

hn

Which of these features do we want to add and where?

0.x

1.x

2.x

Distant future

Database needs to be reset between tests.

• Fix handle types, labels for sections in the slider. Also update naming of css-classes
• Use work, lunch, leisure?
• Use start, lunch_start, lunch_end, end?

Add the ability to edit a teacher profile from the teacher overview using the "edit"-button.

Generate automatic e-mails for periods (instructions, reminders and the likes).

The current email templates are in english.

The owner of the repository needs to add the developers as collaborators in the repository. Before this is done, we can't add/edit/move labels for issues.

Write a script that generates some bogus data. Primarily for manual testing.

This might be due to bootstrap/base.html which we extend in our base.html.

Solutions:

• Update bootstrap to a version that is using 2.x?
• Manually edit bootstap/base.html

When we discuss how the current version of the app is implemented tomorrow, I think we should focus on improving comments together. By doing this, we would not only get a deeper understanding of the code and help the people not attending class tomorrow but we would most importantly improve future maintain ability of the app - one of our core goals with this project?

Currently the buttons look quite odd when focused. Needs to be fixed

Create a page that allows admins to approve and unlock schedules.

I've seen some mixed English and Swedish and also some phrasings that could be improved.

Might not be the highest priority right now but definitely something we want to fix before our production-deployment

Since the deadline for the alpha-version of the app (4th May) is approaching, we could start discussing how we're going to do it and what we need to think about as we get ideas under the comping weeks.

Here's some initial suggestions:

• For the second round of user-tests, involve users from every role in the system to get accurate feedback.
• Ask admins and users if they want names on workperiods (see #90 )

Handle periods in the admin ui.

Allow users with READ_SCHEDULE permissions to print out schedules in some useful format. On screen or as PDF.

Create the page that allows teachers to enter and submit their base schedule. Depends on #37.

Depends on #38.

By adding live-linting to our editors, we'll get better code consistency and catch syntax-mistakes more easily.

I suggest linter-js-standard as the JS-linter for Atom.

There are several Python linters for Atom - Which one should we use?

Should be fixed by removing

from ..models import Post
from .forms import PostForm

from views.py.

This feels like a natural part of the admin dashboard.

I have some thoughts about how the routes for authentication should be structured.
Right now, the blueprint for auth goes after /auth.

My thoughts is about how the routing should be for signing in, and explain for teachers who tries to sign in without using the link, how they should do in the following way:

If you go to /, and are not signed in, you should be redirected to /auth, which provides something like this:

If you press "Administrator", you are redirected to /auth/admin which provides a sign in-page for the administrator. If you press "Teacher", you are redirected to /auth/teacher (or another url not decided yet), you are provided with something like this:

(If "click here" is clicked, the user is provided a page with an email form and a reset button).

What are your thoughts on this?

What permission levels should exist?

Since the built-in datetime-library (https://docs.python.org/3.5/library/datetime.html#) isn't that great the need arises to discuss what data types should be used in the model. As it is the built-ins are used (datetime.date, datetime.time).

The Arrow library is a lot better (http://crsmithdev.com/arrow/) but at the moment I am unsure as how to best integrate it with SQLAlchemy. As I see it there's a few alternatives.

1. Stick to the built-in datetime-based types. This already works but the datetime.date and datetime.time types are crappy when performing calculations.
2. Use SQLalchemy_utils and the ArrowType data type. This will create a less obvious model where both Date and Time becomes ArrowType.
3. Replace the date and time attributes on the fly. Sounds like a bad hack. Will probably create a lot of issues but allows us to keep two distinct data types for date and time.

Leaning towards 2

There's a few missing commands in the current version that could be added to make it more clear.

It is my understanding that the list of teachers displayed in the admin-part of the interface will always load every teacher in the system. If that is the case, I think the filter/search function should be implemented with JavaScript on the client side.

I've made a working version of the email-login using tokens. But my problem is that when using the same configuration as in the flasky example for email (and a Gmail account) I get this error:

    raise SMTPServerDisconnected('please run connect() first')
smtplib.SMTPServerDisconnected: please run connect() first

Is this a known issue? If someone would like to examine it, just comment so I can create a branch with my dummy functions for sending the email I've been using right now.

@Limpan