fix(entity): Fix mapping of old/sub-types to actually supported datab…

[nickvergessen]

…ase types

• Follow-ups from feat(AppFramework): Add full support for date / time / datetime columns #47329

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[nickvergessen]

shall we document those to satisfy psalm? Or yolo?

[susnux]

So the options are this, right?

1. Document and make it somewhat official by doing so
2. yolo and apps have to baseline or use the types from the constants

I would prefer to fix the apps (so 2), but not sure if this is too much effort and I do not want to make all devs angry...

[nickvergessen]

Added a @since entry to the method to explain it, together with a psalm-suppress.
We could backport the setter() change, to make sure using Types::TEXT and the others works also on stable branches. But then the apps would have to depend on a specific patch release or still need a version switch.

So for now I would say they will have to use the psalm baseline until they dropped support for everything < 31 and then move to Types?

[st3iny]

Let's get this in quickly please 🙏 Thanks!

CI is red in all Groupware apps and we are kind of blocked until a decision is made on this.

EDIT: Or we simply migrate to 'integer' which shouldn't be breaking anything, right?

[nickvergessen]

CI is red in all Groupware apps and we are kind of blocked until a decision is made on this.

Unless you migrate to the new consts psalm will stay red, but yeah same issue in talk