Re: Creating internal/admin pages without Models

[Igor Margitich]

Hi Vasanth,

Can you ptovide an example when do you need generic admin view? I have case
where I need gather some information from different not directly related
tables. I have used https://pypi.org/project/django-nonrelated-inlines/.
Can't say it is exactly what I need but seems it does the job.
Also sometimes I need action's intermediate page which is more then just
simple template. This is the case where would be nice to have CBV. Watch
this presentation to get some ideas about CBV actions
https://youtu.be/HJfPkbzcCJQ?t=1817.

Best regards,
Ihor

вт, 25 окт. 2022 г. в 11:22, Vasanth Mohan :

> Hello,
>
> I'd like to gauge the general opinion of more experienced devs before
> starting on a project.
>
> I personally love the sheer flexibility that the django admin provides me
> to get started on the DB and manage the backend. I can add actions, filters
> and charts with just a few third-party apps. On top of that, permissions to
> control user access to everything.
>
> However, I find myself having to build a separate set of templates and
> view for internal use often as the admin is tightly tied to the DB. I find
> myself not being able to expose the admin as it requires too much
> customisation to be useful to tech & non-tech teams at the same time.
> Moreover, DB structure is not as intuitive to non-tech users.
>
> So I'd like to build a generic admin view that is not tied to the DB but
> can still leverage the widgets (tables, inputs, messages etc.) that Django
> offers. A set of tools to design custom pages like django-etc and design
> easy-to-customise top/sidebars
>
> My question to the reader is quite simple, is this something feasible ?
> Are all widgets tightly coupled and expect models to function ? Anything
> you believe that might trip me up?
>
> Thanks,
> Vaz
>
> --
> 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/d6146414-c423-4f2a-b482-5eccb971f16cn%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/CAHi_fyv7QrWwpNOdyv8ZvOg%2B84mzTLKvrc-iYHjee8SQ6gPd%2Bg%40mail.gmail.com.

Re: Proposal: cacheif template tag

[Igor Margitich]

Hey Carlton,
I am not sure I got your idea.
The point of proposal is not in user.is_authenticated. 
user.is_authenticated is just a boolean. Conditional caching for non logged 
in user is just very simple and common use case when `cacheif` could be 
used. 

пʼятниця, 30 вересня 2022 р. о 09:09:53 UTC+2 carlton...@gmail.com пише:

> Hey Igor, 
>
> I wonder if you can achieve the same varying the timeout parameter based 
> in user.is_authenticated?
>
> Kind Regards,
>
> Carlton
>
> On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:
>
>> Hi django-developers,
>>
>> I would like to propose new template tag `cacheif`. Could be useful when 
>> you need to cache part of html and it depends on some condition. Template 
>> tag is similar to built-in `cache` tag but accepts extra boolean parameter. 
>> See example:
>>
>> {% cacheif user.is_anonymous 10 homepage %}
>>   
>>  .
>>   
>> {% endcacheif %}
>>
>>
>> -- 
>> 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/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.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/a44ef6f2-b546-4f16-96ff-3055b9910961n%40googlegroups.com.

Proposal: cacheif template tag

[Igor Margitich]

Hi django-developers,

I would like to propose new template tag `cacheif`. Could be useful when 
you need to cache part of html and it depends on some condition. Template 
tag is similar to built-in `cache` tag but accepts extra boolean parameter. 
See example:

{% cacheif user.is_anonymous 10 homepage %}
  
 .
  
{% endcacheif %}


-- 
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/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.com.

Django self reference (FK) change SQL result

[igor malinov]

Good day for Everyone.
Because I have self-reference, my queryset no work properly
I have a model


class Agency(Organization):
organization_ptr = models.OneToOneField(to='Organization', 
parent_link=True, primary_key=True, related_name='%(class)s', serialize=False, 
on_delete=CASCADE)
accreditation = models.OneToOneField('Accreditation', null=True, 
blank=True, on_delete=DO_NOTHING)
parent = models.ForeignKey("self", null=True, blank=True, 
on_delete=SET_NULL)  



