diff --git a/.github/workflows/lint_pr.yml b/.github/workflows/lint_pr.yml new file mode 100644 index 000000000..2f9229737 --- /dev/null +++ b/.github/workflows/lint_pr.yml @@ -0,0 +1,72 @@ +name: "gradido lint pull request CI" + +on: + pull_request: + pull_request_target: + types: + - opened + - edited + - synchronize + +jobs: + main: + name: Validate PR title + runs-on: ubuntu-latest + steps: + - uses: amannn/action-semantic-pull-request@v5 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + # Configure which types are allowed (newline delimited). + # Default: https://github.com/commitizen/conventional-commit-types + #types: | + # fix + # feat + # Configure which scopes are allowed (newline delimited). + scopes: | + backend + frontend + admin + database + release + other + # Configure that a scope must always be provided. + requireScope: true + # Configure which scopes (newline delimited) are disallowed in PR + # titles. For instance by setting # the value below, `chore(release): + # ...` and `ci(e2e,release): ...` will be rejected. + #disallowScopes: | + # release + # Configure additional validation for the subject based on a regex. + # This example ensures the subject doesn't start with an uppercase character. + subjectPattern: ^(?![A-Z]).+$ + # If `subjectPattern` is configured, you can use this property to override + # the default error message that is shown when the pattern doesn't match. + # The variables `subject` and `title` can be used within the message. + subjectPatternError: | + The subject "{subject}" found in the pull request title "{title}" + didn't match the configured pattern. Please ensure that the subject + doesn't start with an uppercase character. + # If you use GitHub Enterprise, you can set this to the URL of your server + #githubBaseUrl: https://github.myorg.com/api/v3 + # If the PR contains one of these labels (newline delimited), the + # validation is skipped. + # If you want to rerun the validation when labels change, you might want + # to use the `labeled` and `unlabeled` event triggers in your workflow. + #ignoreLabels: | + # bot + # ignore-semantic-pull-request + # If you're using a format for the PR title that differs from the traditional Conventional + # Commits spec, you can use these options to customize the parsing of the type, scope and + # subject. The `headerPattern` should contain a regex where the capturing groups in parentheses + # correspond to the parts listed in `headerPatternCorrespondence`. + # See: https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-commits-parser#headerpattern + headerPattern: '^(\w*)(?:\(([\w$.\-*/ ]*)\))?: (.*)$' + headerPatternCorrespondence: type, scope, subject + # For work-in-progress PRs you can typically use draft pull requests + # from GitHub. However, private repositories on the free plan don't have + # this option and therefore this action allows you to opt-in to using the + # special "[WIP]" prefix to indicate this state. This will avoid the + # validation of the PR title and the pull request checks remain pending. + # Note that a second check will be reported if this is enabled. + wip: true diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 34ebeff11..c3238507a 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,6 +1,6 @@ name: gradido test CI -on: [push] +on: push jobs: ############################################################################## @@ -15,7 +15,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # FRONTEND ############################################################### ########################################################################## @@ -24,7 +24,7 @@ jobs: docker build --target test -t "gradido/frontend:test" frontend/ docker save "gradido/frontend:test" > /tmp/frontend.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-frontend-test path: /tmp/frontend.tar @@ -41,7 +41,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # ADMIN INTERFACE ######################################################## ########################################################################## @@ -50,7 +50,7 @@ jobs: docker build --target test -t "gradido/admin:test" admin/ --build-arg NODE_ENV="test" docker save "gradido/admin:test" > /tmp/admin.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-admin-test path: /tmp/admin.tar @@ -67,7 +67,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # BACKEND ################################################################ ########################################################################## @@ -76,7 +76,7 @@ jobs: docker build -f ./backend/Dockerfile --target test -t "gradido/backend:test" . docker save "gradido/backend:test" > /tmp/backend.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-backend-test path: /tmp/backend.tar @@ -93,7 +93,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DATABASE UP ############################################################ ########################################################################## @@ -102,7 +102,7 @@ jobs: docker build --target test_up -t "gradido/database:test_up" database/ docker save "gradido/database:test_up" > /tmp/database_up.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-database-test_up path: /tmp/database_up.tar @@ -119,7 +119,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # BUILD MARIADB DOCKER IMAGE ############################################# ########################################################################## @@ -128,7 +128,7 @@ jobs: docker build --target mariadb_server -t "gradido/mariadb:test" -f ./mariadb/Dockerfile ./ docker save "gradido/mariadb:test" > /tmp/mariadb.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-mariadb-test path: /tmp/mariadb.tar @@ -139,13 +139,13 @@ jobs: build_test_nginx: name: Docker Build Test - Nginx runs-on: ubuntu-latest - #needs: [nothing] + needs: [build_test_backend, build_test_admin, build_test_frontend] steps: ########################################################################## # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # BUILD NGINX DOCKER IMAGE ############################################### ########################################################################## @@ -154,7 +154,7 @@ jobs: docker build -t "gradido/nginx:test" nginx/ docker save "gradido/nginx:test" > /tmp/nginx.tar - name: Upload Artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: name: docker-nginx-test path: /tmp/nginx.tar @@ -171,12 +171,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Frontend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-frontend-test path: /tmp @@ -200,12 +200,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Frontend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-frontend-test path: /tmp @@ -229,12 +229,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Frontend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-frontend-test path: /tmp @@ -258,12 +258,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Admin Interface) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-admin-test path: /tmp @@ -287,12 +287,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Admin Interface) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-admin-test path: /tmp @@ -308,7 +308,7 @@ jobs: # JOB: LOCALES ADMIN ######################################################### ############################################################################## locales_admin: - name: Locales - Admin + name: Locales - Admin Interface runs-on: ubuntu-latest needs: [build_test_admin] steps: @@ -316,12 +316,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Admin Interface) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-admin-test path: /tmp @@ -345,12 +345,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Backend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-backend-test path: /tmp @@ -374,12 +374,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGE ################################################## ########################################################################## - name: Download Docker Image (Backend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-database-test_up path: /tmp @@ -403,12 +403,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGES ################################################# ########################################################################## - name: Download Docker Image (Frontend) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-frontend-test path: /tmp @@ -453,12 +453,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGES ################################################# ########################################################################## - name: Download Docker Image (Admin Interface) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-admin-test path: /tmp @@ -495,12 +495,12 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOWNLOAD DOCKER IMAGES ################################################# ########################################################################## - name: Download Docker Image (Mariadb) - uses: actions/download-artifact@v2 + uses: actions/download-artifact@v3 with: name: docker-mariadb-test path: /tmp @@ -543,7 +543,7 @@ jobs: # CHECKOUT CODE ########################################################## ########################################################################## - name: Checkout code - uses: actions/checkout@v2 + uses: actions/checkout@v3 ########################################################################## # DOCKER COMPOSE DATABASE UP + RESET ##################################### ########################################################################## @@ -553,3 +553,108 @@ jobs: run: docker-compose -f docker-compose.yml run -T database yarn up - name: database | reset run: docker-compose -f docker-compose.yml run -T database yarn reset + + ############################################################################## + # JOB: END-TO-END TESTS ##################################################### + ############################################################################## + end-to-end-tests: + name: End-to-End Tests + runs-on: ubuntu-latest + needs: [build_test_mariadb, build_test_database_up, build_test_backend, build_test_admin, build_test_frontend, build_test_nginx] + steps: + ########################################################################## + # CHECKOUT CODE ########################################################## + ########################################################################## + - name: Checkout code + uses: actions/checkout@v3 + ########################################################################## + # DOWNLOAD DOCKER IMAGES ################################################# + ########################################################################## + - name: Download Docker Image (Mariadb) + uses: actions/download-artifact@v3 + with: + name: docker-mariadb-test + path: /tmp + - name: Load Docker Image (Mariadb) + run: docker load < /tmp/mariadb.tar + - name: Download Docker Image (Database Up) + uses: actions/download-artifact@v3 + with: + name: docker-database-test_up + path: /tmp + - name: Load Docker Image (Database Up) + run: docker load < /tmp/database_up.tar + - name: Download Docker Image (Backend) + uses: actions/download-artifact@v3 + with: + name: docker-backend-test + path: /tmp + - name: Load Docker Image (Backend) + run: docker load < /tmp/backend.tar + - name: Download Docker Image (Frontend) + uses: actions/download-artifact@v3 + with: + name: docker-frontend-test + path: /tmp + - name: Load Docker Image (Frontend) + run: docker load < /tmp/frontend.tar + - name: Download Docker Image (Admin Interface) + uses: actions/download-artifact@v3 + with: + name: docker-admin-test + path: /tmp + - name: Load Docker Image (Admin Interface) + run: docker load < /tmp/admin.tar + - name: Download Docker Image (Nginx) + uses: actions/download-artifact@v3 + with: + name: docker-nginx-test + path: /tmp + - name: Load Docker Image (Nginx) + run: docker load < /tmp/nginx.tar + + ########################################################################## + # BOOT UP THE TEST SYSTEM ################################################ + ########################################################################## + - name: Boot up test system | docker-compose mariadb + run: docker-compose -f docker-compose.yml -f docker-compose.test.yml up --detach mariadb + + - name: Boot up test system | docker-compose database + run: docker-compose -f docker-compose.yml -f docker-compose.test.yml up --detach --no-deps database + + - name: Boot up test system | docker-compose backend + run: docker-compose -f docker-compose.yml -f docker-compose.test.yml up --detach --no-deps backend + + - name: Sleep for 10 seconds + run: sleep 10s + + - name: Boot up test system | seed backend + run: | + sudo chown runner:docker -R * + cd database + yarn && yarn dev_reset + cd ../backend + yarn && yarn seed + cd .. + + - name: Boot up test system | docker-compose frontends + run: docker-compose -f docker-compose.yml -f docker-compose.test.yml up --detach --no-deps frontend admin nginx + + - name: Sleep for 15 seconds + run: sleep 15s + + ########################################################################## + # END-TO-END TESTS ####################################################### + ########################################################################## + - name: End-to-end tests | run tests + id: e2e-tests + run: | + cd e2e-tests/cypress/tests/ + yarn + yarn run cypress run --spec cypress/e2e/User.Authentication.feature + - name: End-to-end tests | if tests failed, upload screenshots + if: steps.e2e-tests.outcome == 'failure' + uses: actions/upload-artifact@v3 + with: + name: cypress-screenshots + path: /home/runner/work/gradido/gradido/e2e-tests/cypress/tests/cypress/screenshots/ diff --git a/CHANGELOG.md b/CHANGELOG.md index d4eb48283..754566658 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,8 +4,37 @@ 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.13.3](https://github.com/gradido/gradido/compare/1.13.2...1.13.3) + +- 2294 contribution links on its own page [`#2312`](https://github.com/gradido/gradido/pull/2312) +- fix: Change Orange Color [`#2302`](https://github.com/gradido/gradido/pull/2302) +- fix: Release Statistic Query Runner [`#2320`](https://github.com/gradido/gradido/pull/2320) +- bug: 2295 remove horizontal scrollbar in admin overview [`#2311`](https://github.com/gradido/gradido/pull/2311) +- 2292 community information contact [`#2313`](https://github.com/gradido/gradido/pull/2313) +- bug: 2315 Contribution Month and TEST FAIL in MASTER [`#2316`](https://github.com/gradido/gradido/pull/2316) +- 2291 add button for close contribution messages box [`#2314`](https://github.com/gradido/gradido/pull/2314) + +#### [1.13.2](https://github.com/gradido/gradido/compare/1.13.1...1.13.2) + +> 28 October 2022 + +- release: Version 1.13.2 [`#2307`](https://github.com/gradido/gradido/pull/2307) +- fix: 🍰 Links In Contribution Messages Target Blank [`#2306`](https://github.com/gradido/gradido/pull/2306) +- fix: Link in Contribution Messages [`#2305`](https://github.com/gradido/gradido/pull/2305) +- Refactor: 🍰 Change the query so that we only look on the ``contributions`` table. [`#2217`](https://github.com/gradido/gradido/pull/2217) +- Refactor: Admin Resolver Events and Logging [`#2244`](https://github.com/gradido/gradido/pull/2244) +- contibution messages, links are recognised [`#2248`](https://github.com/gradido/gradido/pull/2248) +- fix: Include Deleted Email Contacts in User Search [`#2281`](https://github.com/gradido/gradido/pull/2281) +- fix: Pagination Contributions jumps to wrong Page [`#2284`](https://github.com/gradido/gradido/pull/2284) +- fix: Changed some texts in E-Mails and Frontend [`#2276`](https://github.com/gradido/gradido/pull/2276) +- Feat: 🍰 Add `deletedBy` To Contributions And Admin Can Not Delete Own User Contribution [`#2236`](https://github.com/gradido/gradido/pull/2236) +- deleted contributions are displayed to the user [`#2277`](https://github.com/gradido/gradido/pull/2277) + #### [1.13.1](https://github.com/gradido/gradido/compare/1.13.0...1.13.1) +> 20 October 2022 + +- release: Version 1.13.1 [`#2279`](https://github.com/gradido/gradido/pull/2279) - Fix: correctly evaluate to EMAIL_TEST_MODE to false [`#2273`](https://github.com/gradido/gradido/pull/2273) - Refactor: Contribution resolver logs and events [`#2231`](https://github.com/gradido/gradido/pull/2231) diff --git a/admin/package.json b/admin/package.json index 2db889771..370f504b8 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.13.1", + "version": "1.13.3", "license": "Apache-2.0", "private": false, "scripts": { diff --git a/admin/src/components/ContentFooter.vue b/admin/src/components/ContentFooter.vue index bab3f5d12..a875100f6 100644 --- a/admin/src/components/ContentFooter.vue +++ b/admin/src/components/ContentFooter.vue @@ -1,7 +1,7 @@ diff --git a/admin/src/pages/Overview.spec.js b/admin/src/pages/Overview.spec.js index 1861c5330..affd018a7 100644 --- a/admin/src/pages/Overview.spec.js +++ b/admin/src/pages/Overview.spec.js @@ -1,6 +1,5 @@ import { mount } from '@vue/test-utils' import Overview from './Overview.vue' -import { listContributionLinks } from '@/graphql/listContributionLinks.js' import { communityStatistics } from '@/graphql/communityStatistics.js' import { listUnconfirmedContributions } from '@/graphql/listUnconfirmedContributions.js' @@ -36,27 +35,6 @@ const apolloQueryMock = jest }, }, }) - .mockResolvedValueOnce({ - data: { - listContributionLinks: { - links: [ - { - id: 1, - name: 'Meditation', - memo: 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut l', - amount: '200', - validFrom: '2022-04-01', - validTo: '2022-08-01', - cycle: 'täglich', - maxPerCycle: '3', - maxAmountPerMonth: 0, - link: 'https://localhost/redeem/CL-1a2345678', - }, - ], - count: 1, - }, - }, - }) .mockResolvedValue({ data: { listUnconfirmedContributions: [ @@ -118,14 +96,6 @@ describe('Overview', () => { ) }) - it('calls listContributionLinks', () => { - expect(apolloQueryMock).toBeCalledWith( - expect.objectContaining({ - query: listContributionLinks, - }), - ) - }) - it('commits three pending creations to store', () => { expect(storeCommitMock).toBeCalledWith('setOpenCreations', 3) }) diff --git a/admin/src/pages/Overview.vue b/admin/src/pages/Overview.vue index cfa247b8e..57bf7ff8c 100644 --- a/admin/src/pages/Overview.vue +++ b/admin/src/pages/Overview.vue @@ -28,31 +28,21 @@ - diff --git a/admin/src/router/router.test.js b/admin/src/router/router.test.js index eb9b646cb..22273c15b 100644 --- a/admin/src/router/router.test.js +++ b/admin/src/router/router.test.js @@ -45,7 +45,7 @@ describe('router', () => { describe('routes', () => { it('has seven routes defined', () => { - expect(routes).toHaveLength(7) + expect(routes).toHaveLength(8) }) it('has "/overview" as default', async () => { @@ -81,6 +81,13 @@ describe('router', () => { }) }) + describe('contribution-links', () => { + it('loads the "ContributionLinks" component', async () => { + const component = await routes.find((r) => r.path === '/contribution-links').component() + expect(component.default.name).toBe('ContributionLinks') + }) + }) + describe('not found page', () => { it('renders the "NotFound" component', async () => { const component = await routes.find((r) => r.path === '*').component() diff --git a/admin/src/router/routes.js b/admin/src/router/routes.js index 72e7b1ac5..ee82f128e 100644 --- a/admin/src/router/routes.js +++ b/admin/src/router/routes.js @@ -23,6 +23,10 @@ const routes = [ path: '/creation-confirm', component: () => import('@/pages/CreationConfirm.vue'), }, + { + path: '/contribution-links', + component: () => import('@/pages/ContributionLinks.vue'), + }, { path: '*', component: () => import('@/components/NotFoundPage.vue'), diff --git a/backend/package.json b/backend/package.json index 3f6f133f6..1db683b2a 100644 --- a/backend/package.json +++ b/backend/package.json @@ -1,6 +1,6 @@ { "name": "gradido-backend", - "version": "1.13.1", + "version": "1.13.3", "description": "Gradido unified backend providing an API-Service for Gradido Transactions", "main": "src/index.ts", "repository": "https://github.com/gradido/gradido/backend", diff --git a/backend/src/config/index.ts b/backend/src/config/index.ts index 3d796af2c..e7139033b 100644 --- a/backend/src/config/index.ts +++ b/backend/src/config/index.ts @@ -10,7 +10,7 @@ Decimal.set({ }) const constants = { - DB_VERSION: '0051-add_delete_by_to_contributions', + DB_VERSION: '0052-add_updated_at_to_contributions', 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 diff --git a/backend/src/graphql/resolver/ContributionResolver.ts b/backend/src/graphql/resolver/ContributionResolver.ts index aec7bc44d..ede61b413 100644 --- a/backend/src/graphql/resolver/ContributionResolver.ts +++ b/backend/src/graphql/resolver/ContributionResolver.ts @@ -13,6 +13,8 @@ import { Contribution, ContributionListResult } from '@model/Contribution' import { UnconfirmedContribution } from '@model/UnconfirmedContribution' import { validateContribution, getUserCreation, updateCreations } from './util/creations' import { MEMO_MAX_CHARS, MEMO_MIN_CHARS } from './const/const' +import { ContributionMessage } from '@entity/ContributionMessage' +import { ContributionMessageType } from '@enum/MessageType' import { Event, EventContributionCreate, @@ -192,7 +194,17 @@ export class ContributionResolver { logger.error('user of the pending contribution and send user does not correspond') throw new Error('user of the pending contribution and send user does not correspond') } - + if ( + contributionToUpdate.contributionStatus !== ContributionStatus.IN_PROGRESS && + contributionToUpdate.contributionStatus !== ContributionStatus.PENDING + ) { + logger.error( + `Contribution can not be updated since the state is ${contributionToUpdate.contributionStatus}`, + ) + throw new Error( + `Contribution can not be updated since the state is ${contributionToUpdate.contributionStatus}`, + ) + } const creationDateObj = new Date(creationDate) let creations = await getUserCreation(user.id) if (contributionToUpdate.contributionDate.getMonth() === creationDateObj.getMonth()) { @@ -204,10 +216,28 @@ export class ContributionResolver { // all possible cases not to be true are thrown in this function validateContribution(creations, amount, creationDateObj) + + const contributionMessage = ContributionMessage.create() + contributionMessage.contributionId = contributionId + contributionMessage.createdAt = contributionToUpdate.updatedAt + ? contributionToUpdate.updatedAt + : contributionToUpdate.createdAt + const changeMessage = `${contributionToUpdate.contributionDate} + --- + ${contributionToUpdate.memo} + --- + ${contributionToUpdate.amount}` + contributionMessage.message = changeMessage + contributionMessage.isModerator = false + contributionMessage.userId = user.id + contributionMessage.type = ContributionMessageType.HISTORY + ContributionMessage.save(contributionMessage) + contributionToUpdate.amount = amount contributionToUpdate.memo = memo contributionToUpdate.contributionDate = new Date(creationDate) contributionToUpdate.contributionStatus = ContributionStatus.PENDING + contributionToUpdate.updatedAt = new Date() dbContribution.save(contributionToUpdate) const event = new Event() diff --git a/backend/src/graphql/resolver/StatisticsResolver.ts b/backend/src/graphql/resolver/StatisticsResolver.ts index b0c061d91..7bfae319e 100644 --- a/backend/src/graphql/resolver/StatisticsResolver.ts +++ b/backend/src/graphql/resolver/StatisticsResolver.ts @@ -63,6 +63,8 @@ export class StatisticsResolver { .where('transaction.decay IS NOT NULL') .getRawOne() + await queryRunner.release() + return { totalUsers, activeUsers, diff --git a/backend/src/graphql/resolver/TransactionLinkResolver.test.ts b/backend/src/graphql/resolver/TransactionLinkResolver.test.ts index 3d40adbf6..275242bd3 100644 --- a/backend/src/graphql/resolver/TransactionLinkResolver.test.ts +++ b/backend/src/graphql/resolver/TransactionLinkResolver.test.ts @@ -6,8 +6,15 @@ import { bibiBloxberg } from '@/seeds/users/bibi-bloxberg' import { peterLustig } from '@/seeds/users/peter-lustig' import { cleanDB, testEnvironment } from '@test/helpers' import { userFactory } from '@/seeds/factory/user' -import { login, createContributionLink, redeemTransactionLink } from '@/seeds/graphql/mutations' +import { + login, + createContributionLink, + redeemTransactionLink, + createContribution, + updateContribution, +} from '@/seeds/graphql/mutations' import { ContributionLink as DbContributionLink } from '@entity/ContributionLink' +import { UnconfirmedContribution } from '@model/UnconfirmedContribution' import Decimal from 'decimal.js-light' import { GraphQLError } from 'graphql' @@ -32,6 +39,7 @@ describe('TransactionLinkResolver', () => { describe('redeem daily Contribution Link', () => { const now = new Date() let contributionLink: DbContributionLink | undefined + let contribution: UnconfirmedContribution | undefined beforeAll(async () => { await mutate({ @@ -79,56 +87,59 @@ describe('TransactionLinkResolver', () => { ) }) - it('allows the user to redeem the contribution link', async () => { - await expect( - mutate({ - mutation: redeemTransactionLink, - variables: { - code: 'CL-' + (contributionLink ? contributionLink.code : ''), - }, - }), - ).resolves.toMatchObject({ - data: { - redeemTransactionLink: true, - }, - errors: undefined, - }) - }) - - it('does not allow the user to redeem the contribution link a second time on the same day', async () => { - await expect( - mutate({ - mutation: redeemTransactionLink, - variables: { - code: 'CL-' + (contributionLink ? contributionLink.code : ''), - }, - }), - ).resolves.toMatchObject({ - errors: [ - new GraphQLError( - 'Creation from contribution link was not successful. Error: Contribution link already redeemed today', - ), - ], - }) - }) - - describe('after one day', () => { + describe('user has pending contribution of 1000 GDD', () => { beforeAll(async () => { - jest.useFakeTimers() - /* eslint-disable-next-line @typescript-eslint/no-empty-function */ - setTimeout(() => {}, 1000 * 60 * 60 * 24) - jest.runAllTimers() await mutate({ mutation: login, - variables: { email: 'peter@lustig.de', password: 'Aa12345_' }, + variables: { email: 'bibi@bloxberg.de', password: 'Aa12345_' }, + }) + const result = await mutate({ + mutation: createContribution, + variables: { + amount: new Decimal(1000), + memo: 'I was brewing potions for the community the whole month', + creationDate: now.toISOString(), + }, + }) + contribution = result.data.createContribution + }) + + it('does not allow the user to redeem the contribution link', async () => { + await expect( + mutate({ + mutation: redeemTransactionLink, + variables: { + code: 'CL-' + (contributionLink ? contributionLink.code : ''), + }, + }), + ).resolves.toMatchObject({ + errors: [ + new GraphQLError( + 'Creation from contribution link was not successful. Error: The amount (5 GDD) to be created exceeds the amount (0 GDD) still available for this month.', + ), + ], + }) + }) + }) + + describe('user has no pending contributions that would not allow to redeem the link', () => { + beforeAll(async () => { + await mutate({ + mutation: login, + variables: { email: 'bibi@bloxberg.de', password: 'Aa12345_' }, + }) + await mutate({ + mutation: updateContribution, + variables: { + contributionId: contribution ? contribution.id : -1, + amount: new Decimal(800), + memo: 'I was brewing potions for the community the whole month', + creationDate: now.toISOString(), + }, }) }) - afterAll(() => { - jest.useRealTimers() - }) - - it('allows the user to redeem the contribution link again', async () => { + it('allows the user to redeem the contribution link', async () => { await expect( mutate({ mutation: redeemTransactionLink, @@ -160,6 +171,56 @@ describe('TransactionLinkResolver', () => { ], }) }) + + describe('after one day', () => { + beforeAll(async () => { + jest.useFakeTimers() + /* eslint-disable-next-line @typescript-eslint/no-empty-function */ + setTimeout(() => {}, 1000 * 60 * 60 * 24) + jest.runAllTimers() + await mutate({ + mutation: login, + variables: { email: 'bibi@bloxberg.de', password: 'Aa12345_' }, + }) + }) + + afterAll(() => { + jest.useRealTimers() + }) + + it('allows the user to redeem the contribution link again', async () => { + await expect( + mutate({ + mutation: redeemTransactionLink, + variables: { + code: 'CL-' + (contributionLink ? contributionLink.code : ''), + }, + }), + ).resolves.toMatchObject({ + data: { + redeemTransactionLink: true, + }, + errors: undefined, + }) + }) + + it('does not allow the user to redeem the contribution link a second time on the same day', async () => { + await expect( + mutate({ + mutation: redeemTransactionLink, + variables: { + code: 'CL-' + (contributionLink ? contributionLink.code : ''), + }, + }), + ).resolves.toMatchObject({ + errors: [ + new GraphQLError( + 'Creation from contribution link was not successful. Error: Contribution link already redeemed today', + ), + ], + }) + }) + }) }) }) }) diff --git a/backend/src/graphql/resolver/TransactionLinkResolver.ts b/backend/src/graphql/resolver/TransactionLinkResolver.ts index 4ba5dcd0b..74c531c54 100644 --- a/backend/src/graphql/resolver/TransactionLinkResolver.ts +++ b/backend/src/graphql/resolver/TransactionLinkResolver.ts @@ -258,7 +258,7 @@ export class TransactionLinkResolver { } } - const creations = await getUserCreation(user.id, false) + const creations = await getUserCreation(user.id) logger.info('open creations', creations) validateContribution(creations, contributionLink.amount, now) const contribution = new DbContribution() diff --git a/backend/src/graphql/resolver/util/creations.ts b/backend/src/graphql/resolver/util/creations.ts index 9987dfae6..abf4017cb 100644 --- a/backend/src/graphql/resolver/util/creations.ts +++ b/backend/src/graphql/resolver/util/creations.ts @@ -1,4 +1,3 @@ -import { TransactionTypeId } from '@/graphql/enum/TransactionTypeId' import { backendLogger as logger } from '@/server/logger' import { getConnection } from '@dbTools/typeorm' import { Contribution } from '@entity/Contribution' @@ -50,27 +49,27 @@ export const getUserCreations = async ( const dateFilter = 'last_day(curdate() - interval 3 month) + interval 1 day' logger.trace('getUserCreations dateFilter=', dateFilter) - const unionString = includePending - ? ` - UNION - SELECT contribution_date AS date, amount AS amount, user_id AS userId FROM contributions - WHERE user_id IN (${ids.toString()}) - AND contribution_date >= ${dateFilter} - AND confirmed_at IS NULL AND deleted_at IS NULL` - : '' - logger.trace('getUserCreations unionString=', unionString) + const sumAmountContributionPerUserAndLast3MonthQuery = queryRunner.manager + .createQueryBuilder(Contribution, 'c') + .select('month(contribution_date)', 'month') + .addSelect('user_id', 'userId') + .addSelect('sum(amount)', 'sum') + .where(`user_id in (${ids.toString()})`) + .andWhere(`contribution_date >= ${dateFilter}`) + .andWhere('deleted_at IS NULL') + .andWhere('denied_at IS NULL') + .groupBy('month') + .addGroupBy('userId') + .orderBy('month', 'DESC') - const unionQuery = await queryRunner.manager.query(` - SELECT MONTH(date) AS month, sum(amount) AS sum, userId AS id FROM - (SELECT creation_date AS date, amount AS amount, user_id AS userId FROM transactions - WHERE user_id IN (${ids.toString()}) - AND type_id = ${TransactionTypeId.CREATION} - AND creation_date >= ${dateFilter} - ${unionString}) AS result - GROUP BY month, userId - ORDER BY date DESC - `) - logger.trace('getUserCreations unionQuery=', unionQuery) + if (!includePending) { + sumAmountContributionPerUserAndLast3MonthQuery.andWhere('confirmed_at IS NOT NULL') + } + + const sumAmountContributionPerUserAndLast3Month = + await sumAmountContributionPerUserAndLast3MonthQuery.getRawMany() + + logger.trace(sumAmountContributionPerUserAndLast3Month) await queryRunner.release() @@ -78,9 +77,9 @@ export const getUserCreations = async ( return { id, creations: months.map((month) => { - const creation = unionQuery.find( - (raw: { month: string; id: string; creation: number[] }) => - parseInt(raw.month) === month && parseInt(raw.id) === id, + const creation = sumAmountContributionPerUserAndLast3Month.find( + (raw: { month: string; userId: string; creation: number[] }) => + parseInt(raw.month) === month && parseInt(raw.userId) === id, ) return MAX_CREATION_AMOUNT.minus(creation ? creation.sum : 0) }), diff --git a/database/entity/0052-add_updated_at_to_contributions/Contribution.ts b/database/entity/0052-add_updated_at_to_contributions/Contribution.ts new file mode 100644 index 000000000..2242a753f --- /dev/null +++ b/database/entity/0052-add_updated_at_to_contributions/Contribution.ts @@ -0,0 +1,95 @@ +import Decimal from 'decimal.js-light' +import { + BaseEntity, + Column, + Entity, + PrimaryGeneratedColumn, + DeleteDateColumn, + JoinColumn, + ManyToOne, + OneToMany, +} from 'typeorm' +import { DecimalTransformer } from '../../src/typeorm/DecimalTransformer' +import { User } from '../User' +import { ContributionMessage } from '../ContributionMessage' + +@Entity('contributions') +export class Contribution extends BaseEntity { + @PrimaryGeneratedColumn('increment', { unsigned: true }) + id: number + + @Column({ unsigned: true, nullable: false, name: 'user_id' }) + userId: number + + @ManyToOne(() => User, (user) => user.contributions) + @JoinColumn({ name: 'user_id' }) + user: User + + @Column({ type: 'datetime', default: () => 'CURRENT_TIMESTAMP', name: 'created_at' }) + createdAt: Date + + @Column({ type: 'datetime', nullable: false, name: 'contribution_date' }) + contributionDate: Date + + @Column({ length: 255, nullable: false, collation: 'utf8mb4_unicode_ci' }) + memo: string + + @Column({ + type: 'decimal', + precision: 40, + scale: 20, + nullable: false, + transformer: DecimalTransformer, + }) + amount: Decimal + + @Column({ unsigned: true, nullable: true, name: 'moderator_id' }) + moderatorId: number + + @Column({ unsigned: true, nullable: true, name: 'contribution_link_id' }) + contributionLinkId: number + + @Column({ unsigned: true, nullable: true, name: 'confirmed_by' }) + confirmedBy: number + + @Column({ nullable: true, name: 'confirmed_at' }) + confirmedAt: Date + + @Column({ unsigned: true, nullable: true, name: 'denied_by' }) + deniedBy: number + + @Column({ nullable: true, name: 'denied_at' }) + deniedAt: Date + + @Column({ + name: 'contribution_type', + length: 12, + nullable: false, + collation: 'utf8mb4_unicode_ci', + }) + contributionType: string + + @Column({ + name: 'contribution_status', + length: 12, + nullable: false, + collation: 'utf8mb4_unicode_ci', + }) + contributionStatus: string + + @Column({ unsigned: true, nullable: true, name: 'transaction_id' }) + transactionId: number + + @Column({ nullable: true, name: 'updated_at' }) + updatedAt: Date + + @DeleteDateColumn({ name: 'deleted_at' }) + deletedAt: Date | null + + @DeleteDateColumn({ unsigned: true, nullable: true, name: 'deleted_by' }) + deletedBy: number + + @OneToMany(() => ContributionMessage, (message) => message.contribution) + @JoinColumn({ name: 'contribution_id' }) + messages?: ContributionMessage[] +} diff --git a/database/entity/Contribution.ts b/database/entity/Contribution.ts index 4b1dfc9c8..0441e7a1f 100644 --- a/database/entity/Contribution.ts +++ b/database/entity/Contribution.ts @@ -1 +1 @@ -export { Contribution } from './0051-add_delete_by_to_contributions/Contribution' +export { Contribution } from './0052-add_updated_at_to_contributions/Contribution' diff --git a/database/migrations/0052-add_updated_at_to_contributions.ts b/database/migrations/0052-add_updated_at_to_contributions.ts new file mode 100644 index 000000000..e7cc5b7b4 --- /dev/null +++ b/database/migrations/0052-add_updated_at_to_contributions.ts @@ -0,0 +1,12 @@ +/* eslint-disable @typescript-eslint/explicit-module-boundary-types */ +/* eslint-disable @typescript-eslint/no-explicit-any */ + +export async function upgrade(queryFn: (query: string, values?: any[]) => Promise>) { + await queryFn( + `ALTER TABLE \`contributions\` ADD COLUMN \`updated_at\` datetime DEFAULT NULL AFTER \`transaction_id\`;`, + ) +} + +export async function downgrade(queryFn: (query: string, values?: any[]) => Promise>) { + await queryFn(`ALTER TABLE \`contributions\` DROP COLUMN \`updated_at\`;`) +} diff --git a/database/package.json b/database/package.json index 0a97b5135..096c7a9bd 100644 --- a/database/package.json +++ b/database/package.json @@ -1,6 +1,6 @@ { "name": "gradido-database", - "version": "1.13.1", + "version": "1.13.3", "description": "Gradido Database Tool to execute database migrations", "main": "src/index.ts", "repository": "https://github.com/gradido/gradido/database", diff --git a/docker-compose.test.yml b/docker-compose.test.yml index 79ee46906..790bd468d 100644 --- a/docker-compose.test.yml +++ b/docker-compose.test.yml @@ -1,6 +1,25 @@ version: "3.4" services: + ######################################################## + # FRONTEND ############################################# + ######################################################## + frontend: + image: gradido/frontend:test + build: + target: test + environment: + - NODE_ENV="test" + + ######################################################## + # ADMIN INTERFACE ###################################### + ######################################################## + admin: + image: gradido/admin:test + build: + target: test + environment: + - NODE_ENV="test" ######################################################## # BACKEND ############################################## @@ -21,15 +40,19 @@ services: # DATABASE ############################################# ######################################################## database: + image: gradido/database:test_up build: context: ./database target: test_up + environment: + - NODE_ENV="test" # restart: always # this is very dangerous, but worth a test for the delayed mariadb startup at first run ######################################################### ## MARIADB ############################################## ######################################################### mariadb: + image: gradido/mariadb:test networks: - internal-net - external-net @@ -51,6 +74,12 @@ services: - external-net volumes: - /sessions + + ######################################################### + ## NGINX ################################################ + ######################################################### + nginx: + image: gradido/nginx:test networks: external-net: diff --git a/docu/Concepts/BusinessRequirements/UC_Manuel_User_Registration.md b/docu/Concepts/BusinessRequirements/UC_Manuel_User_Registration.md new file mode 100644 index 000000000..97dae661f --- /dev/null +++ b/docu/Concepts/BusinessRequirements/UC_Manuel_User_Registration.md @@ -0,0 +1,275 @@ +# Manuelle User-Registrierung + +## Motivation + +Bei einer Veranstaltung o.ä. sollen neue Mitglieder geworben werden. Dabei ist ungewiss, ob sie ein Endgerät dabei haben bzw. dieses korrekt bedienen können (QR-Code, E-Mail-Zugang etc.). Es soll nun ohne Einsatz zusätzlicher Technologien eine schnelle und unkomplizierte Möglichkeit geschaffen werden, dass ein Moderator im Admin-Interface zusätzliche Funktionen zur Unterstützung des User-Registrierungsprozesses erhält: + +1. manuelle Aktivierung eines User-Accounts ohne Email-Bestätigung und setzen eines (vorläufigen) Passworts +2. vollständige User-Registrierung mit Daten-Erfassung, Account-Aktivierung und setzen eines (vorläufigen) Passworts + +## 1. Unterstützung einer User-Registrierung + +Ein neuer User hat schon selbständig mit seiner Registrierung bei Gradido begonnen, aber in dem Moment keinen Zugriff auf seine Emails. Somit kann er seine erhaltene Bestätigungs-Email mit dem Link zur Konto-Aktivierung nicht abrufen und die Registrierung nicht abschließen. + +Für diesen Fall wird im Admin-Interface eine neue Funktionalität zur "manuellen Aktivierung eines User-Accounts" bereitgestellt. Diese "manuelle Aktivierung" durch den Admin soll den neuen User kurzfristig ermächtigen auf sein Konto zugreifen zu können. Das heißt, dieser Admin-Prozess muss + +* das Konto des neuen Users als aktiviert kennzeichnen +* für den User ein (vorläufiges) Passwort generieren +* die Kennzeichnung beibehalten, dass die Email-Adresse des Users noch nicht bestätigt ist +* dem User ein Login-Prozess ermöglichen, in dem der User das (vorläufige) Passwort verwenden kann +* den User nach dem erfolgreichen Login mit dem (vorläufigen) Passwort direkt zur Eingabe eines eigenen Passwortes bringen + +### 1.1 Starten des Registrierungsunterstützungs-Prozesses + +#### Vorbedingungen + +Nach dem der neue User für sich schon die Erfassung seiner persönlichen Daten im Registrierungsdialog durchgeführt und gespeichert hat, schickt die Anwendung dem User eine Confirmation-Email an seine angegebene Email-Adresse. Der User kommt aber aktuell nicht an seine Emails bzw. benötigt Unterstützung, wie er jetzt weiter machen soll, um sich anzumelden. Mit diesem Bedarf nach Unterstützung wendet der User sich an einen Moderator mit entsprechenden Admin-Rechten. + +#### Manuelle Aktivierung und One-Time-Passwort + +Der Admin navigiert in seinem angemeldeten Gradido-Account auf das Admin-Interface. Dort öffnet er den Dialog "Nutzersuche". + +Neu in diesem Dialog sind nun die neuen Checkboxen "noch nicht aktiviertes Konto" und "unbestätigte Email-Adresse". Im Normalfall sind diese beiden Checkboxen nicht selektiert, so dass mit der üblichen Nutzersuche alle User wie bisher ermittelt werden können. + +![img](./image/Admin-UserSearch.png) + +Um nun schneller einen neuen User mit "noch nicht aktiviertem Konto" und noch "unbestätigter Email-Adresse" für die Registrierungsunterstützung zu finden, kann der Admin die neuen Filter-Checkboxen selektieren. Diese schränken die User-Suche zusätzlich zur üblichen Namens-Eingabe ein, dh. ohne Eingabe eines einschränkenden Namens werden alle User-Accounts gelistet, die ein "noch nicht aktiviertes Konto" und noch eine "unbestätigte Email-Adresse" haben. + +![img](./image/Admin-UserSearch_inaktivAccount.png) + +Sobald der gewünschte User-Account in der Liste gefunden wurde, kann der Detail-Dialog zu diesem User per Klick geöffnet werden. + +![img](./image/Admin-UserAccount-Details.png) + +Der geöffnete Detail-Dialog zeigt einen neuen Reiter "Registrierung", in dem die Informationen über das User-Konto stehen: wann wurde es erzeugt und wie ist der Status der "Konto-Aktivierung" und der "Email-Bestätigung". + +Der Admin kann nun entweder manuell ein One-Time-Passwort in das Eingabefeld eingeben oder über den "erzeugen"-Button eines kreieren lassen. Dieses wird dann über den Button "speichern & Konto aktivieren" in die Datenbank geschrieben, wobei damit gleichzeitig der Status des User-Kontos auf *aktiviert* gesetzt wird. + +Der Admin kann nun das One-Time-Passwort dem User mitteilen, so dass dieser sich über den Login-Prozess in seinen Account ohne vorherige Email-Bestätigung anmelden kann. Der Login-Prozess mit einem One-Time-Passwort muss nach erfolgreicher Anmeldung den User sofort auf den Passwort-Ändern-Dialog führen, um den User direkt die Möglichkeit zu geben sein eigenes Passwort zu vergeben. + +Mit Öffnen des Passwort-Ändern-Dialogs für einen User-Account mit One-Time-Passwort kann nicht mit Sicherheit davon ausgegangen werden, dass der User selbst der Datenschutzerklärung zugestimmt hat - dies könnte durch die Unterstützung der Moderators beim User untergegangen sein. Daher muss in diesem Fall in dem Dialog eine Checkbox zur Bestätigung der Datenschutzerklärung eingeblendet sein. Erst wenn der User sein neues Passwort gemäß den Passwort-Richtlinien gesetzt und den Datenschutzbestimmungen zugestimmt hat, wird der "Speichern"-Button enabled und die Daten können gespeichert werden. + +#### One-Time-Passwort anzeigen oder ändern + +Falls ein neuer User sein erhaltenes One-Time-Passwort noch nicht für einen Login verwendet hat und dieses erneut vom Admin erfragen möchte, dann kann der Administrator dieses erneut im Admin-Interface über die Nutzer-Suche anzeigen lassen. Dazu kann er die Filter-Checkbox "noch nicht aktiviertes Konto" deselektieren, aber die Checkbox "unbestätigte Email-Adresse" selektiert lassen. Dann bekommt er alle User deren Email-Bestätigung noch offen ist und nur User-Konten, die schon aktiviert sind. + +![img](./image/Admin-UserAccount-ActivatedOneTimePasswort.png) + +Beim Öffnen der Userkonto-Details im Reiter "Registrierung" ist dann zu sehen, dass das "Konto schon aktiv", aber die "Email-Bestätigung noch offen" ist. Im Eingabefeld des One-Time-Passwortes ist das zuvor schon gespeicherte Passwort zu lesen, so dass der Admin dieses dem User erneut mitteilen kann. Der Admin kann aber auch über den "erzeugen"-Button oder manuell das vorhandene Passwort ändern. Über den "speichern"-Button, der aufgrund der vorherigen Konto-Aktivierung nun nicht mehr "speichern & Konto aktivieren" heißt, kann die Passwort-Änderung in die Datenbank geschrieben werden. + +### 1.2 Starten einer manuellen Admin-User-Registrierung + +Im Admin-Interface wird im Menü ein neuer Reiter "Registrierung" angezeigt. Mit Auswahl dieses Reiters kann der Moderator den Dialog zur "Manuellen User-Registrierung" öffnen. + +![img](./image/Admin-CreateUser.png) + +Dabei kann der Moderator die Attribute Vorname, Nachname, Email-Adresse und ein One-Time-Passwort eingeben. Mit dem "speichern & Konto aktivieren"-Button wird im Backend zunächst eine Prüfung durchgeführt, ob die eingegebene Email-Adresse ggf. schon von einem anderen existierenden User verwendet wird. Sollte dies der Fall sein, dann wird eine entsprechend aussagekräftige Fehlermeldung ausgegeben und die zuvor eingegebenen Daten werden in dem "Manuelle User-Registrierung" erneut angezeigt. Sind alle Daten soweit valide, dann werden die eingegebenen Daten in der Datenbank gespeichert und der Konto-Status auf *aktiviert* gesetzt. + +Es wird auch hier eine Email zur Emailadress-Bestätigung verschickt. Der Status "email_checked" bleibt auf false, weil der User seine Confirmation-Email zwar bekommen, aber noch nicht bestätigt hat oder eben nicht zeitnah bestätigen kann. Durch das One-Time-Passwort, das der Moderator dem User mitteilen kann, hat der User direkt die Möglichkeit sich über den Login-Prozess anzumelden, ohne vorher den Email-Bestätigungslink aktivieren zu müssen. + +### 1.3 User-Login mit One-Time-Passwort + +Sobald der User selbst oder durch den Moderator ein neues User-Konto angelegt und ein One-Time-Passwort vergeben ist, dann kann der User selbst sich über den üblichen Login-Prozess anmelden. + +Die Anwendung erkennt, dass der Login über ein One-Time-Passwort erfolgte, so dass der User direkt nach dem erfolgreichen Login auf die Passwort-Ändern-Seite geführt wird. + +![img](./image/One-Time-Passwort-Login.png) + +Auf dieser Seite muss der User dann sein neues, nur ihm persönlich bekanntes Passwort eingeben und zur Kontrolle wiederholen. Da der User-Account über eine One-Time-Passwort Registrierung erstellt wurde, hatte der User sehr wahrscheinlich nicht die Gelegenheit der Datenschutzerklärung selbst zuzustimmen. Daher wird hier im Passwort-Ändern-Dialog dies nachgeholt, indem erst mit der Zustimmung zur Datenschutzerklärung der "Passwort ändern"-Button aktiviert wird. + +## 2. Implementierung und Anpassungen + +### 2.1 Datenbank + +Für diese fachlichen Anforderungen müssen folgende Informationen neu in der Datenbank aufgenommen und gespeichert werden: + +* Merkmal, dass für den User ein Konto vorhanden, aber dieses noch nicht aktiviert ist +* Merkmal, dass für den User ein Konto vorhanden und dieses schon aktiviert ist +* One-Time-Passwort, das von der Anwendung im Original angezeigt werden kann - unverschlüsselt oder ohne Interaktion zu entschlüsseln +* Merkmal, ob bzw. wann der User der Datenschutzerklärung zugestimmt hat + +Es stellt sich die Frage, ob mit diesem UseCase gleich die schon sowieso geplante neue Tabelle `accounts `erstellt wird oder die obigen Merkmale erst einmal in die users-Tabelle einfließen? + +**Empfehlung:** erstellen der `accounts`-Tabelle + +In dieser `accounts`-Tabelle werden dann alle Account spezifischen Daten gespeichert und ein `accounts`-Eintrag ist über die Spalte `user_id` dem User in der `users`-Tabelle zugeordnet. + +Ansonsten werden aber keine weiteren Datenbank-Migrationen, wie Zuordnung der Transaktionen oder Contributions zur `accounts`-Tabelle durchgeführt. Dies muss in einem separaten Issue migriert werden. + +#### accounts-Tabelle + +| Column | Type | Description | +| ----------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------- | +| id | unsigned int(10) | technical unique key | +| user_id | unsigned int(10) | foreign key to users entry | +| type | enum | account type: AGE (default), AGW, AUF | +| created_at | datetime(3) | the point of time the entry was created | +| activated | tinyint(4) | switch if account is active or inactive | +| creations_allowed | tinyint(4) | switch if account allows to create gradidos or not; necessary for type AGW and AUF | +| decay | tinyint(4) | switch if account supports decay or not; in case the GDT will be shiftet as a separate account type here in the application | +| balance | decimal(40, 20) | amount of gradidos at the updated_at point of time | +| updated_at | datetime(3) | the point of time the entry was updated, especially important for the balance | + +Die letzten vier Spalten sind ersteinmal rein informativ, was ein `accounts`-Eintrag zukünftig enthalten wird und für diesen Usecase optional. Sie könnten auch auf ein zukünftiges Migrations-Issue verschoben werden. + +#### users-tabelle + +| Column | Type | Description | +| ------------------------ | ----------- | ------------------------------------------------------------------------------------------------------- | +| privacy_policy_at | datetime(3) | point of time the user agreed with the privacy policy - during registration or one-time-password change | +| password_encryption_type | enum | defines the type of encrypting the password: 0 = one-time, 1 = email (default), 2 = gradidoID, ... | + +Um zu vermeiden, dass in Bezug auf das One-Time-Passwort und der anstehenden Migration der Passwort-Verschlüsselung ohne Email und stattdessen per GradidoID, es hier zu unnötigen Tabellen-Migrationen kommt, wird mit diesem Usecase die Spalte *password_encryption_type* eingeführt. Damit ist dann erkennbar, ob es sich bei dem gespeicherten Passwort um ein One-Time-Passwort handelt oder um ein anderweitig verschlüsseltes Passwort. + +Sollte das Issue zur Migration der Passwort-Verschlüsselung schon vor diesem Usecase umgesetzt sein, dann existiert in der `users`-Tabelle schon die Spalte `passphrase_encryption_type`. Dann sollte diese in `password_encryption_type` umbenannt und dem Enum der Wert 0 für One-Time-Passwort hinzugefügt werden. Die Bezeichnung *passphrase_encryption_type* ist irreführend, da in der Tabelle eine Spalte `passphrase `existiert. Doch die Verschlüsselung wird auf die Spalte `password `und nicht auf `passphrase` angewendet. + +#### Migration + +Mit den zuvor beschriebenen Datenbankänderungen muss eine Datenbankmigration auf die bestehenden Daten durchgeführt werden. Nachdem die strukturellen Änderungen wie neue `accounts`-Tabelle anlegen und bestehende `users`-Tabelle ändern durchgeführt wurde, erfolgt nun die eigentliche Migration der Daten: + +* erzeugen der neuen `accounts`-Tabelle wie oben beschrieben +* ändern der bestehenden `users`-Tabelle wie oben beschrieben mit folgenden Default-Initialisierungen + * privacy_policy_at = created_at + * passwort_encryption_type = Enum `PasswordEncryptionType.EMAIL` oder Wert=1 +* Insert pro Eintrag aus der `users`-Tabelle jeweils einen Eintrag in die `accounts`-Tabelle mit folgenden Initialisierungen: + * `accounts.user_id` = `users.id` + * `accounts.type` = Enum `AccountType.AGE` + * `accounts.created_at` = `users.created_at` + * `accounts.activated` = `users.emailContact.email_checked` + * `accounts.creations_allowed` = TRUE (weil es ein account type = AGE ist) + * `accounts.decay` = TRUE (weil es ein account type = AGE ist) + * `accounts.balance` = null (dieses Attribut wird in separatem Issue "Update Account-Balance during writing a Transaction" bedient) + * `account.updated_at` = null (dieses Attribut wird in separatem Issue "Update Account-Balance during writing a Transaction" bedient) + +### 2.2 Admin-Interface + +#### searchUsers + +Der Service *AdminResolver.searchUsers* muss die Filterkriterien "aktiviertes Konto" und "bestätigte Email" getrennt von einander unterstützen. Bisher gibt es in den *SearchUserFilters* das Filterkriterium "byActivated", doch dieses wird auf das Flag `email_checked` in der `user_contacts`-Tabelle angewendet. Das entspricht aber dann dem FilterKriterium "bestätigte Email". + +Somit muss das schon existierende Fitlerkriterium "aktiviertes Konto" auf die Spalte "`activated`" in der `accounts`-Tabelle angewendet werden und ein zusätzliches Filterkriterium "bestätigte Email", das auf die Spalte `email_checked` in der `user_contacts`-Tabelle filtert. + +Der ErgebnisTyp `SearchUsersResult `des Service *searchUsers* muss um die Informationen erweitert werden, die in dem oben aufgezeigten Detail-Dialog der *Nutzer-Suche* auf dem Reiter "Registrierung" zur Anzeige gebracht werden: + +* Zeitpunkt der Konto-Erstellung (`accounts.created_at`) +* Status des Kontos (`accounts.activated`) +* Status der Email-Bestätigung (`user_contacts.email_checked`) +* falls `users.password_encryption_type` = 0, dann das One-Time-Passwort (`users.password`) + +#### adminCreateUser + +Im *AdminResolver* muss aus Berechtigungsgründen ein neuer Service *adminCreateUser* erstellt werden, da im *UserResolver* der Service *createUser* für jeden offen ist, ohne dass eine vorherige Authentifizierung per Login stattgefunden hat. + +Dieser neue Service benötigt folgende Signatur als Eingabeparameter: + +| Argument | Type | Bezeichnung | +| --------------- | ------ | ------------------------------------- | +| vorname | String | der Vorname des neuen Users | +| nachname | String | der Nachname des neuen Users | +| email | String | die Email-Adresse des neuen Users | +| oneTimePassword | String | das One-Time-Passwort des neuen Users | + + Der neue Service entspricht der internen Logik weitestgehend dem exitierenden Service `UserResolver.create`. + +* prüfen ob Email schon existiert und wenn ja, dann an diese Email eine Info-Nachricht und Abruch mit Fehlermeldung +* neues User-Objekt initialisieren mit + * GradidoID + * Vorname + * Nachname + * One-Time-Passwort mit gleichzeitigem Setzen von `password_encryption_type` = Enum `PasswordEncryptionType.ONETIME` +* das neue User-Objekt speichern +* neues UserContact-Objekt initialisieren mit + * Email + * vorherige userID +* das neue UserContact-Objekt speichern +* die erhaltene ID des neuen UserContact-Eintrags in den vorher erzeugten User-Eintrag als `emailId` schreiben +* einen EventProtokoll-Eintrag schreiben vom Typ *EventAdminRegister*, der neu anzulegen ist und von `EventBasicUserId `abgeleitet wird, aber zusätzlich die *UserId* des Moderators in das Attribut `xUserId `einträgt. +* die Confirmation-Email zur Bestätigung der Email-Adresse verschicken +* alle fachlich sonst notwendigen Eventprotokolle schreiben + +Alle logischen Schritte bzgl. einer PublisherID oder eines Redeem-Links bleiben hier in diesem Service aussen vor. + +Als Rückgabe sind erst einmal keine weiteren fachlichen Daten geplant, ausser einem Boolean=TRUE für eine evtl. Erfolgsmeldung. Im Fehlerfall wird der Service mit einer Exception beendet. + +#### adminUpdateUser + +Im *AdminResolver* wird der neue Service *adminUpdateUser* eingeführt, um für einen schon existierenden User das One-Time-Passwort zu aktualisieren. Über die vorher durchgeführte Nutzer-Suche sind die aktuell gespeicherten Userdaten schon ermittelt worden. Damit ergibt sich als Signatur für diesen Service folgendes: + +| Argument | Typ | Beschreibung | +| -------- | ------ | -------------------------------------------------------- | +| userId | number | der technisch eindeutige Identifer des betroffenen Users | +| password | String | das geänderte One-Time-Passwort | + +Dieser Service führt mit der übergebenen *userId* ein update auf dem *User* aus. Dazu wird bei der Aktualisierung das Kriterium `passwort_encryption_type` = Enum `PasswordEncryptionType.ONETIME` sichergestellt und das Attribut `password `mit dem übergebenen Parameter *password* sowie das Flag `activated `= TRUE gesetzt. Abschließend erfolgt das Schreiben eines EventProtokoll-Eintrags vom Typ *EventAdminPasswortChange*, der neu anzulegen ist und von `EventBasicUserId `abgeleitet wird, aber zusätzlich die *UserId* des Moderators in das Attribut `xUserId `einträgt. + +Als Rückgabe sind erst einmal keine weiteren fachlichen Daten geplant, ausser einem Boolean=TRUE für eine evtl. Erfolgsmeldung. Im Fehlerfall wird der Service mit einer Exception beendet. + +### 2.3 User-Interface + +#### login + +Im *UserResolver* muss der Service *login* angepasst werden, um eine Anmeldung per One-Time-Passwort zu erlauben. + +Dabei wird zuerst per übergebener *email* der User aus der Datenbank ermittelt. Bevor die Prüfung auf das Flag `user.emailContact.email_checked` erfolgt, muss eine Prüfung auf das Attribut `user.password_encryption_type` durchgeführt werden. Ist die Passwort-Verschlüsselung dieses Users auf dem Wert `PasswordEncryptionType.ONETIME`, dann wird die Prüfung des Flags `user.emailContact.email_checked` übersprungen. + +Durch den Wert des Attributs `user.password_encryption_type` wird die Passwort-Entschlüsselungsart und Prüfung gesteuert. Beim Wert `PasswordEncryptionType.ONETIME` ist das Passwort selbst für die Anwendung kein Geheimnis, da dieses durch einen Moderator und nicht geheim durch den User eingegeben wurde und jederzeit durch einen Moderator im Klartext wieder angezeigt werden kann. + +Wenn zuvor es sich um ein Login per One-Time-Passwort handelte, dann erfolgt keine Überprüfung des EloPage-Status und Aktuallisierung der PublisherId. + +Mit erfolgreicher Beendigung des Login-Service wird der User mit seinen aktuellen Attributwerten zurückgeliefert. Dabei ist nun im Frontend sicherzustellen, dass wenn im User das Attribut `user.password_encryption_type` den Wert `PasswordEncryptionType.ONETIME` hat, dass dann mit Verlassen des Login-Dialogs der Anwender direkt nur auf die Passwort-Ändern-Seite geführt wird. Dem Einstieg in den Passwort-Ändern-Dialog muss aus dem Login-Dialog die Information mitgeteilt werden, dass es sich hier um ein One-Time-Passwort Login handelte, damit der Passwort-Ändern-Dialog die entsprechenden Änderungen in Bezug auf diesen UseCase durchführen kann. + +#### changePassword + +Im *UserResolver* ist der neue Service *changePassword* zu erstellen. Dieser bekommt als Eingabesignatur folgende Parameter: + +| Argument | Type | Bezeichnung | +| ------------- | ------- | ----------------------------------------------------------------------------------------- | +| userId | number | eindeutiger Identifier des Users, der zuvor beim Login an das Frontend übermittelt wurde | +| oldPassword | String | altes Passwort des angemeldeten Users | +| newPassword | String | neues Passwort des angemeldeten Users | +| privacyPolicy | boolean | optional: Flag zur Zustimmung der Datenschutzerklärung | + +Die übergebenen Parameter müssen im ersten Schritt auf ihre Validität untersucht werden. Das heißt sind alle mandatorischen Parameter übergeben und entsprechen ihre Werte den formellen Anforderungen (z.B. sind die Passworte gemäß den Passwort-Regeln). + +Mit der übergebenen *userId* wird der zugehörige User aus der Datenbank ermittelt. Bevor die eigentliche Logik zur Passwort-Änderung durchgeführt wird, erfolgt zuvor noch eine Prüfung auf den Userkonto-Status im Attribut `accounts.activated`. Nur wenn das Userkonto im Status *aktiviert* - per One-Time-Passwort durch den Moderator oder per Email-Confirmation durch den User selbst - ist, kann das Passwort geändert werden. + +In Abhängigkeit des im User gespeicherten Typs der Passwort-Verschlüsselung, muss das übergebene *oldPassword* gegen die im User gespeicherten Passwort-Daten überprüft werden: + +* *EncryptionType = One-Time-Passwort:* das im User gespeicherte Passwort muss dem übergebenen *oldPassword* entsprechen. Je nach technischer Implementierung könnte ggf. eine Entschlüsselungslogik auf das gespeicherte Passwort notwendig sein, da ein Passwort niemals im Klartext in der Datenbank gespeichert sein soll. Das heißt das im User gespeicherte Passwort muss nach einer evtl. Entschlüsselung mit dem übergebenen Passwort übereinstimmen. Ein One-Way-Hashing ist zwar sicherer aber reicht hier nicht, da das One-Time-Passwort im Admin-Interface im Klartext angezeigt werden können muss. +* *EncryptionType = EMAIL:* das im User gespeicherte Passwort wurde mit der im User gespeicherten Email als Salt verschlüsselt und als EmailHash gespeichert. Daher muss mit der im User gespeichert Email und dem übergebenen *oldPassword* ein EmailHash erzeugt werden, um diesen mit dem im User gespeicherten Emailhash zu vergleichen. +* *EncryptionType = GradidoID:* das im User gespeicherte Passwort wurde mit der im User gespeicherten *GradidoID* als Salt verschlüsselt und als EmailHash gespeichert. Daher muss mit der im User gespeicherten *GradidoID* und dem übergebenen *oldPassword* ein EmailHash erzeugt werden, um diesen mit dem im User gespeicherten EmailHash zu vergleichen. + +Ist die Überprüfung des alten Passwortes in Abhängigkeit des Verschlüsselungstyps erfolgreich, dann kann mit der Verschlüsselung des *newPassword* weiter gemacht werden. Als Verschlüsselungstyp wird immer der höchsten Wert des Verschlüsselungs-Enums eingesetzt, auch wenn zuvor ein niedrigerer Typ verwendet wurde. Damit erfolgt immer ein implizites Upgrade auf den aktuellsten Verschlüsselungstyp. Somit wird das übergebene *newPassword* mit der *GradidoID* des Users zu einem EmailHash verschlüsselt und zusammen mit dem Attribut `user.password_encryption_type` = `PasswordEncryptionType.GRADIDO_ID` in die Datenbank geschrieben. Je nach Wert des übergebenen Flags `privacyPolicy` wird im User das Attribut `privacy_policy_at` mit dem aktuellen Zeitpunkt ebenfalls aktualisiert. + +War die Passwort-Änderung erfolgreich wird ein boolean=TRUE zurückgegeben, ansonsten eine Exception mit aussagekräftiger Fehlermeldung. + +## Brainstorming von Bernd + +Damit wir ohne zusätzliche Technologie möglichst schnell und unkompliziert eine Lösung bekommen, dass wir neue User direkt vor Ort registrieren können, schlage ich folgende zwei Funktionen im Admin-Bereich vor: + +1. Manuell bestätigen und (vorläufiges) Passwort setzen +2. Neuen User registrieren + +### Usecase + +Bei einer Veranstaltung o.ä. sollen neue Mitglieder geworben werden. Dabei ist ungewiss, ob sie ein Endgerät dabei haben bzw. dieses korrekt bedienen können (QR-Code, E-Mail-Zugang etc.) + +#### Lösung: + +Bei der Veranstaltung ist ein Moderator vor Ort, oder der Veranstalter bekommt vorübergehend Moderatoren-Rechte. + +Der Moderator hat auf einem Browser sein Gradido-Konto (Admin-Interface) laufen. Auf einem anderen Browser (oder einem anderen Gerät) können sich ggf. User einloggen. + +##### Variante 1: + +Der Interessent registriert sich über Link/QR-Code, hat aber keinen Zugang zu seinen E-Mails. Der Moderator bestätigt ihn und gibt ihm ein vorläufiges Passwort (oder lässt den User im Backend selbst ein Passwort eintippen). + +##### Variante 2: + +Der Moderator registriert den Interessenten und gibt ihm ein vorläufiges Passwort (oder lässt den User im Backend selbst ein Passwort eintippen). + +Das vorläufige Passwort kann so lange vom Moderator geändert werden, bis der User über die Mail sein Passwort neu gesetzt hat. Dadurch wird erreicht, dass der Moderator den User so lange unterstützen kann (z.B. wenn er sein PW vergessen hat), bis er Mail-Zugang hat und sein Passwort selbst setzen kann. + +##### Weitere Anwendungsfälle: + +Wenn eine (zukünftige) Community beschließt, dass neue Mitglieder nur durch persönliche Einladung aufgenommen werden. Für diesen Fall müsste dann noch die User-Registrierung abgeschaltet werden können. diff --git a/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md b/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md index ab04efc7f..ac982fa53 100644 --- a/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md +++ b/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md @@ -2,6 +2,18 @@ Die Idee besteht darin, dass ein Administrator eine Contribution mit all seinen Attributen und Regeln im System erfasst. Dabei kann er unter anderem festlegen, ob für diese ein Link oder ein QR-Code generiert und über andere Medien wie Email oder Messenger versendet werden kann. Der Empfänger kann diesen Link bzw QR-Code dann über die Gradido-Anwendung einlösen und bekommt dann den Betrag der Contribution als Schöpfung auf seinem Konto gutgeschrieben. +## Ausbaustufen + +Die beschriebenen Anforderungen werden in mehrere Ausbaustufen eingeteilt. Damit können nach und nach die Dialoge und Businesslogik schrittweise in verschiedene Releases gegossen und ausgeliefert werden. + +### Ausbaustufe 1 + +Diese Ausbaustufe wird gezielt für die "Dokumenta" im Juni 2022 zusammengestellt. Details siehe weiter unten im speziellen Kapitel "Ausbaustufe 1". + +### Ausbaustufe 2 + +Diese Ausbaustufe wird gezielt für die Anforderungen für das Medidationsportal von "Abraham" zusammegestellt. Details siehe weiter unten im speziellen Kapitel "Ausbaustufe 2". + ## Logischer Ablauf Der logische Ablauf für das Szenario "Activity-Confirmation and booking of Creations " wird in der nachfolgenden Grafik dargestellt. Dabei wird links das Szenario der "interactive Confirmation and booking of Creations" und rechts "automatic Confirmation and booking of Creations" dargestellt. Ziel dieser Grafik ist neben der logischen Ablaufsübersicht auch die Gemeinsamkeiten und Unterschiede der beiden Szenarien herauszuarbeiten. @@ -28,11 +40,11 @@ Der Gültigkeitsstart wird als Default mit dem aktuellen Erfassungszeitpunkt vor Wie häufig ein User für diese Contribution eine Schöpfung gutgeschrieben bekommen kann, wird über die Auswahl eines Zyklus - stündlich, 2-stündlich, 4-stündlich, etc. - und innerhalb dieses Zyklus eine Anzahl an Wiederholungen definiert. Voreinstellung sind 1x täglich. -![Zyklus](./image/UC_Send_Contribution_Admin-new ContributionZyklus.png) +![img](./image/UC_Send_Contribution_Admin-new_ContributionZyklus.png) Ob die Contribution über einen versendeten Link bzw. QR-Code geschöpft werden kann, wird mittels der Auswahl "Versenden möglich als" bestimmt. -![send](./image/UC_Send_Contribution_Admin-new ContributionSend.png) +![img](./image/UC_Send_Contribution_Admin-new_ContributionSend.png) Für die Schöpfung der Contribution können weitere Regeln definiert werden: @@ -44,11 +56,11 @@ Für die Schöpfung der Contribution können weitere Regeln definiert werden: ![new](./image/UC_Send_Contribution_Admin-newContribution.png) -### Ausbaustufe-1: +## Ausbaustufe-1: -Die Ausbaustufe-1 wird gezielt auf die Anforderungen der "Dokumenta" im Juni 2022 abgestimmt. +Die Ausbaustufe-1 wird gezielt auf die Anforderungen der "Dokumenta" im Juni 2022 abgestimmt. -#### Contribution-Erfassungsdialog (Adminbereich) +### Contribution-Erfassungsdialog (Adminbereich) Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gestellt: @@ -64,14 +76,12 @@ Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gest | VersendenMöglich | - hier wird "als Link / QR-Code" voreingestellt | | alle weiteren Attribute | - entfallen für diese Ausbaustufe
- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden
- diese GUI-Komponenten müssen wenn sichtbar disabled sein und dürfen damit keine Eingaben entgegen nehmen | - -#### Ablauflogik +### Ablauflogik Für die Ausbaustufe-1 wird gemäß der Beschreibung aus dem Kapitel "Logischer Ablauf" nur die "automatic Confirmation and booking of Creations" umgesetzt. Die interaktive Variante - sprich Ablösung des EloPage Prozesses - mit "interactive Confirmation and booking of Creations" bleibt für eine spätere Ausbaustufe aussen vor. Das Regelwerk in der Businesslogik wird gemäß der reduzierten Contribution-Attribute aus dem Erfassungsdialog, den vordefinierten Initialwerten und der daraus resultierenden Variantenvielfalt vereinfacht. - #### Kriterien "Dokumenta" * Es soll eine "Dokumenta"-Contribution im Admin-Bereich erfassbar sein und in der Datenbank als ContributionLink gespeichert werden. @@ -91,6 +101,66 @@ Das Regelwerk in der Businesslogik wird gemäß der reduzierten Contribution-Att * es erfolgt eine übliche Schöpfungstransaktion nach der Bestätigung der Contribution * die Schöpfungstransaktion schreibt den Betrag der Contribution dem Kontostand des Users gut +## Ausbaustufe-2 + +Die Ausbaustufe-2 wird gezielt auf die Anforderungen zur Anbindung des Meditationsportals von Abraham im Oktober 2022 abgestimmt. + +### Contribution-Erfassungsdialog (Adminbereich) + +Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gestellt: + +| Attribut | Beschreibung | +| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| GültigBis | - das Datum, wie lange die Contribution gültig und damit einlösbar ist
- für diese Ausbaustufe soll ein offenes Ende möglich sein, daher bleibt dieses Attribut leer | +| Zyklus | - Angabe wie häufig eine Contribution gutgeschrieben werden kann
- als Auswahlliste (Combobox) geplant, aber für diese Ausbaustufe nur mit dem Wert "täglich" vorbelegt | +| Wiederholungen | - Anzahl an Wiederholungen pro Zyklus
- für diese Ausbaustufe wird der Wert "1" vorbelegt -> somit gilt: ein User kann diese Contribution nur 1x täglich einlösen | +| alle weiteren noch nicht vorhandenen Attribute | - entfallen für diese Ausbaustufe
- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden
- diese GUI-Komponenten müssen wenn sichtbar disabled sein und dürfen damit keine Eingaben entgegen nehmen | + +### Ablauflogik + +Für die Ausbaustufe-2 und der inzwischen umgesetzten Ablösung des "EloPage Contribution Erfassungsprozesses" wird gemäß der Beschreibung aus dem Kapitel "Logischer Ablauf" die "automatic Confirmation and booking of Creations" sowie die interaktive Variante "interactive Confirmation and booking of Creations" mit berücksichtigt. + +Das Regelwerk in der Businesslogik wird gemäß der noch nicht vollumfänglich geplanten Contribution-Attribute aus dem Erfassungsdialog, den vordefinierten Initialwerten und der daraus resultierenden Variantenvielfalt vereinfacht. + +#### Kriterien "Meditationsportal (Abraham)" + +* Es soll eine "GlobalMeditation"-Contribution nur im Admin-Bereich erfassbar sein und in der Datenbank als ContributionLink gespeichert werden. +* Es wird ein offenes Ende als Gesamtlaufzeit dieser Contribution benötigt, was durch ein leeres GültigBis-Datum ausgedrückt bzw. erfasst werden soll. +* Die "Meditationsportal"-Contribution kann von einem User maximal 1x täglich aktiviert werden. Dies wird über die Erfassung des Attributes "Zyklus" = täglich und des Attributes "Wiederholungen" = 1 ermöglicht. +* Ein User kann mit diesem Link nur die Menge an GDDs schöpfen, die in der Contribution als "Betrag" festgelegt ist +* Die "GlobalMeditation"-Contribution kann als Link / QR-Code erzeugt, angezeigt und in die Zwischenablage kopiert werden +* Jeder beliebige User kann den Link / QR-Code aktivieren +* der Link führt auf eine Gradido-Seite, wo der User sich anmelden oder registrieren kann +* mit erfolgreichem Login bzw. Registrierung wird der automatische Bestätigungs- und Schöpfungsprozess getriggert +* es erfolgt eine Überprüfung der definierten Contribution-Regeln für den angemeldeten User: + * Gültigkeit: liegt die Aktivierung im Gültigkeitszeitraum der Contribution + * Zyklus und WIederholungen: bei einem Zyklus-Wert = "täglich" und einem Wiederholungswert = 1 darf der User den Betrag dieser Contribution nur einmal am Tag schöpfen. Es gibt keine Überprüfung eines zeitlichen Mindestabstandes zwischen zwei Schöpfungen an zwei aufeinanderfolgenden Tagen. + * max. schöpfbarer Gradido-Betrag pro Monat: wenn der Betrag der Contribution plus der Betrag, den der User in diesem Monat schon geschöpft hat, den maximal schöpfbaren Betrag pro Monat von 1000 GDD übersteigt, dann wird die Schöpfung dieser Contribution abgelehnt +* mit erfolgreich durchlaufenen Regelprüfungen wird ein "besätigter" aber "noch nicht gebuchten" Eintrag in der "Contributions"-Tabelle erzeugt +* ein "bestätigter" aber "noch nicht gebuchter" "Contributions"-Eintrag stößt eine Schöpfungstransaktion für den User an +* es erfolgt eine übliche Schöpfungstransaktion mit automatischer Bestätigung der Contribution +* die Schöpfungstransaktion schreibt den Betrag der Contribution dem Kontostand des Users gut + +## Ausbaustufe-3 + +### Änderungen im Registrierungsprozess + +Aktuell treten Probleme mit der Aktivierung des ContributionLinks während des Registrierungsprozesses auf. Sobald der User bei der Registrierung sein Konto zwar angelegt, aber die erhaltene Email-Confirmation nicht abgeschlossen und damit sein Konto noch nicht aktiviert hat, kann derzeit der Redeem-Link nicht als Transaktion durchgeführt werden. Die Gültigkeitsdauer des Redeemlink reicht meist nicht bis der User sein Konto aktiviert. Daher wird nun die Idee verfolgt die Einlösung des Redeemlinks schon während der Anlage des inaktiven Kontos als "pendingRedeem Contribution" anzulegen. Sobald dann der User sein Konto per Email-Confirmation aktiviert, soll die "pendingRedeem Contribution" automatisch zu einer Tranaktion überführt und der Betrag des Redeemlinks auf das Konto des Users gebucht werden. + +Folgende Schritte und Änderungen sind dabei vorgesehen (siehe in der Grafik rechts im orange markierten Bereich im Vergleich zur Grafik im Kapitel "Logischer Ablauf"): + +![img](./image/Ablauf_manuelle_auto_Creations_2.png) + +* Der User landet mit Aktivierung eines Redeem-Links wie bisher auf der Login/Registrierungsseite, wobei wie bisher schon der Redeemlink als Parameter in den Registrierungsprozess übergeben wird. +* Mit der Anlage des neuen aber noch inaktiven User-Kontos und einer Übergabe eines Redeemlinks wird der Redeemlink zu einer "pendingRedeem Contribution" für den neuen User angelegt, aber noch nicht als Transaktion gebucht + * nach Anlage des inaktiven User-Kontos und bevor die Confirmation-Email abgeschickt wird, erfolgt das Schreiben eines neuen Contribution-Eintrages mit den Daten des Redeem-Links. + * Die neu angelegte Contribution wird im Status "pendingRedeem" gespeichert. Dieser neue Status ist notwendig, um im AdminInterface die normalen "pending Contributions" von den "pendingRedeem Contributions" zu unterscheiden. Denn der Admin soll zum Einen diese "pendingRedeem Contributions" weder bestätigen noch ablehnen können und zum Anderen sollen die "pendingRedeem Contributions" automatisiert bestätigt und gebucht werden können. Daher wird eine Unterscheidung zwischen den interaktiv angelegten Contributions im Status pending und den per Redeem-Link angelegten Contributions im Status pending benötigt. + * Damit endet erst einmal die weitere Verarbeitung der Redeem-Link-Aktivierung +* Mit Aktivierung des Links in der Email-Confirmation und damit der Aktivierung des User-Kontos erfolgt automatisch die Buchung der "pendingRedeem Contribution" und führt damit zur eigentlichen Buchung des Redeem-Betrages auf das User Konto. + * mit Erhalt der Email-Confirmation Aktivierung wird das User-Konto aktiviert + * Nach der Aktivierung des User-Kontos erfolgt eine Prüfung auf schon vorhandene "pendingRedeem Contributions" aus vorherigen Redeem-Link-Aktivierungen + * Jede vorhandene "pendingRedeem Contribution" wird jetzt automatisch bestätigt und zu einer Transaktion überführt + * Mit der bestätigten Contribution und daraus überführten Transaktion erhält der User eine Bestätigungsemail mit den Contribution spezifischen Daten. ## Datenbank-Modell @@ -100,34 +170,36 @@ Das nachfolgende Bild zeigt das Datenmodell vor der Einführung und Migration au ![Datenbankmodell](./image/DB-Diagramm_20220518.png) -### Datenbank-Änderungen +### Ausbaustufe-1 + +#### Datenbank-Änderungen Die Datenbank wird in ihrer vollständigen Ausprägung trotz Ausbaustufe-1 wie folgt beschrieben umgesetzt. -#### neue Tabellen +##### neue Tabellen -##### contribution_links - Tabelle +###### contribution_links - Tabelle | Name | Typ | Nullable | Default | Kommentar | | ------------------------------- | ------------ | :------: | :------------: | -------------------------------------------------------------------------------------------------------------------------------------- | | id | INT UNSIGNED | NOT NULL | auto increment | PrimaryKey | -| name | varchar(100) | NOT NULL | | unique Name | -| description | varchar(255) | | | | +| name | varchar(100) | NOT NULL | | unique Name | +| description | varchar(255) | | | | | valid_from | DATETIME | NOT NULL | NOW | | -| valid_to | DATETIME | | NULL | | -| amount | DECIMAL | NOT NULL | | | +| valid_to | DATETIME | | NULL | | +| amount | DECIMAL | NOT NULL | | | | cycle | ENUM | NOT NULL | ONCE | ONCE, HOUR, 2HOUR, 4HOUR, 8HOUR, HALFDAY, DAY, 2DAYS, 3DAYS, 4DAYS, 5DAYS, 6DAYS, WEEK, 2WEEKS, MONTH, 2MONTH, QUARTER, HALFYEAR, YEAR | | max_per_cycle | INT UNSIGNED | NOT NULL | 1 | | -| max_amount_per_month | DECIMAL | | NULL | | -| total_max_count_of_contribution | INT UNSIGNED | | NULL | | -| max_account_balance | DECIMAL | | NULL | | -| min_gap_hours | INT UNSIGNED | | NULL | | -| created_at | DATETIME | | NOW | | -| deleted_at | DATETIMEBOOL | | NULL | | -| code | varchar(24) | | NULL | | -| link_enabled | BOOL | | NULL | | +| max_amount_per_month | DECIMAL | | NULL | | +| total_max_count_of_contribution | INT UNSIGNED | | NULL | | +| max_account_balance | DECIMAL | | NULL | | +| min_gap_hours | INT UNSIGNED | | NULL | | +| created_at | DATETIME | | NOW | | +| deleted_at | DATETIMEBOOL | | NULL | | +| code | varchar(24) | | NULL | | +| link_enabled | BOOL | | NULL | | -##### contributions -Tabelle +###### contributions -Tabelle | Name | Typ | Nullable | Default | Kommentar | | --------------------- | ------------ | -------- | -------------- | -------------------------------------------------------------------------------- | @@ -145,9 +217,9 @@ Die Datenbank wird in ihrer vollständigen Ausprägung trotz Ausbaustufe-1 wie f | booked_at | DATETIME | | NULL | date, when the system has booked the amount of the activity on the users account | | deleted_at | DATETIME | | NULL | soft delete | -#### zu migrierende Tabellen +##### zu migrierende Tabellen -##### Tabelle admin_pending_creations +###### Tabelle admin_pending_creations Diese Tabelle wird im Rahmen dieses UseCase migriert in die neue Tabelle contributions... @@ -168,6 +240,18 @@ Diese Tabelle wird im Rahmen dieses UseCase migriert in die neue Tabelle contrib ...und kann nach Übernahme der Daten in die neue Tabelle gelöscht werden oder es erfolgen die Änderungen sofort auf der Ursprungstabelle. -### Zielmodell +#### Zielmodell ![Contributions-DB](./image/DB-Diagramm_Contributions.png) + +### Ausbaustufe-2 + +Für die Ausbaustufe-2 sind keine Datenbank-Änderungen notwendig. Gemäß dem Zielmodell sind alle notwendigen Tabellen und Attribute schon vorhanden. + +#### Zielmodell + +![img](./image/DB-Diagramm_Contributions_Stufe_2.png) + +### Ausbaustufe-3 + +Für die Ausbaustufe-3 dürften im Grunde ebenfalls keine zusätzlichen Datenbankänderungen notwendig sein. Denn für eine "pending Contribution" und deren Confirmation mit Tranaktionsüberführng sind ebenfalls schon alle Attribute vorhanden. diff --git a/docu/Concepts/BusinessRequirements/graphics/Ablauf_manuelle_auto_Creations.drawio b/docu/Concepts/BusinessRequirements/graphics/Ablauf_manuelle_auto_Creations.drawio index b4f1f45ea..3c2ae0559 100644 --- a/docu/Concepts/BusinessRequirements/graphics/Ablauf_manuelle_auto_Creations.drawio +++ b/docu/Concepts/BusinessRequirements/graphics/Ablauf_manuelle_auto_Creations.drawio @@ -1,6 +1,6 @@ - + @@ -183,31 +183,31 @@ - + - + - + - + - + - + @@ -317,15 +317,15 @@ - + - + - + @@ -334,10 +334,10 @@ - + - + @@ -351,7 +351,7 @@ - + @@ -359,8 +359,76 @@ - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docu/Concepts/BusinessRequirements/graphics/GradidoÜbersichtMaske.bmpr b/docu/Concepts/BusinessRequirements/graphics/GradidoÜbersichtMaske.bmpr index 94c259f9c..86ffadba4 100644 Binary files a/docu/Concepts/BusinessRequirements/graphics/GradidoÜbersichtMaske.bmpr and b/docu/Concepts/BusinessRequirements/graphics/GradidoÜbersichtMaske.bmpr differ diff --git a/docu/Concepts/BusinessRequirements/graphics/UC_ManuelleUserRegistrierung.bmpr b/docu/Concepts/BusinessRequirements/graphics/UC_ManuelleUserRegistrierung.bmpr new file mode 100644 index 000000000..885ce6762 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/graphics/UC_ManuelleUserRegistrierung.bmpr differ diff --git a/docu/Concepts/BusinessRequirements/image/Ablauf_manuelle_auto_Creations_2.png b/docu/Concepts/BusinessRequirements/image/Ablauf_manuelle_auto_Creations_2.png new file mode 100644 index 000000000..4211f65cf Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Ablauf_manuelle_auto_Creations_2.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Admin-CreateUser.png b/docu/Concepts/BusinessRequirements/image/Admin-CreateUser.png new file mode 100644 index 000000000..5b15b27e2 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Admin-CreateUser.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-ActivatedOneTimePasswort.png b/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-ActivatedOneTimePasswort.png new file mode 100644 index 000000000..1f6ad0b73 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-ActivatedOneTimePasswort.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-Details.png b/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-Details.png new file mode 100644 index 000000000..ce2cd2ede Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Admin-UserAccount-Details.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Admin-UserSearch.png b/docu/Concepts/BusinessRequirements/image/Admin-UserSearch.png new file mode 100644 index 000000000..3d59dd7cb Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Admin-UserSearch.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Admin-UserSearch_inaktivAccount.png b/docu/Concepts/BusinessRequirements/image/Admin-UserSearch_inaktivAccount.png new file mode 100644 index 000000000..e8ddb5f36 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Admin-UserSearch_inaktivAccount.png differ diff --git a/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png b/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png new file mode 100644 index 000000000..eee7fa23f Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png differ diff --git a/docu/Concepts/BusinessRequirements/image/One-Time-Passwort-Login.png b/docu/Concepts/BusinessRequirements/image/One-Time-Passwort-Login.png new file mode 100644 index 000000000..3e275db94 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/One-Time-Passwort-Login.png differ diff --git a/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionSend.png b/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionSend.png similarity index 100% rename from docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionSend.png rename to docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionSend.png diff --git a/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionZyklus.png b/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionZyklus.png similarity index 100% rename from docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionZyklus.png rename to docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionZyklus.png diff --git a/docu/Concepts/TechnicalRequirements/UC_Introduction_of_Gradido-ID.md b/docu/Concepts/TechnicalRequirements/UC_Introduction_of_Gradido-ID.md index 9d607ba97..a6ca83bfc 100644 --- a/docu/Concepts/TechnicalRequirements/UC_Introduction_of_Gradido-ID.md +++ b/docu/Concepts/TechnicalRequirements/UC_Introduction_of_Gradido-ID.md @@ -10,30 +10,27 @@ Additionally the Gradido-ID allows to administrade any user account data like ch The formalized definition of the Gradido-ID can be found in the document [BenutzerVerwaltung#Gradido-ID](../BusinessRequirements/BenutzerVerwaltung#Gradido-ID). -## Steps of Introduction +## 1st Stage -To Introduce the Gradido-ID there are several steps necessary. The first step is to define a proper database schema with additional columns and tables followed by data migration steps to add or initialize the new columns and tables by keeping valid data at all. +The 1st stage of introducing the Gradido-ID contains several steps. The first step is to define a proper database schema with additional columns and tables followed by data migration steps to add or initialize the new columns and tables by keeping valid data at all. -The second step is to decribe all concerning business logic processes, which have to be adapted by introducing the Gradido-ID. +The second step is to decribe all concerning business logic processes, which have to be adapted by introducing the Gradido-ID and handling the attributes of the new user_contacts table. ### Database-Schema #### Users-Table -The entity users has to be changed by adding the following columns. +The entity users has to be changed by adding the following columns. The column State gives a hint about the working state including the ticket number. -| Column | Type | Description | -| ------------------------ | ------ | ----------------------------------------------------------------------------------------------------------------- | -| gradidoID | String | technical unique key of the user as UUID (version 4) | -| alias | String | a business unique key of the user | -| passphraseEncryptionType | int | defines the type of encrypting the passphrase: 1 = email (default), 2 = gradidoID, ... | -| emailID | int | technical foreign key to the entry with type Email and contactChannel=maincontact of the new entity UserContacts | +| State | Column | Type | Description | +| -------------- | --------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| *done #2125* | gradidoID | String | technical unique key of the user as UUID (version 4) | +| *done #2125* | alias | String | a business unique key of the user | +| *done #2165* | emailID | int | technical foreign key to the UserContacts-Table with the entry of type Email, which will be interpreted as the maincontact from the Users table point of view | ##### Email vs emailID -The existing column `email`, will now be changed to the primary email contact, which will be stored as a contact entry in the new `UserContacts` table. It is necessary to decide if the content of the `email `will be changed to the foreign key `emailID `to the contact entry with the email address or if the email itself will be kept as a denormalized and duplicate value in the `users `table. - -The preferred and proper solution will be to add a new column `Users.emailId `as foreign key to the `UsersContact `entry and delete the `Users.email` column after the migration of the email address in the `UsersContact `table. +The existing column `email`, will now be changed to the primary email contact, which will be stored as a contact entry in the new `UserContacts` table. #### new UserContacts-Table @@ -55,17 +52,21 @@ A new entity `UserContacts `is introduced to store several contacts of different | phone | String | defines the address of a contact entry of type Phone | | contactChannels | String | define the contact channel as comma separated list for which this entry is confirmed by the user e.g. main contact (default), infomail, contracting, advertisings, ... | +##### ToDo: + +The UserContacts, expecially the email contacts, will for future be categorized to communication channels for example to allow the user to define which information he will get on which email-contact (aspects of administration, contract, advertising, etc.) + ### Database-Migration After the adaption of the database schema and to keep valid consistent data, there must be several steps of data migration to initialize the new and changed columns and tables. -#### Initialize GradidoID +#### Initialize GradidoID (done #2125) In a one-time migration create for each entry of the `Users `tabel an unique UUID (version4). -#### Primary Email Contact +#### Primary Email Contact (done #1798) -In a one-time migration read for each entry of the `Users `table the `Users.id` and `Users.email`, select from the table `login_email_opt_in` the entry with the `login_email_opt_in.user_id` = `Users.id` and create a new entry in the `UsersContact `table, by initializing the contact-values with: +In a one-time migration read for each entry of the `Users `table the `Users.id` and `Users.email` and create for it a new entry in the `UserContacts `table, by initializing the contact-values with: * id = new technical key * type = Enum-Email @@ -88,72 +89,130 @@ After this one-time migration and a verification, which ensures that all data ar The following logic or business processes has to be adapted for introducing the Gradido-ID -#### Read-Write Access of Users-Table especially Email +#### Capturing of alias + +To avoid using the email as primary identifier it is necessary to introduce a capturing of the alias. It is not a good solution to create for existing users an individual alias by a migration. So each user should capture his own alias during registration- and/or login-process. + +These requirements are described in the concept document [../BusinessRequirements/UC_Set_UserAlias.md]() **(done #2144)** and the implementation of these requirements will be the prerequisite for changing the login-process from single email-identifier to the future identifiers alias / gradidoID / email. + +#### Read-Write Access of Users-Table especially Email (done #1798) The ORM mapping has to be adapted to the changed and new database schema. -#### Registration Process +#### Create and Update User Processes -The logic of the registration process has to be adapted by +The logic of the create and update user process has to be adapted by -* initializing the `Users.userID` with a unique UUID -* creating a new `UsersContact `entry with the given email address and *maincontact* as `usedChannel ` -* set `emailID `in the `Users `table as foreign key to the new `UsersContact `entry -* set `Users.passphraseEncrpytionType = 2` and encrypt the passphrase with the `Users.userID` instead of the `UsersContact.email` +* creating a new User including with a unique UUID-V4 **(done #2125)** +* creating a new `UserContacts `entry with the given email address **(#2165)** +* set `emailID `in the `Users `table as foreign key to the new `UserContacts `entry **(#2165)** +* handling the new emailXXX attributes in the `user_contacts `table previously in the `email_opt_in `table **(#2165)** -#### Login Process +#### Search User Processes (#2165) -The logic of the login process has to be adapted by +The logic of all processes where the user is searched has to be adapted by -* search the users data by reading the `Users `and the `UsersContact` table with the email (or alias as soon as the user can maintain his profil with an alias) as input -* depending on the `Users.passphraseEncryptionType` decrypt the stored password - * = 1 : with the email - * = 2 : with the userID +* always search a *user* with its relation "emailContact" to load the associated userContact with his email +* a search user by *email* has to be implemented by searching a `userContact `for the given *email* and its relation "user" to load the associated user to this email + +#### Password Processes (#2165) + +The logic of all password processes has to be adapted by + +* read the *emailXXX* attributes out of the `user_contacts `table instead of previoulsy from the `email_opt_in `table +* writing or updating the *emailXXX* attributes now in the `user_contact `table instead of previously in the `email_opt_in `table +* the logic how to de/encrypt the password will not part of this 1st stage of introduction of the gradidoID. This will be part of the 2nd stage + +## 2nd Stage + +In the 2nd stage of this topic the password handling during registration and login process will be changed. These change must keep the current active password handling where the email is part of the encryption as long as all users are shifted to the new logic of password handling where the gradidoID will part of the encryption. This means there must be a kind of versioning which type of password encryption is used. Because some users will not login for a long time, which causes to use the old password encryption at their login process or in the future there could be the requirement to change the password handling to newer and safer algorithms. + +### Database-Schema + +#### Users-Table + +The entity *users* has to be changed by + +| Action | Column | Type | Description | +| :----: | ---------------------- | ---------- | ----------------------------------------------------------------------------------- | +| add | passwordEncryptionType | int | defines the type of encrypting the password: default 1 = email, 2 = gradidoID, ... | +| delete | public_key | binary(32) | before deletion verify and ensure that realy not in use even for encryption type 1 | +| delete | privkey | binary(80) | before deletion verify and ensure that realy not in use even for encryption type 1 | +| delete | email_hash | binary(32) | before deletion verify and ensure that realy not in use even for encryption type 1 | +| delete | passphrase | text | before deletion verify and ensure that realy not in use even for encryption type 1 | + +### Adaption of BusinessLogic #### Password En/Decryption -The logic of the password en/decryption has to be adapted by encapsulate the logic to be controlled with an input parameter. The input parameter can be the email or the userID. +The logic of the existing password en/decryption has to be shifted out of the ***UserResolver.js*** file in separated file(s). This separated file will be placed in the package-directory `backend/src/password` and named ***emailEncryptor.js***. As the name express the password encryption uses the `email `attribute. + +For the new password encryption logic a new file named ***gradidoIDEncryptor.js*** has to be created in the package-directory `backend/src/password`, which uses the *gradidoID* instead of the *email* for the password encryption. As soon as a user is changed to this encryption type with the *gradidoID*, it will be possible for him to change his *email* in his gradido-profile without any effect on his password encryption. + +For possible future requirements of newer and safer encryption logic additional files can be placed in the same directory with an expressiv file name for the new encryption type. + +All these `xxxEncryptor `files has to implement the following API, but with possibly different parameter types, depending on the encryption requirements: + +| API | emailEncryptor | gradidoIDEncryptor | return | description | +| ------------------------- | ---------------- | ------------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | +| **encryptPassword** | dbUser, password | dbUser, password | encrypted password | process the encryption with
the encryptor specific attributs
out of the dbUser and the original 
password entered by the user | +| **verifyPassword** | dbUser, password | dbUser, password | boolean | process the decryption with
the encryptor specific attributs
out of the dbUser and the original
password entrered by the user | +| **isPassword** | password | password | boolean | verifiy the formal rules of the original
password entered by the user | + +Which of the *xxxEncryptor* implementations will be used, depends on the value of the attribute `user.passwordEncryptionType`, which has to be interpreted before. To encapsulate this logic from the general business logic the ***Encryptor.js*** will be created with the same API as the specific *encryptor* classes, but it will interpret the attribute `dbUser.passwordEncryptionType` to select and invoke the correct *encryptor* implementation and to decide if an upgrade to a newer *encryptor* class should be done. + +The new Enum `PasswordEncryptionType `with the increasing values: + +* 1 = emailEncryptor +* 2 = gradidoIDEncryptor +* ... = ? + +will be used to define the order, which encryptor implementation is the oldest and the newest. That means if a user is still not using the newest *encryptor* for his password encryption the logic will implicit start a change to the newest *encryptor*. In all business processes, where the user enters his password the invokation of the ***Encryptor.js*** has to be introduced, because without the original entered password from the user no *encryptor* upgrade can be done. + +#### Registration Process + +The backend logic of the registration process has to be adapted + +* the ***UserResolver.createUser*** logic has to be changed by setting for a new user the attribut `Users.passwordEncrpytionType = 2` +* As soon as the user activates the email-confirmation link `https://gradido.net/checkEmail/` the application frontend invokes + + * at first the ***UserResolver.queryOptIn*** method, which will not be necessary, because the same checks about the given *emailOptIn*-code will be done a 2nd time in the invocation of *UserResolver.setPassword* + * at second the ***UserResolver.setPassword*** method, which has to be changed + * to use the new ***Encryptor.isPassword*** to validate the formal rules of the given password + * to remove all cryptographic logic like passphrase and key pair generation and password hashing to the new ***emailEncryptor.js*** + * to introduce the invocation of the new ***Encryptor.encryptPassword*** in the existing logic flow + +#### Login Process + +The logic of the login process has to be adapted in frontend and backend + +* Frontend + * The login dialog has to be changed at the email input component + * the new label contains "Email / Alias / GradidoID" + * the validation of the input field has to be changed to accept the input of one of these three possible values + * in case of failed validation an expressiv error message for the specific given input has to be shown (for more details about the rules for alias and gradidoID see the concepts [UC_SetUserAlias.md](../BusinessRequirements/UC_SetUserAlias.md) and [BenutzerVerwaltung#Gradido-ID](../BusinessRequirements/BenutzerVerwaltung#Gradido-ID)). + * The signature of the backend invocation ***UserResolver.login*** has to be changed to accept all three variants of identifiers + * depending on the implemented backend solution the frontend has to detect and initialize the correct parameter settings +* Backend + * The signature of the backend invocation ***UserResolver.login*** has to be changed to accept all three variants of identifiers + * solution-A: the first parameter *email* is renamed to *identifier* and the backend has to detect which type of identifier is given + * solution-B: two additional parameters *alias* and *gradidoID* are inserted in the type ***UnsecureLoginArgs*** and the frontend has to decide, which type of identifier is given and initialize the correct parameter + * **TODO**: solution-A is preferred? + * The logic of ***UserResolver.login*** has to be changed by + * in case of solution-A for the signature, the given identifier has to be detected for the correct user searching + * the user to be searched by the given identifier (email / alias / gradidoID) + * if a user could be found all the existing checks will be done as is, except the public and private key check, which will be removed + * for the password check the new ***Encryptor.isPassword*** and ***Encryptor.verifyPassword*** has to be invoked; all existing cryptographic logic has to be deleted #### Change Password Process -The logic of change password has to be adapted by +There are two ways to change a user password. -* if the `Users.passphraseEncryptionType` = 1, then +The first one is the *Forget-Password process*, which will use the same backend invocation with activating the email link like the *Registration Process* to set the password; for details see description above. - * read the users email address from the `UsersContact `table - * give the email address as input for the password decryption of the existing password - * use the `Users.userID` as input for the password encryption for the new password - * change the `Users.passphraseEnrycptionType` to the new value =2 -* if the `Users.passphraseEncryptionType` = 2, then +The second one is the *Update-Userinfo process*, which invokes the ***UserResolver.updateUserInfos***. This method has to be changed in the *password check block* by - * give the `Users.userID` as input for the password decryption of the existing password - * use the `Users.userID` as input for the password encryption fo the new password - -#### Search- and Access Logic - -A new logic has to be introduced to search the user identity per different input values. That means searching the user data must be possible by - -* searching per email (only with maincontact as contactchannel) -* searching per userID -* searching per alias - -#### Identity-Mapping - -A new mapping logic will be necessary to allow using unmigrated APIs like GDT-servers api. So it must be possible to give this identity-mapping logic the following input to get the respective output: - -* email -> userID -* email -> gradidoID -* email -> alias -* userID -> gradidoID -* userID -> email -* userID -> alias -* alias -> gradidoID -* alias -> email -* alias -> userID -* gradidoID -> email -* gradidoID -> userID -* gradidoID -> alias - -#### GDT-Access - -To use the GDT-servers api the used identifier for GDT has to be switch from email to userID. +* removing all the cryptographic logic and +* invoke the new ***Encryptor.isPassword*** for the given *newPassword* and if valid then +* invoke the new ***Encryptor.verifyPassword*** for the given *oldPassword* and if valid then +* invoke the new ***Encryptor.encryptPassword*** for the given *newPassword* diff --git a/e2e-tests/cypress/tests/cypress.config.ts b/e2e-tests/cypress/tests/cypress.config.ts index ad6a8d7de..9621b7a00 100644 --- a/e2e-tests/cypress/tests/cypress.config.ts +++ b/e2e-tests/cypress/tests/cypress.config.ts @@ -36,6 +36,7 @@ export default defineConfig({ supportFile: "cypress/support/index.ts", viewportHeight: 720, viewportWidth: 1280, + video: false, retries: { runMode: 2, openMode: 0, diff --git a/frontend/package.json b/frontend/package.json index 2fc892f9f..4e983d716 100755 --- a/frontend/package.json +++ b/frontend/package.json @@ -1,6 +1,6 @@ { "name": "bootstrap-vue-gradido-wallet", - "version": "1.13.1", + "version": "1.13.3", "private": true, "scripts": { "start": "node run/server.js", diff --git a/frontend/src/assets/scss/custom/gradido-custom/_color.scss b/frontend/src/assets/scss/custom/gradido-custom/_color.scss index 20fcbefd6..f42555adf 100644 --- a/frontend/src/assets/scss/custom/gradido-custom/_color.scss +++ b/frontend/src/assets/scss/custom/gradido-custom/_color.scss @@ -33,7 +33,9 @@ $indigo: #5603ad !default; $purple: #8965e0 !default; $pink: #f3a4b5 !default; $red: #f5365c !default; -$orange: #fb6340 !default; + +// $orange: #fb6340 !default; +$orange: #8c0505 !default; $yellow: #ffd600 !default; $green: #2dce89 !default; $teal: #11cdef !default; diff --git a/frontend/src/components/ContributionMessages/ContributionMessagesList.vue b/frontend/src/components/ContributionMessages/ContributionMessagesList.vue index 5f1c03b22..4b7045a40 100644 --- a/frontend/src/components/ContributionMessages/ContributionMessagesList.vue +++ b/frontend/src/components/ContributionMessages/ContributionMessagesList.vue @@ -5,15 +5,23 @@ - -
- - {{ $t('form.close') }} + + + + +
+ + + {{ $t('form.close') }} +
@@ -55,4 +63,7 @@ export default { .temp-message { margin-top: 50px; } +.clearboth { + clear: both; +} diff --git a/frontend/src/components/ContributionMessages/LinkifyMessage.vue b/frontend/src/components/ContributionMessages/LinkifyMessage.vue index 5d6ec34cb..09418858f 100644 --- a/frontend/src/components/ContributionMessages/LinkifyMessage.vue +++ b/frontend/src/components/ContributionMessages/LinkifyMessage.vue @@ -1,7 +1,7 @@