Ability to defer permission and utility registration for translations by jasonvarga · Pull Request #7343 · statamic/cms

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jasonvarga · 2023-01-11T21:06:14Z

Fixes#3467
Fixes#2041
Fixes#5666

This PR fixes an issue where if a user has a locale preference different to what the app is configure with, some permission and utility labels will use the incorrect language.

The issue is because of when the permission/utility is registered in a provider, the user's locale preference had not yet been applied, so the __() translation helper will use the default language. The fix was to defer booting the permissions/utilities until after the user's locale preference was applied.

This fixes it for the core permissions/utilities, but does not change the behavior for third party permissions/utilities.

Addon developers can fix the issue for their own permissions/utilities by simply wrapping their registration code in extend closures:

+Permission::extend(function () {
Permission::register('foo', '...');
+});+Utility::extend(function () {
Utility::make('foo')->register();
+});

Additionally, utilities have been updated for consistency. They can use register to start the fluent chain instead of make, and then avoid calling register at the end:

-Utility::make('foo')->title('Foo')->etc()->register();+Utility::register('foo')->title('Foo')->etc();

However, there's no requirement to change that. The old methods still work (but are now deprecated). If you're in there to wrap your code with extend, you may as well change that too. 😄

…r front end.

…stomizable-navs

…ater).

…ete method.

…ences.

…tle case convention.

…purposes, otherwise `false` it.

…avBuilder.php`.

…/customizable-navs

# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

jasonvarga · 2023-01-13T20:35:38Z

There are so many commits because I was branching off the preferences-ui branch which got squashed into master so all of it's commits look new. Oops. This is squashed anyway so no biggie.

jesseleiteand others added 30 commits September 12, 2022 14:38

This is now normalized by UserNavConfig.
80dbb06

Process newly created child items the same way we process regular items.
8165a66

Can't do that in PHP 7.4 my dear boy.
16924bb

Use whenNotEmpty(), but still apparently can't shorthand fn() it.
2ec1918

Refactor to separate params.
90e4bf3

Ensure we can rebuild nav from fresh slate.
a781a9a

Support tracking preference manipulations on each NavItem instance fo…
58be4f9
…r front end.

Track preference manipulations.
49d35c6

Allow passing of different preferences into Nav::build().
4542c42

Rename UserNavConfig to NavPreferencesConfig.
5e87094

Lots of front end.
6d8cfd9

Merge branch '3.3' ofhttps://github.com/statamic/cmsinto feature/cu…
429e06a
…stomizable-navs

The Nav and NavItem JSON resources used by the builder.
63093d8

Hardcode link to nav.
84bd7e3

Hide breadcrumb, because there is no preferences section yet (maybe l…
518a6da
…ater).

Normalize original for simpler logic in back end.
6429bde

Wire up discard changes behaviour.
61e2823

Icons.
088b26a

Fix issue with new item IDs.
c6acbb7

Route and controller.
e108e5f

Add Nav Pref index and icon
4a438be

Move PreferenceController and fix destroy route to actually use del…
3d7dcf4
…ete method.

Wire up routes and controllers for default, role, and user nav prefer…
814e920
…ences.

Move into CoreNav.
a517164

Add buildDefault() alias.
2629fd1

Update front end.
b2b7ffe

Update tests.
f273d75

Only show section if roles exist.
1b4bef9

Add test coverage for new Preference::preventMergingChildren() method.
41f2713

Implement preventMergingChildren().
336a22d

Might as well avoid using deprecated code now
398da66

jasonvarga changed the title ~~Ability to defer permission registration~~Ability to defer permission and utility registration for translationsJan 11, 2023

jasonvargaand others added 15 commits January 12, 2023 11:25

Pass preferences into section closure
5f81ff7

Add simpler syntax for registering preferences
efa60e6

avoid facade
e652e7a

prevent overriding section display names
93329f9

Add test coverage for Nav::extend()’d sections that don’t follow ti…
6d9416b
…tle case convention.

Only pass along display if it’s explicitly configured for renaming …
c2b3098
…purposes, otherwise `false` it.

Pass failing tests by moving section display and rename logic into `N…
6eefad5
…avBuilder.php`.

Merge branch 'master' ofhttps://github.com/statamic/cmsinto feature…
666c723
…/customizable-navs

Merge branch 'feature/customizable-navs' into feature/preferences-ui
ddf695a

Merge branch 'feature/preferences-ui' into permission-translations
d5261cd

Merge branch 'master' into feature/preferences-ui
95a4b3b
# Conflicts: # resources/views/partials/global-header.blade.php # routes/cp.php # src/Preferences/Preferences.php

Disable save part of button and leave dropdown active
f9673de

Leave dropdown active
77c3115

Add heading
421e81e

Merge branch 'feature/preferences-ui' into permission-translations
01e883e

Base automatically changed from feature/preferences-ui to masterJanuary 13, 2023 19:47

jasonvarga added 2 commits January 13, 2023 14:48

Merge branch 'master' into permission-translations
1f56155
# Conflicts: # src/Preferences/Preferences.php # src/Providers/CpServiceProvider.php

unnecessary
f2fa807

jasonvarga marked this pull request as ready for review January 13, 2023 20:05

jasonvarga merged commit 5d2d82e into masterJan 13, 2023

jasonvarga deleted the permission-translations branch January 13, 2023 20:35

jasonvarga mentioned this pull request Feb 13, 2023
[4.x] Remove deprecations #7536
Merged

duncanmcclean mentioned this pull request Jan 23, 2024
Statamic may get forced into English only through addons #3127
Closed

duncanmcclean mentioned this pull request Feb 28, 2025
[6.x] Update authorization / permissions #11516
Merged