Re: Handle Form Submission

[Tawfeeq Zaghlool]

Thanks Faisal, I really appreciate it.
If I have any other questions, I will ask you then.
Thanks again mate :) :)

Tawfeeq Zaghlool

IoT Full Stack Developer || Project Manager & Youth Leader

+962 77 8891479

<+962778891479>



  



On Wed, May 29, 2024 at 2:35 PM Faisal Mahmood 
wrote:

> I'd be glad to craft a solution that addresses the issues you've outlined:
>
> Solutions:
>
> 1. Cancel Button Redirect Issue:
>
>- Problem: The cancel button in the popup redirects to items/ instead
>of items/user_id.
>- Solution:
>   - Pass user_id in the form: Modify your form in the popup to
>   include a hidden field containing the user_id retrieved from the
>   session. This ensures the user_id persists even after form
>   submission.
>   - Access user_id in the view: In the view handling the cancel
>   button form submission, access the user_id from the form data
>   (hidden field) or the session.
>   - Redirect with user_id: Use the retrieved user_id to construct the
>   correct redirect URL (items/user_id) and redirect the user there.
>
> Code Example (assuming a Django form):
>
> from django.shortcuts import redirect def handle_form_submission(request):
> if request.method == 'POST': form = YourForm(request.POST) if
> form.is_valid(): # Handle order submission logic (if applicable) if
> 'cancel' in request.POST: # Check for cancel button submission user_id =
> request.POST.get('user_id') # Get user_id from hidden field return
> redirect('items/{}'.format(user_id)) # Redirect with user_id # ... handle
> submit logic return render(request, 'your_template.html', {'form': form})
>
> 2. Back Button Redirect Issue:
>
>- Problem: Clicking the browser's back button after sending the
>message redirects to the popup instead of items/user_id.
>- Solution:
>   - Server-Side Session Flag: Set a session flag (order_submitted or
>   similar) after successfully sending the message.
>   - Check Session Flag in View: In the view handling the request
>   after clicking back, check for the presence of the session flag.
>   - Conditional Redirect: If the flag is present, redirect to
>   items/user_id. Otherwise, display the normal page content.
>
> Code Example:
>
> from django.shortcuts import render, redirect def after_message_view(
> request): if request.session.get('order_submitted'): del request.session[
> 'order_submitted'] # Remove flag to avoid confusion later return redirect(
> 'items/{}'.format(request.session.get('user_id'))) # ... display normal
> page content return render(request, 'your_template.html')
>
> Additional Considerations:
>
>- Messenger Chat Page: Consider using Django's built-in URL reverse
>functionality (reverse('messenger_chat_page')) to construct the URL
>for the chat page.
>- Error Handling: Implement robust error handling in both views to
>gracefully handle potential issues like missing session data or invalid
>form submissions.
>- Frontend UX: You might want to provide a more user-friendly
>experience by disabling the browser's back button or displaying a
>confirmation message when the user attempts to navigate back using the
>button.
>
> By implementing these solutions and considerations, you should be able to
> achieve the desired behavior for your Django application, ensuring that
> the cancel button and back button both redirect the user to the
> items/user_id URL as expected.
>
> don't hesitate to ask further info.
>
> On Monday, May 27, 2024 at 7:14:04 PM UTC+5 Tawfeeq Zaghlool wrote:
>
>> Hello Djangooos:
>>
>> I am building a simple Django application, that shows products in
>> items/employee_id url, the customer opens the link and start selecting the
>> items by clicking on them, then an action button appears to prepare for
>> submission to display a modal asking the customer to enter his data name,
>> phone number location and email, then the customer either clicks on submit
>> the order or cancel, if he clicks on submit the order button it will
>> redirect to messenger chat page with order details where he can send the
>> order which he selects, this popup window (handle_form_submission) asks the
>> customer to either send the message or cancel sending, send the message
>> button will open the Chat Page on The Agent chat page with a copy of the
>> Order details and wait for the customer to send the order, the cancel will
>> redirect the customer to the items/user_id url the same where he starts, if
>> the user clicks on send the order, and then clicks on a back button from
>> the browser it should redirect him also to the items/user_id url where he
>> starts, to start a new order or close the page.
>>
>> I have two issues as follows:
>>
>> 1- Cancel button in the popup redirect message doesn't redirect to the

