Re: get_manager short ut function proposal

[Ramez Ashraf]

Mmmm I believe what you shared Shai is very sophisticated than what is
proposed.
The proposal is a shortcut function for with ability to have a custom
parent for more usability for an everyday use , like what's in the
documentation about managers.

My proposal is *not* a new way to write managers . This can be your or
someone else's fully baked idea.

With respect.

On Sun, 1 Jan 2023, 19:00 Shai Berger,  wrote:

> On Sun, 1 Jan 2023 16:33:45 +0200
> Ramez Ashraf  wrote:
>
> >
> > Interested or do you think the function can be enhanced it to make
> > more useable for your everyday other cases ?
> >
>
> This is half-baked, just a thought, but maybe you can take it some
> place interesting:
>
> Imagine a class that "collects" calls for later execution. Something
> like (this exactly won't work, details below):
>
> from functools import partialmethod
> from django.db.models import QuerySet as QSet
>
> class QS:
> def __init__(self):
> self._calls = []
> def filter(self, *args, **kw):
> self._calls.append(
> partialmethod(QSet.filter, *args, **kw)
> )
> return self
> def annotate(*args, **kw):
> # ... (same idea)
> # ... other relevant methods,
> def __call__(self, qset):
> for call in self._calls:
> qset = apply(call, qset)
> return qset
>
> This won't work, I think, because partialmethod isn't supposed to work
> quite this way, and the "apply" in the last line isn't defined. But
> with this (fixed) already you could, I think, do something like
>
> def qset_manager(qs: QS) -> Manager
> class CustomManager(models.Manager):
> def get_queryset(self):
> orig = super().get_queryset()
> return qs(orig)
> return CustomManager()
>
> And then, in your model,
>
> class Person(models.Model):
> ...
> authors = qset_manager(QS().filter(role="A"))
>
> and now the "make a manager with a modified queryset" pattern is
> shortened in a general way.
>
> As I said, just a half-baked thought. There's problems here to solve,
> and many improvements to make.
>
> HTH,
> Shai.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPtjUtg6JGLbdkcdTep-XbLVnogKg2EdJr%3DUJxP3Y0KRgmiaUA%40mail.gmail.com.

Re: get_manager short ut function proposal

[Ramez Ashraf]

Hello Adam
Happy new year!

Thank you for the feedback, really appreciate it.
I thought the same like you at first, a cool function in my project (which
is indeed the case)
One thing that gave me more incentive is the documentation code example.
IMO, i can see how shorter (and more readable) it would be with the
proposed shortcut.
In fact it's indeed simple and doesn't offer the full support a real
declared custom manager class would do. It's intended to be something like
get_object_or_404.

Interested or do you think the function can be enhanced it to make more
useable for your everyday other cases ?



On Sat, 31 Dec 2022, 12:41 'Adam Johnson' via Django developers
(Contributions to Django itself), 
wrote:

> Your proposal is quite niche: it only shortens the creation of a Manager
> class when you need to add a single filter() call. The function seems like
> it might be a useful helper within a project, if you use many such
> managers. But custom managers might use any queryset methods, or other
> logic. I've often used a custom manager to add annotate() and
> prefetch_related() calls.
>
> So, I think your shortcut is a smart addition for your project, but
> perhaps not suitable for Django itself. I think it's worth sharing in a
> blog post though!
>
> On Mon, Dec 19, 2022 at 10:51 PM Ramez Ashraf 
> wrote:
>
>> Hello everyone,
>>
>> I want to propose a helper function
>> `get_manager(parent_manager=None, *args, **kwargs)`
>>
>> A shortcut to return a manager, *args & **kwargs are passed to the
>> manager .filter()
>> pass parent_manager to customize the parent manager, defaults to
>> ``Manager``.
>>
>> it can be used like this
>>
>> from django.db.models import get_manager
>>
>> class Person(models.Model):
>> # ...
>> authors = models.get_manager(role='A')
>> editors = models.get_manager(role='E')
>> special = get_manager(~Q(name="Roald Dahl"), role='E')
>> manager_with_counts = get_manager(parent_manager=PollManager,
>> name="Roald Dahl")
>>
>> Instead of the current
>>
>> class AuthorManager(models.Manager):
>> def get_queryset(self):
>> return super().get_queryset().filter(role='A')
>>
>> class EditorManager(models.Manager):
>> def get_queryset(self):
>> return super().get_queryset().filter(role='E')
>>
>> class Person(models.Model):
>> people = models.Manager()
>> authors = AuthorManager()
>> editors = EditorManager()
>>...
>>
>> The first is more readable and nicer .. yeah ?
>> Code is working and ready at  github
>> <https://github.com/django/django/compare/main...RamezIssac:django:feature/get_manager_shortcut>
>>  ,
>>
>> Do i get +1(s) to move forward and create a ticket ?
>>
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/f0e4367d-8a7e-48da-b78c-35036015212fn%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/f0e4367d-8a7e-48da-b78c-35036015212fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/CISeAzzESHA/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0Jk%3DYsXQVRydaanmg%3DP_wMMmg%2B4uPETSvEXs3jFgCB%2BQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM0Jk%3DYsXQVRydaanmg%3DP_wMMmg%2B4uPETSvEXs3jFgCB%2BQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPtjUth2XV-RajOfkj95C%2Bzy7tuQy%2B%3DzP8W5CMpxPB%2B9gkkpNg%40mail.gmail.com.

get_manager short ut function proposal

[Ramez Ashraf]

Hello everyone, 

I want to propose a helper function
`get_manager(parent_manager=None, *args, **kwargs)` 

A shortcut to return a manager, *args & **kwargs are passed to the manager 
.filter()
pass parent_manager to customize the parent manager, defaults to 
``Manager``.

it can be used like this 

from django.db.models import get_manager

class Person(models.Model):
# ...
authors = models.get_manager(role='A')
editors = models.get_manager(role='E')
special = get_manager(~Q(name="Roald Dahl"), role='E')
manager_with_counts = get_manager(parent_manager=PollManager, 
name="Roald Dahl")

Instead of the current 

class AuthorManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(role='A')

class EditorManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(role='E')

class Person(models.Model):
people = models.Manager()
authors = AuthorManager()
editors = EditorManager()
   ...

The first is more readable and nicer .. yeah ?
Code is working and ready at  github 

 ,  

Do i get +1(s) to move forward and create a ticket ? 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f0e4367d-8a7e-48da-b78c-35036015212fn%40googlegroups.com.

Re: Permissions don't get translated in admin interface

[Ramez Ashraf]

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.
For Django core, it think its very hard to do it as one can also have more 
than one non English of languages supported .. which permission language 
will be recorded in the database then ?

Screen shot for tabular permissions
[image: tabular_permisions.png]

On Sunday, September 25, 2022 at 3:07:27 AM UTC+2 baido...@gmail.com wrote:

> 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 + 
>> gettext( ‘can’) + gettext(view/change/delete) and it should be translated.
>>
>> With custom translation is a little bit  more work, but it also works. 
>>
>> I am not sure, that if override of __str__ helps, but it also possible.
>>
>>  
>>
>>  
>>
>> By the way - My solution DJANGO-TOF 2.version solves you ask without any 
>> changes in code.
>>
>> I‘ve presented it on last Django con 2022
>>
>> We works with permissions and also custom permissions already long time 
>> in Multilanguage Project and I don’t see any problem with that.
>>
>>  
>>
>>  
>>
>> Mit freundlichen Grüßen,
>>
>> DI Mag. Maxim Danilov
>>
>>  
>>
>> +43(681)207 447 76
>>
>> ma...@wpsoft.at
>>
>>  
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
>> *On Behalf Of *Thibaud Colas
>> *Sent:* Saturday, September 24, 2022 9:25 AM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* 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  reconsidered, as 
>> to me it seems like a clear bug, which affects a lot of users. Though not 
>> many people might be managing permissions regularly, when you do, it’s very 
>> jarring that the text is in the wrong language.
>>
>>  
>>
>> I’m not sure what Django’s stance is on supporting non-english users 
>> generally, but based on our diversity statement I feel like "100% of the 
>> admin UI translated" is an important goal – and looking at Transifex 
>> , there are a lot of 
>> people putting in a lot of effort to get it there. If this is a wontfix 
>> because the store-label-in-DB approach is effectively impossible to make 
>> work, then I think this would be worth clearing documenting on the 
>> Localizing 
>> Django 
>>  
>> page so translators know what to expect. Ideally also mention elsewhere in 
>> a place visible to end users.
>>
>>  
>>
>> ---
>>
>>  
>>
>> From a technical perspective, this is far from my area of expertise but 
>> as I understand there are clear solutions – one that’s "quick and dirty" 
>> would be to hard-code a list of gettext_lazy calls with the same labels as 
>> stored in the DB for the purpose of collecting the labels for PO files, and 
>> then we could use {% translate %} over the DB-provided values anyway. No 
>> change to the DB needed. I count 8 Django-provided models in my demo site 
>> (might be missing others), each has 4 Django-provided permissions, so 
>> that’s 32 strings to hard-code. Feels doable!
>>
>>  
>>
>>  
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8e14c59f-3331-401a-85a1-cbf27d49fe65n%40googlegroups.com
>>  
>> 
>> .
>>
>> -- 
>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/01d8d064%24f9d25dd0%24ed771970%24%40wpsoft.at
>>  
>> 

Re: Digest for django-developers@googlegroups.com - 2 updates in 1 topic

[Ramez Ashraf]

I almost never use `id` and always use `pk`.. at least whenever possible.
It gives me more freedom and sets a normalisation to code logic.
Very *very* useful 

On Fri, 28 Jan 2022, 05:40 ,  wrote:

> django-developers@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Topic digest
> View all topics
> 
>
>- Deprecation of using pk in public ORM API
><#m_-3825817018666023648_group_thread_0> - 2 Updates
>
> Deprecation of using pk in public ORM API
> 
> Albert : Jan 26 10:46AM +0100
>
> Hello all,
>
> I would like to know your opinion about deprecation of using "pk"
> alias in filters and other places of public ORM API.
> I use Django long time and never use "pk" because in my opinion
> it is misleading.
> I mean, instead:
> Car.objects.filter(pk=1)
> I use
> Car.objects.filter(id=1)
> Insted car.pk I use car.id
>
> From SQL point of view it doesn't matter because it is always:
> SELECT * FROM car WHERE id=1
>
> It am not sure if using "pk" gives value to users. Field "pk" is not
> defined by user.
>
> But from our, django developers, point of view we need to do extra work to
> support it.
>
> I think that "pk" could be only a private attribute of a model
> ("_pk") and only for internal use or avoid using it at all.
> I think it would give us more flexibility to develop/improve orm.
>
> What do you think?
>
> Regards,
> Albert Defler
> "Curtis Maloney" : Jan 28 10:24AM +1100
>
> Hello Mike,
>
> On Wed, 26 Jan 2022, at 20:46, Albert wrote:
> > I use
> > Car.objects.filter(id=1)
> > Insted car.pk I use car.id
>
> AIUI the purpose of the `pk` alias is you can't assume the primary key
> will always be named `id`.
>
> Knowing you can always refer to `pk` allows more generic query
> construction.
>
> This is used, for example, in the generic views.
>
> > SELECT * FROM car WHERE id=1
>
> > It am not sure if using "pk" gives value to users. Field "pk" is not
> > defined by user.
>
> No, but the model's primary key field might be, which is the point.
>
> --
> Curtis
> Back to top <#m_-3825817018666023648_digest_top>
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> 
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to django-developers+unsubscr...@googlegroups.com.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPtjUtgRSSWJzp1oxr5GWYCd3yzm0vZq-%3DXV198e_9Rujyg2aQ%40mail.gmail.com.

Re: Admin change list header for languages with grammatical cases

[Ramez Ashraf]

Yep Confirm.

On Monday, May 24, 2021 at 10:52:15 PM UTC+2 macie...@gmail.com wrote:

> Thank you Ramez,
>
> Could you confirm that grammatical case in Arabic in case of this sentence 
> ("Select {}") it is an accusative (المنصوب)?
>
> https://arabic.desert-sky.net/g_cases.html#acc
>
> Kind regards,
> Maciej
>
> pon., 24 maj 2021 o 10:18 Ramez Ashraf  napisał(a):
>
>> Thank you for bringing this up
>>
>> Arabic is one of those language, the issue comes with masculine and 
>> feminine nouns.
>> " Select {model} to change"
>> If model noun is masculine then it's ok... if a feminine one then it's 
>> not correct.
>>
>> Example: 
>> Correct أختر مقال لتغييره 
>> Wrong/awkward  اختر هيئه لتغييره 
>> should be اختر هيئه لتغييرها
>>
>> i work around that by adding both .لتغييره(ها)
>> An other approach is change the text to 
>> Select {model} *record* to change
>> Because now change verb will be to a record which is a masculine noun 
>> regardless of the model.
>>
>> Thanks for bringing this up again.
>>
>> On Saturday, May 22, 2021 at 2:54:50 AM UTC+2 macie...@gmail.com wrote:
>>
>>> I forgot to mention that my implementation extensively uses gettext 
>>> context functionality [1]. I am happy to comment on and discuss particular 
>>> parts of the implementation.
>>>
>>> The implementation is quite general, it does not limit the use of 
>>> attributes and contexts to only grammatical cases.
>>>
>>> I decided to use "*accusative*" for attribute and context name hoping 
>>> that all languages will use base verbose name case or accusative 
>>> grammatical case. But on the other hand context/attribute name "*changelist 
>>> title*" would be probably equally good (the former would be better, if 
>>> there would be more uses than in changelist title only).
>>>
>>> I think there comes natural expectation that similar mechanism would 
>>> work also in Django templates. That may be impossible because of dynamic 
>>> nature of this feature and serialization needed for safety and portability 
>>> in templates, although I'm not yet 100% sure.
>>>
>>> Regards,
>>> Maciej
>>>
>>> [1] 
>>> https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers
>>>
>>> sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):
>>>
>>>> Admin’s change list headers are “Select {model} to change”, “Select 
>>>> {model} to view” or “Select {model}” (for pop-ups). We inject model’s 
>>>> verbose name in that strings. It renders correct strings for most of the 
>>>> languages, but not for those, which have grammatical cases [1] for nouns. 
>>>> Such languages include Polish, Greek, Russian, Hungarian, Czech and many 
>>>> more.
>>>>
>>>> I try to track how many of languages are affected for selected nouns in 
>>>> a spreadsheet [2] with help of Google Translate.
>>>>
>>>> To make the headers correct for this languages we should inject a 
>>>> verbose name into “Select {}[…]” sentences in a correct grammatical case. 
>>>> Effectively it is usually a word with changed ending comparing to a base 
>>>> form of a noun (verbose name value).
>>>>
>>>> I’d like to propose a backwards compatible way to support an ability to 
>>>> provide a translation for a grammatical case of model’s verbose name and 
>>>> “selecting” to use it in a translation string.
>>>>
>>>> In short the implementation requires:
>>>>
>>>>- switching from %-string formatting to format-strings in admin’s 
>>>>changelist headers source strings,
>>>>- adding a class that will behave like string, but also let access 
>>>>it’s attributes,
>>>>- leveraging accessing attributes in Python format-string syntax.
>>>>
>>>> You can see here the implementation concluded in 7 commits: 
>>>> https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2
>>>>
>>>> I don’t have enough means to confirm it for all languages, but my 
>>>> cursory research says that probably the case used in “Select {}” sentence 
>>>> is an *accusative* for all languages that have grammatical cases.
>>>>
>>>> I would like that feature to be in Django as currently the admin 
>>>> changeli

