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

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 transla

Re: Permissions don't get translated in admin interface

the default permissions: https://github.com/thibaudcolas/django/pull/1 It seems to work well. As far as I could see, there’s no reason for at least the app name to be displayed in english (just need to switch from app_label to verbose_name). On Sunday, 25 September 2022 at 14:02:33 UTC+1

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

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

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

Permissions don't get translated in admin interface

👋 there have been a lot of discussions and tickets opened on permissions translations in the past. I’m not sure what the etiquette here is, hence why I’m starting a new conversation. I would like to see #1688 Permissions don't get translated in admin interface <https://code.djangopro

Re: Add feature request for django permissions.

e > > في السبت، 12 يونيو 2021 في تمام الساعة 11:27:39 ص UTC+3، كتب ‪wael > muhammed‬‏ رسالة نصها: > >> ? What is yours opinion could I make a pull request >> >> في السبت، 12 يونيو 2021 في تمام الساعة 9:40:48 ص UTC+3، كتب ‪wael >> muhammed‬‏ رسالة نصها:

Re: Add feature request for django permissions.

ا: could this <https://stackoverflow.com/questions/67946118/django-permissions-according-to-branch-id> want feature request. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itsel

Re: Add feature request for django permissions.

gt;> >> could this >> <https://stackoverflow.com/questions/67946118/django-permissions-according-to-branch-id> >> >> want feature request. >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contribut

Re: Add feature request for django permissions.

? What is yours opinion could I make a pull request في السبت، 12 يونيو 2021 في تمام الساعة 9:40:48 ص UTC+3، كتب ‪wael muhammed‬‏ رسالة نصها: > > could this > <https://stackoverflow.com/questions/67946118/django-permissions-according-to-branch-id> > > want featur

Add feature request for django permissions.

could this <https://stackoverflow.com/questions/67946118/django-permissions-according-to-branch-id> want feature request. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Translation of group permissions

This is an old decision not to store translated strings in the db... and it's makes sense what if your site is multi lingual ? Solution: The widget should be replaced with a another widget that display the permissions in a dynamically translated fashion. There is this app to address that a

Re: Translation of group permissions

cie...@gmail.com wrote: > > Hi, > > The permissions are stored in the database and don't get translated. > > Refer: https://code.djangoproject.com/ticket/1688. > > poniedziałek, 10 maja 2021 o 19:35:38 UTC+2 M Vv napisał(a): >> Translation of user permi

Re: Translation of group permissions

Hi, The permissions are stored in the database and don't get translated. Refer: https://code.djangoproject.com/ticket/1688. poniedziałek, 10 maja 2021 o 19:35:38 UTC+2 M Vv napisał(a): > Translation of user permissions is not done. > > [image: gruop trans.PNG] > > How s

Translation of group permissions

Translation of user permissions is not done. [image: gruop trans.PNG] How should it go about it? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiv

Re: Migration strategy for proxy model permissions to use their own content type

. Best regards, -- Aymeric. On 26 Nov 2018, at 16:10, Arthur Rio wrote: Hi all, I have been working on a 9 years old ticket that I'd like to close once and for all. The outstanding question is about the migration path to choose in order to update existing proxy model permissions. I

Re: Migration strategy for proxy model permissions to use their own content type

, -- Aymeric. > On 26 Nov 2018, at 16:10, Arthur Rio wrote: > > Hi all, > > I have been working on a 9 years old ticket that I'd like to close once and > for all. The outstanding question is about the migration path to choose in > order to update existing proxy

Re: Default upload permissions

I like this solution, as it applies the fix for new things moving forward with no change in behavior to cause problem for existing tweaked in sites. The most likely time to run in to this problem is, in my opinion, is when varying platforms or starting fresh projects. Once settled in to a proj

Re: Default upload permissions

Hi, On 12/5/18 9:54 AM, Carlton Gibson wrote: > *Proposal*: we should change the default for FILE_UPLOAD_PERMISSION to > 0o644 (or maybe 0o664), and document that as a backward incompatible > change. This would be correct for almost all users.  If you're > deliberately leveraging `FILE_UPLOAD_PERM

Re: Default upload permissions

