Commit Graph

160 Commits

Author SHA1 Message Date
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
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
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
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
6299612adc refactor: various minor changes, mostly some comments 2024-08-07 17:51:33 +02:00
507a7e02fc fix(avs): using firm superior as UserEmail is a no-go due to uniqueness constraints
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.
2024-07-31 15:03:26 +02:00
43f5c5f485 fix(avs): fix #173 by not using firm superior email as display email
Instead, a valid firm superior email is used as `UserEmail` so that it can be used as a fallback address.
2024-07-31 14:16:40 +02:00
b9f70c7796 chore(avs): ensure supervisor reroutes are correct upon company switch 2024-07-30 15:58:12 +02:00
8c8ffa5183 chore(avs): remove company superior, if there is none anymore 2024-07-12 13:44:21 +02:00
fee14edf36 refactor(firm): fix #157 refactor duplicated code
also ensures that supervisor default reaons filters are obeyed.
2024-07-12 12:21:17 +02:00
28e2739e51 fix(firm): fix #157 by removing redundant duplicated code in firm user and supervision handling 2024-07-11 18:37:40 +02:00
d65fb2f4cd chore(firm): add reason for user company association 2024-07-10 15:54:15 +02:00
5bf85394d4 fix(avs): towards #169 - superiors are elevated to max priority for that company
this entails that users may have multiple equal priority companies
2024-07-02 18:14:54 +02:00
99f03078a1 chore(db): use runDBRead more often 2024-07-02 17:37:34 +02:00
9e2f2214ce fix(avs): do not associate users by AvsInfoPersonEmail 2024-07-02 15:27:56 +02:00
ff9014ce05 fix(avs): fix superfluous quotes for matriculation numbers on newly created users 2024-07-02 13:20:34 +02:00
37efc89e07 fix(avs): company superior emails become company wide supervisors 2024-06-27 12:40:35 +02:00
975bf13d9c chore(avs): proper company superiors as company wide default APs (WIP) 2024-06-26 17:18:41 +02:00
2559346d96 fix(avs): new AVS from existing LDAP user no longer misses fields 2024-06-26 15:08:38 +02:00
f108c6cfec fix(avs): match mobile number better between LDAP and AVS 2024-06-25 17:36:33 +02:00
e4fa1ddd68 fix(avs): priority for picking primary email demote superior 2024-06-25 15:54:55 +02:00
766b8589d6 fix(avs): keep company on unchange address/email only if either is non-empty 2024-06-21 13:47:05 +02:00
ab5e432b77 refactor(avs): use associated type family to consistently produce CheckUpdate 2024-06-19 15:10:23 +02:00
a6d0105903 fix(avs): fix rare avs update bug involving values optional in avs but compulsory in user entity 2024-06-17 17:50:41 +02:00
0eac40457b chore(avs): add more auto update indicators to profile page 2024-06-13 14:51:05 +02:00
76e0710c7b fix(avs): fix #165 by updating userCompanyDepartmen and userCompanyPersonalNumer
- Die interne Firma Assoziation im User-Eintrag wird gelöscht, sobald der letzte erfolgreiche LDAP Sync älter ist als der eingestellte SYNCHRONISE_LDAP_EXPIRE (default = halbes Jahr).
- Firmen-Assoziation wird ebenfalls gelöscht, falls vorhanden
- Die Personalnummer bleibt erhalten, wenn das AVS diese noch liefert; ansonsten wird sie ebenfalls gelöscht.
- UserLdapPrimaryKey wird ggf. von AVS aktualisiert
2024-06-12 17:48:17 +02:00
996e6a0ce5 fix(avs): repeated avs sync enqueue no longe violates duplicate db uniqueness constraints 2024-06-12 11:47:23 +02:00
da74b95729 fix(avs): fix #164 by removing companyPersonalNumber and companyDepartment upon ldap sync expiry
SYNCHRONISE_LDAP_EXPIRE may be null (do nothing) or some seconds (15897600 = half a year). If no successful LDAP synch happened for the specified time, a successful AVS (sic!) update will delete the companyPersonalNumber and companyDepartment
2024-06-11 15:42:24 +02:00
bb101dee7b fix(avs): company update no longer fails on duplicate key 2024-06-10 14:56:33 +02:00
e553ad4358 fix(avs): profile page correctly indicates automatic email and postal addresses 2024-06-07 17:42:05 +02:00
ea0fa9a3fa chore(avs): add more debug message for company updates failing 2024-05-27 17:21:28 +02:00
9451d90a9e fix(avs): company update checks uniques and ignores those updates if necessary 2024-05-23 17:08:30 +02:00
ff2347b1c9 fix(avs): avs update on company shorthands working now 2024-05-17 18:06:16 +02:00
ccf9340449 fix(avs): deal gracefully with empty card status results 2024-05-17 12:05:08 +02:00
5944efcb86 chore(avs): change to secondary company (WIP) form missing 2024-05-02 17:29:04 +02:00
fdbaa3c9d4 chore(avs): add function to change to secondary company 2024-04-30 17:45:29 +02:00
697979c277 fix(avs): fix #69 by redesigning live avs status page 2024-04-26 17:55:29 +02:00
a5dfd5e10f refactor(avs): add more logging to AVS synch ops 2024-04-26 16:04:28 +02:00
6fd45f6896 refactor(avs): complete rewrite AVS synch
Three former background jobs could be removed
2024-04-25 17:07:12 +02:00
2e4e1a94c9 refactor(avs): rewrite AVS synch (WIP) 2024-04-24 18:01:44 +02:00
a52c8a6ad7 fix(avs): several minor bugfixes
- See notes in #158 for details on update change policy
- fieldLensVal was not working
- create index for deleted table prevented start
- some hlint errors
2024-04-22 18:19:07 +02:00
4f8850b3b4 fix(avs): fix #36 and remove dead code 2024-04-18 18:30:23 +02:00
b7af6312f9 refactor(avs): complete createAvsUserById 2024-04-18 18:02:16 +02:00