1. 21 Sep, 2022 2 commits
  2. 20 Sep, 2022 1 commit
  3. 19 Sep, 2022 2 commits
  4. 18 Sep, 2022 1 commit
  5. 11 Aug, 2022 1 commit
  6. 10 Aug, 2022 2 commits
  7. 04 Aug, 2022 1 commit
  8. 03 May, 2022 3 commits
  9. 24 Apr, 2022 7 commits
    • Konrad Mohrfeldt's avatar
      fix: properly handle steering scheduling API errors · e01a3692
      Konrad Mohrfeldt authored
      The steering API returns HTTP 400 errors for general payload and 409
      errors for scheduling conflicts that we didn’t handle yet.
      fixes #93
    • Konrad Mohrfeldt's avatar
      feat: add ServerErrors component · 4a07ad9e
      Konrad Mohrfeldt authored
      A simple b-alert list wrapper that handles the standard error format
      from Django REST framework.
    • Konrad Mohrfeldt's avatar
      feat: allow views to check if a translation key exists · 690a1cf8
      Konrad Mohrfeldt authored
      Views may want to display a fallback message if the translation key does
      not exist.
    • Konrad Mohrfeldt's avatar
      refactor: update old schedule attribute names · cb84bfe6
      Konrad Mohrfeldt authored
      The steering API has some deprecated attribute names that we should no
      longer use. These are:
        dstart → first_date
        until → last_date
        tstart → start_time
        tend → end_time
        byweekday → by_weekday
      These changes in naming have also been applied to variable names,
      attribute names and translatations in the dashboard code in order to
      avoid confusion.
    • Konrad Mohrfeldt's avatar
      feat: allow API store consumers to use traditional flow-control · f4da882f
      Konrad Mohrfeldt authored
      The currently prevalent API response handling is based on a callback
      pattern. This has at least two major drawbacks:
      1. More broadly it facilitates the use of nested callbacks, which make
         the code harder to read and clutter stack traces.
      2. Our specific callback solution does not follow the traditional node
         callback pattern that looks like `function (err, data) { ... }`.
         Instead we have `callback` and `callbackCancel`, none of which are
         meant to handle actual error/exception objects.
      The latter makes it hard to write code that is executed irrespective of
      the specific code path, like in a try-finally clause. In practice it’s
      also a violation of the separation-of-concerns design principle as it
      forces error handling to happen in the store function instead of the
      caller that is best suited to handle error states.
      This change attempts to facilitate a gradual migration to a
      Promise-based result handling by it to co-exist with the currently used
      callback pattern. Callers that don’t provide any callback functions are
      assumed to handle promises whereas callers that do provide callback
      functions will see no change in behaviour.
      This allows us to transition one API-call at a time instead of doing one
      large and time-consuming refactoring.
      refs #55
    • Konrad Mohrfeldt's avatar
      feat: add has helper-function · 6fd3bef2
      Konrad Mohrfeldt authored
    • Konrad Mohrfeldt's avatar
      refactor: clean up time & date functions · 1140b802
      Konrad Mohrfeldt authored
      * replace all `var` declarations and use `const` where appropriate
      * strip unnecessary temporary variables
      * replace single character variable names
      * replace multiline variable declarations
      * simplify expressions
      * replace invalid uses of parseInt
  10. 23 Apr, 2022 1 commit
  11. 22 Apr, 2022 3 commits
  12. 21 Apr, 2022 1 commit
  13. 29 Mar, 2022 4 commits
  14. 28 Mar, 2022 5 commits
  15. 25 Mar, 2022 6 commits