class Application(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)

name = models.CharField(max_length=255)

seers = models.ManyToManyField('Agency', blank=True, 
through='ApplicationAgencySeer')

# and other



class ApplicationAgencySeer(models.Model):
application = models.ForeignKey(Application, on_delete=models.CASCADE)
agency = models.ForeignKey('Agency', on_delete=models.CASCADE)
status = models.IntegerField('Status', choices=CHOICE)
created = models.DateTimeField(auto_now_add=True)




Now I wanna exclude (simple query)

a = 
Application.objects.exclude(seers__agency__id='9e71cff4-443d-4c60-ac2d-9dcca2a9c147')
print(a.query)


" * "  change by myself

SELECT *
FROM "myapp_application"
WHERE NOT ("myapp_application"."id" IN (SELECT U1."application_id"
   FROM "myapp_applicationagencyseer" U1
  INNER JOIN "myapp_agency" U2 
ON (U1."agency_id" = U2."organization_ptr_id")
  INNER JOIN "myapp_agency" U3 
ON (U2."organization_ptr_id" = U3."parent_id")
   WHERE U3."organization_ptr_id" = 
'9e71cff4-443d-4c60-ac2d-9dcca2a9c147'))
ORDER BY "myapp_application"."created_date" DESC;


result


application_id

7d83d056-5a7d-4095-9037-98bde29a3d78otherfields...otherfields..

7cb60afc-109d-4570-ad24-6cad6b7ddd9aotherfields...otherfields.. 
  <-- this row error



exclude - no really exclude
Invoked problem by `INNER JOIN "myapp_agency" U3 ON (U2.
"organization_ptr_id" = U3."parent_id")`

--return 0

(SELECT U1."application_id"
FROM "myapp_applicationagencyseer" U1
INNER JOIN "myapp_agency" U2 ON (U1."agency_id" = U2."organization_ptr_id")
INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" = U3."parent_id")
WHERE U3."organization_ptr_id" = '9e71cff4-443d-4c60-ac2d-9dcca2a9c147')


--althouth I have  myapp_applicationagencyseer

id   created   agency_id
   application_id status

1   2018-12-10 17:41:14.272684  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
7cb60afc-109d-4570-ad24-6cad6b7ddd9a1
2   2018-12-11 19:25:58.818000  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
7cb60afc-109d-4570-ad24-6cad6b7ddd9a0


-- myapp_agency

organization_ptr_idaccreditation   parent

aff44d42-ce81-4c3e-b6e1-056ed9351adbNull   Null

9e71cff4-443d-4c60-ac2d-9dcca2a9c14710АА71 Null   <-- It have 
Null parent



Why Query have `INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" = 
U3."parent_id")` . 

-- 
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/de52c7d8-b05e-4266-8ab8-146f098ac5d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re:

[Igor]

фейсик после ipo сильно потерял в цене акций - им нужна комерциализация 
конче ;)


хорошее слово "конче"

нам тоже нужно ентое "конче"

On Tue 09 Oct 2012 07:28:01 EEST, django-developers@googlegroups.com 
wrote:

Today's Topic Summary

Group: http://groups.google.com/group/django-developers/topics

  * Feature request: collectstatic shouldn't recopy files that already
exist in destination <#group_thread_0> [9 Updates]

Feature request: collectstatic shouldn't recopy files that already
exist in destination


Dan Loewenherz  Oct 07 08:58PM -0700

This issue just got me again tonight, so I'll try to push once
more on this
issue. It seems right now most people don't care that this is
broken, which
is a bummer, but in which case I'll just continue using my working
solution.

Dan

ptone  Oct 07 10:38PM -0700

so after scanning this thread and the ticket again - it is still
unclear
that there could be a completely universal solution.