Hi all, This has come up again. So proposal below. https://code.djangoproject.com/ticket/30004 "Document TemporaryUploadedFile potential permission issues" Issue is that, with the default settings, you get 0o644 permissions for "small" files and 0o600 permissions for &qu

Migration strategy for proxy model permissions to use their own content type

Hi all, I have been working on a 9 years old ticket that I'd like to close once and for all. The outstanding question is about the migration path to choose in order to update existing proxy model permissions. I have explained three different approaches I can think of in the pull re

Default upload permissions

Hi all, https://code.djangoproject.com/ticket/28540 explains that unless FILE_UPLOAD_PERMISSION is set (not set by default), uploaded file permissions are often a mix of 0o600 and 0o644 (or another value depending of the default umask), based on the upload method (memory or temporary file

Re: Update permissions on custom permissions migration

class *Meta*: > permissions = (('spam', 'Can eat spam'),) > > ... > > $ manage.py makemigrations > $ manage.py migrate > > Now we have a custom permission in the User admin: > > foods | spam | Can eat spam > > Then upd

Update permissions on custom permissions migration

A model with a custom permission: class *Spam*(Model): class *Meta*: permissions = (('spam', 'Can eat spam'),) ... $ manage.py makemigrations $ manage.py migrate Now we have a custom permission in the User admin: foods | spam | Can eat s

Re: adding object level permissions on the core permissions

Hi. To achieve object level permissions you need to write custom authentication backend. Django does provide support for object level permissions but there isn't default implementation because object level permissions have different meaning for different people. See auth docs for

adding object level permissions on the core permissions

I want to add object level permissions to the Django'd core auth app Permission model. currently permission instances follow this string format '._' ideally i want this object level permissions to follow a similar string format with as few variations from the originals as po

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

#x27;s also this discussion: * https://code.djangoproject.com/wiki/RowLevelPermissions Looking at this, I don't think we're quite saying what I took us to be saying. i.e. we're not clearly spelling out the object-permissions situation. (Beyond those pages all the top search results are

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

Thanks for the response. Do you think what Florian or I sent is a good example to include in the docs for the way #1? From: Carlton Gibson Sent: Monday, January 22, 2018 2:13 AM To: Django developers (Contributions to Django itself) Subject: Re: Default Authorization BackEnd Denying Permissions

Re: Default Authorization BackEnd Denying Permissions if Object Provided

while, however, so... I've used this API, with Django Guardian and without. It never occurred to me that there was a problem with ModelBackend's behaviour. For me the it (i.e. the docs) says: > I don't do object permissions so I always return `False` if you ask. That seems c

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Aymeric, If one doesn’t have time to read 21 emails, then should also not have time to judge them. Regards, On Fri, Jan 19, 2018 at 2:33 PM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > 2018-01-19 17:54 GMT+01:00 Mehmet Dogan : > >> I propose throwing out the proposed behavior

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-19 17:54 GMT+01:00 Mehmet Dogan : > I propose throwing out the proposed behavior as Option B, and see what > happens. > "Make changes and see what happens" doesn't sound like the way Django is maintained in general. Unfortunately I don't have enough motivation to go through the 21 emails

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hey Carlton, I think everybody said what they would. What do you say? I propose throwing out the proposed behavior as Option B, and see what happens. Something along these lines: *class *ModelBackendIgnoreObject(ModelBackend): *def *get_user_permissions(self, user_obj, obj=*Non

RE: Default Authorization BackEnd Denying Permissions ifObjectProvided

sense, so it will should not be an issue. Sent from Mail for Windows 10 From: Mehmet Dogan Sent: Thursday, January 18, 2018 2:04 PM To: django-developers@googlegroups.com Subject: RE: Default Authorization BackEnd Denying Permissions ifObjectProvided Andrew, > Why you would use the user API

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

Andrew, > Why you would use the user API if you cared about a specific backend? True. I wouldn’t. > Using your example of the RolesBackend, either > A) You want to leave it up to the user whether a role grants object level > permissions or not. > B) You want to have consiste

Re: Default Authorization BackEnd Denying Permissions if Object Provided

