robwa / herweg Goto Github PK

I've done it.

I'll do it.

Ist es möglich, dass auf einem breiten Laptop so viele Tage angezeigt werden, wie Platz haben? Und dass man, wenn man weiter klickt nicht nur einen Tag weiterkommt, sondern eben so viele Tage, wie in der Breite angezeigt werden können?

The mobile view doesn't seem to be working. Probably we should remove some columns.

On startup, normally the current day is preselected. There seem to be occasions in which this doesn't work (i.e. the previous day or something similar is selected).

I feel that non-root setups are weird, I do not understand the rewrite/link rules, I needed two commits to make it work, and I suspect that our current setup may break in other environments.

I suggest to remove that option. Instead, we should recommend the use of a subdomain (IMHO).

It may be desirable not to expose all data via the HTTP API.

1. Should we remove the unused endpoint GET /api/v1/surveys?
2. Should we require a valid survey UUID for all API requests to /api/v1/categories and /api/v1/assignments?

I am considering to use an HTTP header field: With the exception of POST /api/v1/surveys, the server can check for the presence of a valid survey UUID in that header field. All corresponding database queries can then be restricted to that survey.

After filling the user input, forms can be submitted multiple times with the very same data. I know several options for how to mitigate this:

1. disable/reset the form in the UI once the user submits
2. generate a unique token for each form in the frontend and check for uniqueness in the backend
3. request a unique token from the backend before any form can be submitted, and check for uniqueness in the backend

What are your thoughts on this?

Sometimes users accidentally delete categories (and all entries for the category). Some kind of warning ("Do you really want to do this?") probably could help.

Showing something like (mo) or "Monday" next to the date would improve readability.

After private discussion with @robwa : Let us consequently follow the zero-setup philosophy: Use frontend and backend URLs that just work™ without mod_rewrite.

This supersedes #6 because base URLs will just work without hassle, too.

User input ends up in SQL statements all over the place.

We should fix these sql-injection vulnerabilities. I see two options:

1. use a whitelist or regex for each string that ends up in the query string
2. do not build the queries dynamically from user input, but hardcode the few required use cases (using prepared statements, of course).

What do you think?

Installations might need an imprint. Probably we should add support for this.

... and may break when sent via email.

Take your pick:

• I don't care about long URLs.
  • What is that email, anyway?
• We should recommend/integrate a trustworthy URL-shortening service.
  • Data protection statement?
• We should integrate a URL-shortening strategy.
  • How?

On mobile devices, the column width for the day column sometimes gets too small. It is then not possible to enter data. We should enforce column width or add data by button (and popup).

I suggest using the AGPL. Opinions?

Should we implement soft deletion (deleted_at), or should we implement a straight DELETE FROM?

Soft deletion might be easier because there is less hassle with foreign keys becoming invalid. Real deletion is better concerning privacy/data protection. The best solution IMHO is soft deletion combined with a background worker that cleans up deleted resources after n days. The background worker may involve too much setup overhead, though.