Re: Improvements to the startproject template

[Olivier Dalang]

+1 for Adam's suggestion, I use it as well and like it very much.

> root folder
- manage.py
- ...
> myproject
- __init__.py
- settings.py
- urls.py
- ...
> myapp
- __init__.py
- models.py
- ...

Pros:
- everything is well namespaced under myproject (`myproject.settings`,
quite straightforward)
- makes it clear that `settings.py`, `urls.py`, etc. concern the project as
a whole, and not just an app.
- also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear
that myapp is part of this project)
- it leaves the root level for stuff like .gitignore, db.sqlite, etc, so
the actual source stays clean from such files.
- having a parent package allows (does not require) relative imports
across modules of the same project, which more clearly conveys that such
apps are tightly coupled
- with manage.py still in the root folder, you don't need to cd into any
folder to start working

I use it all the time.

Cheers,

Olivier




Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :

> I prefer Adam's suggestion in the forum post as it lets you namespace
> everything under your project name nicely and avoids package name
> collisions, although it doesn't solve the problem of having two directories
> with the same name by default.
>
> That said, either would be an improvement on what we have so I'm in favour
> of either approach over doing nothing.
>
> Cheers,
> Tom
>
> On Wed, 20 Apr 2022 at 16:49, John M 
> wrote:
>
>> I do exactly this for every new Django project, so it's +1 from me as
>> well.
>>
>> John
>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>
>> +1 for me - this would be really useful.
>>
>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org wrote:
>>
>>> Hi Tim,
>>>
>>> This feels like a good idea to me.
>>>
>>> Regards,
>>> Ian
>>>
>>> On Mon, 18 Apr 2022 at 18:17, Tim Allen 
>>> wrote:
>>>
 Greetings, friends!

 I've issued a PR that makes two changes to the `startproject` template:

- instead of putting configuration files such
as `settings.py`, `wsgi.py`, and the
root `urls.py` in `my_project/my_project`, they are created
in `my_project/config`
- start the project with a custom User model app, `users`

 Over the years, I've taught or tutored over 100 Djangonauts starting
 their first project. Having to distinguish between two directories with the
 same name is a constant pain point in the teaching process - "cd into
 my_project ... no, the other one!"

- The `config` option seemed to be the consensus from this thread
in the forum: Django New Project Structure/Name - Using Django -
Django Forum (djangoproject.com)

 
- Ticket: https://github.com/django/django/pull/15609

 It is sometimes better to show rather than tell, so following our own
 documentation and including a custom User model with the initial project
 template reinforces the best practice that we explicitly point out in the
 documentation.

- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
Django (djangoproject.com)

- Avoids ever having this come up again:

 https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/

 Here's a link to the PR: https://github.com/django/django/pull/15609

 My apologies for not starting with a discussion first. I'm an
 infrequent contributor to the Django codebase!

 Regards,

 Tim

>>> --
 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/33cb49d0-2469-47c0-920e-9501245c5a27n%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/a184bfc1-e3fb-4bd7-8378-292194e52595n%40googlegroups.com
>> 
>> .
>>
>> --
>> You received this message 

Re: django-admin startproject settings.py has some security holes

[Olivier Dalang]

Hi,

Just a reminder about this page in the docs:
https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
It basically already covers it all. Maybe a direct link to that page from
the settings file would be good enough?

Cheers,

Olivier

On Thu, Oct 24, 2019, 04:45 Josh Smeaton  wrote:

> A quick idea from the top of my head, is to change the assignment of
> SECRET_KEY in the generated settings to something like:
>
> SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY",
> "insecure-")
>
> It signals that secrets in the environment are a good idea, that the
> default generated value is insecure, and it still has a random part so that
> default sites aren't automatically hackable when deployed. There's no
> impact to people just getting started.
>
> We could go a small step forward and use `check --deploy` to check for the
> substring `insecure` (even though I believe the KEY is technically bytes?).
>
> Just throwing something out there.
>
>
> On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
>>
>> Is the requirement here to avoid introduce additional barriers to getting
>> up and running in local development, or to deploying a site so that it's
>> accessible from the public internet?
>>
>> Both of these are important goals, but trading off security against the
>> latter worries me. I don't think we're doing beginners any favors if we
>> make it easier for them to deploy sites with security issues, especially
>> since they won't be in a good position to appreciate the consequences.
>> Ideally we'd make it easy for beginners to deploy sites without security
>> issues, but that's a hard problem given the diversity of production
>> environments; in the meantime, I think we need to accept the reality that
>> figuring out how to store secrets *is* a prerequisite to deploying Django
>> in production, notwithstanding how much we wish it weren't.
>>
>> I'd be interested in trying to contribute a solution more secure than the
>> status quo without introducing more barriers to local development, if it
>> would have a chance of being accepted.
>>
>> Taymon
>>
>> On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
>>>
>>> It's just scope:
>>>
>>>* Not clear we need to _replace_ the space for books, and blog posts,
>>> and so on, in the main docs.
>>>
>>> and bandwidth:
>>>
>>>* These things are difficult to get right, and it needs someone to do
>>> them. (PRs always warmly received!)
>>>
>>> On balance, I have to say, I think the default project template does
>>> very well.
>>> Taking a beginner, say, and adding, "As well as the million things
>>> you're already dealing with, there are these things called environment
>>> variable and..." is a step I'd be very cautious about taking.
>>>
>>> Yes, granted, for professional deployment, you might want different —
>>> but we have to serve everyone.
>>>
>> --
> 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/3443dbe6-1a6a-45af-b5ec-08cf78426869%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/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%40mail.gmail.com.

PR for Admin view permission

[Olivier Dalang]

Hi !

Just wanted to draw attention towards PR 6734
 that adds a view permission to
Django admin (original work done by PetrDlouhy). I was hoping to get it
merged for 1.11, then 2.0.

I just merged in the new code, and now there's some tests failing again.

