Re: Admin form_url breakout problem

[Mike Dewhirst]

Django 2.0 makes no difference either so I've gone back to 1.11 for the 
time being. To recap ... I'm successfully launching a Stripe payment 
page from within the Admin  followed by a success (or failure) page 
which is at the following URL ...


http://localhost:8000/admin/substance/substance/1442/change/payment

... with a link back to the original Admin page.

http://localhost:8000/admin/substance/substance/1442/

On clicking that link the Admin shows *no error but no content* other 
than the normal top of page at the following correct URL ...


http://localhost:8000/admin/substance/substance/1442/change/

The only way I can get it to show the proper content at that URL is to 
reload runserver.


Here are my project urls ...

from __future__ import unicode_literals, absolute_import, division

from django.conf import settings
from django.conf.urls import include
from django.conf.urls import url as re_path  # ready for 1.2
from django.contrib import admin
import django.contrib.auth.views as auth_views
import django.views as django_views

from billing import views as billing_views
from common.views import privacy


admin.autodiscover()
adminurls = admin.site.urls


urlpatterns = [

    re_path(r'^substance/', include('substance.urls')),

    re_path(r'', include('common.urls')),

    re_path(r'payment$',
    billing_views.payment_view,
    name='payment_view'
    ),

    re_path(r'success$',
    billing_views.success_view,
    name='success_view'
    ),


    re_path(r'^admin/password_reset/$',
    auth_views.password_reset,
    name='django.contrib.auth.views.admin_password_reset'),

    re_path(r'^admin/password_reset/done/$',
    auth_views.password_reset_done,
    name='django.contrib.auth.views.password_reset_done'),

re_path(r'^reset/(?P[0-9A-Za-z_\-]+)/(?P.+)/$',
    auth_views.password_reset_confirm,
name='django.contrib.auth.views.password_reset_confirm'),

    re_path(r'^reset/done/$',
    auth_views.password_reset_complete,
name='django.contrib.auth.views.password_reset_complete'),

    # Uncomment the admin/doc line below to enable admin documentation:
    re_path(r'^admin/doc/', include('django.contrib.admindocs.urls')),

    re_path(r'^admin/', admin.site.urls),
]

if not settings.APACHE:
    urlpatterns.append(
    re_path(r'^media\/(?P.*)$',
    django_views.static.serve,
    {'document_root': settings.MEDIA_ROOT}),
    )
    urlpatterns.append(
    re_path(r'^static\/(?P.*)$',
    django_views.static.serve,
    {'document_root': settings.STATIC_ROOT}),
    )


I'm using ModelAdmin.change_view as follows ...


    def change_view(self, request, object_id, form_url='', 
extra_context=None):

    """
    self = SubstanceAdmin
    request = wsgi request object
    object_id = substance
    form_url = no idea!
    extra_context = dict of apps, models, admin_urls and permissions
    """
        # Substance_Ingredients is a m2m (to self being Substance) 
through table #
    ingredients = 
Substance_Ingredients.objects.filter(substance_id=object_id)

    subscription = None
    for sm2mi in ingredients:
    payable, fee_type = sm2mi.fee_payable()  # eg., True, PAID_DATA
    if payable:
    subscription = billing_subscribe(sm2mi, fee_type)
    if subscription:    # we need to collect money for the 
owner

    self.change_form_template = 'payment.html'
    context = billing_collect_context(
    sm2mi,
    subscription,
    )
    # get everything into the payment_view context
    if not extra_context:
    extra_context = dict()
extra_context.update(self.admin_site.each_context(request))
    extra_context.update(context)
    self.admin_site.admin_view(
    # call the Stripe mechanism
    billing_payment_view(
    request,
    sm2mi,
    subscription,
    context=extra_context,
    )
    )
    # payment for only one sm2mi at a time
    break
    return super(SubstanceAdmin, self).change_view(
    request, object_id, form_url, extra_context
    )


 I have tried myriad ways to reload the urls and persist context past 
the Stripe form but cannot do it apart from reloading the server.