Re: Admin change list header for languages with grammatical cases

[Ramez Ashraf]

Thank you for bringing this up

Arabic is one of those language, the issue comes with masculine and 
feminine nouns.
" Select {model} to change"
If model noun is masculine then it's ok... if a feminine one then it's not 
correct.

Example: 
Correct أختر مقال لتغييره 
Wrong/awkward  اختر هيئه لتغييره 
should be اختر هيئه لتغييرها

i work around that by adding both .لتغييره(ها)
An other approach is change the text to 
Select {model} *record* to change
Because now change verb will be to a record which is a masculine noun 
regardless of the model.

Thanks for bringing this up again.

On Saturday, May 22, 2021 at 2:54:50 AM UTC+2 macie...@gmail.com wrote:

> I forgot to mention that my implementation extensively uses gettext 
> context functionality [1]. I am happy to comment on and discuss particular 
> parts of the implementation.
>
> The implementation is quite general, it does not limit the use of 
> attributes and contexts to only grammatical cases.
>
> I decided to use "*accusative*" for attribute and context name hoping 
> that all languages will use base verbose name case or accusative 
> grammatical case. But on the other hand context/attribute name "*changelist 
> title*" would be probably equally good (the former would be better, if 
> there would be more uses than in changelist title only).
>
> I think there comes natural expectation that similar mechanism would work 
> also in Django templates. That may be impossible because of dynamic nature 
> of this feature and serialization needed for safety and portability in 
> templates, although I'm not yet 100% sure.
>
> Regards,
> Maciej
>
> [1] 
> https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers
>
> sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):
>
>> Admin’s change list headers are “Select {model} to change”, “Select 
>> {model} to view” or “Select {model}” (for pop-ups). We inject model’s 
>> verbose name in that strings. It renders correct strings for most of the 
>> languages, but not for those, which have grammatical cases [1] for nouns. 
>> Such languages include Polish, Greek, Russian, Hungarian, Czech and many 
>> more.
>>
>> I try to track how many of languages are affected for selected nouns in a 
>> spreadsheet [2] with help of Google Translate.
>>
>> To make the headers correct for this languages we should inject a verbose 
>> name into “Select {}[…]” sentences in a correct grammatical case. 
>> Effectively it is usually a word with changed ending comparing to a base 
>> form of a noun (verbose name value).
>>
>> I’d like to propose a backwards compatible way to support an ability to 
>> provide a translation for a grammatical case of model’s verbose name and 
>> “selecting” to use it in a translation string.
>>
>> In short the implementation requires:
>>
>>- switching from %-string formatting to format-strings in admin’s 
>>changelist headers source strings,
>>- adding a class that will behave like string, but also let access 
>>it’s attributes,
>>- leveraging accessing attributes in Python format-string syntax.
>>
>> You can see here the implementation concluded in 7 commits: 
>> https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2
>>
>> I don’t have enough means to confirm it for all languages, but my cursory 
>> research says that probably the case used in “Select {}” sentence is an 
>> *accusative* for all languages that have grammatical cases.
>>
>> I would like that feature to be in Django as currently the admin 
>> changelist header translation, with model name not inflected, in Polish 
>> (“Wybierz użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd 
>> assume for other such languages the situation is similar. Bringing 
>> grammatical cases there would be a great step towards perfection (that 
>> should attract perfectionists :) ) in admin for languages like Czech, 
>> Greek, Hungarian and many more.
>>
>> I didn’t post a ticket nor created a pull request yet, as I’d like to 
>> consult it with the community beforehand, according to the best practices.
>>
>> Would you accept such a functionality in the Django project?
>>
>> Best regards,
>> Maciej Olko
>>
>> PS. There is a ticket about bringing gettext plurals into model’s verbose 
>> name [3] loosly connected with this particular topic, but the discussion 
>> underneath touches also the topic of grammatical cases.
>>
>> [1] https://en.wikipedia.org/wiki/Grammatical_case
>> [2] 
>> https://docs.google.com/spreadsheets/d/1GfdCMvqCdg1c2fTf940r8yEnCiXr9s86p0JbGRV4Aio
>> [3] https://code.djangoproject.com/ticket/11688
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: Translation of group permissions

