Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

Hi Carlton,

As I understand it, separate admin sites may register different models, but 
I'm only going to see the History for instances that are visible to the 
current admin no? 

The Django admin interface uses a templatetag named get_admin_log. It 
renders the content of all entries of model LogEntry filtered by the 
current user.
Check here for 
details: 
https://github.com/django/django/blob/34b328814976a2e2f7907361a494202763649f3f/django/contrib/admin/templatetags/log.py#L14
If you instantiate more than one Django-Admin interface, the logged in user 
therefore sees all his actions, regardless of the chosen admin instance.

My proposal would be to add another column to LogLevel containing the name 
of the admin interface. That column then shall be used as an additional 
filter. 
It should also be possible to swap that model against a compatible 
implementation, for instance if someone separates the admin interface 
because he also
separated the underlying databases.
 
Maybe you mean the Recent actions > My actions bit of the index page? (I 
didn't check but, if not already, could that list be filtered by the 
content type of registered models for the current admin? 🤔)

Yes, that's what I wrote and intended.

– Jacob

-- 
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/bfcd58e8-bbf1-42bc-a7dc-25a788e47b1en%40googlegroups.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Carlton Gibson]

Thanks for clarifying Jacob, great.

So, the registered content_types are in the available_apps key to the
context passed to that tag. (Currently that needs reconstructing in a
filter/comprehension, but it could feasibly be added to the
`AdminSite.each_context` method.) Adding the matching `__in` lookup to the
filter call there should allow retricting to only registered models no?

I'm personally sceptical that a "I added the same model to multiple
AdminSites and need to see only actions for each model from the AdminSite
that it occurred on" use-case is one we should cover. That's pretty niche
I'd say.

Kind Regards,

Carlton

On Thu, 26 Jan 2023 at 10:01, Jacob Rief  wrote:

> Hi Carlton,
>
> As I understand it, separate admin sites may register different models,
> but I'm only going to see the History for instances that are visible to the
> current admin no?
>
> The Django admin interface uses a templatetag named get_admin_log. It
> renders the content of all entries of model LogEntry filtered by the
> current user.
> Check here for details:
> https://github.com/django/django/blob/34b328814976a2e2f7907361a494202763649f3f/django/contrib/admin/templatetags/log.py#L14
> If you instantiate more than one Django-Admin interface, the logged in
> user therefore sees all his actions, regardless of the chosen admin
> instance.
>
> My proposal would be to add another column to LogLevel containing the name
> of the admin interface. That column then shall be used as an additional
> filter.
> It should also be possible to swap that model against a compatible
> implementation, for instance if someone separates the admin interface
> because he also
> separated the underlying databases.
>
> Maybe you mean the Recent actions > My actions bit of the index page? (I
> didn't check but, if not already, could that list be filtered by the
> content type of registered models for the current admin? 🤔)
>
> Yes, that's what I wrote and intended.
>
> – Jacob
>
> --
> 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/bfcd58e8-bbf1-42bc-a7dc-25a788e47b1en%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/CAJwKpyT0yGSrZGrRcH%2ByRk2vhpKgBjANo_xuDuTe5p60m-BuPw%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

['Alex Krupp' via Django developers (Contributions to Django itself)]

I just submitted a proposal to create a Discourse plugin to improve the
accuracy of their inbound email parsing. This would enable two things:

   - Folks who prefer to live in their inbox could continue to do so and
   contribute by just replying to emails. Discourse currently has
   reply-by-email, but it often mangles formatting and/or entirely deletes
   text. Once these issues are fixed, folks who like the current experience
   would be able to just pretend the forum doesn't exist and continue having
   the same experience as they currently have with Google Groups.
   - Right now importing the archives from Google Groups into Discourse
   isn't realistic for the same reasons; some messages will import correctly,
   but others will be mangled or missing text. This would also be made
   possible.

If this is something you care about (positively or negatively), here is the
exploratory proposal:

https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944

Any feedback and/or testing would be much appreciated! Right now Discourse
recognizes that this is a problem and is interested in solving it, but
getting it prioritized will require folks to A) speak up saying they want
it done B) test the underlying API to verify that it actually solves the
problem.

Alex

On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson 
wrote:

