Skip to content
Snippets Groups Projects
  1. Apr 04, 2024
  2. Mar 12, 2024
  3. Mar 03, 2024
  4. Feb 08, 2024
    • Julian Dominguez-Schatz's avatar
      Add rules with splits (#2059) · 2bb7b3c2
      Julian Dominguez-Schatz authored
      * Add split creation UI to rule creation modal
      
      * Support applying splits when rules execute
      
      * fix: deserialize transaction before running rules
      
      According to how rules are run in other places in the app, we should be
      supplying a "deserialized" (i.e., integer-for-amount and ISO date)
      transaction rather than a "serialized" (amount-plus-formatted-date) one.
      This fixes a crash in how split transactions are applied, as well as
      date-based rules not applying correctly previously (any rule with a date
      condition would never match on mobile).
      
      * Add release notes
      
      * Fix missing types pulled in from master
      
      * PR feedback: use `getActions`
      
      * PR feedback: use `flatMap`
      
      * Fix action deletion
      
      * Don't flicker upon split deletion
      
      * Let users specify parent transaction actions (e.g. linking schedules)
      
      * Support empty splits
      
      * Revert adding `no-op` action type
      
      * Support splits by percent
      
      * Fix types
      
      * Fix crash on transactions page when posting a transaction
      
      The crash would probably have occurred in other places too with
      auto-posting schedules :/
      
      * Fix a bug where schedules wouldn't be marked as completed
      
      This was because the query that we previously used didn't select parent
      transactions, so no transaction was marked as being scheduled (since
      only parent transactions have schedule IDs).
      
      * Add feature flag
      
      * Limit set actions within splits to fewer fields
      
      * Fix merge conflict
      
      * Don't run split rules if feature is disabled
      
      * Fix percent-based splits not applying
      
      * Fix crash when editing parent transaction amount
      
      * Auto-format
      
      * Attempt to fix failing tests
      
      * More test/bug fixes
      
      * Add an extra split at the end if there is a remaining amount
      
      * Make sure split has correct values for dynamic remainder
      
      * Remove extraneous console.log
      Unverified
      2bb7b3c2
  5. Jan 15, 2024
  6. Jan 12, 2024
  7. Dec 06, 2023
  8. Nov 22, 2023
  9. Aug 08, 2023
  10. Jun 28, 2023
  11. Jun 20, 2023
  12. Apr 10, 2023
    • Alberto Gasparin's avatar
      Convert commonjs to esm (#877) · cd00da76
      Alberto Gasparin authored
      This PR converts everything (aside from electron) from CommonJS to ESM.
      It is needed to reduce the changes that will happen during the migration
      to Typescript (as TS does not play nice with CJS).
      
      Basically:
      - rewrite `require()` to `import`
      - rewrite `module.exports` to `exports`
      - introduce `ts-node` to run importers so we can convert them to TS too
      
      Lastly, sorry for this larg-ish PR, not my preference but when I tried
      to reduce its scope, I would end up with mixed commons/esm that was even
      more tricky to handle.
      Unverified
      cd00da76
  13. Apr 03, 2023
    • Alberto Gasparin's avatar
      Convert loot-core to TS p1 (#841) · 79ad04dd
      Alberto Gasparin authored
      Part 1 of the conversion. Mostly renaming js to ts and making sure
      things make still sense. Added also handy TS ESLint rules.
      
      In order to support the various .web/.electron/... I ended up adopting
      `index.d.ts` as pattern to share type definition. Let me know if that
      makes sense for you too. Right now the function type definition is
      duplicated, but the solution will be importing from `index.d.ts` and
      using `const fn: FnDef = () => ...` that way we can keep all variants in
      sync from a single type file.
      
      Such rewrite however is better done in another PR otherwise we risk
      confusing git and loosing history (rename + too many changes). Another
      thing that might do in the next PR is convert all files to ESModules, as
      things get confusing between CJS exports, ESM default/named and TS adds
      extra complains.
      Unverified
      79ad04dd
  14. Feb 10, 2023
  15. Jan 10, 2023
  16. Sep 02, 2022
  17. Aug 23, 2022
  18. Apr 29, 2022
Loading