Re: Permissions don't get translated in admin interface

As suggested by @nessita on Discord, I’ve taken this to the Django Forum in Django Internals: https://forum.djangoproject.com/t/permissions-dont-get-translated-in-admin-interface/21324. Let’s try to keep the discussion going over there! On Friday, 2 June 2023 at 20:58:50 UTC+1 Thibaud Colas wr

Re: Permissions don't get translated in admin interface

Ah-ha! Correct :) That’s great. So as of that commit, it’s just the permission names that aren’t translated. Here’s a screenshot of the current state: [image: permission-names-django-Django-5.0.dev20230602105440.png] I’ve updated my POC accordingly (https://github.com/thibaudcolas/django/pull/

Re: Permissions don't get translated in admin interface

Is it not partly fixed by a52bdea5a27ba44b13eda93642231c65c581e083 ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To un

Re: Permissions don't get translated in admin interface

👋 without further input, I’m not quite sure what to do with this. We need this ticket re-opened so anyone actually considers working on a fix for this. For reference, the initial reason for closing this bug report was: > The permissions are stored in the database and don't get translated. To me

Re: Permissions don't get translated in admin interface

I worked on a potential fix for this yesterday at the Django London’s hack day with Nick (hi Nick if you’re reading this!). - Here is where translation names get created: https://github.com/django/django/blob/main/django/contrib/auth/management/__init__.py#L31 - And where the strings

Re: Permissions don't get translated in admin interface

Hello it's for this reason, i created this package https://github.com/RamezIssac/django-tabular-permissions It displays the permissions in a table that is easily translated , and easier to work with Aside from a 3rd party app, a workaround (like the one suggested above) will be the way to go.

Re: Permissions don't get translated in admin interface

Thanks On Sat, Sep 24, 2022, 22:28 Danilov Maxim wrote: > Hi, Tribaud. > > > > In your case you can override Permission admin to show translated names of > permissions and for widgets you can override modelchoiceiterator > > The name of permission you can translate like model.verbose_name + > ge

RE: Permissions don't get translated in admin interface

Hi, Tribaud. In your case you can override Permission admin to show translated names of permissions and for widgets you can override modelchoiceiterator The name of permission you can translate like model.verbose_name + gettext( ‘can’) + gettext(view/change/delete) and it should be translate

Re: permissions and groups data migration

Thank you, Luis-José Torres! On the basis of your code I added the following to my migrations: def fix_perms(*app_labels): def wrapped(apps, schema_editor): from django.apps.registry import apps from django.contrib.contenttypes.management import update_contenttypes fr

Re: permissions and groups data migration

Hi, This worked for me: from django.apps.registry import apps as apps_alt from django.contrib.auth.management import create_permissions for app_config in apps_alt.get_app_configs(): create_permissions(app_config) On Tuesday, December 30, 2014 at 11:01:11 PM UTC-6, Adam Venturella wrote:

Re: permissions and groups data migration

Hi Adam, Migrations build a fake app registry containing fake app configs for each state of the models. They implement a small subset of features of the real app configs. See https://github.com/django/django/blob/5e32605/django/db/migrations/state.py#L119-L131 That’s why my_app_config.models_

Re: permissions and groups data migration

Attempting this approach, calling : create_permissions(my_app_config) from within my migration fails to create the permissions. It looks like *create_permissions *checks for *models_module* on the provided app config. However, when my migration runs, my *models_module* is *None. * So is there

Re: permissions and groups data migration

On 10/15/2014 06:52 AM, Michael wrote: > Also, ContentType.objects.get_for_model does not work ('Manager' object > has no attribute 'get_for_model'). Not sure, but it might work to instead call `django.contrib.auth.management.create_permissions(...)` in the migration? You'll need to get hold of th

Re: permissions and groups data migration

Also, ContentType.objects.get_for_model does not work ('Manager' object has no attribute 'get_for_model'). Le mercredi 15 octobre 2014 07:43:03 UTC-5, Michael a écrit : > > I do not want to create a permission, I want to assign to a group some of > the default permissions django creates: add,

Re: permissions and groups data migration

I do not want to create a permission, I want to assign to a group some of the default permissions django creates: add, change and delete ( https://docs.djangoproject.com/en/dev/topics/auth/default/#default-permissions) Obviously, the permissions are not created yet when I run my first python ma

Re: permissions and groups data migration

As the ticket suggests, you can call the function to create permissions yourself in the data migration, and then you can assign them as normal. There's no need to use fixtures (in fact, migrations are better without fixtures, as there's no easy way to load them). Andrew On Tue, Oct 14, 2014 at 6:

Re: Permissions model limiting the length of verbose-name

Hi Russell, I'm reordering the text I'm replying to below, to make things clearer. On Monday 11 March 2013 12:14:22 Russell Keith-Magee wrote: > On Mon, Mar 11, 2013 at 5:58 PM, Shai Berger wrote: > > > > I would like to draw your attention to bug #8162[1]. It is old as sin, > > and annoying as

Re: Permissions model limiting the length of verbose-name

On Mon, Mar 11, 2013 at 5:58 PM, Shai Berger wrote: > Hi all, > > I would like to draw your attention to bug #8162[1]. It is old as sin, and > annoying as virtue. > You won't get any argument from me on this analysis. > The gist of it is: because, for all models, when the admin is present, > p

Re: Permissions independent of models

Use decorator user_passes_test from django.contrib.auth.decorator U will find all required docs in django docs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send e

Re: Permissions independent of models

On Sat, Jul 25, 2009 at 6:33 AM, Júlio Cesar wrote: > > Hey, Guys, > > There are some permissions that I would like to add in my project, > associated with acess a some views, particularly. > > But, there's no a clean mode to do this, because all permissions are > associated with ContentTypes, rig

Re: Permissions

On 4/28/06, Andreas Neumeier <[EMAIL PROTECTED]> wrote: > > I'm not quite sure, it may be me: Is the permission system working at > all in the magig-removal branch? > > I added something like that to my model just yesterday: > --- > class Meta: > permissions = ( > ("can_create", "Can c

Re: Permissions

I'm not quite sure, it may be me: Is the permission system working at all in the magig-removal branch? I added something like that to my model just yesterday: --- class Meta: permissions = ( ("can_create", "Can create"), ("can_modify", "Can modify"), ("can_view", "Can view

Re: Permissions

On Thu, 2006-04-27 at 21:21 -0700, SmileyChris wrote: > An ACL system seems appropriate as long as all objects of one type have > the same rights, which often isn't the case in the web environment. > > For example, someone was asking recently in the Django Users group how > they could allow users

Re: Permissions

I agree that maybe an object level ACL system could also be a solution. The main problem I see with a fine-grained ACL system is that it turns quickly into Zope permission soup (for those that have played with Zope). You quickly get so many permissions per object - it gets confusing fast! --~--

Re: Permissions

An ACL system seems appropriate as long as all objects of one type have the same rights, which often isn't the case in the web environment. For example, someone was asking recently in the Django Users group how they could allow users to only edit their own posts. This was what sparked me starting

Re: Permissions

Personally I'd like to see a more fine granied ACL system (ie.. object level permissions). actually I'll put that up as a 'SoC' project and see if I can get a sucker^h^h^h^hstudent to do it. --Ian On 4/28/06, SmileyChris <[EMAIL PROTECTED]> wrote: > > I'm not a fan of the current permissions sy

Re: Permissions

On Thu, 2006-04-27 at 15:56 -0700, SmileyChris wrote: > I'm not a fan of the current permissions system. It'd be neat to see > admin permissions evolve to a *nix-like system of user/group/all, > read/write permissions per object. > Objects could be linked into the permissions system with a single