The Token model is used to store access tokens and had field names which may have caused confusion for developers using them. Therefore, the field previously called name: now has the correct identifier token: (as it stores the actual token value), and the field previously called label: is now called name: for better consistency with other models.
- Translations are no longer fetched from the cloud.
- Instead, they are extracted from the codebase and stored in i18n/zammad.pot.
- Translations will be managed via a public Weblate instance soon.
- The translated .po files are fed to the database as before.
- It is now possible to change "translation" strings for en-us locally via the admin GUI.
- It is no longer possible to submit local changes.
This commit was prepared to facilitate a larger refactoring assignment
as part of the Pundit migration.
As a bonus, it includes some SQL query optimizations!
=== Why was this refactoring necessary?
It's not, strictly speaking.
But the Pundit migration involves taking complex querying logic
and moving it into Scope classes as appropriate,
and deciding where things belong is really difficult
when you can't see what they're doing.
=== So how does this refactoring fix the problem?
* It replaces raw SQL queries with Ruby-esque ActiveRecord queries.
* It replaces complex, procedural code
that's full of loops and obscure local variable assignment
with compact, cleanly-formatted code
that follows Ruby idioms and uses meaningful variable names.
In my opinion, it's much faster and easier
to understand what the code does this way.
=== What kinds of SQL query optimizations are included?
* n+1 query: user_access_token#index instantiated all active permissions
and then called current_user.permissions? on _every single one._
A fresh installation of Zammad contains 57 permissions,
so this was a lot of unnecessary queries.
The method has been rewritten to make only one query instead.
* User#permissions? used to query the DB once
for each argument it was given.
Now, it only queries the DB once, even when given many arguments.
* We had a couple SQL queries that used both #select and #pluck.
(When using #pluck, #select is redundant.)
Removing #select from these calls did not improve performance,
but it did clean up unnecessary code.