[Ramez Ashraf]

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 and to address the fact that it's is not 
very user friendly especially when we have an increased number of models 
https://github.com/RamezIssac/django-tabular-permissions
*Disclaimer: i'm the author of this library.*
 

On Saturday, May 22, 2021 at 9:04:17 AM UTC+2 fran.h...@gmail.com wrote:

> I ran into this same issue last week. That ticket raises a valid question 
> IMHO: why even save permission descriptions in the DB? 
>
> Anyone seeing any downsides of the proposed approach to fetch the 
> descriptions from code (and apply translation on the fly)?
>
> Fran
>
> On 22.05.2021., at 02:08, macie...@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 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 receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/da4f96c9-d780-4dde-8ae8-d6c7f0ef59b7n%40googlegroups.com
>  
> 
> .
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c08b5352-1b13-4b47-9ead-04f590a6defdn%40googlegroups.com.

Multi theme support for admin

[Ramez Ashraf]

Hello Django Developers list

I'm sending on this thread to hopefully open a discussion about
*Adding the ability for a multi custom theme in Django's Admin*.

*What do i mean ?*
We can have many multiple Django admin sites 
,
 
where each site can have its registered models, apps, admin views, etc.. ok?
However, 
Those different admin sites are limited to one interface/html structure, 
located at `tempates/admin`. A change in one admin site base.html will 
affect the other admin sites.

