Re: Static Code analysis and Security Scanning tools for Django Web Applications

[Paul Tiplady]

I also use safety  to scan for package 
vulnerabilities in the pipeline. This is similar to a repo-scanning app 
like Dependabot or Snyk.

Prospector is decent, although I found it preferable to use pre-commit 
 to wire up individual tools like bandit, black, 
./manage.py check, safety, flake8 -- that way I can run them as individual 
build jobs that run in parallel in the build pipeline, rather than one 
command invocation.

On Tuesday, July 5, 2022 at 10:17:14 PM UTC-7 ram.mu...@gmail.com wrote:

> Hi,
>
> We have tried Prospector tool: https://prospector.landscape.io/en/master/
>
> and got the following result
>
>
> Check Information
>> =
>>  Started: 2022-07-05 20:29:59.548372
>> Finished: 2022-07-05 20:38:58.411776
>>   Time Taken: 538.86 seconds
>>Formatter: grouped
>> Profiles: default, no_doc_warnings, no_test_warnings, 
>> strictness_medium, strictness_high, strictness_veryhigh, no_member_warnings
>>   Strictness: None
>>   Libraries Used: django, celery
>>Tools Run: dodgy, mccabe, profile-validator, pycodestyle, 
>> pyflakes, pylint
>>   Messages Found: 17186
>
>
> but wondering if you guys use any other better tools than this. Our goal 
> is find out gaps and error from the following items:
>
> 1. Security scanning
> 2. Static code analysis
> 3. Vulnerabilities scanning
>
> Best regards,
> ~Ram
>
>
>
>
>

-- 
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/1edee7b5-f410-4759-9316-a6705360ea78n%40googlegroups.com.

Using activate() to set the timezone in Model Admin

[Paul Tiplady]

I'd like to have my Admin site use a different default timezone than the 
rest of my django app.

I prefer the backend and API to operate in UTC, because this is a general 
good practice for geographically distributed teams. However admin users 
(based in a specific timezone) find this confusing, and would like to see 
their datetimes in a local timezone (say, Pacific Time).

The docs state that a local time can be set using 
activate(): 
https://docs.djangoproject.com/en/4.0/ref/utils/#django.utils.timezone.activate

Specifically: 
https://docs.djangoproject.com/en/4.0/topics/i18n/timezones/#default-current-time-zone
 
says "You should set the current time zone to the end user’s actual time 
zone with activate() 
.
 
Otherwise, the default time zone is used.".

Where should this be done to set the timezone only in the admin?

Simon Wilson has a suggestion to set this globally using 
Middleware: https://til.simonwillison.net/django/show-timezone-in-django-admin

I'm wondering if there's a better way that won't affect the TZ of non-admin 
requests. It seems that this should be configurable somewhere on the 
AdminSite.

Has anyone made this work specifically for the Django Admin?

Thanks!

-- 
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/7d09876e-5cdf-4010-abb1-bdbf5a71f41fn%40googlegroups.com.

Re: Where are you deploying Django App? How much does it cost for a hobby project

[Paul Tiplady]

You can deploy to Heroku, there's a free tier and it's very low maintenance.

https://devcenter.heroku.com/articles/deploying-python

I've had a free Django app running there that I set up almost 10 years ago 
without any work required to keep it up since then.