, either A) You want to leave it up to the user whether a role grants object level permissions or not. B) You want to have consistent behavior for your backend. Explanation: A) In this case you would use your pseudo code example. To return true (proposed) for an object when a user has the model

Re: Default Authorization BackEnd Denying Permissions if Object Provided

overall. People can always extend it and put it above it in the setting to alter default behavior, or just replace it, if they need. But I would also like to point out one disadvantage of the new way: it will make harder, and maybe impossible in some cases, to pull object permissions over the common

Re: Default Authorization BackEnd Denying Permissions if Object Provided

for details). *Long Answer:* I am trying to write a Roles backend with, and without reinventing the wheels for, object and model permissions. The logic is very simple. class Role(models.Model): delegate = models.OneToOneField(Permission,* ...*) perms = models.ManyToManyField(Permission

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Thursday, January 18, 2018 at 2:55:27 AM UTC+1, Mehmet Dogan wrote: > > If that is the way forward, I will volunteer for the code. But, as you > also point out, there needs to be a *path* out. That I don't know :) > Personally I think it is (though I haven't had hours to think about it). Th

Re: Default Authorization BackEnd Denying Permissions if Object Provided

one is the model and the other is the object permissions. In case of plug-ins, that will go away, and it will be even harder to leverage existing backends. Also, the logic that polls backends is in auth/models.py, I do not see how would it be possible to design an API that will let picking and c

Re: Default Authorization BackEnd Denying Permissions if Object Provided

The "expected behavior" is that *one has permission on an entire table would also have permission on a row of it*. This seems to be the one thing that everyone can agree on. And, I am yet to see a person that argues otherwise. But, it seems, we just need someone or some people to make that *hard *d

Re: Default Authorization BackEnd Denying Permissions if Object Provided

