ACT_RU_*: RU stands for runtime. These are the runtime tables that contain the runtime data of process instances, user tasks, variables, jobs, etc. The engine only stores the runtime data during process instance execution and removes the records when a process instance ends. This keeps the runtime tables small and fast.
ACT_ID_*: ID stands for identity. These tables contain identity information such as users, groups, etc.
Following this naming-schema, I wouldn’t expect authorizations to a user stored in a ACT_RU-table. Wouldn’t a ACT_ID-table make more sense? Thus I would propose renaming ACT_RU_AUTHORIZATION to ACT_ID_AUTHORIZATION.
It’s not a bad suggestion but i think there’s a good reason to keep it the way they are. Very often the ID tables are not used. Instead people would choose to connect to their own LDAP server. In that case the ID tables aren’t used. BUT the Authorization tables are still used. The authorization tables are in fact used no matter how you decide to store your users. So it should probably remain in Runtime for that reason.
Funny thing is, that’s exactly the thing where I struggled
I did migrate a centralised Camunda-DB into multiple DBs (one for each microservice, that hosts Camunda processes). Almost everything went fine, but suddenly permissions went fly. I looked into the ID-tables which I found empty. I was a bit confused as of how Camunda would manage permissions if not with those tables.
Then I stumbled across the ACT_RU_AUTHORIZATION which had viciously been hiding in between some HI-tables in my schema visualization tool. The rest is history.
Getting your point though. Thanks for taking your time to reply.