*Proposal:*
A way to direct each AdminSite to the template path where it should find 
the templates.

*Example:*
Add a setting called ADMIN_DEFAULT_THEME = 'admin'
Add an attribute to AdminSite called theme which default to 
ADMIN_DEFAULT_THEME, and basically this setting controls which directory 
this admin site look for templates.
So whenever a path like 'admin/some_file_name.html' occurs, it is to be 
replaced with something like f'{admin_theme}/some_file_name.html'
This will take effect in extends statements, AdminSite templates 
loading(index/app index / etc) and ModelAdmin template loading (change 
form/list/delete etc..)

*Use case:*
You want to be able to use the django admin default theme along with 
something like django-jazzmin  
along 
with Grappelli  or django-suit 
.

*Final thoughts:*
* I see no real reason why we should not implement this.
* I sits well with the multi admin site idea. If we can have several 
different sites then they should be able to look different . 
* This open the door for admin theme to be something plug and play which in 
my opinion have some interesting nice outcomes

Finally, Thank you for your time reading this and i hope you support it or 
engage in a discussion.
Looking forward for your replies .. 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f96a4b22-3ce3-4031-a97a-d3b406d788ccn%40googlegroups.com.

Re: New Feature discussion: making admin app & model url configurable

[Ramez Ashraf]

Taking it off from Collin's crucial suggestion
https://github.com/django/django/pull/10111

Implement it as an AdminSite method, Which, after some thoughts, i think
it's fair that if one wants to customize the admin urls, then they should
sub class the AdminSite,
Also i believe for developers relying "heavily" on the admin (those who
will actually use of this feature), they already did sub class AdminSite
for one reason or the other.



On Fri, Jun 29, 2018 at 5:09 PM Ramez Ashraf  wrote:

> Another comment, if i may, about the implementation after some thoughts
>
> 1- it does not customize the app_index url
> 2- as a consequence, the "uniformity" the admin urls may be broken
> So maybe there is a way, that this method `get_urls_for_model` get changed
> to include both the app_index, and the models customization ?
>
> Finally, taking the app_index url into account,it would suggest that this
> method lives on the AdminSite (*not in the ModelAdmin*)
>
> Thank you so much for your appreciated cooperation Collin
>
>
>
> On Fri, Jun 29, 2018 at 4:23 PM Ramez Ashraf 
> wrote:
>
>> Sure that's a great idea Colin !
>>
>> I'm little greedy, I wanted to make it little easier, ie without needing
>> to subclass the AdminSite... But that's absolutely great implementation too!
>>
>> On Fri, Jun 29, 2018, 4:07 PM Collin Anderson 
>> wrote:
>>
>>> Maybe we could make an AdminSite.get_urls_for_model(self, model,
>>> model_admin)
>>>
>>> https://github.com/django/django/pull/10108/files
>>>
>>> On Fri, Jun 29, 2018 at 8:57 AM  wrote:
>>>
>>>> Personally, I'm not sure I see that much value. As I see it, the admin
>>>> is intended for technical users, not as a general admin interface for end
>>>> users (in this context I'm mostly talking about non-programmers). While it
>>>> can and I sometimes do allow end-users to use the admin directly, I really
>>>> feel like it's not the intended use.
>>>>
>>>> I'm also not really sure what modifying the URLs would achieve, since
>>>> users aren't likely to be typing them in directly, anyway.
>>>>
>>>> Tom
>>>>
>>>> On Friday, June 29, 2018 at 10:49:26 AM UTC+1, Ramez Ashraf wrote:
>>>>>
>>>>> Hello guys,
>>>>>
>>>>> I use the admin quite extensively in my work with Django, and it's
>>>>> awesome.
>>>>> One place that can use some polish is the urls.
>>>>> As you know, the admin urls evolve around are the  /
>>>>>  , and those two can get technical, long and in short not user
>>>>> friendly.
>>>>> Hence, I propose a new feature of making those urls configurable
>>>>>
>>>>> First of all, what do you think ? Would you benefit from this new
>>>>> feature? and mainly i'm asking devs with extensive use of the admin.
>>>>>
>>>>> Now for the technical part:
>>>>> The idea was initially is to state those configuration around the
>>>>> AppConfig (for the app part of the url) and in the model meta (for the
>>>>> model part)
>>>>> I got a review from Tim, that he don't like the idea of the meta, and
>>>>> i can kinda agree with his point, and so, where do you suggest stating 
>>>>> this
>>>>> configuration?
>>>>>
>>>>> Another idea that cross my mind now, is to state those configuration
>>>>> in the `settings.py`, something like this
>>>>>
>>>>> ADMIN_URLS = {
>>>>> 'apps': {
>>>>> 'celery_queue_tools': 'cool-app-name'
>>>>> },
>>>>> 'models': {
>>>>>'mylongmodelname': 'user-friendly'
>>>>> }
>>>>> }
>>>>>
>>>>> This is just another idea of where to write the url customization
>>>>> configuration, all is up for discussion.
>>>>>
>>>>> Thank you all and awaiting your feedback.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> 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+unsubscr...@googlegroups.com.
>>>> To post to this group, send emai

Re: New Feature discussion: making admin app & model url configurable

[Ramez Ashraf]

Another comment, if i may, about the implementation after some thoughts

1- it does not customize the app_index url
2- as a consequence, the "uniformity" the admin urls may be broken
So maybe there is a way, that this method `get_urls_for_model` get changed
to include both the app_index, and the models customization ?

Finally, taking the app_index url into account,it would suggest that this
method lives on the AdminSite (*not in the ModelAdmin*)

Thank you so much for your appreciated cooperation Collin



On Fri, Jun 29, 2018 at 4:23 PM Ramez Ashraf  wrote:

> Sure that's a great idea Colin !
>
> I'm little greedy, I wanted to make it little easier, ie without needing
> to subclass the AdminSite... But that's absolutely great implementation too!
>
> On Fri, Jun 29, 2018, 4:07 PM Collin Anderson 
> wrote:
>
>> Maybe we could make an AdminSite.get_urls_for_model(self, model,
>> model_admin)
>>
>> https://github.com/django/django/pull/10108/files
>>
>> On Fri, Jun 29, 2018 at 8:57 AM  wrote:
>>
>>> Personally, I'm not sure I see that much value. As I see it, the admin
>>> is intended for technical users, not as a general admin interface for end
>>> users (in this context I'm mostly talking about non-programmers). While it
>>> can and I sometimes do allow end-users to use the admin directly, I really
>>> feel like it's not the intended use.
>>>
>>> I'm also not really sure what modifying the URLs would achieve, since
>>> users aren't likely to be typing them in directly, anyway.
>>>
>>> Tom
>>>
>>> On Friday, June 29, 2018 at 10:49:26 AM UTC+1, Ramez Ashraf wrote:
>>>>
>>>> Hello guys,
>>>>
>>>> I use the admin quite extensively in my work with Django, and it's
>>>> awesome.
>>>> One place that can use some polish is the urls.
>>>> As you know, the admin urls evolve around are the  /
>>>>  , and those two can get technical, long and in short not user
>>>> friendly.
>>>> Hence, I propose a new feature of making those urls configurable
>>>>
>>>> First of all, what do you think ? Would you benefit from this new
>>>> feature? and mainly i'm asking devs with extensive use of the admin.
>>>>
>>>> Now for the technical part:
>>>> The idea was initially is to state those configuration around the
>>>> AppConfig (for the app part of the url) and in the model meta (for the
>>>> model part)
>>>> I got a review from Tim, that he don't like the idea of the meta, and i
>>>> can kinda agree with his point, and so, where do you suggest stating this
>>>> configuration?
>>>>
>>>> Another idea that cross my mind now, is to state those configuration in
>>>> the `settings.py`, something like this
>>>>
>>>> ADMIN_URLS = {
>>>> 'apps': {
>>>> 'celery_queue_tools': 'cool-app-name'
>>>> },
>>>> 'models': {
>>>>'mylongmodelname': 'user-friendly'
>>>> }
>>>> }
>>>>
>>>> This is just another idea of where to write the url customization
>>>> configuration, all is up for discussion.
>>>>
>>>> Thank you all and awaiting your feedback.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/d6c3b94e-3bcd-49b5-b1b5-1c93c381ec11%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/d6c3b94e-3bcd-49b5-b1b5-1c93c381ec11%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/H8y6_HOKU2o/unsubscribe
>> .
>> To unsubsc

Re: New Feature discussion: making admin app & model url configurable

[Ramez Ashraf]

Sure that's a great idea Colin !

I'm little greedy, I wanted to make it little easier, ie without needing to
subclass the AdminSite... But that's absolutely great implementation too!

On Fri, Jun 29, 2018, 4:07 PM Collin Anderson  wrote:

> Maybe we could make an AdminSite.get_urls_for_model(self, model,
> model_admin)
>
> https://github.com/django/django/pull/10108/files
>
> On Fri, Jun 29, 2018 at 8:57 AM  wrote:
>
>> Personally, I'm not sure I see that much value. As I see it, the admin is
>> intended for technical users, not as a general admin interface for end
>> users (in this context I'm mostly talking about non-programmers). While it
>> can and I sometimes do allow end-users to use the admin directly, I really
>> feel like it's not the intended use.
>>
>> I'm also not really sure what modifying the URLs would achieve, since
>> users aren't likely to be typing them in directly, anyway.
>>
>> Tom
>>
>> On Friday, June 29, 2018 at 10:49:26 AM UTC+1, Ramez Ashraf wrote:
>>>
>>> Hello guys,
>>>
>>> I use the admin quite extensively in my work with Django, and it's
>>> awesome.
>>> One place that can use some polish is the urls.
>>> As you know, the admin urls evolve around are the  /
>>>  , and those two can get technical, long and in short not user
>>> friendly.
>>> Hence, I propose a new feature of making those urls configurable
>>>
>>> First of all, what do you think ? Would you benefit from this new
>>> feature? and mainly i'm asking devs with extensive use of the admin.
>>>
>>> Now for the technical part:
>>> The idea was initially is to state those configuration around the
>>> AppConfig (for the app part of the url) and in the model meta (for the
>>> model part)
>>> I got a review from Tim, that he don't like the idea of the meta, and i
>>> can kinda agree with his point, and so, where do you suggest stating this
>>> configuration?
>>>
>>> Another idea that cross my mind now, is to state those configuration in
>>> the `settings.py`, something like this
>>>
>>> ADMIN_URLS = {
>>> 'apps': {
>>> 'celery_queue_tools': 'cool-app-name'
>>> },
>>> 'models': {
>>>'mylongmodelname': 'user-friendly'
>>> }
>>> }
>>>
>>> This is just another idea of where to write the url customization
>>> configuration, all is up for discussion.
>>>
>>> Thank you all and awaiting your feedback.
>>>
>>>
>>>
>>>
>>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d6c3b94e-3bcd-49b5-b1b5-1c93c381ec11%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/d6c3b94e-3bcd-49b5-b1b5-1c93c381ec11%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/H8y6_HOKU2o/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFO84S5WV7K_A1ZWqAVcXc85%3D5UZtHp_txm_rVmuvMDitNDwmg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFO84S5WV7K_A1ZWqAVcXc85%3D5UZtHp_txm_rVmuvMDitNDwmg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPtjUtiE3kTb7HYO9h3o2NYrHot0PpYDT9HBL3g25sccbDniFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

New Feature discussion: making admin app & model url configurable

[Ramez Ashraf]

Hello guys, 

I use the admin quite extensively in my work with Django, and it's awesome.
One place that can use some polish is the urls.
As you know, the admin urls evolve around are the  /  
 , and those two can get technical, long and in short not user 
friendly.
Hence, I propose a new feature of making those urls configurable

First of all, what do you think ? Would you benefit from this new feature? 
and mainly i'm asking devs with extensive use of the admin.

Now for the technical part:
The idea was initially is to state those configuration around the AppConfig 
(for the app part of the url) and in the model meta (for the model part)
I got a review from Tim, that he don't like the idea of the meta, and i can 
kinda agree with his point, and so, where do you suggest stating this 
configuration?

Another idea that cross my mind now, is to state those configuration in the 
`settings.py`, something like this 

ADMIN_URLS = {
'apps': {
'celery_queue_tools': 'cool-app-name'
}, 
'models': {
   'mylongmodelname': 'user-friendly'
}
}

This is just another idea of where to write the url customization 
configuration, all is up for discussion.

Thank you all and awaiting your feedback.




-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/712bbe7e-91ed-4f63-89c6-f572e2cdfc48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Permissions Scheme

[Ramez Ashraf]

>
>
> 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 solution can be implemented 
by each developer in their project if they dislike how the current 
permission work or it is simply not enough for them.

So maybe we can be satisfied with the current Permission implementation for 
some more time.

Hopefully this idea -customizing permissions by changing the ModelBackend 
Authentication , leaving the current Permission as it is-  might come in 
handy if anyone is not satisfied with the Django Permissions . 
It can also be stated *more clearly* in the docs.

Greetings to you all.





-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d69c8163-b57e-4771-b7c0-d66ffbe7faa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Permissions Scheme

[Ramez Ashraf]

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 permission (for example) , with my approach, the
developer would have to change the Base model the Permission is inheriting
from (Or go and swap the model all together as with user).
With the new advice from Django to create own user model at the start of
each project (even if it's not needed), maybe we will start see more
Swapped Users models then what we see now.

Permission like `can_do_something` will (and should) still be supported.

Regarding User.has_perm, i think the method can be enhanced to accept model
instance, or model_name and the action name. along side with the current
implementation.

My Approach will -of course- help with the translation as it there is no
strings in the database.
Also the idea is about how to make the permissions flexible, to give the
developers more accurate control.
Again with this approach,  the developer can add extra field(s) to the
"model permission" which can be anything which he/she can use.
I'll make a repo soon for demonstration.


On Thu, Sep 21, 2017 at 11:19 PM, ludovic coues <cou...@gmail.com> wrote:

> 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 production code using permission like is_something.
> Yeah, sure, it's not semantically correct. Being a bot or a moderator
> or a senior user is not a permission. But current permission system
> work nicely for that kind of stuff.
>
> Yeah, sure, people can swap the model like with user. But I have seem
> more often code adding a foreign key pointing to the user rather than
> swapping the model. I doubt that kind of solution will work with stuff
> like user.has_perm().
>
> In a nutshell, what you propose will break a lot of code, require more
> work from developer, won't really help with translation and the only
> help with the widget because you are cutting most of the useful stuff
> out of the permission system.
>
> 2017-09-21 22:14 GMT+02:00 Ramez Ashraf <ramezash...@gmail.com>:
> > Good day dear fellow Django developers,
> >
> > Current permissions scheme in Django does suffer many flaws
> > Like Inconsistency with permissions for proxy models #11154 and the fact
> > that permission names are not translatable (no translation in the
> database)
> > and the Permission Widget (FilteredSelect) is not very user friendly if
> we
> > have a lot of models.
> > Some of these issues have some work around like gists creating correct
> > permissions for proxy models, widgets to display the permissions in a
> > translated Tabular format (django-tabular-permissions)
> > But the problems are still there.
> > And the current implementation in itself is some what naive, only add ,
> > change , delete
> > Maybe i can delete only the records created by me, maybe i can delete but
> > not older then 1 day unless i'm superuser
> >
> > I want to suggest a complete Permission makeover
> > Basically a new model / db table for User permissions which look
> something
> > like this (and another one for the groups of course.)
> >
> > user_id | contenttype_id | add  | change| delete
> > 1   | 1  | True | True| False
> >
> > The new model can be swap-able (like the User model) so end developers
> might
> > add more specified fields beside the add , change,  delete like (can edit
> > other users entries, limit to date etc.)
> > It might be also advised to create your own Permission model at the
> start of
> > the project (like what is happening now with the user model)
> >
> > And the current Permissions table can be used for the custom permissions
> .
> >
> > I understand that this is might not be the most backward compatible
> solution
> > (although if accepted by you, we can figure this out, using data
> migrations
> > or something)
> >
> > But Permissions in Django have been dragging for far too long, and
> delaying
> > fixing them if not helping.
> > I see the new simplified url (and letting go of the regular expressions-
> at
> > least up front) and i say wow, things can change. :-)
> >
> > Looking forward for your much appreciated input, ideas & discussion.
> >
> > Thank you for your time re

New Permissions Scheme

[Ramez Ashraf]

Good day dear fellow Django developers,

Current permissions scheme in Django does suffer many flaws
Like Inconsistency with permissions for proxy models #11154 
 and the fact that permission 
names are not translatable (no translation in the database) and the 
Permission Widget (FilteredSelect) is not very user friendly if we have a 
lot of models.
Some of these issues have some work around like gists creating correct 
permissions for proxy models, widgets to display the permissions in a 
translated Tabular format (django-tabular-permissions)
But the problems are still there. 
And the current implementation in itself is some what naive, only add , 
change , delete 
Maybe i can delete only the records created by me, maybe i can delete but 
not older then 1 day unless i'm superuser

I want to suggest a complete Permission makeover
Basically a new model / db table for User permissions which look something 
like this (and another one for the groups of course.)

user_id | contenttype_id | add  | change| delete
1   | 1  | True | True| False

The new model can be swap-able (like the User model) so end developers 
might add more specified fields beside the add , change,  delete like (can 
edit other users entries, limit to date etc.) 
It might be also advised to create your own Permission model at the start 
of the project (like what is happening now with the user model) 

And the current Permissions table can be used for the custom permissions .

I understand that this is might not be the most backward compatible 
solution (although if accepted by you, we can figure this out, using data 
migrations or something)

But Permissions in Django have been dragging for far too long, and delaying 
fixing them if not helping. 
I see the new simplified url (and letting go of the regular expressions- at 
least up front) and i say wow, things can change. :-)

Looking forward for your much appreciated input, ideas & discussion.

Thank you for your time reading this and Best wishes to all of you.


Ramez






-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bbdf1910-6b89-4568-8c1b-a681b5807871%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Ramez Ashraf]

Like what is "site front end" that the admin shouldn't replace ?!
I work with business application where clients puts data in and get reports 
back... (Like Sales/Store/Client balances and stuff)
I tried to work "my front end" (after getting the bad/wrong message from 
the docs) but it was so much time and mess and so much like re-inventing 
the wheel really.

The admin have lots of capabilities that does not yet exist in any other 
parts or CBV
To name a few:
1. Inlines  (FormView is like a teenager playing in the park next to 
Spartan Hero)
2. Entry Log change message 
3. Various 3rd party support (ex: django-reversion)
4. Changelist filters / search / table sort
5. Change form (save,save and continue, save and add another)
6. Delete confirmation displaying related objects that will get deleted 
along (though sometimes big and heavy)
.. the list can easily get much bigger.

And now with custom admin sites, we can get rid of the is_staff check, get 
rid of unrelated 3rd party app registered models (which might be only 
visible to staff indeed), override the templates and have a completely new 
look .

I think the admin should be seen as the "Best django-inc" way to manipulate 
data to your database, and get advertised as such.
Not "intended to use by only management", but to anyone with access to 
add/change/delete to a model.

IMHO, If there is some enhancement to do for the admin.. i think this 
should be it, along with more documentation/ how-to's & examples.


Thank you and kind regards

On Wednesday, February 10, 2016 at 1:25:20 AM UTC+2, Tim Graham wrote:
>
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata in your model to provide a powerful and 
>> production-ready interface that content producers can immediately use to 
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata from your models to provide a quick and 
>> rudimentary interface where trusted users can manage content on your site. 
>>
>>
>> The admin has many hooks for customization but beware of trying to use 
>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>> may be simpler to write your own views. The admin’s recommended use is as 
>> an organization’s internal management tool. It’s not intended for building 
>> your entire front end around."
>>
>
> However several reviewers have made comments like "I worry that the 
> description of the Admin sells it short. The Admin is actually brilliant 
> kit and works as advertised." and "Downgrading Django's admin from 
> "powerful and production ready" to "quick and dirty [old wording]" is very 
> harsh... And I fear this will not only lower user's expectations, but also 
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of 
> adding hook after hook for customizing every little thing. I worry we'll 
> end up with an unmaintainable mess at some point. The latest proposal that 
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by() 
> for the use case of disabling sorting of a column in the change list [2]. 
> This topic also came up in the discussion of whether or not to add 
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
> yet). There's also an open question about whether or not to add a view 
> permission [4]. I don't want to discuss each of these decisions on this 
> thread but rather the broader question of whether putting a lot of effort 
> in this area is a direction we should pursue. I know there have been some 
> proposals of "admin2" but realistically I think the admin has too many 
> customizations points such that superseding it with something new and 
> innovative won't be feasible from a backwards compatibility standpoint.
>
> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3] 
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4] 
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/540baeb0-7f5a-4f45-b92c-ec4ce1979972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[Ramez Ashraf]

