Problem
The files, lines, strings, translations, translation history, status flags, parser errors, packager releases and packager files are data the parser, the translation workflow and the packager write. 3.0.x gives every one of them add, edit and delete forms with "Add" action links on their admin lists, a page per entity that is the edit form, and a permission per type (administer l10n server string, administer packager file and so on, one of them mislabeled "status string"). Editing a string or a translation by hand bypasses the hash keys, the history rows, the status flags and the counts the code keeps consistent. Drupal 7 had none of this: the parsed data and the translations were only reachable through the parser, the translation interface and the packager, and one administer localization server permission covered administration. Projects and releases keep their forms, those are meant to be edited.
Proposed resolution
- Drop the nine entity form classes, the add, edit and delete link templates, the per-entity pages and the "Add" action links. The admin lists stay for support.
- Drop the nine custom route providers, whose only purpose was to serve the edit form as the entity page.
- Drop the seven
administer l10n server ...per-type permissions and the two packager ones. The access handler checks the entity admin permission,administer localization server, plus the view permissions as before. - The remaining permission labels lose the "l10n server" machine name wording: "View projects", "Edit releases", "Browse translations" as on Drupal 7, and so on. The machine names stay, site roles reference them.
No site role on localize.drupal.org grants any of the removed permissions.
Tests
The entity access test no longer expects the per-type permissions to grant anything. The functional tests cover the remaining admin lists and the project and release forms.
LLM disclosure
LLM was used to find, diagnose explain and fix this issue. With human review.
Comments
Comment #3
gábor hojtsy