If I fix those, will it get merged ? I'm not familiar with Django's dev
process, but I think this checked all the boxes (PR reviewed, tests, doc,
other user's support, etc...).

Thanks for all the good work !

Olivier

-- 
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/CAExk7p2t2meDsmNhfcT8G0AoO%3Dh61D711vnD-YKC7MHkxTi7BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: (contrib.admin) Improving object deletion

[Olivier Dalang]

On the same topic (I'm not really sure whether it's not the same thing
you're talking about), currently, even if a user has not the permission to
delete an object via the change form (because of some custom logic in
modeladmin.has_delete_permission(request,obj) ), he can delete it via the
batch delete tool.

I think it's not really consistent, arguably a bug.

I guess this is the case because we use Queryset.delete(), which doesn't
allow for per-instance permission checking.

To me, the cleanest way to deal with this would be :

- have the default delete_selected action take
modeladmin.has_delete_permission(request,obj), and by the way, have the
default delete_selected use Model.delete() instead of Queryset.delete()
- provide a non default delete_selected_fast action work like the current
delete_selected action








2016-10-14 15:31 GMT+00:00 Tim Graham :

> Here is a ticket about the memory issue: https://code.djangoproject.
> com/ticket/10919
>
> It's hard for me to evaluate the other idea without looking at the code.
> If you want to open a ticket and provide a patch, go ahead.
>
> On Friday, October 14, 2016 at 9:08:16 AM UTC-4, Marcin Nowak wrote:
>>
>> Hi all.
>>
>> Sometimes there is huge amount of related objects. In the effect there is
>> no possibility to delete a model because of http timeout error.
>> Displaying objects to be deleted is quite nice feature, but just unusable
>> in cases like that.
>>
>> Another thing is that nobody will read 74k related objects. Believe me.
>> It is better to display a summary in that case.
>> To display the summary, a related objects must be counted and this is
>> time consuming process, of course, but we can count them similar way to
>> Collector's fast deletion (using querysets instead of counting models one
>> by one).
>>
>> There is also other design flaw in ModelAdmin.delete_view() - related
>> objects are counted twice: one time for display, and second time after
>> confirming deletion (for request.method==POST). For the second case django
>> is checking only permissions and collected objects aren't used for anything
>> else. Until Django provides no row-level permissions checking those can be
>> done without instantiating all related objects again.
>>
>> I'd like to suggest:
>>
>>- separation of permissions checking from related objects collector,
>>- adding configration option for ModelAdmin.delete_view (to display
>>related objects, display summary, or finally display nothing).
>>
>> Thank you.
>>
>> Marcin.
>>
> --
> 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/fb2c2044-241f-4ea6-9db2-
> ec2dafebbeb5%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 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/CAExk7p1dYqhbna5n78f0qGQR0g3qFZ1PRhH5rBQwbyFTcGzGfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: missing feature, View permission for django admin

[Olivier Dalang]

Dear List,

In the meantime, there are two failing builds (default and windows) for the
PR <https://github.com/django/django/pull/6734>.

I can't see what the error is because the links to the build output is a 404
<http://djangoci.com/job/pull-requests-trusty/7936/>and I wasn't able to
setup a working testing environnement yet. Any help would be greatly
appreciated to fix the PR !!

I really hope we can have this merged in master soon, so that it can be
tested a bit more before release. I'm using it locally (backported to 1.9)
and it works well so far, but it's only for a small project with few users.


Thanks,

Olivier



2016-08-05 11:20 GMT+00:00 Olivier Dalang <olivier.dal...@gmail.com>:

> Hi,
>
> As 1.10 is out now, I'd like to draw your attention again on this feature,
> still hoping to see it merged as soon as possible in the release process so
> that we get as much testing as possible.
>
> Thanks for all the great work,
>
> Olivier Dalang
>
>
>
> 2016-06-15 12:01 GMT+00:00 Tim Graham <timogra...@gmail.com>:
>
>> Just to give you my perspective so you don't feel ignored, after the 1.10
>> release is a better for reviewing and merging larger features than right
>> now.
>>
>> On Wednesday, June 15, 2016 at 7:40:44 AM UTC-4, Olivier Dalang wrote:
>>>
>>> Hi,
>>>
>>> I worked a bit on this feature lately. I rebased PetrDlouhy's great work
>>> (PR 5297 <https://github.com/django/django/pull/5297>) onto master in a
>>> new PR 6734 <https://github.com/django/django/pull/6734>.
>>>
>>> I think everyone agrees this is a very useful addition to the admin. If
>>> we also agree on the implementation; I suggest to merge as soon as possible
>>> so that we can benefit from as much testing as possible before release, and
>>> more importantly so that third parties have time to adapt their packages
>>> (grappelli...).
>>>
>>> Please let me know if there's anything more I can do.
>>>
>>> I'm really looking forward for this feature, and judging from the
>>> frequency this topic is raised on the ml, I'm not the only one ;)
>>>
>>> Thanks a lot,
>>>
>>> Olivier
>>>
>>>
>>>
>>> On 31 May 2016 13:20, "Tim Graham" <timog...@gmail.com> wrote:
>>>
>>>> This feature is tracked in https://code.djangoproject.com/ticket/8936.
>>>> Feel free to review, contribute to, or test the patch if you want to help.
>>>>
>>>> On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, Ander Ustarroz wrote:
>>>>>
>>>>> I am surprised this feature is not implemented yet, at the moment when
>>>>> we create a new model  three permissions are created automatically for the
>>>>> admin panel:
>>>>>
>>>>>- *add_permission*
>>>>>- *change_permission*
>>>>>-
>>>>> *delete_permission *
>>>>>
>>>>> We really missing the *view_permission* here, when we want staff to
>>>>> be able to see the content but not being able to modify it. Searching a
>>>>> bit,  you can find many different implementations to achieve this, but all
>>>>> of them are extending django.contrib.*admin.**ModelAdmin*. Having so
>>>>> many people rewriting these methods in my opinion is a clear sign that 
>>>>> this
>>>>> feature should be part of the core.
>>>>>
>>>>> Regards,
>>>>>
>>>> --
>>>> 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 post to this group, send email to django-d...@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/ms
>>>> gid/django-developers/cfe9b399-2486-4dff-97e6-1c3f94b13f65%4
>>>> 0googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/cfe9b399-2486-4dff-97e6-1c3f94b13f65%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 the Google Groups
>> "Django develop

Re: missing feature, View permission for django admin

[Olivier Dalang]

Hi,

As 1.10 is out now, I'd like to draw your attention again on this feature,
still hoping to see it merged as soon as possible in the release process so
that we get as much testing as possible.

Thanks for all the great work,

Olivier Dalang



2016-06-15 12:01 GMT+00:00 Tim Graham <timogra...@gmail.com>:

> Just to give you my perspective so you don't feel ignored, after the 1.10
> release is a better for reviewing and merging larger features than right
> now.
>
> On Wednesday, June 15, 2016 at 7:40:44 AM UTC-4, Olivier Dalang wrote:
>>
>> Hi,
>>
>> I worked a bit on this feature lately. I rebased PetrDlouhy's great work
>> (PR 5297 <https://github.com/django/django/pull/5297>) onto master in a
>> new PR 6734 <https://github.com/django/django/pull/6734>.
>>
>> I think everyone agrees this is a very useful addition to the admin. If
>> we also agree on the implementation; I suggest to merge as soon as possible
>> so that we can benefit from as much testing as possible before release, and
>> more importantly so that third parties have time to adapt their packages
>> (grappelli...).
>>
>> Please let me know if there's anything more I can do.
>>
>> I'm really looking forward for this feature, and judging from the
>> frequency this topic is raised on the ml, I'm not the only one ;)
>>
>> Thanks a lot,
>>
>> Olivier
>>
>>
>>
>> On 31 May 2016 13:20, "Tim Graham" <timog...@gmail.com> wrote:
>>
>>> This feature is tracked in https://code.djangoproject.com/ticket/8936.
>>> Feel free to review, contribute to, or test the patch if you want to help.
>>>
>>> On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, Ander Ustarroz wrote:
>>>>
>>>> I am surprised this feature is not implemented yet, at the moment when
>>>> we create a new model  three permissions are created automatically for the
>>>> admin panel:
>>>>
>>>>- *add_permission*
>>>>- *change_permission*
>>>>-
>>>> *delete_permission *
>>>>
>>>> We really missing the *view_permission* here, when we want staff to be
>>>> able to see the content but not being able to modify it. Searching a bit,
>>>>  you can find many different implementations to achieve this, but all of
>>>> them are extending django.contrib.*admin.**ModelAdmin*. Having so many
>>>> people rewriting these methods in my opinion is a clear sign that this
>>>> feature should be part of the core.
>>>>
>>>> Regards,
>>>>
>>> --
>>> 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 post to this group, send email to django-d...@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/ms
>>> gid/django-developers/cfe9b399-2486-4dff-97e6-1c3f94b13f65%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/cfe9b399-2486-4dff-97e6-1c3f94b13f65%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 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/4c529e2a-4cd3-4930-b532-
> c0d0a10c05cc%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4c529e2a-4cd3-4930-b532-c0d0a10c05cc%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 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/CAExk7p0ZxhE_VxVF4wo-2NsuHppB9aSHOVF9Eo6mVuDOQ1SmcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: missing feature, View permission for django admin

[Olivier Dalang]

Hi,

I worked a bit on this feature lately. I rebased PetrDlouhy's great work
(PR 5297 ) onto master in a new PR
6734 .

I think everyone agrees this is a very useful addition to the admin. If we
also agree on the implementation; I suggest to merge as soon as possible so
that we can benefit from as much testing as possible before release, and
more importantly so that third parties have time to adapt their packages
(grappelli...).

Please let me know if there's anything more I can do.

I'm really looking forward for this feature, and judging from the frequency
this topic is raised on the ml, I'm not the only one ;)

Thanks a lot,

Olivier



On 31 May 2016 13:20, "Tim Graham"  wrote:

> This feature is tracked in https://code.djangoproject.com/ticket/8936.
> Feel free to review, contribute to, or test the patch if you want to help.
>
> On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, Ander Ustarroz wrote:
>>
>> I am surprised this feature is not implemented yet, at the moment when we
>> create a new model  three permissions are created automatically for the
>> admin panel:
>>
>>- *add_permission*
>>- *change_permission*
>>-
>> *delete_permission *
>>
>> We really missing the *view_permission* here, when we want staff to be
>> able to see the content but not being able to modify it. Searching a bit,
>>  you can find many different implementations to achieve this, but all of
>> them are extending django.contrib.*admin.**ModelAdmin*. Having so many
>> people rewriting these methods in my opinion is a clear sign that this
>> feature should be part of the core.
>>
>> Regards,
>>
> --
> 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/cfe9b399-2486-4dff-97e6-1c3f94b13f65%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 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/CAExk7p0G%3DCGebL8y084ea9f3zgSjmWu%3DmWCm5JsbHyEbK6ionw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Good idea to transition from MS Access to local webapp built on Django?

[Olivier Dalang]

Hi,

We use it here for a similar use case (small NGO's project management
database) and are very happy. It's almost exclusively based on django-admin
to keep everything as modular and easy to maintain as possible, which means
our forms can't be too complex and do reflect the database schema (1 form =
1 database row plus it's 1 to n relations using inlines). We just have a
few specific views to render pdfs using wkhtmltopdf and a a custom
dashboard with shortcuts to the admin change list pages with predefined
filters/ordering.

I'm not very familiar with Access, so I can't easily compare, but the fact
every user can access the same last version through the browser is
definitely a big plus. No need to install, any OS works, users can access
the system from home, etc... By the way, Access and Django are not
necessarily exclusive, as you could perfectly access the database from
Access if you are to produce some specific queries/outputs from Access...

The authentication is very safe as long as you add a throttling on failed
login attempts limit and a session time out, but there are modules for that.

Some say that django-admin isn't meant to be exposed to the users, but only
to the webmaster/developer. I think this only applies to cases where you
don't control who's accessing the site and where you can't teach your users
how the site works.

If you have some more complex workflow needs, have a look at viewflow.io (I
don't use it but it looks interesting).

Any ways, you should just try it, even if you're completely new to python
you'll have something usable really quickly by following the tutorial.

Let us know how it works out !

Olivier



2016-04-29 16:52 GMT+00:00 Patrik Mjartan :

> Hi,
>
> I work for a very small company that I developed an application for, all
> using MS Access (it has back-end MS Access db - although this is planned to
> change to some more robust RDBMS, and a front-end app built in MS Access).
> Currently this app is used to calculate the exact wages of some employees
> (sorry, English is not my native language so I don't know how that type of
> wage is called here, but basically we look at how many products they
> produced and calculate it based on that. It's not a hourly wage). However,
> this summer I would like to expand it to do some order management too (ie.
> each order has specific products that need to be produced... each of those
> can be produced by our employees and so it's directly linked to the wages).
>
> However, it is very hard to manage everything using MS Access. Basically
> each time I make any change to FE or BE, I have to re-distribute the FE to
> all of the front-users. This is not a HUGE problem, the big problem,
> however, is within the MS Access itself, that is, it's very hard to manage
> all the forms as they are listed as simple names (ie. you cannot sub-group
> them efficiently to make a tree-view). Overall I cannot see myself working
> with MS Access in 5 years time as I can already see the scalability
> problems after a few months of working with it.
>
> What I thought of, however, is making a website that is only for local
> use, but is it possible to have the same functionality as a regular
> front-end app? Is this good idea to begin with? I had a brief look at
> Django (I'm VERY new to web-dev, but I'm a fast learner I like to think)
> and I really like it so far. But is it possible to have the same level of
> functionality MS Access offers? That is, for example a sub-form on a form
> that gives more details about the current record selected in the main form?
> Ie. main form consists of overview of 10 recent orders and the lower
> portion of the main form is a subform that displays some detailed info
> about a selected order.
>
> How does it stand from security-perspective if the app is changed from
> local to public? Obviously even on local I'd imagine I'd put a login
> requirement there, similar to how the admin page has it, but how safe is it
> regardless if put to public? Are there pre-determined measures that if
> taken, it will be 100% secure? As you'd imagine I wouldn't be very happy if
> someone deleted all of our inventory records because they could bypass the
> logging system.
>
> Is there any good literature I can read up on doing some similar
> exercises/examples? For instance: orders/inventory management web app?
>
> Thanks a lot in advance!
>
> --
> 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/57c05c25-e8a9-417c-864c-0b21ecb4bcf1%40googlegroups.com

Reopening of Ticket "list_display does not allow functions of referenced objects (#5863)"

[Olivier Dalang]

Dear List,

The idea of allowing relations lookups in the list display was proposed in
ticket #5863 , but it was
closed as wontfix 5 years ago.

The reason it was closed as wontfix is because it's quite easy to achieve
exactly the same result with a method on the ModelAdmin.

However, that workaround is much more verbose, and makes the code much less
readable. And I'm pretty sure I'm not the only one to use this in almost
all ModelAdmins.

What is your opinion about reopening the ticket ?

Compare the suggested syntax :

class BookAdmin(admin.ModelAdmin):
> list_display = ('title','author__name')


vs the current syntax :

class BookAdmin(admin.ModelAdmin):
> list_display = ('title','authorname')
> def authorname(self,obj):
> return obj.author.name if obj.author else '-'
> author_name.short_description = 'name'
> author_name.admin_order_field = 'author__name'



Thanks !

Olivier

-- 
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/CAExk7p0sn%3D7j7LQJf3ALOhYo5uZgOdGGb_ycZKX5vYpd-OnPuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: View permissions to admin

[Olivier Dalang]

Hi,

+1 for view permission and Petr's rationale

There's one use case where missing the view permission should even be
considered a bug: when you have foreign key with the raw id widget,
currently the user gets a 403 error in the popup if he doesn't have edit
permission on the related model.

Best,

Olivier


On 31 Jan 2016 17:10, "Petr Dlouhý"  wrote:

> Hi Markus, Adam,
>
> I looked to Django admin documentation (
> https://docs.djangoproject.com/en/1.9/ref/contrib/admin/). I don't see
> anything discouraging from such usage, but rather I see encouraging for
> usage as interface for content managers:
>
> "One of the most powerful parts of Django is the automatic admin
> interface. It reads metadata in your model to provide a powerful and
> production-ready interface that content producers can immediately use to
> start adding content to the site. In this document, we discuss how to
> activate, use and customize Django’s admin interface."
>
> I totally agree with that quote, Django admin is one of the top things
> that I love at Django. For it flexibility, easy development and usefulness.
> Why not to make Django strengthenesses even stronger? I use it in such ways
> and I am not aware about any "fiddling with the internals". The view
> permissions was first such case.
>
> If Django admin usage for such purposes is not intended, I would expect to
> see big fat warning as a first thing on that page.
>
> View permissions in admin seems to me as something very natural that is
> missing there. The implementation of that is very lightweight and nicely
> fitting - I mostly only added what was missing there. I wouldn't call that
> hacking.
> Yes, I was thinking of making an independent application, but that would
> probably be very difficult and would require to copy some code of the
> Django internals. That would require big hacking!
>
> 2016-01-31 17:49 GMT+01:00 Adam Johnson :
>
>> Hi,
>>
>> At YPlan we've hacked in view permissions to the admin, exactly because
>> of the reasons Markus talked about - it's the front end we've built for
>> employees, done rather than building a proper process-based interface. I
>> think it could just about be done in a third-party package (It might rely
>> on a patchy.patch  call though),
>> rather than incorporating it into Django - have you considered this? At
>> this point we're all in preference of a better toolbox for building
>> internal tools, as Markus is suggesting, rather than "improving" the admin.
>>
>> Adam
>>
>> On Thursday, January 28, 2016 at 6:17:26 AM UTC, Markus Holtermann wrote:
>>>
>>> Hi Petr, all,
>>>
>>> I managed to find some time to look into your PR (updated link:
>>> https://github.com/django/django/pull/5297) and the related issue:
>>> https://code.djangoproject.com/ticket/8936 .
>>> Also, related discussion:
>>> https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion
>>> and issues: https://code.djangoproject.com/ticket/820 and
>>> https://code.djangoproject.com/ticket/17295
>>>
>>> First of all, thank you for your your contribution and persistence.
>>>
>>> I think Django should provide an easy way to get a read-only view of
>>> your data in the database. However, I don't really like the integration
>>> into contrib.admin . As it stands now, people commonly use the admin as a
>>> front end for their employees instead of building a proper process-oriented
>>> interface. This may work to some degree but it's not uncommon that
>>> developers need to fiddle with the internals of the admin to make specific
>>> things work. Adding a read-only view to the admin would encourage people
>>> even more to use the admin for reasons where they shouldn't.
>>>
>>> I'd prefer an approach on a different level where Django gains a proper
>>> (de)serialization implementation. The implementation would e.g. leverage
>>> content negotiation to define the output, e.g. JSON, XML, HTML, etc.
>>>
>>> What I'm pretty much saying is, I'd rather see a proper django.rest (or
>>> whatever we wanna call it) instead of a feature on top of the convoluted
>>> admin which provides only half of what people probably want and use.
>>>
>>> Cheers,
>>>
>>> /Markus
>>>
>>> On Wednesday, August 26, 2015 at 9:49:58 PM UTC+10, Petr Dlouhý wrote:

 Hello all,

 I am still waiting for some information about what should I do next to
 get this pulled into Django. Isn't here somebody willing to take a look at
 this?

 PR is at https://github.com/django/django/pull/5108

>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>>