I'm thinking that maybe the Admin has a mechanism to re-init itself but 
I can't find it. I'm out of ideas at the moment so if anyone can help I 
would be very appreciative.


I still haven't got Apache working with Python 3.5 mod_wsgi so I can't 
say anything there.


Thanks

Mike


On 13/02/2019 12:37 pm, Mike Dewhirst wrote:

Starting a new thread with the same subject because 

Deploying a chatbot with Django: WebSockets vs HTTP

[Mukul Mantosh]

I currently have a chatbot app in my django project that I would like to 
deploy.


I am confused as to whether I should use WebSockets or normal HTTP calls 
(AJAX) for it's implementation. This is what I have understood about the 
pros/cons of each(in the context of my use-case) till now after some 
internet research.
Reasons for using WebSockets over HTTP:
   
   1. WebSockets are recommended for chat applications because of low 
   overhead per user message once the connection has been established. HTTP 
   will have the overhead of establishing a connection each time a message is 
   sent (Also the header will be bigger in size, which will be sent with each 
   request/user message)
   2. WebSockets allow for real-time communication without *workarounds* like 
   polling in case of HTTP which can lead to many unnecessary requests from 
   the client.

Reasons for using HTTP over WebSockets:
   
   1. HTTP *just might* be okay for a chatbot(not human to human chat) 
   because the response of the chatbot is only triggered when the user 
   messages something i.e. The Bot isn't expected to message the user all of a 
   sudden at random intervals which would require real-time communication. The 
   Bot only sends replies to user messages.
   2. Will have to use django-channels and an ASGI server for the chatbot 
   part, which will require maintaining two servers (along with WSGI), which 
   will make the implementation a little bit complicated.

What should I go ahead with?

P.S. Someone suggested I look into services like Pusher 
, although it doesn't seem to have server side SDK for 
python

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d7611fcc-76a7-4533-9b2b-fa21891dd42d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to sent OTPA verification in mail while login with django

[aswaniachu1698]

Thank you,
actually insted of senting a verification link i need to sent random 
numbers.how can i write the view for it. 

On Friday, 15 February 2019 23:56:59 UTC+5:30, Khaleel Ahmed H. M. Shariff 
wrote:
>
> Hi Aswani,
> May Peace, Blessings & Mercy of Almighty God be on you!
> You can use random number generation for OTP authentication. 
> Hope it helps.
> Best of Luck.
> Thanks in advance. 
>
>
> God Bless You!
> God Bless India!!
> --
>
> Love & Regards
> Khaleel Ahmed H. M.
>
> Managing Director, Tanzanite Realty India Private Limited
>
> ---
>
> Human Life is Precious
> Koran Surah Ma'idah Chapter 5 Verse 32:
> If anyone killed a person, not in retaliation of murder, or (and) to 
> spread mischief in the land - it would be as if he killed all mankind, & if 
> anyone saved a life, it would be as if he saved the life of all mankind.
>
>
> On Fri, Feb 15, 2019 at 6:10 PM > 
> wrote:
>
>> How to sent OTPA  verification in mail while login with django
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/f92f30a2-8613-4f8d-8e2c-1f8b669965aa%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/094e2487-e5b7-448f-b84b-365a74b699d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django command logging levels

[Dan Davis]

The common verbosity will be passed to the handler:

class Command(BaseCommand):
...
def handler(**kwargs):
 verbosity = kwargs['verbosity']


I tried to get clever once and not have **kwargs, but Django sends that 
common stuff, like '--settings", and it is good for me to pay attention.

OTOH, if you want to know whether this has anything to do with Python's 
logging module, it doesn't - that all depends on your settings file 
contents.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e6e1936a-d45d-4212-acfc-be79d2cb328a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django command logging levels

[co16326 . ccet]

Django command interface has the following CLI arg

  -v {0,1,2,3}, --verbosity {0,1,2,3}
Verbosity level; 0=minimal output, 1=normal output,
2=verbose output, 3=very verbose output

It doesn't connect with the logging levels used by the commands, so the 
commands don't show extra information.