That's a solution :-) Thanks!
I personally create my projects/apps via a script with customized templates.

But for new comers, they will suffer from adding "_app" to their main app.
I know i did at one point.:-)

All the best.


On Tue, Mar 15, 2016 at 2:26 AM, Curtis Maloney <cur...@tinbrain.net> wrote:

> Well, you could use:
>
> mkdir my_client_name
> django-admin startproject project my_client_name/
>
> So it will create my_client_name/project/settings.py, and leave the
> namespace clear for you to create my_client_name/my_client_name/ as your
> app...
>
> --
> Curtis
>
>
>
> On 15/03/16 10:51, Ramez Ashraf wrote:
>
>> May i add to the proposal suffixing the project_name inner directory
>> (the one containing settings.py) with '_proj'
>> Usually i start project called 'my_client_name', then i want an app
>> called 'my_client_name' too,
>> usually i do NOT want my main app called "my_client_name_app"..  table
>> names just looks ugly and unnecessarily long in this case.
>> Nor i want my main/parent directory to be called "my_client_name_proj" ,
>> unnecessarily long for nginx/uwsgi/other paths.
>>
>>
>> tl;dr
>> project_name/
>>..
>>project_name+ "_proj"/
>>app1/
>>..
>>
>> Regards;
>>
>>
>>
>> On Saturday, March 12, 2016 at 6:29:55 PM UTC+2, is_null wrote:
>>
>> Hi all,
>>
>> There's a pattern I like to use in my projects which I'd like to
>> suggest for django startproject.
>>
>> It looks like:
>>
>> project_name/
>>setup.py
>>src/
>>  myapp1/
>>  myapp2/
>>  project_name/
>>settings.py
>>urls.py
>>manage.py
>>wsgi.py
>>
>> My settings.py here uses environment variables for everything to
>> override defaults.
>>
>> Setup.py here allows:
>>
>> - Adding an entry point,
>> - Installing all apps as packages,
>> - Installing test dependencies with extra_requires and pip install
>> project_name[test],
>> - Adding runtime dependencies.
>>
>> For example, with that:
>>
>>  entry_points = {
>>  'console_scripts': [
>>  'project_name = project_name.manage:main',
>>  ],
>>  },
>>
>> And such a manage.py:
>>
>>def main():
>>  os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>> "project_name.settings")
>>  from django.core.management import execute_from_command_line
>>  execute_from_command_line(sys.argv)
>>
>>if __name__ == "__main__":
>>  main()
>>
>> Installing the package will add the project_name command, allowing to
>> run `project_name migrate` for example from any directory.
>>
>> I know it's too opinionated to add that to django, but I'd like to
>> open a discussion here and perhaps there's something we might find
>> worth changing in django's default project template.
>>
>> Thanks for reading !
>>
>> --
>> 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+unsubscr...@googlegroups.com
>> <mailto:django-developers+unsubscr...@googlegroups.com>.
>> To post to this group, send email to django-developers@googlegroups.com
>> <mailto:django-developers@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/django-developers/de495e35-ecad-409c-a5d2-f30512c36931%40googlegroups.com
>> <
>> https://groups.google.com/d/msgid/django-developers/de495e35-ecad-409c-a5d2-f30512c36931%40googlegroups.com?utm_medium=email_source=footer
>> >.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/X1exTiEybMA/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-de

