diff --git a/CHANGELOG.md b/CHANGELOG.md index 9ce354b1e..26b71ea03 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,8 +4,21 @@ All notable changes to this project will be documented in this file. Dates are d Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog). +#### [1.15.0](https://github.com/gradido/gradido/compare/1.14.1...1.15.0) + +- fix(database): wrong balance and decay values [`#2423`](https://github.com/gradido/gradido/pull/2423) +- fix(backend): wrong balance after transaction receive [`#2422`](https://github.com/gradido/gradido/pull/2422) +- feat(other): feature gradido roadmap [`#2301`](https://github.com/gradido/gradido/pull/2301) +- refactor(backend): new password encryption implementation [`#2353`](https://github.com/gradido/gradido/pull/2353) +- refactor(admin): statistics in a table and on separate page in admin area [`#2399`](https://github.com/gradido/gradido/pull/2399) +- feat(backend): 🍰 Email Templates [`#2163`](https://github.com/gradido/gradido/pull/2163) +- fix(backend): timezone problems [`#2393`](https://github.com/gradido/gradido/pull/2393) + #### [1.14.1](https://github.com/gradido/gradido/compare/1.14.0...1.14.1) +> 14 November 2022 + +- chore(release): version 1.14.1 - hotfix [`#2391`](https://github.com/gradido/gradido/pull/2391) - fix(frontend): load contributionMessages is fixed [`#2390`](https://github.com/gradido/gradido/pull/2390) #### [1.14.0](https://github.com/gradido/gradido/compare/1.13.3...1.14.0) diff --git a/admin/package.json b/admin/package.json index 7f0e7ffd5..75800a526 100644 --- a/admin/package.json +++ b/admin/package.json @@ -3,7 +3,7 @@ "description": "Administraion Interface for Gradido", "main": "index.js", "author": "Moriz Wahl", - "version": "1.14.1", + "version": "1.15.0", "license": "Apache-2.0", "private": false, "scripts": { diff --git a/backend/.env.dist b/backend/.env.dist index 3b6fe2ce4..c0a2a6098 100644 --- a/backend/.env.dist +++ b/backend/.env.dist @@ -1,4 +1,4 @@ -CONFIG_VERSION=v11.2022-10-27 +CONFIG_VERSION=v12.2022-11-10 # Server PORT=4000 @@ -61,7 +61,8 @@ EVENT_PROTOCOL_DISABLED=false # POSSIBLE VALUES: all | trace | debug | info | warn | error | fatal # LOG_LEVEL=info -# DHT -# if you set this value, the DHT hyperswarm will start to announce and listen -# on an hash created from this tpoic -# DHT_TOPIC=GRADIDO_HUB +# Federation +# if you set the value of FEDERATION_DHT_TOPIC, the DHT hyperswarm will start to announce and listen +# on an hash created from this topic +# FEDERATION_DHT_TOPIC=GRADIDO_HUB +# FEDERATION_DHT_SEED=64ebcb0e3ad547848fef4197c6e2332f diff --git a/backend/.env.template b/backend/.env.template index d009d08ff..1bb2e4155 100644 --- a/backend/.env.template +++ b/backend/.env.template @@ -56,5 +56,6 @@ WEBHOOK_ELOPAGE_SECRET=$WEBHOOK_ELOPAGE_SECRET # EventProtocol EVENT_PROTOCOL_DISABLED=$EVENT_PROTOCOL_DISABLED -# DHT -DHT_TOPIC=$DHT_TOPIC +# Federation +FEDERATION_DHT_TOPIC=$FEDERATION_DHT_TOPIC +FEDERATION_DHT_SEED=$FEDERATION_DHT_SEED diff --git a/backend/package.json b/backend/package.json index 3e26225bf..519f9e6c0 100644 --- a/backend/package.json +++ b/backend/package.json @@ -1,6 +1,6 @@ { "name": "gradido-backend", - "version": "1.14.1", + "version": "1.15.0", "description": "Gradido unified backend providing an API-Service for Gradido Transactions", "main": "src/index.ts", "repository": "https://github.com/gradido/gradido/backend", @@ -19,13 +19,7 @@ }, "dependencies": { "@hyperswarm/dht": "^6.2.0", - "@types/email-templates": "^10.0.1", - "@types/i18n": "^0.13.4", - "@types/jest": "^27.0.2", - "@types/lodash.clonedeep": "^4.5.6", - "@types/uuid": "^8.3.4", "apollo-server-express": "^2.25.2", - "apollo-server-testing": "^2.25.2", "axios": "^0.21.1", "class-validator": "^0.13.1", "cors": "^2.8.5", @@ -46,18 +40,23 @@ "random-bigint": "^0.0.1", "reflect-metadata": "^0.1.13", "sodium-native": "^3.3.0", - "ts-jest": "^27.0.5", "type-graphql": "^1.1.1", "uuid": "^8.3.2" }, "devDependencies": { + "@types/email-templates": "^10.0.1", "@types/express": "^4.17.12", "@types/faker": "^5.5.9", + "@types/i18n": "^0.13.4", + "@types/jest": "^27.0.2", "@types/jsonwebtoken": "^8.5.2", + "@types/lodash.clonedeep": "^4.5.6", "@types/node": "^16.10.3", "@types/nodemailer": "^6.4.4", + "@types/uuid": "^8.3.4", "@typescript-eslint/eslint-plugin": "^4.28.0", "@typescript-eslint/parser": "^4.28.0", + "apollo-server-testing": "^2.25.2", "eslint": "^7.29.0", "eslint-config-prettier": "^8.3.0", "eslint-config-standard": "^16.0.3", @@ -66,8 +65,10 @@ "eslint-plugin-prettier": "^3.4.0", "eslint-plugin-promise": "^5.1.0", "faker": "^5.5.3", + "jest": "^27.2.4", "nodemon": "^2.0.7", "prettier": "^2.3.1", + "ts-jest": "^27.0.5", "ts-node": "^10.0.0", "tsconfig-paths": "^3.14.0", "typescript": "^4.3.4" diff --git a/backend/src/config/index.ts b/backend/src/config/index.ts index 26227b90d..c9e5ea79f 100644 --- a/backend/src/config/index.ts +++ b/backend/src/config/index.ts @@ -10,14 +10,14 @@ Decimal.set({ }) const constants = { - DB_VERSION: '0053-change_password_encryption', + DB_VERSION: '0054-recalculate_balance_and_decay', DECAY_START_TIME: new Date('2021-05-13 17:46:31-0000'), // GMT+0 LOG4JS_CONFIG: 'log4js-config.json', // default log level on production should be info LOG_LEVEL: process.env.LOG_LEVEL || 'info', CONFIG_VERSION: { DEFAULT: 'DEFAULT', - EXPECTED: 'v11.2022-10-27', + EXPECTED: 'v12.2022-11-10', CURRENT: '', }, } @@ -117,7 +117,8 @@ if ( } const federation = { - DHT_TOPIC: process.env.DHT_TOPIC || null, + FEDERATION_DHT_TOPIC: process.env.FEDERATION_DHT_TOPIC || null, + FEDERATION_DHT_SEED: process.env.FEDERATION_DHT_SEED || null, } const CONFIG = { diff --git a/backend/src/federation/index.ts b/backend/src/federation/index.ts index 2ca58b432..82b961c63 100644 --- a/backend/src/federation/index.ts +++ b/backend/src/federation/index.ts @@ -4,11 +4,16 @@ import DHT from '@hyperswarm/dht' // import { Connection } from '@dbTools/typeorm' import { backendLogger as logger } from '@/server/logger' +import CONFIG from '@/config' function between(min: number, max: number) { return Math.floor(Math.random() * (max - min + 1) + min) } +const KEY_SECRET_SEEDBYTES = 32 +const getSeed = (): Buffer | null => + CONFIG.FEDERATION_DHT_SEED ? Buffer.alloc(KEY_SECRET_SEEDBYTES, CONFIG.FEDERATION_DHT_SEED) : null + const POLLTIME = 20000 const SUCCESSTIME = 120000 const ERRORTIME = 240000 @@ -27,8 +32,9 @@ export const startDHT = async ( ): Promise => { try { const TOPIC = DHT.hash(Buffer.from(topic)) - - const keyPair = DHT.keyPair() + const keyPair = DHT.keyPair(getSeed()) + logger.info(`keyPairDHT: publicKey=${keyPair.publicKey.toString('hex')}`) + logger.debug(`keyPairDHT: secretKey=${keyPair.secretKey.toString('hex')}`) const node = new DHT({ keyPair }) diff --git a/backend/src/index.ts b/backend/src/index.ts index dc1bbb115..e63f80827 100644 --- a/backend/src/index.ts +++ b/backend/src/index.ts @@ -19,8 +19,14 @@ async function main() { }) // start DHT hyperswarm when DHT_TOPIC is set in .env - if (CONFIG.DHT_TOPIC) { - await startDHT(CONFIG.DHT_TOPIC) // con, + if (CONFIG.FEDERATION_DHT_TOPIC) { + // eslint-disable-next-line no-console + console.log( + `starting Federation on ${CONFIG.FEDERATION_DHT_TOPIC} ${ + CONFIG.FEDERATION_DHT_SEED ? 'with seed...' : 'without seed...' + }`, + ) + await startDHT(CONFIG.FEDERATION_DHT_TOPIC) // con, } } diff --git a/database/Dockerfile b/database/Dockerfile index 4069ffcd8..03c7d9a3b 100644 --- a/database/Dockerfile +++ b/database/Dockerfile @@ -100,6 +100,8 @@ COPY --from=build ${DOCKER_WORKDIR}/node_modules ./node_modules COPY --from=build ${DOCKER_WORKDIR}/package.json ./package.json # Copy Mnemonic files COPY --from=build ${DOCKER_WORKDIR}/src/config/*.txt ./src/config/ +# Copy log folder +COPY --from=build ${DOCKER_WORKDIR}/log ./log # Copy run scripts run/ # COPY --from=build ${DOCKER_WORKDIR}/run ./run diff --git a/database/log/.gitignore b/database/log/.gitignore new file mode 100644 index 000000000..c96a04f00 --- /dev/null +++ b/database/log/.gitignore @@ -0,0 +1,2 @@ +* +!.gitignore \ No newline at end of file diff --git a/database/migrations/0054-recalculate_balance_and_decay.ts b/database/migrations/0054-recalculate_balance_and_decay.ts new file mode 100644 index 000000000..516d0d1e3 --- /dev/null +++ b/database/migrations/0054-recalculate_balance_and_decay.ts @@ -0,0 +1,160 @@ +/* MIGRATION TO FIX WRONG BALANCE + * + * Due to a bug in the code + * the amount of a receive balance is substracted + * from the previous balance instead of added. + * + * Therefore all balance and decay fields must + * be recalculated + * + * WARNING: This Migration must be run in TZ=UTC + */ + +/* eslint-disable @typescript-eslint/explicit-module-boundary-types */ +/* eslint-disable @typescript-eslint/no-explicit-any */ + +import fs from 'fs' +import Decimal from 'decimal.js-light' + +// Set precision value +Decimal.set({ + precision: 25, + rounding: Decimal.ROUND_HALF_UP, +}) + +const DECAY_START_TIME = new Date('2021-05-13 17:46:31') // GMT+0 + +interface Decay { + balance: Decimal + decay: Decimal | null + start: Date | null + end: Date | null + duration: number | null +} + +export enum TransactionTypeId { + CREATION = 1, + SEND = 2, + RECEIVE = 3, +} + +function decayFormula(value: Decimal, seconds: number): Decimal { + return value.mul(new Decimal('0.99999997803504048973201202316767079413460520837376').pow(seconds)) +} + +function calculateDecay( + amount: Decimal, + from: Date, + to: Date, + startBlock: Date = DECAY_START_TIME, +): Decay { + const fromMs = from.getTime() + const toMs = to.getTime() + const startBlockMs = startBlock.getTime() + + if (toMs < fromMs) { + throw new Error('to < from, reverse decay calculation is invalid') + } + + // Initialize with no decay + const decay: Decay = { + balance: amount, + decay: null, + start: null, + end: null, + duration: null, + } + + // decay started after end date; no decay + if (startBlockMs > toMs) { + return decay + } + // decay started before start date; decay for full duration + if (startBlockMs < fromMs) { + decay.start = from + decay.duration = (toMs - fromMs) / 1000 + } + // decay started between start and end date; decay from decay start till end date + else { + decay.start = startBlock + decay.duration = (toMs - startBlockMs) / 1000 + } + + decay.end = to + decay.balance = decayFormula(amount, decay.duration) + decay.decay = decay.balance.minus(amount) + return decay +} + +export async function upgrade(queryFn: (query: string, values?: any[]) => Promise>) { + // Write log file + const logFile = 'log/0054-recalculate_balance_and_decay.log.csv' + await fs.writeFile( + logFile, + `email;first_name;last_name;affected_transactions;new_balance;new_decay;old_balance;old_decay;delta;\n`, + (err) => { + if (err) throw err + }, + ) + + // Find all users & loop over them + const users = await queryFn('SELECT user_id FROM transactions GROUP BY user_id;') + for (let u = 0; u < users.length; u++) { + const userId = users[u].user_id + // find all transactions for a user + const transactions = await queryFn( + `SELECT *, CONVERT(balance, CHAR) as dec_balance, CONVERT(decay, CHAR) as dec_decay FROM transactions WHERE user_id = ${userId} ORDER BY balance_date ASC;`, + ) + + let previous = null + let affectedTransactions = 0 + let balance = new Decimal(0) + for (let t = 0; t < transactions.length; t++) { + const transaction = transactions[t] + const decayStartDate = previous ? previous.balance_date : transaction.balance_date + const amount = new Decimal(transaction.amount) + const decay = calculateDecay(balance, decayStartDate, transaction.balance_date) + balance = decay.balance.add(amount) + + const userContact = await queryFn( + `SELECT email, first_name, last_name FROM users LEFT JOIN user_contacts ON users.email_id = user_contacts.id WHERE users.id = ${userId}`, + ) + const userEmail = userContact.length === 1 ? userContact[0].email : userId + const userFirstName = userContact.length === 1 ? userContact[0].first_name : '' + const userLastName = userContact.length === 1 ? userContact[0].last_name : '' + + // Update if needed + if (!balance.eq(transaction.dec_balance)) { + await queryFn(` + UPDATE transactions SET + balance = ${balance}, + decay = ${decay.decay ? decay.decay : 0} + WHERE id = ${transaction.id}; + `) + affectedTransactions++ + + // Log on last entry + if (t === transactions.length - 1) { + fs.appendFile( + logFile, + `${userEmail};${userFirstName};${userLastName};${affectedTransactions};${balance};${ + decay.decay ? decay.decay : 0 + };${transaction.dec_balance};${transaction.dec_decay};${balance.sub( + transaction.dec_balance, + )};\n`, + (err) => { + if (err) throw err + }, + ) + } + } + + // previous + previous = transaction + } + } +} + +/* eslint-disable @typescript-eslint/no-empty-function */ +/* eslint-disable-next-line @typescript-eslint/no-unused-vars */ +export async function downgrade(queryFn: (query: string, values?: any[]) => Promise>) {} diff --git a/database/package.json b/database/package.json index 6216a25fb..abc7789c4 100644 --- a/database/package.json +++ b/database/package.json @@ -1,6 +1,6 @@ { "name": "gradido-database", - "version": "1.14.1", + "version": "1.15.0", "description": "Gradido Database Tool to execute database migrations", "main": "src/index.ts", "repository": "https://github.com/gradido/gradido/database", diff --git a/deployment/bare_metal/.env.dist b/deployment/bare_metal/.env.dist index 1d0e96455..9c6bfd735 100644 --- a/deployment/bare_metal/.env.dist +++ b/deployment/bare_metal/.env.dist @@ -26,7 +26,7 @@ COMMUNITY_REDEEM_CONTRIBUTION_URL=https://stage1.gradido.net/redeem/CL-{code} COMMUNITY_DESCRIPTION="Gradido Development Stage1 Test Community" # backend -BACKEND_CONFIG_VERSION=v11.2022-10-27 +BACKEND_CONFIG_VERSION=v12.2022-11-10 JWT_EXPIRES_IN=10m GDT_API_URL=https://gdt.gradido.net @@ -59,10 +59,11 @@ WEBHOOK_ELOPAGE_SECRET=secret # EventProtocol EVENT_PROTOCOL_DISABLED=false -## DHT -## if you set this value, the DHT hyperswarm will start to announce and listen -## on an hash created from this tpoic -# DHT_TOPIC=GRADIDO_HUB +# Federation +# if you set the value of FEDERATION_DHT_TOPIC, the DHT hyperswarm will start to announce and listen +# on an hash created from this topic +# FEDERATION_DHT_TOPIC=GRADIDO_HUB +# FEDERATION_DHT_SEED=64ebcb0e3ad547848fef4197c6e2332f # database DATABASE_CONFIG_VERSION=v1.2022-03-18 diff --git a/docu/Concepts/BusinessRequirements/Zeitzonen_Behandlung.md b/docu/Concepts/BusinessRequirements/Zeitzonen_Behandlung.md new file mode 100644 index 000000000..771526ffb --- /dev/null +++ b/docu/Concepts/BusinessRequirements/Zeitzonen_Behandlung.md @@ -0,0 +1,379 @@ +# Zeitzonen + +Die Gradido-Anwendung läuft im Backend in der Zeitzone UTC und im Frontend in der jeweiligen lokalen Zeitzone, in der der User sich anmeldet. Dadurch kann es zu zeitlichen Diskrepanzen kommen, die innerhalb der Anwendungslogik aufgelöst bzw. entsprechend behandelt werden müssen. In den folgenden Kapiteln werden die verschiedenen zeitlichen Konstellationen dargestellt und für die verschiedenen fachlichen Prozesse die daraus resultierenden Problemlösungen beschrieben. + +![img](./image/ZeitzonenKonstellationen.png) + +## Beispiel 1 + +Ein User meldet sich in einer Zeitzone t0 - 4 an. Das bedeutet der User liegt 4 Stunden gegenüber der Backend-Zeit zurück. + +Konkret hat der User die Zeit 31.08.2022 21:00:00 auf dem Server ist aber die Zeit bei 01.09.2022 01:00:00 + +Für die Erstellung einer Contribution hat der User noch folgende Gültigkeitsmonate und Beträge zur Wahl: + + Juni 2022: 500 GDD | Juli 2022: 200 GDD | August 2022: 1000 GDD + +**aber das Backend liefert nur die Beträge, die eigentlich so korrekt wären!!!!!** + + **Juli 2022: 200 GDD | August 2022: 1000 GDD | September 2022: 1000 GDD** + +Er möchte für den Juni 2022 eine Contribution mit 500 GDD erfassen. **Wird ihm der Juni noch als Schöpfungsmonat angezeigt?** + +Falls ja, dann wählt er dabei im FE im Kalender den 30.06.2022. Dann liefert das FE folgende Contribution-Daten an das Backend: + +* Gültigkeitsdatum: 30.06.2022 00:00:00 +* Memo: text +* Betrag: 500 GDD +* **Zeitzone: wird eine Zeitzone des User aus dem Context geliefert? Das fehlt: entweder über eine Zeit vom FE zum BE und ermitteln Offset im BE** + +Im Backend wird dieses dann interpretiert und verarbeitet mit: + +* **Belegung des Schöpfungsmonate-Arrays: [ 6, 7, 8] oder [7, 8, 9] da auf dem Server ja schon der 01.09.2022 ist?** +* Gültigkeitsdatum: **30.06.2022 00:00:00 oder 01.07.2022 04:00:00 ?** +* Memo: text +* Betrag 500 GDD +* created_at: 01.07.2022 04:00:00 + +**Frage: wird die Contribution dem Juni (6) oder dem Juli (7) zugeordnet?** + +1. falls Juni zugeordnet kann die Contribution mit 500 GDD eingelöst werden +2. falls Juli zugeordnet muss die Contribution mit 500 GDD abgelehnt werden, da möglicher Schöpfungsbetrag überschritten + + +## Beispiel 2 + + +Ein User meldet sich in einer Zeitzone t0 + 1 an. Das bedeutet der User liegt 1 Stunde gegenüber der Backend-Zeit voraus. + +Konkret hat der User die Zeit 01.09.2022 00:20:00 auf dem Server ist aber die Zeit bei 31.08.2022 23:20:00 + +Für die Erstellung einer Contribution hat der User noch folgende Gültigkeitsmonate und Beträge zur Wahl: + + Juli 2022: 200 GDD | August 2022: 1000 GDD | September 2022: 1000 GDD + +**oder wird ihm** + +** + Juni 2022: 500 GDD | Juli 2022: 200 GDD | August 2022: 1000 GDD** + +**angezeigt, da auf dem BE noch der 31.08.2022 ist?** + +Er möchte für den September 2022 eine Contribution mit 500 GDD erfassen und wählt dabei im FE im Kalender den 01.09.2022. Dann liefert das FE folgende Contribution-Daten an das Backend: + +* Gültigkeitsdatum: 01.09.2022 00:00:00 (siehe Logauszüge der Fehleranalyse im Ticket #2179) +* Memo: text +* Betrag: 500 GDD +* **Zeitzone: wird eine Zeitzone des User aus dem Context geliefert?** + +Im Backend wird dieses dann interpretiert und verarbeitet mit: + +* Belegung des Schöpfungsmonate-Arrays: [ 6, 7, 8] **wie kann der User dann aber vorher September 2022 für die Schöpfung auswählen?** +* Gültigkeitsdatum: 01.09.2022 00:00:00 +* Memo: text +* Betrag 500 GDD +* created_at: 31.08.2022 23:20:00 + +Es kommt zu einem **Fehler im Backend**, da im Schöpfungsmonate-Array kein September (9) vorhanden ist, da auf dem Server noch der 31.08.2022 und damit das Array nur die Monate Juni, Juli, August und nicht September beinhaltet. + + +## Erkenntnisse: + +* die dem User angezeigten Schöpfungsmonate errechnen sich aus der lokalen User-Zeit und nicht aus der Backend-Zeit + * das Backend muss somit für Ermittlung der möglichen Schöpfungsmonate und deren noch freien Schöpfungssummen den UserTimeOffset berücksichten +* der gewählte Schöpfungsmonat muss 1:1 vom Frontend in das Backend übertragen werden +* es darf kein Mapping in die Backend-Zeit erfolgen + * sondern es muss der jeweilige UserTimeOffset mitgespeichert werden +* die Logik im BE muss den übertragenen bzw. ermittelten Offset der FE-Zeit entsprechend berücksichten und nicht die Backendzeit in der Logik anwenden + * im BE darf es kein einfaches now = new Date() geben + * im BE muss stattdessen ein userNow = new Date() + UserTimeOffset verwendet werden +* ein CreatedAt / UpdatedAt / DeletedAt / ConfirmedAt wird wie bisher in BE-Zeit gespeichert + * **NEIN nicht notwendig:** plus in einer jeweils neuen Spalte CreatedOffset / UpdatedOffset / DeletedOffset / ConfirmedOffset der dabei gültige UserTimeOffset +* im FE wird immer im Request-Header der aktuelle Zeitpunkt mit Zeitzone geschrieben +* + +## Entscheidung + +* in den HTTP-Request-Header wird generell der aktuelle Timestamp des Clients eingetragen, sodass die aktuelle Uhrzeit des Users ohne weitere Signatur-Änderungen in jedem Aufruf am Backend ankommt. Moritz erstellt Ticket +* es wird eine Analyse aller Backend-Aufrufe gemacht, die die Auswertung der User-Time und dessen evtl. Timezone-Differenz in der Logik des Backend-Aufrufs benötigt. +* diese Backend-Methoden müssen fachlich so überarbeitet werden, dass immer aus dem Timezone-Offset die korrekte fachliche Logik als Ergebnis heraus kommt. In der Datenbank wird aber immer die UTC-Zeit gespeichert. +* Es werden keine zusätzlichen Datanbank-Attribute zur Speicherung des User-TimeOffsets benötigt. + + +## Analyse der Backend-Aufrufe + +Es werden alle Resolver und ihre Methoden sowie im Resolver exportierte Attribute/Methoden untersucht. + +Mit + gekennzeichnet sind diese, die mit dem UserTimeOffset interagieren und überarbeitet werden müssen. + +Mit - gekennzeichnet sind diese, die keiner weiteren Aktion bedürfen. + + +### AdminResolver + +#### + adminCreateContribution + +Hier wird der User zur übergebenen Email inklusive der Summen über die letzten drei Schöpfungsmonate aus seinen vorhandenen Contributions, egal ob bestätigt oder noch offen ermittelt. + +Hier muss der User-TimeOffset berücksichtigt werden, um die korrekten drei Schöpfungsmonate und dann daraus die korrekten Beträge der Contributions zu ermitteln. + +Zusätzlich wird als Parameter ein *creationDate* vom User mitgeliefert, das dem User-TimeOffset unterliegt. Auch dieses muss entsprechend beachtet und beim internen Aufruf von *validateContribution()* und der Initialisierung der Contribution berücksichtigt werden. + +#### - adminCreateContributionMessage + +nothing to do + +#### + adminCreateContributions + +Hier wird eine Liste von übergebenen Contributions über den internen Aufruf von *adminCreateContribution()* verarbeitet. Da dort eine Berücksichtigung des User-TimeOffsets notwendig ist, muss hier die UserTime entsprechen im Context weitergereicht werden. + +#### - adminDeleteContribution + +nothing to do + +#### + adminUpdateContribution + +analog adminCreateContribution() muss hier der User-TimeOffset berücksichtigt werden. + +#### + confirmContribution + +Hier wird intern *getUserCreation()* und *validateContribution()* aufgerufen, daher analog adminCreateContribution() + +#### + createContributionLink + +Hier werden zwar ein *ValidFrom* und ein *ValidTo* Datum übergeben, doch dürften diese keiner Beachtung eines User-TimezoneOffsets unterliegen. Trotzdem bitte noch einmal verifizieren. + +#### - creationTransactionList + +nothing to do + +#### - deleteContributionLink + +Es wird zwar der *deletedAt*-Zeitpunkt als Rückgabewert geliefert, doch m.E. dürft hier keine Berücksichtigung des User-TimezoneOffsets notwendig sein. + +#### - deleteUser + +Es wird zwar der *deletedAt*-Zeitpunkt als Rückgabewert geliefert, doch m.E. dürft hier keine Berücksichtigung des User-TimezoneOffsets notwendig sein. + +#### - listContributionLinks + +nothing to do + +#### + listTransactionLinksAdmin + +Hier wird die BE-Zeit für die Suche nach ValidUntil verwendet. Dies sollte nocheinmal verifiziert werden. + +#### + listUnconfirmedContributions + +Hier wird intern *getUserCreations()* aufgerufen für die Summen der drei Schöpfungsmonate, somit ist der User-TimezoneOffset zu berücksichtigen. + +#### + searchUsers + +Hier wird intern *getUserCreations()* aufgerufen für die Summen der drei Schöpfungsmonate, somit ist der User-TimezoneOffset zu berücksichtigen. + +#### - sendActivationEmail + +analog *UserResolver.checkOptInCode* + +#### - setUserRole + +nothing to do + +#### - unDeleteUser + +nothing to do + +#### + updateContributionLink + +Hier werden zwar ein *ValidFrom* und ein *ValidTo* Datum übergeben, doch dürften diese keiner Beachtung eines User-TimezoneOffsets unterliegen. Trotzdem bitte noch einmal verifizieren. + + +### BalanceResolver + +#### + balance + +Hier wird der aktuelle Zeitpunkt des BE verwendet, um den Decay und die Summen der Kontostände zu ermitteln. Dies müsste eigentlich von dem User-TimezoneOffset unabhängig sein. Sollte aber noch einmal dahingehend verifiziert werden. + + +### CommunityResolver + +#### - communities + +nothing to do + +#### - getCommunityInfo + +nothing to do + + +### ContributionMessageResolver + +#### - createContributionMessage + +nothing to do + +#### - listContributionMessages + +nothing to do + + +### ContributionResolver + +#### + createContribution + +Hier wird der User inklusive der Summen über die letzten drei Schöpfungsmonate aus seinen vorhandenen Contributions, egal ob bestätigt oder noch offen ermittelt. + +Hier muss der User-TimeOffset berücksichtigt werden, um die korrekten drei Schöpfungsmonate und dann daraus die korrekten Beträge der Contributions zu ermitteln. + +Zusätzlich wird als Parameter ein *creationDate* vom User mitgeliefert, das dem User-TimeOffset unterliegt. Auch dieses muss entsprechend beachtet und beim internen Aufruf von *validateContribution()* und der Initialisierung der Contribution berücksichtigt werden. + +#### - deleteContribution + +nothing to do + +#### - listAllContributions + +nothing to do + +#### - listContributions + +nothing to do + +#### + updateContribution + +Hier werden die Contributions des Users inklusive der Summen über die letzten drei Schöpfungsmonate aus seinen vorhandenen Contributions, egal ob bestätigt oder noch offen ermittelt. + +Hier muss der User-TimeOffset berücksichtigt werden, um die korrekten drei Schöpfungsmonate und dann daraus die korrekten Beträge der Contributions zu ermitteln. + +Zusätzlich wird als Parameter ein *creationDate* vom User mitgeliefert, das dem User-TimeOffset unterliegt. Auch dieses muss entsprechend beachtet und beim internen Aufruf von *validateContribution()* und dem Update der Contribution berücksichtigt werden. + +### GdtResolver + +#### - existPid + +nothing to do + +#### - gdtBalance + +nothing to do + +#### - listGDTEntries + +nothing to do + + +### KlicktippResolver + +nothing to do + + +### StatisticsResolver + +#### + communityStatistics + +Hier werden die Daten zum aktuellen BE-Zeitpunkt ermittelt und dem User angezeigt. Aber der User hat ggf. einen anderen TimeOffset. Daher die Frage, ob die Ermittlung der Statistik-Daten mit dem User-TimeOffset stattfinden muss. + + +### TransactionLinkResolver + +#### - transactionLinkCode + +nothing to do + +#### - transactionLinkExpireDate + +nothing to do + +#### - createTransactionLink + +nothing to do + +#### - deleteTransactionLink + +nothing to do + +#### - listTransactionLinks + +nothing to do + +#### - queryTransactionLink + +nothing to do + +#### - redeemTransactionLink + +nothing to do + + +### TransactionResolver + +#### - executeTransaction + +nothing to do + +#### - sendCoins + +nothing to do + +#### + transactionList + +Hier wird der aktuelle BE-Zeitpunkt verwendet, um die Summen der vorhandenen Transactions bis zu diesem Zeitpunkt zu ermitteln. Nach ersten Einschätzungen dürfte es hier nichts zu tun geben. Aber es sollte noch einmal geprüft werden. + + +### UserResolver + +#### - activationLink + +nothing to do + +#### - checkOptInCode + +Hier wird der übergebene OptIn-Code geprüft, ob schon wieder eine erneute Email gesendet werden kann. Die Zeiten werden auf reiner BE-Zeit verglichen, von daher gibt es hier nichts zu tun. + +#### - createUser + +nothing to do + +#### - forgotPassword + +In dieser Methode wird am Ende in der Methode *sendResetPasswordEmailMailer()* die Zeit berechnet, wie lange der OptIn-Code im Link gültig ist, default 1440 min oder 24 h. + +Es ist keine User-TimeOffset zu berücksichten, da der OptInCode direkt als Parameter im Aufruf von queryOptIn verwendet und dann dort mit der BE-Time verglichen wird. + +#### - hasElopage + +nothing to do + +#### - login + +nothing to do + +#### - logout + +nothing to do + +#### - queryOptIn + +Hier wird der OptIn-Code aus der *sendResetPasswordEmailMailer()* als Parameter geliefert. Da dessen Gültigkeit zuvor in forgotPassword mit der BE-Zeit gesetzt wurde, benögt man hier keine Berücksichtigung des User-TimeOffsets. + +#### - searchAdminUsers + +nothing to do + +#### - setPassword + +nothing to do, analog *queryOptIn* + +#### - printTimeDuration + +nothing to do + +#### - updateUserInfos + +nothing to do + +#### + verifyLogin + +Hier wird der User inklusive der Summen über die letzten drei Schöpfungsmonate aus seinen vorhandenen Contribtutions, egal ob bestätigt oder noch offen ermittelt. + +Hier muss der User-TimeOffset berücksichtigt werden, um die korrekten drei Schöpfungsmonate und dann daraus die korrekten Beträge der Contributions zu ermitteln. diff --git a/docu/Concepts/BusinessRequirements/graphics/ZeitzonenKonstellationen.drawio b/docu/Concepts/BusinessRequirements/graphics/ZeitzonenKonstellationen.drawio new file mode 100644 index 000000000..52ff19af9 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/graphics/ZeitzonenKonstellationen.drawio @@ -0,0 +1,217 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docu/Concepts/BusinessRequirements/image/ZeitzonenKonstellationen.png b/docu/Concepts/BusinessRequirements/image/ZeitzonenKonstellationen.png new file mode 100644 index 000000000..3f8fddbcb Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/ZeitzonenKonstellationen.png differ diff --git a/frontend/package.json b/frontend/package.json index cfc12630e..6f1474521 100755 --- a/frontend/package.json +++ b/frontend/package.json @@ -1,6 +1,6 @@ { "name": "bootstrap-vue-gradido-wallet", - "version": "1.14.1", + "version": "1.15.0", "private": true, "scripts": { "start": "node run/server.js", diff --git a/package.json b/package.json index 72efee984..22f444155 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "gradido", - "version": "1.14.1", + "version": "1.15.0", "description": "Gradido", "main": "index.js", "repository": "git@github.com:gradido/gradido.git",