mirror of
https://github.com/IT4Change/gradido.git
synced 2025-12-13 07:45:54 +00:00
Merge branch 'master' into setup-hyperswarm
This commit is contained in:
Moriz Wahl
GitHub
commit
6d1224d7c5
72
.github/workflows/lint_pr.yml
vendored
Normal file
72
.github/workflows/lint_pr.yml
vendored
Normal file
@ -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
|
||||
181
.github/workflows/test.yml
vendored
181
.github/workflows/test.yml
vendored
@ -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/
|
||||
|
||||
29
CHANGELOG.md
29
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)
|
||||
|
||||
|
||||
@ -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": {
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<template>
|
||||
<div class="content-footer">
|
||||
<hr />
|
||||
<b-row align-v="center" class="mt-4 justify-content-lg-between">
|
||||
<div align-v="center" class="mt-4 mb-4 justify-content-lg-between">
|
||||
<b-col>
|
||||
<div class="copyright text-center text-lg-center text-muted">
|
||||
{{ $t('footer.copyright.year', { year }) }}
|
||||
@ -25,7 +25,7 @@
|
||||
</a>
|
||||
</div>
|
||||
</b-col>
|
||||
</b-row>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
<script>
|
||||
|
||||
@ -35,8 +35,8 @@
|
||||
</div>
|
||||
</template>
|
||||
<script>
|
||||
import ContributionLinkForm from './ContributionLinkForm.vue'
|
||||
import ContributionLinkList from './ContributionLinkList.vue'
|
||||
import ContributionLinkForm from '../ContributionLink/ContributionLinkForm.vue'
|
||||
import ContributionLinkList from '../ContributionLink/ContributionLinkList.vue'
|
||||
|
||||
export default {
|
||||
name: 'ContributionLink',
|
||||
@ -1,6 +1,6 @@
|
||||
import { mount } from '@vue/test-utils'
|
||||
import ContributionLinkForm from './ContributionLinkForm.vue'
|
||||
import { toastErrorSpy, toastSuccessSpy } from '../../test/testSetup'
|
||||
import { toastErrorSpy, toastSuccessSpy } from '../../../test/testSetup'
|
||||
import { createContributionLink } from '@/graphql/createContributionLink.js'
|
||||
|
||||
const localVue = global.localVue
|
||||
@ -1,6 +1,6 @@
|
||||
import { mount } from '@vue/test-utils'
|
||||
import ContributionLinkList from './ContributionLinkList.vue'
|
||||
import { toastSuccessSpy, toastErrorSpy } from '../../test/testSetup'
|
||||
import { toastSuccessSpy, toastErrorSpy } from '../../../test/testSetup'
|
||||
// import { deleteContributionLink } from '../graphql/deleteContributionLink'
|
||||
|
||||
const localVue = global.localVue
|
||||
@ -1,6 +1,6 @@
|
||||
<template>
|
||||
<div class="contribution-link-list">
|
||||
<b-table striped hover :items="items" :fields="fields">
|
||||
<b-table :items="items" :fields="fields" striped hover stacked="lg">
|
||||
<template #cell(delete)="data">
|
||||
<b-button
|
||||
variant="danger"
|
||||
@ -46,7 +46,7 @@
|
||||
</template>
|
||||
<script>
|
||||
import { deleteContributionLink } from '@/graphql/deleteContributionLink.js'
|
||||
import FigureQrCode from './FigureQrCode.vue'
|
||||
import FigureQrCode from '../FigureQrCode.vue'
|
||||
|
||||
export default {
|
||||
name: 'ContributionLinkList',
|
||||
@ -1,7 +1,7 @@
|
||||
<template>
|
||||
<div class="mt-2">
|
||||
<span v-for="({ type, text }, index) in linkifiedMessage" :key="index">
|
||||
<b-link v-if="type === 'link'" :to="text">{{ text }}</b-link>
|
||||
<b-link v-if="type === 'link'" :href="text" target="_blank">{{ text }}</b-link>
|
||||
<span v-else>{{ text }}</span>
|
||||
</span>
|
||||
</div>
|
||||
|
||||
@ -7,6 +7,10 @@ const apolloMutateMock = jest.fn()
|
||||
const storeDispatchMock = jest.fn()
|
||||
const routerPushMock = jest.fn()
|
||||
|
||||
const stubs = {
|
||||
RouterLink: true,
|
||||
}
|
||||
|
||||
const mocks = {
|
||||
$t: jest.fn((t) => t),
|
||||
$apollo: {
|
||||
@ -28,7 +32,7 @@ describe('NavBar', () => {
|
||||
let wrapper
|
||||
|
||||
const Wrapper = () => {
|
||||
return mount(NavBar, { mocks, localVue })
|
||||
return mount(NavBar, { mocks, localVue, stubs })
|
||||
}
|
||||
|
||||
describe('mount', () => {
|
||||
@ -41,13 +45,35 @@ describe('NavBar', () => {
|
||||
})
|
||||
})
|
||||
|
||||
describe('Navbar Menu', () => {
|
||||
it('has a link to overview', () => {
|
||||
expect(wrapper.findAll('.nav-item').at(0).find('a').attributes('href')).toBe('/')
|
||||
})
|
||||
it('has a link to /user', () => {
|
||||
expect(wrapper.findAll('.nav-item').at(1).find('a').attributes('href')).toBe('/user')
|
||||
})
|
||||
it('has a link to /creation', () => {
|
||||
expect(wrapper.findAll('.nav-item').at(2).find('a').attributes('href')).toBe('/creation')
|
||||
})
|
||||
it('has a link to /creation-confirm', () => {
|
||||
expect(wrapper.findAll('.nav-item').at(3).find('a').attributes('href')).toBe(
|
||||
'/creation-confirm',
|
||||
)
|
||||
})
|
||||
it('has a link to /contribution-links', () => {
|
||||
expect(wrapper.findAll('.nav-item').at(4).find('a').attributes('href')).toBe(
|
||||
'/contribution-links',
|
||||
)
|
||||
})
|
||||
})
|
||||
|
||||
describe('wallet', () => {
|
||||
const assignLocationSpy = jest.fn()
|
||||
beforeEach(async () => {
|
||||
await wrapper.findAll('a').at(5).trigger('click')
|
||||
await wrapper.findAll('.nav-item').at(5).find('a').trigger('click')
|
||||
})
|
||||
|
||||
it.skip('changes widnow location to wallet', () => {
|
||||
it.skip('changes window location to wallet', () => {
|
||||
expect(assignLocationSpy).toBeCalledWith('valid-token')
|
||||
})
|
||||
|
||||
@ -63,7 +89,7 @@ describe('NavBar', () => {
|
||||
window.location = {
|
||||
assign: windowLocationMock,
|
||||
}
|
||||
await wrapper.findAll('a').at(6).trigger('click')
|
||||
await wrapper.findAll('.nav-item').at(6).find('a').trigger('click')
|
||||
})
|
||||
|
||||
it('redirects to /logout', () => {
|
||||
|
||||
@ -19,6 +19,9 @@
|
||||
>
|
||||
{{ $store.state.openCreations }} {{ $t('navbar.open_creation') }}
|
||||
</b-nav-item>
|
||||
<b-nav-item to="/contribution-links">
|
||||
{{ $t('navbar.automaticContributions') }}
|
||||
</b-nav-item>
|
||||
<b-nav-item @click="wallet">{{ $t('navbar.my-account') }}</b-nav-item>
|
||||
<b-nav-item @click="logout">{{ $t('navbar.logout') }}</b-nav-item>
|
||||
</b-navbar-nav>
|
||||
|
||||
@ -95,6 +95,7 @@
|
||||
"multiple_creation_text": "Bitte wähle ein oder mehrere Mitglieder aus für die du Schöpfen möchtest.",
|
||||
"name": "Name",
|
||||
"navbar": {
|
||||
"automaticContributions": "automatische Beiträge",
|
||||
"logout": "Abmelden",
|
||||
"multi_creation": "Mehrfachschöpfung",
|
||||
"my-account": "Mein Konto",
|
||||
|
||||
@ -95,6 +95,7 @@
|
||||
"multiple_creation_text": "Please select one or more members for which you would like to perform creations.",
|
||||
"name": "Name",
|
||||
"navbar": {
|
||||
"automaticContributions": "Automatic Contributions",
|
||||
"logout": "Logout",
|
||||
"multi_creation": "Multiple creation",
|
||||
"my-account": "My Account",
|
||||
|
||||
58
admin/src/pages/ContributionLinks.spec.js
Normal file
58
admin/src/pages/ContributionLinks.spec.js
Normal file
@ -0,0 +1,58 @@
|
||||
import { mount } from '@vue/test-utils'
|
||||
import ContributionLinks from './ContributionLinks.vue'
|
||||
import { listContributionLinks } from '@/graphql/listContributionLinks.js'
|
||||
|
||||
const localVue = global.localVue
|
||||
|
||||
const apolloQueryMock = jest.fn().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,
|
||||
},
|
||||
},
|
||||
})
|
||||
|
||||
const mocks = {
|
||||
$t: jest.fn((t) => t),
|
||||
$d: jest.fn((d) => d),
|
||||
$apollo: {
|
||||
query: apolloQueryMock,
|
||||
},
|
||||
}
|
||||
|
||||
describe('ContributionLinks', () => {
|
||||
// eslint-disable-next-line no-unused-vars
|
||||
let wrapper
|
||||
|
||||
const Wrapper = () => {
|
||||
return mount(ContributionLinks, { localVue, mocks })
|
||||
}
|
||||
|
||||
describe('mount', () => {
|
||||
beforeEach(() => {
|
||||
wrapper = Wrapper()
|
||||
})
|
||||
|
||||
it('calls listContributionLinks', () => {
|
||||
expect(apolloQueryMock).toBeCalledWith(
|
||||
expect.objectContaining({
|
||||
query: listContributionLinks,
|
||||
}),
|
||||
)
|
||||
})
|
||||
})
|
||||
})
|
||||
45
admin/src/pages/ContributionLinks.vue
Normal file
45
admin/src/pages/ContributionLinks.vue
Normal file
@ -0,0 +1,45 @@
|
||||
<template>
|
||||
<div class="contribution-link">
|
||||
<contribution-link
|
||||
:items="items"
|
||||
:count="count"
|
||||
@get-contribution-links="getContributionLinks"
|
||||
/>
|
||||
</div>
|
||||
</template>
|
||||
<script>
|
||||
import { listContributionLinks } from '@/graphql/listContributionLinks.js'
|
||||
import ContributionLink from '../components/ContributionLink/ContributionLink.vue'
|
||||
|
||||
export default {
|
||||
name: 'ContributionLinks',
|
||||
components: {
|
||||
ContributionLink,
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
items: [],
|
||||
count: 0,
|
||||
}
|
||||
},
|
||||
methods: {
|
||||
getContributionLinks() {
|
||||
this.$apollo
|
||||
.query({
|
||||
query: listContributionLinks,
|
||||
fetchPolicy: 'network-only',
|
||||
})
|
||||
.then((result) => {
|
||||
this.count = result.data.listContributionLinks.count
|
||||
this.items = result.data.listContributionLinks.links
|
||||
})
|
||||
.catch(() => {
|
||||
this.toastError('listContributionLinks has no result, use default data')
|
||||
})
|
||||
},
|
||||
},
|
||||
created() {
|
||||
this.getContributionLinks()
|
||||
},
|
||||
}
|
||||
</script>
|
||||
@ -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)
|
||||
})
|
||||
|
||||
@ -28,31 +28,21 @@
|
||||
</b-link>
|
||||
</b-card-text>
|
||||
</b-card>
|
||||
<contribution-link
|
||||
:items="items"
|
||||
:count="count"
|
||||
@get-contribution-links="getContributionLinks"
|
||||
/>
|
||||
<community-statistic class="mt-5" v-model="statistics" />
|
||||
</div>
|
||||
</template>
|
||||
<script>
|
||||
import { listContributionLinks } from '@/graphql/listContributionLinks.js'
|
||||
import { communityStatistics } from '@/graphql/communityStatistics.js'
|
||||
import ContributionLink from '../components/ContributionLink.vue'
|
||||
import CommunityStatistic from '../components/CommunityStatistic.vue'
|
||||
import { listUnconfirmedContributions } from '@/graphql/listUnconfirmedContributions.js'
|
||||
|
||||
export default {
|
||||
name: 'overview',
|
||||
components: {
|
||||
ContributionLink,
|
||||
CommunityStatistic,
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
items: [],
|
||||
count: 0,
|
||||
statistics: {
|
||||
totalUsers: null,
|
||||
activeUsers: null,
|
||||
@ -75,20 +65,6 @@ export default {
|
||||
this.$store.commit('setOpenCreations', result.data.listUnconfirmedContributions.length)
|
||||
})
|
||||
},
|
||||
getContributionLinks() {
|
||||
this.$apollo
|
||||
.query({
|
||||
query: listContributionLinks,
|
||||
fetchPolicy: 'network-only',
|
||||
})
|
||||
.then((result) => {
|
||||
this.count = result.data.listContributionLinks.count
|
||||
this.items = result.data.listContributionLinks.links
|
||||
})
|
||||
.catch(() => {
|
||||
this.toastError('listContributionLinks has no result, use default data')
|
||||
})
|
||||
},
|
||||
getCommunityStatistics() {
|
||||
this.$apollo
|
||||
.query({
|
||||
@ -113,7 +89,6 @@ export default {
|
||||
created() {
|
||||
this.getPendingCreations()
|
||||
this.getCommunityStatistics()
|
||||
this.getContributionLinks()
|
||||
},
|
||||
}
|
||||
</script>
|
||||
|
||||
@ -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()
|
||||
|
||||
@ -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'),
|
||||
|
||||
@ -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",
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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()
|
||||
|
||||
@ -63,6 +63,8 @@ export class StatisticsResolver {
|
||||
.where('transaction.decay IS NOT NULL')
|
||||
.getRawOne()
|
||||
|
||||
await queryRunner.release()
|
||||
|
||||
return {
|
||||
totalUsers,
|
||||
activeUsers,
|
||||
|
||||
@ -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,6 +87,58 @@ describe('TransactionLinkResolver', () => {
|
||||
)
|
||||
})
|
||||
|
||||
describe('user has pending contribution of 1000 GDD', () => {
|
||||
beforeAll(async () => {
|
||||
await mutate({
|
||||
mutation: login,
|
||||
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(),
|
||||
},
|
||||
})
|
||||
})
|
||||
|
||||
it('allows the user to redeem the contribution link', async () => {
|
||||
await expect(
|
||||
mutate({
|
||||
@ -120,7 +180,7 @@ describe('TransactionLinkResolver', () => {
|
||||
jest.runAllTimers()
|
||||
await mutate({
|
||||
mutation: login,
|
||||
variables: { email: 'peter@lustig.de', password: 'Aa12345_' },
|
||||
variables: { email: 'bibi@bloxberg.de', password: 'Aa12345_' },
|
||||
})
|
||||
})
|
||||
|
||||
@ -162,6 +222,7 @@ describe('TransactionLinkResolver', () => {
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('transactionLinkCode', () => {
|
||||
|
||||
@ -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()
|
||||
|
||||
@ -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)
|
||||
}),
|
||||
|
||||
@ -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[]
|
||||
}
|
||||
@ -1 +1 @@
|
||||
export { Contribution } from './0051-add_delete_by_to_contributions/Contribution'
|
||||
export { Contribution } from './0052-add_updated_at_to_contributions/Contribution'
|
||||
|
||||
12
database/migrations/0052-add_updated_at_to_contributions.ts
Normal file
12
database/migrations/0052-add_updated_at_to_contributions.ts
Normal file
@ -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<Array<any>>) {
|
||||
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<Array<any>>) {
|
||||
await queryFn(`ALTER TABLE \`contributions\` DROP COLUMN \`updated_at\`;`)
|
||||
}
|
||||
@ -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",
|
||||
|
||||
@ -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
|
||||
@ -52,6 +75,12 @@ services:
|
||||
volumes:
|
||||
- /sessions
|
||||
|
||||
#########################################################
|
||||
## NGINX ################################################
|
||||
#########################################################
|
||||
nginx:
|
||||
image: gradido/nginx:test
|
||||
|
||||
networks:
|
||||
external-net:
|
||||
internal-net:
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Sobald der gewünschte User-Account in der Liste gefunden wurde, kann der Detail-Dialog zu diesem User per Klick geöffnet werden.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
Ob die Contribution über einen versendeten Link bzw. QR-Code geschöpft werden kann, wird mittels der Auswahl "Versenden möglich als" bestimmt.
|
||||
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
### Ausbaustufe-1:
|
||||
## Ausbaustufe-1:
|
||||
|
||||
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<br />- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden<br />- 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<br />- 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<br />- als Auswahlliste (Combobox) geplant, aber für diese Ausbaustufe nur mit dem Wert "täglich" vorbelegt |
|
||||
| Wiederholungen | - Anzahl an Wiederholungen pro Zyklus<br />- 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<br />- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden<br />- 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"):
|
||||
|
||||
|
||||
|
||||
* 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,13 +170,15 @@ Das nachfolgende Bild zeigt das Datenmodell vor der Einführung und Migration au
|
||||
|
||||
|
||||
|
||||
### 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 |
|
||||
| ------------------------------- | ------------ | :------: | :------------: | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
@ -127,7 +199,7 @@ Die Datenbank wird in ihrer vollständigen Ausprägung trotz Ausbaustufe-1 wie f
|
||||
| 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
|
||||
|
||||
|
||||
|
||||
### Ausbaustufe-2
|
||||
|
||||
Für die Ausbaustufe-2 sind keine Datenbank-Änderungen notwendig. Gemäß dem Zielmodell sind alle notwendigen Tabellen und Attribute schon vorhanden.
|
||||
|
||||
#### Zielmodell
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<mxfile host="65bd71144e">
|
||||
<diagram id="-Bvenr9G4hMm7q4_ZwMA" name="Seite-1">
|
||||
<mxGraphModel dx="3755" dy="1067" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="2336" pageHeight="1654" math="0" shadow="0">
|
||||
<mxGraphModel dx="3699" dy="1067" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="2336" pageHeight="1654" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0"/>
|
||||
<mxCell id="1" parent="0"/>
|
||||
@ -183,31 +183,31 @@
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="63" value="contribution_links<br style="font-size: 24px"><span style="font-size: 20px">id = X<br>code = X-link<br></span>" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fontSize=24;size=0.05263157894736842;" parent="1" vertex="1">
|
||||
<mxGeometry x="1560" y="670" width="380" height="100" as="geometry"/>
|
||||
<mxGeometry x="1560" y="592.5" width="380" height="85" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="121" value="" style="edgeStyle=none;html=1;fontSize=16;" parent="1" source="65" target="71" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="65" value="users<br style="font-size: 24px"><font style="font-size: 20px">ID=Y</font>" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fontSize=24;size=0.05263157894736842;" parent="1" vertex="1">
|
||||
<mxGeometry x="1990" y="930" width="170" height="60" as="geometry"/>
|
||||
<mxGeometry x="1990" y="925" width="170" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="128" value="" style="edgeStyle=none;html=1;fontSize=20;strokeWidth=1;" parent="1" source="67" target="127" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="67" value="lese Contribution zu aktiviertem Link" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="690" width="240" height="60" as="geometry"/>
|
||||
<mxGeometry x="1250" y="605" width="240" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="120" value="" style="edgeStyle=none;html=1;fontSize=16;" parent="1" source="69" target="71" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="122" value="" style="edgeStyle=none;html=1;fontSize=16;" parent="1" source="69" target="79" edge="1">
|
||||
<mxCell id="122" value="" style="edgeStyle=none;html=1;fontSize=16;entryX=0.25;entryY=0;entryDx=0;entryDy=0;exitX=0.417;exitY=0.991;exitDx=0;exitDy=0;exitPerimeter=0;" parent="1" source="69" target="79" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="69" value="erzeuge aus ContributionLink zu angemeldetem User eine bestätigte Contribution" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="907.5" width="240" height="110" as="geometry"/>
|
||||
<mxGeometry x="1210" y="900" width="240" height="110" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="71" value="contributions<br style="font-size: 24px"><font style="font-size: 20px">confirmed_at = NOW, contribution_links_id=X, user_id=Y</font>" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fontSize=24;size=0.05263157894736842;" parent="1" vertex="1">
|
||||
<mxGeometry x="1560" y="917.5" width="380" height="90" as="geometry"/>
|
||||
<mxGeometry x="1560" y="910" width="380" height="90" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="72" value="" style="edgeStyle=none;html=1;fontSize=24;" parent="1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
@ -317,15 +317,15 @@
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="109" value="veröffentlichter <br>Link / QR-Code für<br>eine Contribution" style="ellipse;whiteSpace=wrap;html=1;fontSize=20;rounded=1;fillColor=#d0cee2;strokeColor=#56517e;" parent="1" vertex="1">
|
||||
<mxGeometry x="2010" y="410" width="310" height="90" as="geometry"/>
|
||||
<mxGeometry x="2020" y="310" width="310" height="90" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="118" value="" style="edgeStyle=none;html=1;fontSize=16;" parent="1" target="113" edge="1">
|
||||
<mxCell id="118" value="" style="edgeStyle=none;html=1;fontSize=16;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" target="113" edge="1" source="111">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="1370" y="570" as="sourcePoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="111" value="User aktiviert <br>Link / QR-Code" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="510" width="240" height="50" as="geometry"/>
|
||||
<mxGeometry x="1250" y="450" width="240" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="115" style="edgeStyle=none;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontSize=16;" parent="1" source="113" target="114" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
@ -334,10 +334,10 @@
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="113" value="User führt <br>Login / Register aus" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="597.5" width="240" height="50" as="geometry"/>
|
||||
<mxGeometry x="1250" y="530" width="240" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="114" value="users" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fontSize=24;size=0.05263157894736842;" parent="1" vertex="1">
|
||||
<mxGeometry x="1990" y="592.5" width="170" height="60" as="geometry"/>
|
||||
<mxGeometry x="1990" y="525" width="170" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="123" style="edgeStyle=none;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontSize=16;" parent="1" source="124" target="125" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
@ -351,7 +351,7 @@
|
||||
<mxCell id="125" value="users" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fontSize=24;size=0.05263157894736842;" parent="1" vertex="1">
|
||||
<mxGeometry x="880" y="592.5" width="170" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="129" value="" style="edgeStyle=none;html=1;fontSize=20;strokeWidth=1;" parent="1" source="127" target="69" edge="1">
|
||||
<mxCell id="129" value="" style="edgeStyle=none;html=1;fontSize=20;strokeWidth=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="127" target="131" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="130" value="Ja" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=20;" parent="129" vertex="1" connectable="0">
|
||||
@ -359,8 +359,76 @@
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="127" value="Contribution <br>und Regel <br>valide?" style="rhombus;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="770" width="240" height="100" as="geometry"/>
|
||||
<mxCell id="127" value="Contribution <br>und Regel valide?<br>" style="rhombus;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1250" y="685" width="240" height="75" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="132" style="edgeStyle=none;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="131" target="69">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1660" y="780"/>
|
||||
<mxPoint x="1330" y="780"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="134" style="edgeStyle=none;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="131" target="133">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="135" value="Nein" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=16;" vertex="1" connectable="0" parent="134">
|
||||
<mxGeometry x="-0.4968" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="131" value="user Konto<br>active?" style="rhombus;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="1540" y="685" width="240" height="75" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="137" value="" style="edgeStyle=none;html=1;fontSize=16;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="133" target="138">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="2210" y="722.5" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="133" value="erzeuge aus ContributionLink zu angemeldetem User eine pending Contribution" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;" vertex="1" parent="1">
|
||||
<mxGeometry x="1830" y="685" width="300" height="75" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="138" value="Ende Redeem-Aktivierung" style="ellipse;whiteSpace=wrap;html=1;fontSize=20;rounded=1;fillColor=#dae8fc;strokeColor=#6c8ebf;gradientColor=#7ea6e0;" vertex="1" parent="1">
|
||||
<mxGeometry x="2170" y="677.5" width="110" height="90" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="141" style="edgeStyle=none;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontSize=16;" edge="1" parent="1" source="139" target="140">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="139" value="Start Konto-<br>bestätigung" style="ellipse;whiteSpace=wrap;html=1;fontSize=20;rounded=1;fillColor=#f5f5f5;strokeColor=#666666;gradientColor=#b3b3b3;" vertex="1" parent="1">
|
||||
<mxGeometry x="2170" y="805" width="110" height="90" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="143" style="edgeStyle=none;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontSize=16;" edge="1" parent="1" source="140" target="142">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="140" value="User führt <br>Email-Bestätigung aus" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
|
||||
<mxGeometry x="1930" y="825" width="210" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="145" value="" style="edgeStyle=none;html=1;fontSize=16;" edge="1" parent="1" source="142" target="144">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="142" value="Konto wird active" style="rounded=1;whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;" vertex="1" parent="1">
|
||||
<mxGeometry x="1720" y="827.5" width="180" height="47.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="147" value="" style="edgeStyle=none;html=1;fontSize=16;" edge="1" parent="1" source="144" target="146">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="144" value="für alle pending Contributions" style="whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="1540" y="825" width="150" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="149" style="edgeStyle=none;html=1;entryX=0;entryY=0.25;entryDx=0;entryDy=0;fontSize=16;" edge="1" parent="1" source="146" target="71">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="150" style="edgeStyle=none;html=1;entryX=0.896;entryY=0.01;entryDx=0;entryDy=0;entryPerimeter=0;fontSize=16;exitX=0.642;exitY=0.988;exitDx=0;exitDy=0;exitPerimeter=0;" edge="1" parent="1" source="146" target="79">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="146" value="erzeuge bestätigte Contribution" style="whiteSpace=wrap;html=1;fontSize=20;fillColor=#008a00;strokeColor=#005700;fontColor=#ffffff;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="1390" y="810" width="120" height="80" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="151" value="" style="rounded=0;whiteSpace=wrap;html=1;fontSize=16;opacity=30;fillColor=#ffcd28;gradientColor=#ffa500;strokeColor=#d79b00;" vertex="1" parent="1">
|
||||
<mxGeometry x="1180" y="680" width="1140" height="220" as="geometry"/>
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 536 KiB |
BIN
docu/Concepts/BusinessRequirements/image/Admin-CreateUser.png
Normal file
BIN
docu/Concepts/BusinessRequirements/image/Admin-CreateUser.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
BIN
docu/Concepts/BusinessRequirements/image/Admin-UserSearch.png
Normal file
BIN
docu/Concepts/BusinessRequirements/image/Admin-UserSearch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 110 KiB After Width: | Height: | Size: 110 KiB |
@ -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<br />the encryptor specific attributs <br />out of the dbUser and the original <br />password entered by the user |
|
||||
| **verifyPassword** | dbUser, password | dbUser, password | boolean | process the decryption with<br />the encryptor specific attributs <br />out of the dbUser and the original <br />password entrered by the user |
|
||||
| **isPassword** | password | password | boolean | verifiy the formal rules of the original<br />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*
|
||||
|
||||
@ -36,6 +36,7 @@ export default defineConfig({
|
||||
supportFile: "cypress/support/index.ts",
|
||||
viewportHeight: 720,
|
||||
viewportWidth: 1280,
|
||||
video: false,
|
||||
retries: {
|
||||
runMode: 2,
|
||||
openMode: 0,
|
||||
|
||||
@ -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",
|
||||
|
||||
@ -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;
|
||||
|
||||
@ -5,15 +5,23 @@
|
||||
<contribution-messages-list-item :message="message" />
|
||||
</div>
|
||||
</b-container>
|
||||
<b-container>
|
||||
<contribution-messages-formular
|
||||
v-if="['PENDING', 'IN_PROGRESS'].includes(state)"
|
||||
:contributionId="contributionId"
|
||||
@get-list-contribution-messages="getListContributionMessages"
|
||||
@update-state="updateState"
|
||||
/>
|
||||
<div v-b-toggle="'collapse' + String(contributionId)" class="text-center pointer h2">
|
||||
</b-container>
|
||||
|
||||
<div
|
||||
v-b-toggle="'collapse' + String(contributionId)"
|
||||
class="text-center pointer h2 clearboth pt-1"
|
||||
>
|
||||
<b-button variant="outline-primary" block class="mt-4">
|
||||
<b-icon icon="arrow-up-short"></b-icon>
|
||||
{{ $t('form.close') }}
|
||||
</b-button>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
@ -55,4 +63,7 @@ export default {
|
||||
.temp-message {
|
||||
margin-top: 50px;
|
||||
}
|
||||
.clearboth {
|
||||
clear: both;
|
||||
}
|
||||
</style>
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<template>
|
||||
<div class="mt-2">
|
||||
<span v-for="({ type, text }, index) in linkifiedMessage" :key="index">
|
||||
<b-link v-if="type === 'link'" :to="text">{{ text }}</b-link>
|
||||
<b-link v-if="type === 'link'" :href="text" target="_blank">{{ text }}</b-link>
|
||||
<span v-else>{{ text }}</span>
|
||||
</span>
|
||||
</div>
|
||||
|
||||
@ -198,6 +198,75 @@ describe('ContributionForm', () => {
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('date with the 31st day of the month', () => {
|
||||
describe('same month', () => {
|
||||
beforeEach(async () => {
|
||||
await wrapper.setData({
|
||||
maximalDate: new Date('2022-10-31T00:00:00.000Z'),
|
||||
form: { date: new Date('2022-10-31T00:00:00.000Z') },
|
||||
})
|
||||
})
|
||||
|
||||
describe('minimalDate', () => {
|
||||
it('has "2022-09-01T00:00:00.000Z"', () => {
|
||||
expect(wrapper.vm.minimalDate.toISOString()).toBe('2022-09-01T00:00:00.000Z')
|
||||
})
|
||||
})
|
||||
|
||||
describe('isThisMonth', () => {
|
||||
it('has true', () => {
|
||||
expect(wrapper.vm.isThisMonth).toBe(true)
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('date with the 28th day of the month', () => {
|
||||
describe('same month', () => {
|
||||
beforeEach(async () => {
|
||||
await wrapper.setData({
|
||||
maximalDate: new Date('2023-02-28T00:00:00.000Z'),
|
||||
form: { date: new Date('2023-02-28T00:00:00.000Z') },
|
||||
})
|
||||
})
|
||||
|
||||
describe('minimalDate', () => {
|
||||
it('has "2023-01-01T00:00:00.000Z"', () => {
|
||||
expect(wrapper.vm.minimalDate.toISOString()).toBe('2023-01-01T00:00:00.000Z')
|
||||
})
|
||||
})
|
||||
|
||||
describe('isThisMonth', () => {
|
||||
it('has true', () => {
|
||||
expect(wrapper.vm.isThisMonth).toBe(true)
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('date with 29.02.2024 leap year', () => {
|
||||
describe('same month', () => {
|
||||
beforeEach(async () => {
|
||||
await wrapper.setData({
|
||||
maximalDate: new Date('2024-02-29T00:00:00.000Z'),
|
||||
form: { date: new Date('2024-02-29T00:00:00.000Z') },
|
||||
})
|
||||
})
|
||||
|
||||
describe('minimalDate', () => {
|
||||
it('has "2024-01-01T00:00:00.000Z"', () => {
|
||||
expect(wrapper.vm.minimalDate.toISOString()).toBe('2024-01-01T00:00:00.000Z')
|
||||
})
|
||||
})
|
||||
|
||||
describe('isThisMonth', () => {
|
||||
it('has true', () => {
|
||||
expect(wrapper.vm.isThisMonth).toBe(true)
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('set contrubtion', () => {
|
||||
|
||||
@ -131,10 +131,8 @@ export default {
|
||||
},
|
||||
computed: {
|
||||
minimalDate() {
|
||||
// sets the date to the 1st of the previous month
|
||||
let date = new Date(this.maximalDate) // has to be a new object, because of 'setMonth' changes the objects date
|
||||
date = new Date(date.setMonth(date.getMonth() - 1))
|
||||
return new Date(date.getFullYear(), date.getMonth(), 1)
|
||||
const date = new Date(this.maximalDate)
|
||||
return new Date(date.setMonth(date.getMonth() - 1, 1))
|
||||
},
|
||||
disabled() {
|
||||
return (
|
||||
|
||||
@ -31,6 +31,7 @@
|
||||
"submitContribution": "Beitrag einreichen",
|
||||
"switch-to-this-community": "zu dieser Gemeinschaft wechseln"
|
||||
},
|
||||
"contact": "Kontakt",
|
||||
"contribution": {
|
||||
"activity": "Tätigkeit",
|
||||
"alert": {
|
||||
|
||||
@ -31,6 +31,7 @@
|
||||
"submitContribution": "Submit contribution",
|
||||
"switch-to-this-community": "Switch to this community"
|
||||
},
|
||||
"contact": "Contact",
|
||||
"contribution": {
|
||||
"activity": "Activity",
|
||||
"alert": {
|
||||
|
||||
@ -44,6 +44,9 @@
|
||||
{{ item.firstName }} {{ item.lastName }}
|
||||
</li>
|
||||
</ul>
|
||||
</b-container>
|
||||
<b-container>
|
||||
<div class="h3">{{ $t('contact') }}</div>
|
||||
<b-link href="mailto: abc@example.com">{{ supportMail }}</b-link>
|
||||
</b-container>
|
||||
<!--
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "gradido",
|
||||
"version": "1.13.1",
|
||||
"version": "1.13.3",
|
||||
"description": "Gradido",
|
||||
"main": "index.js",
|
||||
"repository": "git@github.com:gradido/gradido.git",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user