So is this an incompatibility or I have to add some arguments to my custom 
management commands ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c2591645-5950-4969-98b3-afdb8b7c3ce6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: select_for_update Documentation is confusing(?)

[Simon Charette]

Hello Philoj,

> Does this mean that the above code example will raise 
TransactionManagementError...

It won't cause a TransactionManagementError because of the lazy nature of 
queryset.

Even if the QuerySet.select_for_update() call is made outside of the atomic 
block the query
is really only executed when entries are iterated over.

Given the documentation clearly mentions "*Evaluating* a queryset" and 
"Building a queryset"
I don't think it's worth amending it.

Cheers,
Simon

Le vendredi 15 février 2019 07:40:51 UTC-5, Philoj Johny a écrit :
>
> In the documentation for select_for_update 
> ,
>  
> given code example is:
>
> from django.db import transaction
> entries = Entry.objects.select_for_update().filter(author=request.user)with 
> transaction.atomic():
> for entry in entries:
> ...
>
> At the same time, below in the description it says that:
>
> *Evaluating a queryset with select_for_update() in autocommit mode on
> backends which support SELECT ... FOR UPDATE is a
> TransactionManagementError 
> 
>  error because the
> rows are not locked in that case.*
>
> *Does this mean that the above code example will raise 
> **TransactionManagementError , since the select_for_update_query is evaluated 
> outside atomic block?*
>
>
> *(I have'nt actually tried this out yet, will soon. I think may be a 
> correction is required in the code example)*
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/15abcd7c-c0a3-48c9-a50a-80c71512cc3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: select_for_update Documentation is confusing(?)

[Simon Charette]

I meant, and *not* "Building a queryset" in my previous reply.

Le vendredi 15 février 2019 14:18:27 UTC-5, Simon Charette a écrit :
>
> Hello Philoj,
>
> > Does this mean that the above code example will raise 
> TransactionManagementError...
>
> It won't cause a TransactionManagementError because of the lazy nature of 
> queryset.
>
> Even if the QuerySet.select_for_update() call is made outside of the 
> atomic block the query
> is really only executed when entries are iterated over.
>
> Given the documentation clearly mentions "*Evaluating* a queryset" and 
> "Building a queryset"
> I don't think it's worth amending it.
>
> Cheers,
> Simon
>
> Le vendredi 15 février 2019 07:40:51 UTC-5, Philoj Johny a écrit :
>>
>> In the documentation for select_for_update 
>> ,
>>  
>> given code example is:
>>
>> from django.db import transaction
>> entries = Entry.objects.select_for_update().filter(author=request.user)with 
>> transaction.atomic():
>> for entry in entries:
>> ...
>>
>> At the same time, below in the description it says that:
>>
>> *Evaluating a queryset with select_for_update() in autocommit mode on
>> backends which support SELECT ... FOR UPDATE is a
>> TransactionManagementError 
>> 
>>  error because the
>> rows are not locked in that case.*
>>
>> *Does this mean that the above code example will raise 
>> **TransactionManagementError , since the select_for_update_query is 
>> evaluated outside atomic block?*
>>
>>
>> *(I have'nt actually tried this out yet, will soon. I think may be a 
>> correction is required in the code example)*
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7805f266-aa5e-401f-8171-17e4a7484ee9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to sent OTPA verification in mail while login with django

[Khaleel Ahmed H. M. Shariff]

Hi Aswani,
May Peace, Blessings & Mercy of Almighty God be on you!
You can use random number generation for OTP authentication.
Hope it helps.
Best of Luck.
Thanks in advance.


God Bless You!
God Bless India!!
--

Love & Regards
Khaleel Ahmed H. M.

Managing Director, Tanzanite Realty India Private Limited

---

Human Life is Precious
Koran Surah Ma'idah Chapter 5 Verse 32:
If anyone killed a person, not in retaliation of murder, or (and) to spread
mischief in the land - it would be as if he killed all mankind, & if anyone
saved a life, it would be as if he saved the life of all mankind.


