Issue in admin with sites

[Mohamed El-Kalioby]

Hello everyone,


I’ve opened this issue on the issue tracker, and was asked to post here for
the sake of discussion.

In SaaS product, we have set of organizations (customers), each
organization is working under its own subdomain under the SaaS domain, and
each is completely independent. Each organization will have a super user
who shall have access to the Django admin to edit their organization
objects. Currently, Django admin only shows the objects which belong to the
SITE_ID even with setting the *default_manager* to the *current_site*
manager and enabling the sites middleware.

I think this behavior is misleading and Django admin shall support sites
app, so what do you think?

Best regards,
Mohamed ElKalioby
-- 
Thanks
Mohamed.

-- 
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/CAFJxxNf%2B%3DG8%2BddPjVaqcUwzYU_drvNWtm13q2Yj66ebv%2B0jcRQ%40mail.gmail.com.

Issue in admin and sites

[Mohamed El-Kalioby]

Hello everyone,


I’ve opened this issue on the issue tracker, and was asked to post here for
the sake of discussion.

In SaaS product, we have set of organizations (customers), each
organization is working under its own subdomain under the SaaS domain, and
each is completely independent. Each organization will have a super user
who shall have access to the Django admin to edit their organization
objects. Currently, Django admin only shows the objects which belong to the
SITE_ID even with setting the default_manager to the current_site manager
and enabling the sites middleware.

I think this behavior is misleading and Django admin shall support sites
app, so what do you think?

Best regards
Mohamed ElKalioby

>

-- 
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/CAFJxxNcteC-sA5%3Db1JCjMg4bAOgNsd%3DHrzwb152SjOhnZQRC4g%40mail.gmail.com.

Re: Issue in admin and sites

[Mohamed El-Kalioby]

Here it is

https://code.djangoproject.com/ticket/34526

On Tue, 2 May 2023, 18:32 אורי,  wrote:

> Can you link to the ticket?
> אורי
> u...@speedy.net
>
>
> On Tue, May 2, 2023 at 5:28 PM Mohamed El-Kalioby 
> wrote:
>
>> Hello everyone,
>>
>>
>> I’ve opened this issue on the issue tracker, and was asked to post here
>> for the sake of discussion.
>>
>> In SaaS product, we have set of organizations (customers), each
>> organization is working under its own subdomain under the SaaS domain, and
>> each is completely independent. Each organization will have a super user
>> who shall have access to the Django admin to edit their organization
>> objects. Currently, Django admin only shows the objects which belong to the
>> SITE_ID even with setting the default_manager to the current_site manager
>> and enabling the sites middleware.
>>
>> I think this behavior is misleading and Django admin shall support sites
>> app, so what do you think?
>>
>> Best regards
>> Mohamed ElKalioby
>>
>>> --
>> 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/CAFJxxNcteC-sA5%3Db1JCjMg4bAOgNsd%3DHrzwb152SjOhnZQRC4g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAFJxxNcteC-sA5%3Db1JCjMg4bAOgNsd%3DHrzwb152SjOhnZQRC4g%40mail.gmail.com?utm_medium=email&utm_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/CABD5YeH34ivmtsf0Lm4WLkGcsRnL6GNDAKXZEJBMYhwdc-UudA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeH34ivmtsf0Lm4WLkGcsRnL6GNDAKXZEJBMYhwdc-UudA%40mail.gmail.com?utm_medium=email&utm_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/CAFJxxNeDDS5Pm43GPy8ogOM-Z%3Dd%3DiBF4vVYx6SWYZ%2B5rB0f5-g%40mail.gmail.com.

Re: Proposal to upgrade django.core.mail to Python's modern email API

['Mohamed El-Kalioby' via Django developers (Contributions to Django itself)]

+1, I like to help in this

On Mon, 24 Jun 2024, 05:46 Mike Edmunds,  wrote:

> I want to propose updating django.core.mail to replace use of Python's
> legacy email.message.Message (and other legacy email APIs) with
> email.message.EmailMessage (and other modern APIs).
>
> If there's interest, I can put together a more detailed proposal and/or
> ticket, but was hoping to get some initial feedback first. (I searched for
> relevant discussions in django-developers and the issue tracker, and didn't
> find any. Apologies if this has come up before.)
>
> [Note: I maintain django-anymail
> , which implements Django
> integration with several transactional email service providers.]
>
>
> *Background*
>
> Since Python ~3.6, Python's email package has included two largely
> separate implementations:
>
>- a "modern (unicode friendly) API" based on
>email.message.EmailMessage and email.policy.default
>- a "legacy API" providing compatibility with older Python versions,
>based on email.message.Message and email.policy.compat32
>
> (See https://docs.python.org/3/library/email.html, especially toward the
> end.)
>
> django.core.mail currently uses the legacy API.
>
>
> *Why switch?*
>
> There are no plans to deprecate Python's legacy email API, and it's
> working, so why change Django?
>
>-
>
>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy API.
>My understanding is legacy bugs will generally not be fixed. (And in fact,
>there are some cases where the legacy API deliberately replicates earlier
>buggy behavior.)
>
>Django #35497  is an
>example of a legacy bug (with a problematic proposed workaround) which is
>just fixed in the modern API.
>-
>
>*Simpler, safer code:* A substantial portion
>
> 
>  of
>django.core.mail's internals implements workarounds and security fixes for
>problems in the legacy API. This would be greatly simplified—maybe
>eliminated completely—using the modern API.
>
>Examples: the modern API prevents CR/NL injections in message headers.
>It serializes and folds address headers properly—even ones with unicode
>names. It enforces single-instance headers where appropriate.
>-
>
>*Easier to work with:* The modern API adds some nice conveniences for
>developers working in django.core.mail, third-party library developers, and
>(depending on what we choose to expose) users of Django's mail APIs.
>
>Examples: populating the "Date" header with a datetime or an address
>header with Address
>
> 
>  objects—without
>needing intricate knowledge of email header formats. Using email.policy to
>generate a 7-bit clean serialization (without having to muck about
>with the MIME parts
>
> 
>).
>
>
> *Concerns & risks*
>
> Compatibility and security, of course…
>
>-
>
>*Backwards compatibility (for API users):* django.core.mail largely
>insulates callers from the underlying Python email package. There are a few
>places where this leaks (e.g., attachments
>
> 
>  allows
>legacy email MIMEBase
> objects), but in
>general the switch should be transparent. (And I have some ideas for
>supporting the other cases.)
>-
>
>*Backwards compatibility (for third-party libraries):* Some libraries
>may use internals I'd propose removing (e.g., SafeMIME and friends);
>we'd handle this through deprecation.
>-
>
>*Backwards compatibility (bug-level):* There's probably some code out
>there that unintentionally depends on legacy email bugs (or the specific
>ways Django works around them). I don't have any examples, but I also don't
>have a good solution for when they surface. Plus, while Python's modern
>email API is pretty mature at this point, there are still new bugs being
>reported against it. Email is complicated.
>-
>
>*Security:* As noted above, the modern API should be more secure than
>the legacy one. But we also have a nice collection of email security
>tests—which *mostly* don't depend on internal implementation. We'd
>keep these.
>
> --
> 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 t