While it would be nice if the storage API had a checksum(name) or
md5(name)
method - not all custom storage backends are going to support a
single
checksum standard. S3 doesn't explicitly support MD5 (apparently it
unofficially does through ETags). Without a universal checksum -
you can't
use it to compare files across arbitrary backends.

I do agree that hacking modified_time return value is a little
ugly - the
API is clearly documented as "returns a datetime..." - so
returning a M55
checksum there is, well, hacky.

If you are passionate about moving this forward, here is what I'd
suggest.

Implement, document, and test .md5(name) as a standard method on
storage
backends - like modified_time this would raise NotImplementedError
if not
available - this could easily be its own ticket. md5 is probably the
closest you'll get to a checksum standard.

Once you have an md5 method defined for backends - you could
support a
--md5 option to collectstatic that would use that as the
target/source
comparison.

Another workaround is to just use collectstatic locally - and rsync
--checksum to your remote if it supports rsync.

-Preston


On Sunday, October 7, 2012 8:59:16 PM UTC-7, Dan Loewenherz wrote:

Jannis Leidel  Oct 08 12:33PM +0200


> It's accurate *only* in certain situations. And on a distributed
development team, I've run into a lot of issues with developers
re-upload files that have already been uploaded because they just
recently updated their repo.

> A checksum is the only true accurate method to determine if a
file has changed.

> Additionally, you didn't address my point that I quoted from.
Storage backends don't just reflect filesystems--they could
reflect files stored in a database, S3, etc. And some of these
filesystems don't support last modified times.

Then, frankly, this is a problem of the storage backends, not
Django's. The S3BotoStorage backend *does* have a modified_time
method:


https://bitbucket.org/david/django-storages/src/1574890d87be/storages/backends/s3boto.py#cl-298

What storage backend do you use that doesn't have a modified_time
method?

> This is a bit confusing...why call it last_modified when that's
doesn't necessarily reflect what it's doing? It would be more
flexible to create two methods:

It's called modified_time, not last_modified.

> def modification_identifier(self):

> def has_changed(self):

> Then, any backend could implement these however they might like,
and collectstatic would have no excuse in uploading the same file
more than once. Overloading last_modified to also do things like
calculate md5's seems a bit hacky to me, and confusing for any
developer maintaining a custom storage backend that doesn't
support last modified.

I disagree, modified_time is perfectly capable of handling your
use case.

Jannis

Jannis Leidel  Oct 08 12:50PM +0200


> so after scanning this thread and the ticket again - it is still
unclear that there could be a completely universal solution.

> While it would be nice if the storage API had a checksum(name)
or md5(name) method - not all custom storage backends are going to
support a single checksum standard. S3 doesn't explicitly support
MD5 (apparently it unofficially does through ETags). Without a
universal checksum - you can't use it to compare files across
arbitrary backends.

You're able to ask S3 for the date of last modification, I don't
see why a comparison by hashing the file content is needed
additionally. It'd have to download the full file to do that on
Django's side and I'm not aware of a API for getting a hash from
 

Re: Design decision on ticket #13223

[Igor Sobreira]

When I said "user", I actually meant "developer", "django user"... sorry 
for the confusion :]

When pre-filling the form to display the "clone" page we can provide a 
method the developer can override to copy the files on disk, or change 
anything he wants (for example, change unique fields like slug, since the 
user will have to edit anyway)

But it's possible to implement as Thomas suggested, just provide a new 
reference for the same file on disk by default, and let the developer 
choose to copy or not. I'll work on an implementation for this.

Thanks for the feedback!

Igor.