On Fri, Feb 15, 2019 at 6:10 PM  wrote:

> How to sent OTPA  verification in mail while login with django
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/f92f30a2-8613-4f8d-8e2c-1f8b669965aa%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAMjBbiA%3D3-dQXQAQN1xJgpdX5wbzUCyPMn9OZQeNcWKip01i9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to sent OTPA verification in mail while login with django

[Kasper Laudrup]

Hi,

On 15/02/2019 09.38, aswaniachu1...@gmail.com wrote:

How to sent OTPA  verification in mail while login with django



According to https://acronyms.thefreedictionary.com/OTPA

OTPA can either mean:

Old Towne Preservation Association (Orange, CA)
Office of Tax Policy Analysis (various locations)
Out-of-Turn Plan Amendment
One Time Password Authentication
Optically-Tuned Patch Antenna
Office of Technology and Policy Analysis (US DOC)

I guess what you mean is "One Time Password Authentication"?

You would most likely have a much better chance of receiving help if you 
spend at least a few minutes describing exactly what you it is you want 
to achieve, what you have tried so far and which problems you are facing.


This might be a good start:

http://www.catb.org/esr/faqs/smart-questions.html

Kind regards,

Kasper Laudrup

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f03ce333-52e2-f4c6-e908-70f65f5d5a61%40stacktrace.dk.
For more options, visit https://groups.google.com/d/optout.

How to sent OTPA verification in mail while login with django

[aswaniachu1698]

How to sent OTPA  verification in mail while login with django

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f92f30a2-8613-4f8d-8e2c-1f8b669965aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django + React: State Management in React

[Alice Heaton]

Hello,

I'm wondering what people's approach to React state management is, in
particular for full stack web developers who work both on the Django and
React side of things.

Here are my initial thoughts, based on research more than experience.
I'm keen to hear other people's thoughts, and (even better) experiences.

There are a number of alternatives out there, but I'll consider three:

- React component state. On the plus side this comes out of the box. But
coming from an MVC[*] background, tying my state to UI components does
not feel right;

- Redux. I like the principles; immutability, asynchronous updates, the
state being of function of itself, reducers, etc. I'm ok with the
verbose implementation. What really bothers me is having to keep all my
state in one large unstructured object. Being used to Django's ORM this
feels like prehistory. Even using raw SQL is more structured than a
plain js object. Things like this:
https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape
make me feel like I'm basically re-implementing the database engine.

- MobX. Being used to writing models, MobX feels a lot more natural that
either of the other options. Models as classes, synchronous updates,
etc. There are people out there however who claim that MobX
re-introduces classes of bugs that Redux-like flows were designed to
eliminate (though I've not seen anyone provide actual examples of why
this is the case).

The above sounds like I would lean towards MobX; but then I'm wary of
making a choice because it feels more natural from a Django perspective.
Django is not a reactive framework, Django is a stateless build
pipeline. What is natural in Django might not fit well in a stateful
reactive context.

So - for those of you who combined Django and React, what state
management approach did you use (or are thinking of using) and why?

Thanks :)
Alice

[*] I know, MTV. Also I know that MVC is considered a bad word in js
frontend world.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/07dc5e71-0c22-c496-3180-090f24912d7a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

select_for_update Documentation is confusing(?)

[Philoj Johny]

In the documentation for select_for_update
,
given code example is:

from django.db import transaction
entries = Entry.objects.select_for_update().filter(author=request.user)with
transaction.atomic():
for entry in entries:
...

At the same time, below in the description it says that:

*Evaluating a queryset with select_for_update() in autocommit mode on
backends which support SELECT ... FOR UPDATE is a
TransactionManagementError

error because the
rows are not locked in that case.*

*Does this mean that the above code example will raise
**TransactionManagementError , since the select_for_update_query is
evaluated outside atomic block?*


*(I have'nt actually tried this out yet, will soon. I think may be a
correction is required in the code example)*

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFkxFaGcNMbaruWOoWBk%2BPVjyB9jZOY%2Bhm-677a3CvfJmESQrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.