Heroku is somewhat expensive if you actually get enough traffic that you 
need to start paying them, but it's ideal for the MVP / proof-of-concept 
phase of a project. If you're price-conscious and want to scale up a bit 
more, you can rent a dedicated VM for $5/month (for example, Digital Ocean 
droplets https://www.digitalocean.com/pricing/) and that will get you a lot 
more capacity per $. That said, you may find that the convenience of Heroku 
is worth paying for.

On Sunday, October 3, 2021 at 9:27:25 AM UTC-7 avi.me...@gmail.com wrote:

> Hello! I am building a prototype Django app and would like to deploy it so 
> that people can use it.
> What would be the most cost-effective and cheapest deployment solution to 
> host a django backend? How much would it cost?
> Any ideas, help is most welcomed and appretiated
>

-- 
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/7fdd43b6-5bca-4cc1-90df-7e277d19b5d7n%40googlegroups.com.

Handling multiple timezones in Django Admin

[Paul Tiplady]

Timezone handling in the Django admin is quite confusing when there are 
users in multiple timezones -- does anyone have a good way of handling this?

I'm using USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N. I have admin 
users in US/Pacific and US/Eastern.

When viewing a datetime field, users see the UTC time, with a note below 
saying "Note: You are 7 hours behind server time". This is better than 
nothing, but still quite sub-par for a 201x-era web UI. We really should be 
localizing the timezones in the browser to the user's own time zone, and 
submitting back to the app using TZ-aware timestamp strings. (It's possible 
to pull the TZ unambiguously from a modern 
browser: https://stackoverflow.com/a/37512371/37481).

Any suggestions for getting round this? I'm wondering if there's a good 
tz-aware datetime widget for the admin? Or perhaps a clean way of storing a 
User.time_zone config property that could be used to localize the admin 
cleanly.

Cheers,
Paul

-- 
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/36a1bd2c-490d-4ad8-86f6-0af5425bb7f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: In the Admin, Is it possible to make filters on foreign keys usable with lots of related objects?

[Paul Tiplady]

I've used that in a few admin pages, as far a I understand it just
restricts the allowed values for a model's foreignkey field when editing a
model instance. I don't see any way to use that to change how the
`list_filter` functions -- am I missing something?

Thanks,
Paul

On Fri, Feb 2, 2018 at 3:57 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

> On 3/02/2018 5:23 AM, Paul Tiplady wrote:
>
>> Currently it's simple to configure a filter on a foreign key in the admin:
>>
>> `list_filter = ['theforeignkeyfield']`
>>
>> However in practice this is barely usable in most cases that I've
>> encountered, since the admin uses RelatedFieldListFilter, which fetches the
>> full list of objects from the DB and loads them into the browser. For any
>> production site that either times out or makes the admin unusably slow, not
>> to mention the UX is terrible as it inserts a list of all of the items into
>> the filter bar that needs to be scrolled through.
>>
>> I'm not sure if this is fixed in 2.0 (I haven't played with the new
>> select2 integration that was added), but is there a plugin / workaround to
>> use something like django-autocomplete-light, or a `raw_id_field` type
>> approach in pre-2.0?
>>
>
> Have you looked at  ...
>
> https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#
> django.contrib.admin.ModelAdmin.formfield_for_foreignkey
>
> M
>
>
> --
>> 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 > django-users+unsubscr...@googlegroups.com>.
>> To post to this group, send email to django-users@googlegroups.com
>> <mailto: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/ms
>> gid/django-users/4e610074-ff8c-494d-977e-cf701c8cd92f%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-users/4e610074-ff8
>> c-494d-977e-cf701c8cd92f%40googlegroups.com?utm_medium=email
>> _source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/django-users/j2pDXmEGvJE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ms
> gid/django-users/89fd33b4-c8fb-09ac-1f0b-296f82463f55%40dewhirst.com.au.
>
> 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/CAA%2BchP8RGR8HtC61bSAftMcexhQigLZsxy-tVd3T5jmz8P_HQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: In the Admin, Is it possible to make filters on foreign keys usable with lots of related objects?

[Paul Tiplady]

That's a pretty inflexible solution though; what if I want to filter on
multiple foreign keys, e.g. Tenant=Foo(id=1), Customer=Bar(id=200)?

On Fri, Feb 2, 2018 at 12:57 PM, Andy  wrote:

> You should rather use search_fields instead of filtering together with the
> sorting ability of the admin. Thats much more suited for a scenario like
> described above.
> The filter is for status fields or something with just a few different
> entries, otherwise build your own filter to filter for some specific values.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-users/j2pDXmEGvJE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/1ffa9984-7775-49d1-bc78-6dd2de7fcf5d%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/CAA%2BchP-6LhZhu3g13Zv4g%3D9qOywB8E9HhVJPnA-%3DTe0jB1JpNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Newbie - Microservice in Django - Best place to start learning

[Paul Tiplady]

Assuming you're trying to build a REST API and not a HTML website, you 
should look at http://www.django-rest-framework.org/ as it provides a lot 
of djangonic convenience methods for building REST APIs with the Django ORM.

On Thursday, February 1, 2018 at 9:16:47 AM UTC-8, pratibha sharma wrote:
>
> Hi,
>
> I have created 2 example websites in Django i.e. Voting and event booking 
> systems. 
> I want to learn to create microservice in Django. I took below example for 
> it.
>
> Service will 
> 1. take data from UI (it will send it in JSON format), 
> 2. store data in DB(MySQL)
> 3. Send Data to a device (in JSON format)
>
> My mind is flooded with questions like 
> how UI and service with communicate? 
> how can service communicate to device? etc.
>
> I am not sure where should I start and how to create the design for this 
> work. I am new in microservice and some experience in django.
>
> Please guide me.
>

-- 
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/ee24fd34-b612-4d79-8980-c79fbd4e54bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

In the Admin, Is it possible to make filters on foreign keys usable with lots of related objects?

[Paul Tiplady]

Currently it's simple to configure a filter on a foreign key in the admin:

`list_filter = ['theforeignkeyfield']`

However in practice this is barely usable in most cases that I've 
encountered, since the admin uses RelatedFieldListFilter, which fetches the 
full list of objects from the DB and loads them into the browser. For any 
production site that either times out or makes the admin unusably slow, not 
to mention the UX is terrible as it inserts a list of all of the items into 
the filter bar that needs to be scrolled through.

I'm not sure if this is fixed in 2.0 (I haven't played with the new select2 
integration that was added), but is there a plugin / workaround to use 
something like django-autocomplete-light, or a `raw_id_field` type approach 
in pre-2.0?