Re: How to use different templates for different sites/domains

[Faisal Mahmood]

You're right, using a single Django instance to serve multiple sites with
overridden templates can be tricky. While a custom template loader might
seem appealing, it's true that it doesn't accept the request object by
default. Here's the breakdown and some alternative solutions:

The Challenge:

   - Django's default template loader doesn't consider the current domain
   when searching for templates.
   - You want to use a single Django instance but have domain-specific
   templates.

Less Ugly Solutions:

   1.

   Template Name Prefixing:
   - Prefix your template names with the domain name. For example,
  domain1/home.html and domain2/home.html.
  - In your views, construct the full template name based on the
  current domain (using get_current_site).
  - This approach is simple but can make template names lengthy and
  less readable.
   2.

   Template Inheritance with Context Processors:
   - Create a base template with common elements.
  - Inherit from the base template for each domain-specific template.
  - Use a context processor to inject the current domain information
  into the context.
  - In your domain-specific templates, use the domain information to
  conditionally render specific content.
  - This approach offers flexibility but requires more code in
  templates and context processors.
   3.

   Third-Party Packages:
   - Consider packages like django-sites-templates or
  django-multihost-template-loader.
  - These packages provide custom template loaders that can leverage
  the request object to determine the appropriate template based on the
  domain.
  - This approach can be a good option if the built-in solutions don't
  meet your needs.

Middleware with Context Variables (Least Ugly Hack):

   - While not ideal, storing the request object in a context variable
   using middleware is a workable solution.
   - However, be mindful of potential issues like variable name conflicts
   and unnecessary data passed to every template.

Choosing the Best Approach:

The best solution depends on your project's complexity and preference.
Here's a quick guide:

   - Simple Projects: Template Name Prefixing might suffice.
   - More Complex Projects: Consider Template Inheritance with Context
   Processors or Third-Party Packages for better maintainability.
   - Last Resort: Use the Middleware approach cautiously if other options
   aren't feasible.

Remember, the key is to find a balance between simplicity and
maintainability. Leverage built-in features and explore third-party
packages before resorting to complex hacks.

I'm available if you want further assistance or questions about it😎

Have a good day ahead.

On Wed, May 29, 2024, 5:52 AM Mike Dewhirst  wrote:

> On 28/05/2024 9:09 pm, Antonis Christofides wrote:
>
> Hello,
>
> I use the sites framework for a Django project that serves many different
> domains. But each of those domains has some templates overridden.
>
>
> Might depend on what you are overriding - entire templates or just
> includes or just vars.
>
> I would probably start by refactoring the templates so they were identical
> for all sites and reduce/extract the differences to includes which can be
> selected via contextvars after calling get_current_site() from the view.
>
> Have you looked at template tags?
>
> I use them for displaying additional information on the staging and dev
> sites versus production. Not what you are doing so I haven't thought too
> hard about that. Only worth a thought if you haven't considered it.
>
>
> If I used a different instance of Django (i.e. a different gunicorn
> service) for each domain, I'd have different settings for each site. But
> I'm using a single instance to serve all sites and, wherever I need to, I
> use things that extract the domain from the request, like
> `get_current_site()`. But this doesn't seem to work with templates. A
> custom template loader won't work without a fight because its methods don't
> accept the request object as an argument.
>
> All solutions I've thought about are ugly hacks.
>
>
> Practicality beats purity
>
> The least ugly seems to be to create middleware that stores the request
> object in a contextvar
> . But it strikes me
> that I can't find a simpler solution for this. Is what I want that
> uncommon, or am I missing something?
>
> There's an old closed "wontfix" ticket
>  about this but without
> adequate explanation.
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/175b4601-2038-479b-9581-48d9c196df7cn%40googlegroups.com
> 

Re: Django Admin Shortcuts

[Faisal Mahmood]

Hi, First of all Sorry for the late reply😉

Okay👌 let's go...

