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
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
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)
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
we often have displayNames like "Steffen Joest" and surname "Jöst" which were previously displayed as "Steffen Joest (**Jöst**)" and which are now displayed as "Steffen **Jöst**".
Also, the case of surname is left unchanged, while the displayName is converted to title
Thus, we do not save the firm superior as `UserEmail` any more. The firm superior email is still used as a fallback for `CompanyEmail` which in turn is used as a fallback email, if a `CompanyUser` has no valid email at all.