> OK, I've updated the Trac wiki page to point to the forum too. (We use
> this as a wiki-link in responses to guide folk onwards.)
>
> The docs have a `|django-developers|` shortcut used in quite a few places
> so that needs a moment more to review and adjust.
> (I'll look at it soon-ish... — if no-one beats me to it :)
>
> Thanks.
> C
>
> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>
>> We should at least update those Trac and Triage Workflow docs to point to
>> both, maybe with the Forum first?
>>
>> Andrew
>>
>> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>>
>> I'm trying to begin new conversations there where I can.
>>
>> The main issue is that we're still pointing people here from Trac and the
>> Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
>> adjust practice there.
>>
>> I expect there will always be the "How do I start?" posts. The Forum at
>> least has a pinned post for that. ...
>>
>> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
>> (Contributions to Django itself) 
>> wrote:
>>
>> Hi all,
>>
>> I find that the signal-to-noise ratio on this mailing list is (by my
>> determination) quite bad around this time of year.
>>
>> Is a move to the forum still on the cards?
>>
>> Kye
>> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin ,
>> wrote:
>>
>> I did some investigation of moving django-users and django-developers to
>> the Forum right after DjangoCon; I wanted to see if we could import all the
>> old posts too, which we probably could, but I'm not entirely sure of the
>> utility of that.
>>
>> I will say that the forum is a lot easier to moderate - the ability to
>> moderate after a post has gone out, rather than gating all posts behind
>> approval if they're untrusted, is a big step in itself, not to mention the
>> ability to remove sensitive or offensive content once it's posted.
>>
>> Andrew
>>
>> On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
>>
>> IMO django-announce and django-updates serve a very different purpose and
>> I would be against moving them if it were suggested.
>>
>> I am incredibly strongly in favour of moving django-developers and
>> django-users to the forums. IMO being able to more easily trap people
>> misusing this list as a tech support channel is itself reason enough to
>> move. Beyond that, I’d argue that the plentiful UX issues with Google
>> Groups, and mailing lists in general, certainly don’t do the community any
>> favours in terms of getting more people on board.
>>
>> Kye
>>
>> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers
>> (Contributions to Django itself) , wrote:
>>
>> As someone who only just joined the forum -- I'm +1:
>>
>>- The forum has seen great adoption from what I can tell (nearly half
>>the number of posts as django-developers during the same time period, not
>>bad given the mailing list's head start in subscribers).
>>- It seems beneficial to house future conversations in a single
>>place, e.g., so members don't need to subscribe to both the mailing list
>>and forum to get the full picture of current active development, set up 
>> two
>>different sets of mail filters to tag things appropriately, etc...
>>
>> Would the plan be to switch django-users as well? I think similar
>> arguments could be made for consolidating those...
>>
>> (On the other hand, I see little value in switching django-announce and
>> django-updates, but I'm not necessarily opposed to it either, especially if
>> there's a way to import the subscribers to those lists...)
>>
>> Cheers,
>>
>>
>> *Tobia

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

Hi Carlton,
that proposal makes a lot of sense.

This means that one could for instance add a custom function to that 
context which, if set, would be called
by the AdminLogNode.render method and then overrides the 
context[self.varname].
How would you name that extra context variable, maybe "render_log_entries"?
Another approach would be to move the functionality of method render into 
the class AdminSite. This would
allow Django implementers to override the way, log entries are rendered.

This would be a minimalistic change to the existing code base but would 
allow to change the rendering
of log entries in a much more flexible way.

Shall I create a ticket and a proof of concept?

– Jacob

-- 
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/e50bce39-d1dd-44b5-9fae-fc1bc8c9c864n%40googlegroups.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Carlton Gibson]

Hey Jacob.

I had in mind literally **just** adding the content-types so that the line
in that render call would be:

# this could be via a proposed context["site_content_types"] or via a
map from
# "available_apps"
site_content_types: [ContentType] = ...
entries = LogEntry.objects.filter(
user__pk=user_id,
content_type__in=site_content_types
)

This I can sort of see: OK, folks use multiple AdminSites, and having
non-registered models show up is a cause of uncertainty, plausibly, yes.

You want more than that thought right? (I'm still not certain I've grasped
exactly what use-case you have in mind.)

Passing in a callable seems an extra step of complexity up.
(IDK, maybe it's not, but I'm not seeing it, although I'm known to be slow
at times.)

It would be undocumented magic.
I think I'd lean towards suggesting a custom template and tag in that case.

(But maybe that's just me.)

A diff of what you actually have in mind would likely help (to at least be
clear).


C.



On Thu, 26 Jan 2023 at 15:26, Jacob Rief  wrote:

> Hi Carlton,
> that proposal makes a lot of sense.
>
> This means that one could for instance add a custom function to that
> context which, if set, would be called
> by the AdminLogNode.render method and then overrides the
> context[self.varname].
> How would you name that extra context variable, maybe "render_log_entries"?
> Another approach would be to move the functionality of method render into
> the class AdminSite. This would
> allow Django implementers to override the way, log entries are rendered.
>
> This would be a minimalistic change to the existing code base but would
> allow to change the rendering
> of log entries in a much more flexible way.
>
> Shall I create a ticket and a proof of concept?
>
> – Jacob
>
> --
> 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/e50bce39-d1dd-44b5-9fae-fc1bc8c9c864n%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/CAJwKpyQqW6wLUCHFQiFvReF-67_Ker8XoFHhFDvg4tnkwFLd_w%40mail.gmail.com.