On Wednesday, February 22, 2012 12:04:12 PM UTC-2, juanpex wrote:
>
> That's it. I only identify this 2 behaviour.
> Now, the question is: when and where put this decision the user?
> A like ligthbox before copy on click button "clone"?, or in the new 
> page displaying the cloned object?
> I don't know :)
>
> Regards,
>
> On Wed, Feb 22, 2012 at 11:53 AM, Igor Sobreira  wrote:
>
>> Yes, that's what I wanted to say. We can decide that this behavior is 
>> fine by default, document it, and provide an easy way (with callback and 
>> helper functions) to allow the user to clone the file on disk.
>
>
>
>
> -- 
> juanpex
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/dJcLD6P_e90J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Design decision on ticket #13223

[Igor Sobreira]

On Wednesday, February 22, 2012 2:34:38 AM UTC-2, juanpex wrote:
>
> On Tue, Feb 21, 2012 at 10:55 PM, Thomas Woolford wrote:
>
>> Any files uploaded when the clone view is submitted will be uploaded on 
>> save and associated with the new object anyway.
>>
> It is perfectly valid for two DB rows to point at the same file because as 
>> soon as that file is re-uploaded it creates a new file instead of 
>> overwriting the old one anyway 
>>
>
> But this behaviour doesn't represent all cases. In some cases, the users 
> could be want to "clone" in a full copy and a representation of files too 
> and NOT link to
> the pre-existing files of the other/s objects.
>
>
Yes, that's what I wanted to say. We can decide that this behavior is fine 
by default, document it, and provide an easy way (with callback and helper 
functions) to allow the user to clone the file on disk.
 

> This mean that if I change the "origin" object file, the cloned/s objects 
> will change their links too?
>
> The obviously behaviour will be to copy another file on the server and 
> associate it with this new object and be consistent with the default admin 
> functionality.
>
> Regards,
> -- 
> juanpex
>


-- 
Igor Sobreira 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/sCUmpkS2PosJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Design decision on ticket #13223

[Igor Sobreira]

Hi,

I'm working on a patch for #13223 [1], but I need some help on how to
proceed. The solution I would like to work on is to replace the "save as
new" button  for a "clone object" link. This is how I understood the
suggest on the ticket, and the way makes more sense to me.

I've started to create a clone_view() in admin, and submitted a
prototype-not-yet-done patch, with the idea. When the user enables the
"save_as" admin option (maybe change the name) a "save as new" *link*
appears, which opens a /clone/ view pre-filled data based on the
object id from the url.

Any feedback would be welcome.