Re: Translate permission Django

[Ramez Ashraf]

Hello, 

I created a 3rd party app for this issue , which will also display the app 
and model verbose names + display permissions in a tabular format for more 
easy setting when you have dozens of models.
Check it out at https://github.com/RamezIssac/django-tabular-permissions

Hope it helps :-)

Best

On Monday, February 29, 2016 at 11:20:36 AM UTC+2, Marcos Serrano wrote:
>
> Hello,
>
> How to translate the default permissions django . Keywords ( Add, Delete ... )
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5af65811-b751-467c-9fcd-60e625a8b6b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Admin widget to display user_permissions in tabular format

[Ramez Ashraf]

Hello, 
I came across the idea of having a new permissions widget that display 
basic permissions (add,change & delete)  in a tabular format, and fall back 
to FilteredSelectMultiple for any extra custom permissions
The merits of having this widget are:
1- Setting the permissions is more easy and user friendly, especially when 
the project have dozens of models.
2- The permissions are translated (fixes ticket 1688 
), since the html table is 
initially constructed via the apps and models themselves which give access 
to verbose_names. 

I created a ticket #25891  marked 
wont fix with a suggestion to build it in a third party and come back to 
you when i have something working, which exactly what i'm doing now. :-)

The newly created widget *django-tabular-permission* can be found here
https://github.com/RamezIssac/django-tabular-permissions

