Feature

Each day and each category have possible additional comments. Comments are not linked to a specific time, however when inputting new comments they can be done along side the time. This has not additional meaning, it's only there for convenient input. The content is normalized before being stored. Al white space is reduced to a single space, except for at the start and end of a line where it is trimmed off. Empty lines are also removed. Finally the lines will be sorted, and duplicates will be removed. There will be a trailing newline.

An example normalized string:

This is the first example task
This is the second example task
Finally the last example task

Feature

Currently these are called categories, but a better description is projects. Projects are simply used to put times under a common name, and it will be used when creating reports and analyzing data in general.

Projects can only use lower-case alpha-numeric characters, and a dash (-). Dashes may not exist before or after, and no consecutive dashes may be used. This rule-set exists to enforce consistency, and to allow other systems to make assumptions when transforming the names for display.

Projects work as a hierarchy. The user may select an existing base. They can then us a dot (.) separator to create multiple sub-projects. These must be new projects, the system must reject existing sub-projects. For clarification, the dot isn't a valid character for a project name. Rather it's an indicator for a shortcut to create multiple projects at once.

Feature

Time reports are meant to be compiled into actual reports. Write the code that generates the report. For this feature, the reports should be written as a text file. This file is not meant to be read by computers, it's a human-readable format. For that reason, the exact form of the data does not matter. What does matter is that the following data is included:

• The date, including the day of the week, in a common non-ambiguous format.
• The sum of all times, in hours, formatted in decimal. So 4 and a half hours has a value of "4.5". Each project has its own sum, and there is a sum of all time for that day.
• Comments per project

Then there must also be a global summary for the entire report, both per project and full total. This does not include comments.

The landing page, that is the page at the resource /, is currently incomplete. Make it complete, including styling and information.

In the future, many extensions may want to open URLs. This issue is about implementing a
system to do so in the core of Reduce. By default, when a URL is opened, it should return the
location itself. This can then be injected into the response, which if you've paid attention
has resulted in nothing interesting. The point is, some systems may be used to take over certain
URLs. For example, a video content consumer module, may automatically interface with a PeerTube
instance. So when the open system receives a URL which is deemed to belong to a supported module,
it is changed to redirect to that module instead. For now this is all that should be supported,
it's very important that all modules use this method in the future to open external URLs.

Basic authentication, for now just use passwords to keep things simple. There should be at least an administrator role, or a separate account type, depending on which makes more sense. Administrators must create new accounts for now.

Each type of resource should get an additional column connecting it to a person. From this point on all queries should also filter on the logged in user.

Consider adding a standard interface for security. Ideally all security related code should be in specific files, so it's easier to verify as safe.

Feature

Document downloading will take the form of a rather intricate system when completed. The goal of the download system is to allow a user of the site to more easily share documents generated by the application. For now, only the report generated by time reports will be implemented. But this will become a standalone system, which other systems can use to upload their results.

Each download has a unique key. The shape of the key doesn't matter, as long as there aren't collisions and there is no reasonable way to guess the key. For now, all downloads are hidden but public. As long as the URL doesn't get leaked, it should be reasonably secure, but anyone with the URL can get the file without further authentication.

The URL should lead to a web page, with instructions for downloading the document. Documents can have various formats, and the user can choose the format they prefer. If there are more than one format, there is the option to download an archive containing all formats. Some formats are text-based formats, such as .txt or .md. These will also have a button linking to the data itself provided through HTTP. This can be used by advanced users using tools such as cURL, to access the file through a CLI.

Downloads should expire after 1 month. This will be expanded to be more flexible in the future. Downloads can also be manually removed.

Make it so time report comments each have their own rows when displayed. Then allow the user
to edit or delete the items.

Currently configuration is done directly with environment variables. Change it so it can be
passed to the main function, and then set it in reduce-main.

Expected behavior

Exiting mprocs stops all processes automatically.

Observed behavior

The process running docker compose doesn't close, and requires an additional ctrl+c.

Notes

There is probably a setting for this in the mprocs configuration.