Add a command to stop the current 'ongoing fact'. That is to add an end date to a fact.

Pyhton arrow may be a simpler and more unified/tested solution to our time handling needs.

The original implementation falls back to datetime.time() if no end time is given.
That however translates to 00:00. Legacy hamster-cli help itself however claims it would default to 23:59.
Our original implementation stuck to the fauli behaviour in order to stay compatible.
Our new API however should correct that behaviour.

Also: it may be more sensible to respect configs day-end setting here instead of 23:59.

Due to legacy hamster-cli our Controler provides a dedicated time_range_parsing function (#25) that features a more flexible time pattern. We should adjust our parse_raw_fact method to make use of this extended flexibility as well.

In order to stay API compatible this should only happen once we are willing to break backwards compatibility.

Evaluate ways to allow for databasebase migration.
For our SQLAlchemy backend see here.
Should this be generalized? If so, how?

A a way to list all activities present in the backend.

• Activities means activities in the way our our librarsy, that is an name/category conbination.
• Activities should be retuned as an ordered list (by category).

By mimicing the original implementation our own version tries to do far to much.
Right now we do not only parse the info-string but also handle fallbacks and default logic.
This should be done seperatly.

One of the current downsides, just like in the legacy code, is that defaults are handled in various places.
Instead this method should just parse the string and return the decomposed instances.
We can then have a seperate method that evaluates those and may assign defaults/fallbacks. If this is to happen in the frontend or on the client level remains to be seen.

Also, it seems sensible to move this function to a helper module.

The original implementation creates normalized (lowercase etc.) versions of attribute fields to match search terms against.

Do we actually need this?

start in our initial implementation unifies two faculties:

1. Add a new fact. That is add a comlete fact with full start/end informaion
2. Start a "temporary fact" that is an incomplete fact, not stored in the backend until complete.

Timeframes as returned by hamsterlib.helpers.parse_time_info may miss some of their attribues and as a consequencec not provide a comple referenceframe.

This helper function applies our default fallback/autocomplete strategy in one central place and returns a complete (start, end) tuple of datetime objects.

Provide a command to show the current 'temporary fact' if there is one.

In the past we droped information about legacy hamsters 'API' and expected behaviour right into our codebase. With this release we should clean out those.
If we feel the information is still relevant it should be move into the regular documentation.

Right now, we use the original libs general spec to disect time information when parsing a raw_fact.

The legacy client code however allows much more elaborate time specifications as well as providing a nice parsing function.

In order to avoid reimplementing this in every client, our Controler should provide a parse_time_info method that takes care of that.

Note: This new method may also be utilized by our parse_raw_fact method at a later point.

At least check if end>start.

If hamster_gtk is present, provide a way to launch specific windows/interfaces/views.
If not, provide meaningfull feedback.

Throughout initial development we placed several # [FIXME] Blocks to indicate issues that we need to have a look at later on, once the initial dust has settled.
These can only be short term solutions. We need to go through them and either turn them into proper issues or remove them if they have been rendered obsolete by now.

I suspect SQLAlchemy takes care of this, but we need to doublecheck.

The original implemenation has a rather convoluted concept of a Fact.date and how this relates to __get_facts. Also see legacy information.

The way the original implementation does this is by fetching all facts deemed relevant and assign them date and delta. this is no option for a pure lookup method. We clearly can not look facts up by those properties and in light of an unknown amount of return values this needs to be handled somewhere else. This is where our Hamster.Fact()-properties shine. However, that also means that we can no look up facts by date!

Our first incarnations simply this significantly. A fact.date is the date of a facts startdate.
At some point we should investigate if/how we refactor this to satisfy original API requirements.

Right now, facts.save() will be very accomodating and call _start_tmp_fact if it recieves a fact without end. This makes adding ongoing facts very transparent.
Is this bug or feature? The alternative would be to return an error, suggesting to client to use a dedicated public start_tmp_fat method.

The relevant RFC

store.facts needs a way to retrieve the current ongoing fact. Should return KeyError if ther is none.

Command to list all Facts in a given timeframe.

• start/end time.

For obvious reasons this should be public.

Besides filtering by timeframe, we also want to allow to just match certain terms.

According to this we need to match it against the following:

• fact.activity.name
• fact.category.name
• fact.tag.name

Originaly we wanted to keep any notion of 'ongoing facts' strictly on in the frontend/client-code.

This however, causes problems, for example with representing a Fact missing attributes at a given point.

Whilst we stick to our decission and will not store any ongoing facts our hamsterli object itself will have a ongoing property that allows for easy checks.

instance -> https://github.com/elbenfreund/hamsterlib/blob/develop/hamsterlib/objects.py#L19

storage.facts needs a way to cancel any present ongoing fact.

Maybe use jinja?

Add a command to to export existing facts to one of various files.

supported file formats:

• html
• tsv
• ical
• xml

Right now, category names are case sensitive and unique. This in itself is not a problem.
However, if we later come to decide that search is to be case insensetive, we may up with several results for one search string despite the uniqueness constraint.

We will have to decide if this is desired behavior and we deal with multiple results or if it is preferable to enforce "case insensitive uniqueness" and avoid such subtleties.

six, sqlalchemy and fauxfactory need to be added to isorts 3rd party modules

The old code seems to order the returned list by the related facts start time.

legacy hamster provides a basic reports module. In order to stay compatible we should adjust it as far as feasable and incorporate it into hamsterlib.

The packaged version on pypi does not include the sqlalchemy backend.

Our current method does not match the legacy functionality.
Although some bizzare unused function in hamster-cli does specify categories this is actually not relevant for us.
Instead this method is to return:

• list of all activities
• optionaly searched against activity.name (insensitive)
• ordered by activity name

Users can search existing Facts against a string within an optional timeframe.

• start/end time is optional
• string matches against a facts activity name

Add a command to list facts matching certain criteria ..

Note: How is this different from list command.

When Fact.create_from_raw_fact.parse_time_infois not passed a valid start time, it falls back to 00:00 of the start date. However, to be consistent with the rest of it may be desirable to fall back to the configuresday_start` value from our config instead.

Basic CRUD operations of our storage backend should always log their results as debug().

by category.name