It is generally not recommended to authenticate auto-generated users
directly from inspect_db without proper user model fields and permissions.
Here's why:

   -

   Security Concerns:
   - AbstractBaseUser and PermissionsMixin provide essential
  functionalities for user authentication and authorization. They
  handle password hashing, permissions management, and other security
  aspects. Bypassing these models might lead to vulnerabilities like
  storing passwords in plain text or granting unauthorized access.
   -

   Maintainability Issues:
   - Using inspect_db creates a tight coupling between your authentication
  logic and the specific database schema. This makes it difficult to
  modify the user model or switch databases in the future.

Here are some alternative approaches to consider:

   1.

   Migrate User Model Fields:
   - Gradually migrate your existing user model to include the necessary
  fields from AbstractBaseUser and PermissionsMixin. This ensures
  proper authentication and authorization mechanisms.
   2.

   Custom User Model:
   - Create a custom user model that inherits from AbstractBaseUser and
  includes any additional fields you need. This provides a more secure
  and maintainable approach.
   3.

   Alternative Authentication Methods:
   - Depending on your application's requirements, you might explore
  alternative authentication methods like API keys, tokens, or social
  logins. These can be suitable for non-human users or specific use
  cases.

While it might be technically possible to authenticate through inspect_db,
it's strongly advised against it due to the security and maintainability
drawbacks. Consider the alternative approaches mentioned above for a more
secure and robust solution.

On Wed, May 29, 2024, 3:06 AM utibe solomon  wrote:

> Hey bro is it possible to authenticate an auto generated user from
> inspect_db without necessarily having to migrate fields that come with
> using abstractbaseuser and permissions mixin
>
>
> On Tue, 28 May 2024 at 20:39, Mike Schem 
> wrote:
>
>> Hey Faisal,
>>
>> Thanks for taking the time to read the PR and provide some feedback. I
>> copied all of your concerns here and responded to them accordingly. Please
>> let me know if you have any further questions!
>>
>> 1.
>> Have you considered including a section in the Django admin documentation
>> that outlines the new shortcuts and how to use them?
>>
>> Yes, I absolutely will document this, I was thinking about adding it to
>> the "Other Topics" section here:
>> https://docs.djangoproject.com/en/5.0/ref/contrib/admin/#other-topics.
>> What do you think?
>>
>> 2.
>>  Are the keyboard shortcuts configurable?
>>
>> Not yet, but I would be open to doing this as a future PR.
>>
>> 3.
>> Have you tested the keyboard shortcuts across different browsers and
>> operating systems to ensure consistent behavior?
>>
>>  Any specific browsers or versions where you faced issues?
>>
>> Yes, we've tested on pretty much all major OSs and browsers and have seen
>> consistent behavior.  I've been running this in my company for over a year
>> now. It's been great!
>>
>> 4.
>> What considerations have been made regarding accessibility?
>>
>> I'd say this is largely an accessibility feature since it would allow for
>> the visually impaired to save without needing to see the save buttons,
>> which is great!
>>
>> 5.
>> How does the implementation handle potential conflicts with existing
>> browser or system shortcuts?
>>
>> There is an existing ctrl + S for saving browser pages as HTML, frakely,
>> I don't think that should be the default for users. When saving the page,
>> the action should not be to save it as html, but instead save the content
>> of the admin.
>>
>> 6.
>> Have you noticed any performance impacts with the addition of these
>> shortcuts? Ensuring that the admin interface remains performant is
>> important for all users.
>>
>> No, no performance issues. It's a very simple code change without much
>> impact.
>>
>> On Sat, May 25, 2024 at 7:25 AM Faisal Mahmood <
>> faisalbhagri2...@gmail.com> wrote:
>>
>>> Hi *Mike Schem,
>>>
>>> Thank you for reaching out and for your work on adding keyboard
>>> shortcuts to the Django admin. This is a valuable feature that can greatly
>>> enhance productivity for many users. We appreciate your contribution and
>>> the effort you've put into this PR.
>>>
>>> We have reviewed your pull request and are excited about its potential.
>>> Here are some thoughts and questions we have:
>>>
>>> 1.
>>> Have you considered including a section in the Django admin
>>> documentation that outlines the new shortcuts and how to use them?
>>>
>>> 2.
>>>  Are the keyboard shortcuts configurable?
>>>
>>> 3.
>>> Have you tested the keyboard shortcuts across different browsers and
>>> operating systems to ensure consistent behavior?
>>>
>>>  Any specific browsers o