There is a drawback: file uploads would not work. The user would need to
upload a new file (or the same). Maybe a new ticket would be better to find
the best solution to this (#14760 !?). What I was planning to do is provide
a template method called by clone_view() function where the user could copy
the file on disk or do anything she wants regarding form filling on GET.

Thanks in advance,
Igor.

[1] https://code.djangoproject.com/ticket/13223

-- 
Igor Sobreira
www.igorsobreira.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Use RequestContext if possible in default 500 error view

[Igor Sobreira]

On Thu, Apr 30, 2009 at 10:43 AM, Karen Tracey <kmtra...@gmail.com> wrote:

>
> With the try/except, if in fact there's trouble creating RequestContext or
> rendering with it, the code will fall back to rendering with just an empty
> Context.  So the template still has to handle displaying properly in the
> absence of any context variables, if you want it to display properly
> regardless of the path it takes through 'render_safe'.  So why not just have
> a single path and a simpler template that knows it never has a context to
> rely on?
>
Because it violates DRY, and will mess the template inheritante. I will have
to repeat there the "constants" that are in all templates (like MEDIA_URL).
Well, I understand both sides. It seems a problem that can't be handle
because on how Django works. Or maybe it's not even a problem...i don't
know.
It seems I'll need to always override this view to provide at least
MEDIA_URL for all my projects.
-- 
Igor Sobreira
www.igorsobreira.com
www.smartnutstechnology.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Use RequestContext if possible in default 500 error view

[Igor Sobreira]

Hello devs,
As you know, the view django.views.defaults.server_error() uses Context
instead of RequestContext.
There are 2 tickets about it:
http://code.djangoproject.com/ticket/5617
http://code.djangoproject.com/ticket/6377 (duplicated)
ubernostrum explaied why it works that way:
"The default server-error handler was deliberately written this way to
lessen the odds of new exceptions being raised during the execution of the
server_error view."
But why not use a try/except to handle any error from RequestContext, and
fall back on Context if it happens? As tobias posted on comments [1]
I'm asking for attention on it because I couldn't find a reason why not use
a try/except here, and because the try/except solution what added after the
ticket was closed, maybe nobody paid attention to it.
[1] http://code.djangoproject.com/ticket/5617#comment:3
Regards.
-- 
Igor Sobreira
www.igorsobreira.com
www.smartnutstechnology.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

a small typo in #3007/r4058

[Igor Goryachev]

Hello people.

There is a small bug/typo in patch came with r4058 revision.

random_bits variable became string instead of integer, so the following:

-msg['Message-ID'] = "<[EMAIL PROTECTED]>" % (time.time(), random_bits, 
DNS_NAME)

should be changed to:

+msg['Message-ID'] = "<[EMAIL PROTECTED]>" % (time.time(), random_bits, 
DNS_NAME)


BTW, I've tried to reopen #3007, but got the following message:

Submission rejected as potential spam (Akismet says content is spam)


-- 
Igor Goryachev  E-Mail/Jabber: [EMAIL PROTECTED]

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: sending mail in utf-8

[Igor Goryachev]

Igor Goryachev <[EMAIL PROTECTED]> writes:

> I think it would be very useful if it was possible to send e-mail (using
> 'django.core.mail') in something different than 'us-ascii', for example,
> in 'utf-8' by default. I have tried to implement this:

I have reworked it a bit and submitted patch Ticket #1235.

Any feedback?


-- 
Igor Goryachev  E-Mail/Jabber: [EMAIL PROTECTED]

sending mail in utf-8

[Igor Goryachev]

Hello.

I think it would be very useful if it was possible to send e-mail (using
'django.core.mail') in something different than 'us-ascii', for example,
in 'utf-8' by default. I have tried to implement this:

=
Index: django/conf/global_settings.py
===
--- django/conf/global_settings.py  (revision 1983)
+++ django/conf/global_settings.py  (working copy)
@@ -68,6 +68,9 @@
 DEFAULT_CONTENT_TYPE = 'text/html'
 DEFAULT_CHARSET = 'utf-8'
 
+# Default charset used for sending e-mail messages.
+DEFAULT_EMAIL_CHARSET = 'utf-8'
+
 # E-mail address that error messages come from.
 SERVER_EMAIL = '[EMAIL PROTECTED]'
 
Index: django/core/mail.py
===
--- django/core/mail.py (revision 1983)
+++ django/core/mail.py (working copy)
@@ -1,7 +1,9 @@
 # Use this module for e-mailing.
 
 from django.conf.settings import DEFAULT_FROM_EMAIL, EMAIL_HOST, 
EMAIL_SUBJECT_PREFIX
+from django.conf.settings import DEFAULT_EMAIL_CHARSET
 from email.MIMEText import MIMEText
+from email.Header import Header
 import smtplib
 
 class BadHeaderError(ValueError):
@@ -39,8 +41,8 @@
 if not recipient_list:
 continue
 from_email = from_email or DEFAULT_FROM_EMAIL
-msg = SafeMIMEText(message)
-msg['Subject'] = subject
+msg = SafeMIMEText(message, 'plain', DEFAULT_EMAIL_CHARSET)
+msg['Subject'] = str(Header(subject, 
DEFAULT_EMAIL_CHARSET)).replace('\n', '').replace('\r', '')
 msg['From'] = from_email
 msg['To'] = ', '.join(recipient_list)
 server.sendmail(from_email, recipient_list, msg.as_string())

=


-- 
Igor Goryachev  E-Mail/Jabber: [EMAIL PROTECTED]