With screen shots available right on the README.

Congratulations on the MOSS grant, 
Django (& you valuable community) are the best.

Kind regards;
Ramez 


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/595d7fc2-088b-48fa-9cfa-6c5fde1c2d96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - ModelAdmin exclude

[Ramez Ashraf]

I agree that there are a lot of of hooks in the admin and we might need to 
better document them or remove unneeded or maybe make a revolution :)
But, with the current api and scheme, having get_exclude is more of the 
expected behavior of Django and i think it should be implemented.

What we should certainly do -i believe- is more documenting the admin flow 
& how it's constructed, best practices to achieve certain repeated goals 
etc..

Regards,
Ramez


On Saturday, June 6, 2015 at 3:43:11 PM UTC+2, Marc Tamlyn wrote:
>
> I don't think we should add this. Exclude is passed to the form, and we 
> already have a way of changing the form based on the request. I'd rather 
> see changes made to reduce some of the many many ways to select fields in 
> the admin. By my count at present we have:
>
> ModelAdmin.fields
> ModelAdmin.get_fields()
> ModelAdmin.exclude
> ModelAdmin.fieldsets
> ModelAdmin.get_fieldsets()
> ModelAdmin.readonly_fields
> ModelAdmin.get_readonly_fields()
> ModelAdmin.form concrete fields
> ModelAdmin.form.Meta.fields
> ModelAdmin.form.Meta.exclude
> ModelAdmin.get_form()
>
> There's an argument the only one missing here is get_exclude(), but I 
> think the current API is silly. Personally, I'd like to see us moving 
> towards us encouraging doing more work in the form (and defining the form) 
> rather than doing so much in the ModelAdmin class. This may well require 
> better support for fieldsets in django.forms.
>
> Marc
>
> On 6 June 2015 at 05:06, Peter Farrell  > wrote:
>
>> We are writing a custom admin for CleanerVersion that subclasses 
>> ModelAdmin. Just about every attribute has a hook method which makes 
>> extension easier. For example, list_display has get_list_display(). 
>> However, exclude doesn't have one implemented and it seems like an 
>> oversight. I'm proposing we add one.
>>
>> Our current work seeking is to write a property descriptor for exclude 
>> but then the admin check fails with it not being a tuple or list. Then you 
>> have to create a custom admin checks class to suppress the exclude check 
>> error because it's not a tuple or list (but really a descriptor).
>>
>> If this is ok, I'Ill write a PR.
>>
>> --
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c1e8762d-1c9f-47e9-8fe7-e9761c27e057%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e87b9c7-f834-492b-8e84-bb0d782956ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Okay to use form field labels in admin history?

[Ramez Ashraf]

Yes it worked well enough for over then it should be.
So yes i would love to give it a try.

So we will be storing json as string in the database? or what would be the 
recommended path to go about this ?!



On Wednesday, August 26, 2015 at 3:34:31 PM UTC+2, Tim Graham wrote:
>
> The current approach has worked "well enough" for 10 years. I think we can 
> wait a little longer for a better solution rather than change the message 
> format twice. Want to give it a try?
>
> On Tuesday, August 25, 2015 at 11:07:45 AM UTC-4, Ramez Ashraf wrote:
>>
>> Dear devs 
>> I'm the PR mentioned contributor. 
>> While I understand your concern about translated content in the database 
>> and the other ticket mentioned (having the info stored as Json or yaml) 
>> I see that these are different ways and are not mutually exclusive. 
>> The issue mentioned regards having multiple supported languages, while 
>> what the PR is solving is the simple "not english " site + the idea of 
>> having a customized label or clear verbose name instead of the current 
>> field name. 
>>
>> IMHO, I think this pull is a step forward. And when the issue mentioned 
>> is solved in an enhancement of the log structure, the old structure will 
>> continue to exist for backword compatibility. 
>>
>> I call -if I may- a reconsideration. :) 
>>
>> Last, I'm making extensive use of the admin in my work.. Hopefully I'll 
>> be around contributing in it. 
>>
>> Kind regards
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5728679c-4181-48fa-b76f-1008d3c038eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Okay to use form field labels in admin history?

[Ramez Ashraf]

Dear devs
I'm the PR mentioned contributor.
While I understand your concern about translated content in the database and 
the other ticket mentioned (having the info stored as Json or yaml)
I see that these are different ways and are not mutually exclusive.
The issue mentioned regards having multiple supported languages, while what the 
PR is solving is the simple "not english " site + the idea of having a 
customized label or clear verbose name instead of the current field name.

IMHO, I think this pull is a step forward. And when the issue mentioned is 
solved in an enhancement of the log structure, the old structure will continue 
to exist for backword compatibility. 

I call -if I may- a reconsideration. :) 

Last, I'm making extensive use of the admin in my work.. Hopefully I'll be 
around contributing in it.

Kind regards

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b1f74548-a324-46a1-a126-06b7830b809e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.