6f3dd408bb
fix(form): knownUserField not working as intended (WIP)
2025-02-28 16:53:20 +01:00
c0c1665ccb
refactor(form): knownUserField not working as intended (WIP)
2025-02-28 16:53:20 +01:00
c2e0f6b2b8
chore(form): add knownUserField accepting known users only
2025-02-28 16:53:20 +01:00
ad1d235bea
chore(daily): towards #2347 check complete, except i18n
...
also missing: displaying memcached check results in each line of day view
2025-02-28 16:50:23 +01:00
07cfc0adcb
fix(hlint): implement some hlint suggestions
2025-02-28 16:42:37 +01:00
1f7e9b6a2f
chore(daily): adjust css, improve suggestions
2025-02-28 16:42:03 +01:00
500c9a749a
chore(daily): add suggestions to note fiels (WIP)
2025-02-28 16:40:57 +01:00
fba0b71d50
chore(tutorial): build model for #90
2025-02-28 16:38:41 +01:00
4934f5f89d
fix(room): deduplicate room column and fix order
2025-02-28 16:38:41 +01:00
133a8d3739
chore(daily): show rooms for tutorial lessons
2025-02-28 16:38:41 +01:00
14140c982b
refactor(memcached): checking memcached key security mechanisms
...
RESULTS:
Keys for memcached use their Binary representation!
This means that the following three are all interchangeable as a key:
newtype Foo1 = Foo1 { someInt1 :: Int } deriving newtype (Binary)
data Foo2 = Foo2 { someInt2 :: Int } deriving (Binary)
type Foo3 = Int
Therefore it is best to use $(memcachedHere) or $(memcachedByHere) if possible or add another type
2025-02-28 16:38:41 +01:00
ce125b6495
chore(daily): show course associated qualifications
2025-02-28 16:38:41 +01:00
0c78996260
fix(avs): fix #225 by skipping firm updates entirely if AVS FirmInfo is unchanged for previously seen values for AVS User to be updated
2025-02-28 16:38:18 +01:00
b78c898ebf
fix(avs): fix #224 repeated superior changes no longer occur
...
furthermore AdminProblems are only inserted if the same problem does not exist unsolved
2025-02-28 16:35:13 +01:00
4bca7580d0
refactor(occurrences): fold RoomReference into Occurrences, completed
2025-02-28 16:32:52 +01:00
46f777740f
fix(memcached): using memcachedHere did not compile due to staging problems
2025-02-28 16:32:52 +01:00
a7b08b1ae5
fix(occurrences): room occurrence form works now
2025-02-28 16:32:52 +01:00
3e6717904a
chore(occurrences): workaround provide simple room field with least recent suggestions
2025-02-28 16:32:52 +01:00
2059d678ee
refactor(memcached): remove ARC cache and LRU logic some more
...
more leftover dead code was removed, especially cache prewarm options that no longer had an effect on a non-existing ARC cache
2025-02-28 16:32:52 +01:00
22d6cf737e
refactor(occurrences): remove RoomReference from model and add migration
2025-02-28 16:32:52 +01:00
35cadda2e8
refactor(occurrences): fold RoomReference into Occurrences (WIP)
...
Each Occurrence now has its own RoomReference, i.e. Mondays may have a different Room assigned than Tuesdays
WIP Problem: occurrencesAFrom does not work, always insists on Room missing
2025-02-28 16:32:52 +01:00
36b481a548
fix(occurrences): occurringLessons had an erroneously inverted condition
2025-02-28 16:32:52 +01:00
cb58c20ca1
chore(occurrences): add datatype LessonTime for dealing timetable intervals
2025-02-28 16:32:52 +01:00
e757209b80
refactor(memcached): remove ARC cache entirely
...
NOTE: this was a crude surgery, removing everything ARC related; some dead code artifacts may have remained.
Especially check PrewarmCacheConf
Reason for removall: adding `memcachedInvalidateClass` was difficult to implement with ARC active; ARC was known to be problematic; removal was easier (see #2 2024-09-23)
2025-02-28 16:32:25 +01:00
74c330bd24
chore(memcached): add key classes for easy invalidation
2025-02-28 16:29:45 +01:00
1d01897757
chore(daily): make company a property of TutorialParticipant, towards #90
2025-02-28 16:25:43 +01:00
ce62b99d2b
chore(daily): add more columns #90
2025-02-28 16:25:43 +01:00
11ef856b2b
refactor(jsonb): change DB using JSONB, to improve stub #90
2025-02-28 16:25:43 +01:00
e9a4c838a8
refactor(map): clarify some unnecessarily obfuscated code
...
also, using Map.fromList is more efficient if the list happens to be ordered
2025-02-28 16:25:43 +01:00
ce35c8efc9
Merge branch '145-build-system-rewrite'
2025-02-28 15:37:36 +01:00
e90d11682b
fix(lms): eliminate unlikely possible discrepancy for LMS deletion indicator
...
It was theoretically possible for LMS Learner deletion tag to be not correctly shown in LMS table.
Also see #2605 for further related issues.
2025-01-10 16:49:53 +01:00
1ab8a93b53
refactor: backport saltine (0.2.0.0->0.1.1.1) for compatibility with proper lts-18.0 stack snapshot image
2024-12-15 01:02:45 +01:00
3b0029ba04
fix(avs): fix #225 by skipping firm updates entirely if AVS FirmInfo is unchanged for previously seen values for AVS User to be updated
2024-10-09 12:50:32 +02:00
e554048f5a
fix(avs): avs firm update no longer may update wrong company
...
Note: noticed while working on #225
2024-10-09 12:50:32 +02:00
e59fff352f
fix(avs): fix #224 repeated superior changes no longer occur
...
furthermore AdminProblems are only inserted if the same problem does not exist unsolved
2024-10-09 12:50:32 +02:00
6a070a6775
fix(supervision): fix #181 by unifying deletion of supervision
2024-09-10 17:47:09 +02:00
ade27e6479
fix(avs): fix #178 by deleting old superiors for individual users
2024-09-05 17:53:18 +02:00
1e896da4a3
chore(avs): prepare superior update shortcircuit for future
2024-09-02 09:08:44 +02:00
7e5c256b4c
fix(avs): company superiors are now irregular supervisors and old ones are deleted
...
DETAILS:
Superiors:
- Superiors do not become Company-Default-Supervisors automatically
- Superiors become irregular supervisors without rerouting, existing supervisions are not changed
- Superiors become company users at equal-to-max priority, if not already
For each AVN User update:
- if superior change for unchanged company:
all company supervisions with remark "Vorgesetzter" are removed
create admin problem that notifies about superior change (special if new superior could not be created)
- all company associates are irregularly supervised by the new superior with remark "Vorgesetzer"
Questions:
- company had superior, but no longer: just remove superior-supervisions, do not report admin problem?
- Problem: superior changed, but we first encounter this through a user changing company. Change is not detected at this point, old superiors remain until an old company associate is updated too
2024-08-30 17:41:33 +02:00
cfe2318f81
fix(avs): attempt LDAP upsert before creating avs users
2024-08-29 16:15:16 +02:00
8ec2875590
fix(avs): switch company did not always increase priority
2024-08-27 16:23:42 +02:00
9c82558d71
fix(user): fix pagination and count for supervision tables
2024-08-26 17:40:57 +02:00
53abdb7cc3
chore(health): augement #154 by adding option to disable interface warnings
...
Also:
- add usage explanation
- show intervals in a human readable form
2024-08-22 17:28:28 +02:00
407ba543a1
chore(health): fix #154 by adding interface warning threshold edit handler
2024-08-21 17:34:19 +02:00
2ed626ea4a
chore(avs): towards #124 add filter for multiple firm users with block reason '%firm%'
...
- also add warning to admin avs licence difference for AVS R licence holders about to be changed
2024-08-09 18:33:23 +02:00
f4823aaf28
refactor(avs): switch some runDB to runDBRead
2024-08-09 17:59:14 +02:00
760b102d52
chore(avs): flag AVS R-holders about to be revoked
...
- flag on admin problem view
- exempt from automatic avs licence synch for levels below 3
2024-08-09 17:01:10 +02:00
d209a110e8
refactor(linter): implement minor hlit suggestion
2024-08-08 17:30:03 +02:00
6299612adc
refactor: various minor changes, mostly some comments
2024-08-07 17:51:33 +02:00
8f54ea1051
refactor(qualifications): unify qualification selectField mechanics
2024-08-07 17:50:38 +02:00