-- 
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/4e610074-ff8c-494d-977e-cf701c8cd92f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatic reverse migrations

[Paul Tiplady]

I think it's possible to do better than the current status quo with a bit
more metadata, and without changing the current flow for users that don't
want/need more -- essentially all I'm looking for is a way to record which
migrations were applied in a given run of `./manage.py migrate`, so that I
can revert the same set in a downgrade. This would be equally useful for
reversing manually applied migrations as for doing an automated rollback.

The API I'm thinking of is something like this (zero thought invested in
naming):

```
# ./manage.py migratewithtag 1.2.3
> running migration app1.0002
> running migration app2.0004
> writing tag before and after state to django_migrationtags table
{app1:{before: 0001, after:0002},...}
# ./manage.py rollbacktag 1.2.3
> running migration app1.0001
> running migration app2.0003
```

This is essentially just a layer of metadata above the current migrations
table.

I've yet to start playing with an implementation, but of course suggestions
welcome for potential problems with this approach.

On Mon, Apr 17, 2017 at 5:21 PM, Mike Dewhirst 
wrote:

> On 18/04/2017 9:58 AM, p...@qwil.co wrote:
>
>> Thanks Andrew, will see what I can rustle up.
>>
>> Camilo -- blue/green deploys don't really help with this problem. As each
>> application deployment still talks to the same database, once you have run
>> the migration you can't just abandon your deployment, you need to unwind
>> the db migration first.
>>
>
> I agree it is an unsolvable problem to automate it. Or rather, not worth
> the development cost of making an automatic "unwinder".
>
> For the number of times it is likely to be needed in general it would be
> less costly to do another new migration towards the previous state.
>
>
>> On Saturday, April 15, 2017 at 6:01:03 PM UTC-7, Camilo Torres wrote:
>>
>> Hi,
>> May both of you try to implement "blue-green deployments", and
>> switch only if all tests are OK.
>> You may also be interested in running a test deployment in a
>> testing environment prior to production.
>> Don't know of a solution integrated into django.
>>
>> On Friday, April 14, 2017 at 2:26:51 PM UTC-4, Andrew Godwin wrote:
>>
>> Hi Paul,
>>
>> I have tried this in the past, but it's basically an
>> unsolvable problem in the generic case. Databases do not take
>> well to snapshotting or changing schema, and some operations
>> are naturally irreversible. If you find a way that works well,
>> I suggest you write it up so others can learn from it!
>>
>> Andrew
>>
>> On Fri, Apr 14, 2017 at 10:33 AM,  wrote:
>>
>> In a modern Continuous Delivery environment, it's expected
>> that there is an automated process for deploying code, and
>> therefore performing database migrations. This is all
>> straightforward.
>>
>> I haven't been able to find any good solutions for
>> automatic rollback though. The main problem that I see is
>> that there is (AFAIK) no easy way to definitively know
>> which migrations to unapply to roll back to the previous
>> verison. If you try to rollback from the new N+1 version,
>> you have the migrations, but no recording of the previous
>> version's state. If you rollback from the previous N
>> version, you don't have the new migration files to do the
>> DB rollback.
>>
>> What I'd really like is a way of recording a 'db migration
>> checkpoint' which could be generated per-release (or
>> whenever else you care to checkpoint your migration
>> state), and would say something like `v1: {app1:0002,0003,
>> app2: 0004}, v2: {app1:0004, app2: 0005, 0006}`, thus
>> letting me roll back all of the migrations in the v2
>> deploy with a single command.
>>
>> Does anyone have suggestions or references here? I may try
>> rolling the above solution if there is no prior art, but I
>> want to avoid reinventing the wheel here, as it seems that
>> this issue must have been hit by many other users before me.
>> -- 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/6cafecca-2c71
>>