r.has_perm('foo.change_bar', obj)` I know one is the model and the other is the object permissions. In case of plug-ins, that will go away, and it will be even harder to leverage existing backends. Also, the logic that polls backends is in auth/models.py, I do not see how would it be possible to des

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

dangerous since >> it changes how the API work for all apps installed. Example, guardian makes >> calls to user.has_perm(perm) in several places to check model permissions. >> Although periphery features, they would be broken. >> > > Funny tha

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

check model permissions. > Although periphery features, they would be broken. > Funny that you would say that, because your proposed setting OBJECT_PERMISSION_FALLBACK_TO_MODEL does exactly the same thing ;) -- You received this message because you are subscribed to the Google Groups

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 7:58:17 PM UTC+1, Carlton Gibson wrote: > > Given your comment, would it be along the lines of "Close as "Won't Fix", > perhaps with a review of the documentation", to point users to subclassing > ModelBackend if they need the alternate behaviour? > My comment

RE: Default Authorization BackEnd Denying Permissions ifObjectProvided

Permissions ifObjectProvided Hi.  @Andrew: I'll look at your post anon, as it's longer.  On Wednesday, 17 January 2018 20:46:27 UTC+1, Mehmet Dogan wrote: Can you give an example of what you mean by option 3.  Well, I don't a concrete suggestion in mind, but the general idea wo

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

Hi. @Andrew: I'll look at your post anon, as it's longer. On Wednesday, 17 January 2018 20:46:27 UTC+1, Mehmet Dogan wrote: > > Can you give an example of what you mean by option 3. > Well, I don't a concrete suggestion in mind, but the general idea would be to have ModelBackend proxy to ano

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

Although I found it very interesting at first, this looks dangerous since it changes how the API work for all apps installed. Example, guardian makes calls to user.has_perm(perm) in several places to check model permissions. Although periphery features, they would be broken. From: Florian

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

: Default Authorization BackEnd Denying Permissions if ObjectProvided Hi Mehmet,  Due to the BC issues, this is fairly in-depth.  Having looked at the history, here are my initial thoughts.  The initial issue here is this behaviour from `ModelBackend`: ``` user.has_perm('foo.change_bar&

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Florian, I was hoping you'd post. You've been active on the entire (very-long) history of this issue. Can I ask for your take? Given your comment, would it be along the lines of "Close as "Won't Fix", perhaps with a review of the documentation", to point users to subclassing ModelBacken

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Carlton,     Thanks for the thoughts. I just wanted to share my opinion on your options. 1. "Won't Fix"     I have yet to find anywhere the original design decisions were documented. Based on what I can find, it appears that object level permissions where a bit of an after

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote: > > Florian, > > Can you clarify this part, I am not sure what you meant: > class MyBackend(ModelBackend): def has_perm(…, obj=None,…): if obj: obj = None return super().has_perm(…) something along the lines of

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Florian, Can you clarify this part, I am not sure what you meant: > in the worst case the user would have to change the permission backend which is easy enough… On Wed, Jan 17, 2018 at 10:31 AM Florian Apolloner wrote: > > > On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson w

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson wrote: > > The objection is to this kind of check: > > if user.has_perm('foo.change_bar', obj=bar) or > user.has_perm('foo.change_bar'): > ... > FWIW I would never write code like this. `user.has_perm('

Re: Default Authorization BackEnd Denying Permissions if Object Provided

o — i.e. that the current behaviour is in fact **wrong** — then we should go ahead despite the difficulty. Working out what that entails is non-trivial. That's why it needs a decent discussion and consensus here. Which leads to... 3. Break out the permissions aspect of `Mo

Re: Default Authorization BackEnd Denying Permissions if Object Provided

I updated my patch: https://github.com/django/django/pull/9581 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-dev

Re: Default Authorization BackEnd Denying Permissions if Object Provided

And I forgot; 3rd advantage: - The 3 backend methods mentioned above won't have to take an extra kwarg such as fallback_to_model; thus backward compatible there. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django its

Re: Default Authorization BackEnd Denying Permissions if Object Provided

RoleBackend Advantages: - One will not have to use package specific API for checking just the object permissions, for example. - Cleaner and generic: allows backends re-use each other. For example, I am writing a RoleBackend and can easily make calls to model or object permission back

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Created a pull request: https://github.com/django/django/pull/9581 Mehmet -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Based on this patch: the following 3 methods in the custom authorization backends will have to admit a *fallback_to_model *keyword argument: *def *has_perm(self, user_obj, perm, obj=None, fallback_to_model=None) def get_group_permissions(self, user_obj, obj=None, fallback_to_model=None) def ge

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is a sample patch: https://github.com/doganmeh/django/commit/d85cd3a530984ab5e4cb42f93629a64eb0b65b07 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving

Re: Default Authorization BackEnd Denying Permissions if Object Provided

And the other: Here is what I propose in terms of working around the backward compatibility that seems to have kept it from being solved for so long. 1) define a global setting, say: OBJECT_PERMISSION_FALLBACK_TO_MODEL=False. This is to help maintain the default behavior (unless the setting i

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is the text of linked stuff for convenience: For authorization backends checking object level permissions (like guardian) usually requires calling the django's default authorization backend as a fallback to the more general set of permissions: if user.has_perm('foo.change_bar

Default Authorization BackEnd Denying Permissions if Object Provided

Hello all, I had opened a ticket re issue noted in subject, which happened to be a duplicate, anyways, the text is here : Tim Graham told that it needs to be discussed here. Seems this is a long going issue, with several related issues (se

Re: about ticket 28588- has_perm hide non-existent permissions

Hi, On Monday, October 2, 2017 at 2:24:31 PM UTC+2, moshe nahmias wrote: > > If yes I think I have a good solution, I will return on the check if perm > in Permission.all() > Where exactly do you propose to do that? Here: https://github.com/django/django/blob/master/django/contrib/auth/models.

Re: about ticket 28588- has_perm hide non-existent permissions

n doesn't exist means that we go through >> the same path as a regular user, since (at least on >> auth.backends.ModelBackend) we check already if the user is superuser and >> if so we return all the permissions (I suppose it's only permissions that >> exist) it m

Re: about ticket 28588- has_perm hide non-existent permissions

r and > if so we return all the permissions (I suppose it's only permissions that > exist) it means we only need to remove the check at the start to see if the > user is superuser. > Removing this check would be highly backwards incompatible for 3rd party permission backends. ​

Re: about ticket 28588- has_perm hide non-existent permissions

he first time the user is working on it when running the app but it's not backwards compatible. 3. Return False if the permission doesn't exist means that we go through the same path as a regular user, since (at least on auth.backends.ModelBackend) we check already if the user is superuser and

Re: about ticket 28588- has_perm hide non-existent permissions

t; have a security risk or an adverse effect on performance. Given the > philosophy, "complexity is the enemy of security," I'd lean toward keeping > the permissions checking code simple instead of adding some other logic > based on DEBUG. > > On Wednesday, September 27,

Re: about ticket 28588- has_perm hide non-existent permissions

ance. Given the philosophy, "complexity is the enemy of security," I'd lean toward keeping the permissions checking code simple instead of adding some other logic based on DEBUG. On Wednesday, September 27, 2017 at 9:48:24 AM UTC-4, Florian Apolloner wrote: > > I do not think it

Re: about ticket 28588- has_perm hide non-existent permissions

, the superuser would have it. And there's a backwards-compatibility argument. Think of superusers more as "permissions don't apply to me" than "I have all permissions". I agree with the logging... however, I think has_perm should always return False for non-existent per

Re: about ticket 28588- has_perm hide non-existent permissions

gument. Think of superusers more as "permissions > don't apply to me" than "I have all permissions". > > Dan > > On Sunday, September 24, 2017 at 10:56:40 AM UTC-4, moshe nahmias wrote: >> >> Hi, >> I am a python developer and like to use Django for

Re: about ticket 28588- has_perm hide non-existent permissions

backwards-compatibility argument. Think of superusers more as "permissions don't apply to me" than "I have all permissions". Dan On Sunday, September 24, 2017 at 10:56:40 AM UTC-4, moshe nahmias wrote: > > Hi, > I am a python developer and like to use Dj

about ticket 28588- has_perm hide non-existent permissions

Hi, I am a python developer and like to use Django for web development. Since I like the framework I want to contribute back, so I looked at the open tickets to find something I can start with contributing and found ticket 28588. This ticket is about when checking if the user has permission for so

Re: New Permissions Scheme

Have you tried of django-guardian ? What do you think about it ? TBH I never actually used it (I've been doing Django for 9 years and have never used a permission table), but I think it does what you want. >From my experience, permissions are thought of something that can be calculate

Re: New Permissions Scheme

> > > After some some thoughts, i figured out that one route to change how permissions work in Django can be done by changing AUTHENTICATION_BACKENDS to a Custom ModelBackend Subclass that query for Permissions in a different way or from a different model / Table; And this soluti

Re: New Permissions Scheme

My proposal is mainly about re-thinking how permissions work with Django as a whole, as It's not the most perfect thing. And fixing it in a backward compatible way is next to impossible, so i would say let's revolutionize it and try to ease the transition. Regarding adding a view permi

Re: New Permissions Scheme

There are a lot of issue with your new permissions. Some people have been asking for a view permission in admin. With current system, all one have to do is add a permission per model. With your proposal, the whole system have to be ditched in favor of a more flexible one. I have also seen

New Permissions Scheme

Good day dear fellow Django developers, Current permissions scheme in Django does suffer many flaws Like Inconsistency with permissions for proxy models #11154 <https://code.djangoproject.com/ticket/11154> and the fact that permission names are not translatable (no translation in the da

Re: The key of permissions model

g api' for permissions. Thanks, –Flavio. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubsc

Re: Summer of Code Idea: Class-based [Object] Permissions

on to APIs or JSON: it's the extremely well-designed class-based > permissions > system <http://www.django-rest-framework.org/api-guide/permissions/>. > > For those who aren't familiar, the bottom line is that it's a system that > allows the developer to run

Summer of Code Idea: Class-based [Object] Permissions

Django needs the most from DRF has no direct connection to APIs or JSON: it's the extremely well-designed class-based permissions system <http://www.django-rest-framework.org/api-guide/permissions/>. For those who aren't familiar, the bottom line is that it's a system that

Re: View permissions to admin

mmediately use to >> start adding content to the site. In this document, we discuss how to >> activate, use and customize Django’s admin interface." >> >> I totally agree with that quote, Django admin is one of the top things >> that I love at Django. For it fl

Re: #10686 - inheritance of extra permissions from base class to child class

Thanks for the input, that clears up some details which bring me on agreement for the first suggestion. Op 2 feb. 2016 21:51 schreef "Shai Berger" : > Hi Sergei, > > Two notes: > > 1) For Abstract base classes, Meta is inherited by default[1] which would > make &g

Re: #10686 - inheritance of extra permissions from base class to child class

Hi Sergei, Two notes: 1) For Abstract base classes, Meta is inherited by default[1] which would make the permissions inherited by default. For multi-table inheritance, this is not the case[2]. 2) The second option as you presented it, where AssignedTask.Meta's permissions are added t

