Resolve "Only allow one absence at any point of time" #115
No reviewers
Labels
No labels
Security
TeX
auto-update
board
done
board
ready
board
todo
check
delete-eslint-rc-js
check
update-builddeps-package-json
check
update-eslint-rc-js
check
update-gitignore
check
update-merge-request-template
check
update-prettier-ignore
check
update-pyproject-toml
check
update-tox-ini
part
backend
part
ci
part
docs
part
frontend
part
i18n
part
non-technical
part
packaging
prio
1
prio
2
prio
3
release-mr-5.x
size
large
size
medium
size
small
source
customer
source
customer::fsmw
source
customer::fss
source
customer::teckids
source
downstream
type
breaking
type
bug
type
feature
type
refactoring
workflow
blocked
workflow
confirmed
workflow
current-todo
workflow
discussing
workflow
new-app
workflow
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
aleksis/AlekSIS-App-Kolego!115
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "32-only-allow-one-absence-at-any-point-of-time"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #32
assigned to @yuha
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
4e97b71b- Cut existing absences on absence creation to avoid overlapsCompare with previous version
added 2 commits
66f22cdd- Fix handling of new absences cutting existing ones in two halvesCompare with previous version
@hansegucker @ZugBahnHof two questions:
apart from that, TODO: There are now use cases for which trying to create an absence does not actually lead to an absence being created (when overlaps exist with pre-existing absences that share the same absence reason; this leads to a merge, reflected in the existing absence being updated which seems semantically correct to me). This causes problems with graphene for now since create mutations depend on the obj being created & saved having an ID to return. Probably the logic for handling overlaps should be moved to some custom mutation instead?
second one can be ignore – alsijil already does that
first one goes into follow-up issue
created #35 to continue this discussion
mentioned in issue #35
resolved all threads
added 1 commit
178874bc- Handle overlapping absences with same reason correctlyCompare with previous version
TODO: Refresh absences list after save
TODO/to discuss: what should happen with absences that get deleted because their time span is now fully covered by a newly created/edited absence but that are used as the reference absence in existing participation statuses?
@hansegucker
probably we should just replace the reference values – but how?
Yeah, we should update those references beforehand.
added 4 commits
Compare with previous version
added 3 commits
94361e86- Add basic tests7cf98d40- Fix handling of new absences outside of existing ones6bf75d9c- Fix call of parent save methodCompare with previous version
added 2 commits
f0729721- Fix handling of overlapping absences with same reason and person8ced4059- Correctly return modified objects in mutationCompare with previous version
TODO: actually remove absences from CRUD list when saving leads to deletion (somehow update apollo cache)
created #36 to continue this discussion
mentioned in issue #36
added 2 commits
4838125c- Add classmethod that gets/creates one absence for given time spanc4ddcca2- ReformatCompare with previous version
resolved all threads
assigned to @hansegucker and unassigned @yuha
marked this merge request as ready
added 2 commits
812c00fe- Refactor overlapping logica7a6b029- Add migration for existing overlapping absencesCompare with previous version
resolved all threads
mentioned in commit
7bac57ffa5