#10686 - inheritance of extra permissions from base class to child class

Hi all, I was browsing tickets and stumbled upon https://code.djangoproject.com/ticket/10686, which was accepted except for lack of documentation. The patch in the mentioned ticket makes it so that a Model class that's used as base class with extra permissions: class BaseTask(models.

Re: View permissions to admin

; Why not to make Django strengthenesses even stronger? I use it in such ways > and I am not aware about any "fiddling with the internals". The view > permissions was first such case. > > If Django admin usage for such purposes is not intended, I would expect to > see big fa

Re: View permissions to admin

ally agree with that quote, Django admin is one of the top things that I love at Django. For it flexibility, easy development and usefulness. Why not to make Django strengthenesses even stronger? I use it in such ways and I am not aware about any "fiddling with the internals". The view p

Re: View permissions to admin

Hi, At YPlan we've hacked in view permissions to the admin, exactly because of the reasons Markus talked about - it's the front end we've built for employees, done rather than building a proper process-based interface. I think it could just about be done in a third-party package

Re: View permissions to admin

Hi Petr, all, I managed to find some time to look into your PR (updated link: https://github.com/django/django/pull/5297) and the related issue: https://code.djangoproject.com/ticket/8936 . Also, related discussion: https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion an

Re: WIKI_VIEW privileges are required to perform this operation. You don't have the required permissions.

This issue turned out to be a bug in Trac, fixed by upgrading to the latest version. Details in https://github.com/django/code.djangoproject.com/issues/58. On Monday, August 31, 2015 at 8:35:30 AM UTC-4, Tim Graham wrote: > > Hi, as far as I know, we haven't banned anyone in Trac. We did receive

Re: WIKI_VIEW privileges are required to perform this operation. You don't have the required permissions.

Hi, as far as I know, we haven't banned anyone in Trac. We did receive a similar report in IRC last week (maybe it was you). Could you create a ticket in the code.djangoproject.com issue tracker with any more details? https://github.com/django/code.djangoproject.com/issues On Monday, August 31,

WIKI_VIEW privileges are required to perform this operation. You don't have the required permissions.

I'm getting this always when I try to use Github Login on code.djangoproject.com AFAIU I was banned there, am I right? But I never received any notification. What can I do to get me unbanned? -- You received this message because you are subscribed to the Google Groups "Django developers (Con

Re: View permissions to admin

Hello all, I am still waiting for some information about what should I do next to get this pulled into Django. Isn't here somebody willing to take a look at this? PR is at https://github.com/django/django/pull/5108 -- You received this message because you are subscribed to the Google Groups "

Re: View permissions to admin

provide review > and comment on your changes. > 2. Provide a description of what your patch is aiming to do in the pull > request comments. "view_permissions" for admin don't tell me a whole lot, > why do we need view permissions? Answering that question will help revie

Re: View permissions to admin

lot easier to provide review and comment on your changes. 2. Provide a description of what your patch is aiming to do in the pull request comments. "view_permissions" for admin don't tell me a whole lot, why do we need view permissions? Answering that question will help review. Wr

View permissions to admin

Hi, 4 months ago, I have implemented view permissions for Django admin and posted it under following ticket: https://code.djangoproject.com/ticket/8936 The patch in my branch contains tests and documentation. I am willing to give my time to make this commited to official Django branch. But I

Re: permissions and groups data migration

PM UTC-6, Adam Venturella wrote: >> >> 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 t

  1   2   3   >