from:"Riccardo Magliocchetti"

Re: queryset .all() behavior change in 3.2

2021-07-13 Thread Riccardo Magliocchetti

Hi Uri,

I'm not arguing that the code was correct :) I'm just reporting a reproducible
change in behavior. The tests did run fine with 2.2 and 3.1 and bumping to 3.2
required a code change.

Thanks

On 13/07/21 17:07, אורי wrote:

Hi Riccardo,

It looks to me that *obj.relatedobj_set.all()* has to be evaluated before
setting *obj.pk <http://obj.pk> = None*. *for* and *list()* causes it to be
evaluated. So it's better programming to evaluate it on the lines above
setting *obj.pk <http://obj.pk> = None*. I'm not sure how it is related to
Django versions, though.

Uri.
אורי
u...@speedy.net

On Tue, Jul 13, 2021 at 5:36 PM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

Hello,

when porting a django application from 3.1.13 to 3.2.5 I found a behavior
change
I don't see documented in the release notes.

The code is cloning a an object and all its related objects by settings
the pk
to None. Previously storing a queryset of related objects was enough to
being
able to iterate on that even if the original object was cloned, now we
have to
make it concrete by calling list() on it.

Code was something like the following:

def clone_object(obj):
related_objs = obj.relatedobj_set.all()
obj.pk = None
obj.save()
for related in related_objs:
related.pk = None
related.object = obj
related.save()

And now the related_object line is as:

related_objs = list(obj.relatedobj_set.all())

Is it something that should be documented in the release notes?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

queryset .all() behavior change in 3.2

2021-07-13 Thread Riccardo Magliocchetti


Hello,

when porting a django application from 3.1.13 to 3.2.5 I found a behavior change 
I don't see documented in the release notes.


The code is cloning a an object and all its related objects by settings the pk 
to None. Previously storing a queryset of related objects was enough to being 
able to iterate on that even if the original object was cloned, now we have to 
make it concrete by calling list() on it.


Code was something like the following:

def clone_object(obj):
related_objs = obj.relatedobj_set.all()
obj.pk = None
obj.save()
for related in related_objs:
related.pk = None
related.object = obj
related.save()

And now the related_object line is as:

related_objs = list(obj.relatedobj_set.all())

Is it something that should be documented in the release notes?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/2472148f-0503-65de-c3cd-8a0ad4903011%40gmail.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

2020-05-06 Thread Riccardo Magliocchetti


Hello,

On 05/05/20 23:26, Adam Johnson wrote:

request.GET and request.POST are misleadingly named:

- GET contains the URL parameters and is therefore available whatever
the request method. This often confuses beginners and “returners” alike.
- POST contains form data on POST requests, but not other kinds of data
from POST requests. It can confuse users who are posting JSON or other
formats.

[...]>

I therefore propose these renames:

- request.GET -> request.query_params (to match Django Rest Framework -
see below)
- request.POST -> request.form_data
- request.FILES -> request.files
- request.COOKIES -> request.cookies
- request.META -> request.meta


Yes please, query_params to match DRF makes a lot of sense to me!
These days i use mostly DRF views, still have to maintain plain Django code so 
anything reducing the difference is much appreciated



Since these are very core attributes and the change would cause a huge
amount of churn, I propose not deprecating the old aliases immediately, but
leaving them in with a documentation note that they "may be deprecated."
Perhaps they can be like url() or ifequal which came up on the mailing list
recently - put through the normal deprecation path after a few releases
with such a note.


Given these are on most tutorial / book ever published on paper and on the 
internet I'd just make them an alias of the new proposed names and kept for 
quite a few.


Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/34ff0853-d984-65f3-c63c-71d32015963d%40gmail.com.

Re: include only columns from selected related models in select_related query

2019-02-11 Thread Riccardo Magliocchetti

Hello Collin,

Il 11/02/19 17:35, Collin Anderson ha scritto:

So would you "defer" the other columns like "only()"?

Yeah, something like that

If nothing else, you could try using .annotate(F('author__hometown')) (not
sure if that works) or .values('author__hometown') to just get the values
you need.

Sure but the query would be everything but readable :)
The point of a parameter to select_related would be to avoid to type explicitly
fields not in select_related and the one in select_related twice.

On Mon, Feb 11, 2019 at 5:50 AM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

Hello,

I'm debugging views leaking lots of memory in django 1.11. It looks like
there
is some connections with my usage of select_related(). But that's mail is
not
about that, not sure about my findings yet :)

So I have looked again at the select_related documentation here:
https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related

and found this:
Book.objects.select_related('author__hometown').get(id=4) will cache the
related
Person and the related City

Up until now i thought that only the related model i've specified would
get
added to selected columns e.g. only the City because of hometown. But it
looks
that's not how it is :)

Would it make sense to add a parameter to change select_related behaviour
to
include only the columns of the related models specified? That could save
quite
a lot of bandwitdh for some use cases.

What do you think?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Riccardo Magliocchetti


Il 11/02/19 13:06, Raffaele Salmaso ha scritto:

On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:


InvalidTemplateLibrary: Invalid template library specified. ImportError
raised
when trying to load 'django.contrib.admin.templatetags.base': cannot
import name
getfullargspec

1.11.18 works fine for the same test.


Hi Riccardo, please check if you use the correct django version,
django.contrib.admin.templatetags.base is there from django 2.1


Yeah, what i'm reporting is that the wheel pip downloaded here does not match 
the 1.11.19 tag in git.


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/fd8fde53-2e3b-84b4-4fcf-154a82771515%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Riccardo Magliocchetti


Hello Carlton,

filed here:
https://code.djangoproject.com/ticket/30175

Il 11/02/19 12:58, Carlton Gibson ha scritto:

Hi Riccardo.

Please open a Trac ticket for this. (Current test suite passes, so it looks
like we're missing coverage somewhere.)
Thanks.

On Monday, 11 February 2019 12:26:04 UTC+1, riccardo.magliocchetti wrote:


Hello Carlton,

Il 11/02/19 12:02, Carlton Gibson ha scritto:

Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our

security process. These releases address a security issue, and we encourage
all users to upgrade as soon as possible:


https://www.djangoproject.com/weblog/2019/feb/11/security-releases/



1.11.19 blew my tests on python 2.7, python3 works fine:
File "/usr/local/lib/python2.7/site-packages/django/template/base.py",
line
184, in __init__
  engine = Engine.get_default()
File
"/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line
124, in wrapper
  result = user_function(*args, **kwds)
File
"/usr/local/lib/python2.7/site-packages/django/template/engine.py", line
76, in get_default
  django_engines = [engine for engine in engines.all()
File "/usr/local/lib/python2.7/site-packages/django/template/utils.py",
line
89, in all
  return [self[alias] for alias in self]
File "/usr/local/lib/python2.7/site-packages/django/template/utils.py",
line
80, in __getitem__
  engine = engine_cls(params)
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 30, in __init__
  options['libraries'] = self.get_templatetag_libraries(libraries)
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 48, in get_templatetag_libraries
  libraries = get_installed_libraries()
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 113, in get_installed_libraries
  for name in get_package_libraries(pkg):
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 130, in get_package_libraries
  "trying to load '%s': %s" % (entry[1], e)
InvalidTemplateLibrary: Invalid template library specified. ImportError
raised
when trying to load 'django.contrib.admin.templatetags.base': cannot
import name
getfullargspec

1.11.18 works fine for the same test.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it






--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/934e1e54-a7c0-432c-af55-5679bc698ea0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

2019-02-11 Thread Riccardo Magliocchetti


Hello Carlton,

Il 11/02/19 12:02, Carlton Gibson ha scritto:

Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our security 
process. These releases address a security issue, and we encourage all users to 
upgrade as soon as possible:

https://www.djangoproject.com/weblog/2019/feb/11/security-releases/



1.11.19 blew my tests on python 2.7, python3 works fine:
  File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 
184, in __init__

engine = Engine.get_default()
  File "/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line 
124, in wrapper

result = user_function(*args, **kwds)
  File "/usr/local/lib/python2.7/site-packages/django/template/engine.py", line 
76, in get_default

django_engines = [engine for engine in engines.all()
  File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", line 
89, in all

return [self[alias] for alias in self]
  File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", line 
80, in __getitem__

engine = engine_cls(params)
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 30, in __init__

options['libraries'] = self.get_templatetag_libraries(libraries)
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 48, in get_templatetag_libraries

libraries = get_installed_libraries()
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 113, in get_installed_libraries

for name in get_package_libraries(pkg):
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 130, in get_package_libraries

"trying to load '%s': %s" % (entry[1], e)
InvalidTemplateLibrary: Invalid template library specified. ImportError raised 
when trying to load 'django.contrib.admin.templatetags.base': cannot import name 
getfullargspec


1.11.18 works fine for the same test.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/65914ae6-3647-322e-8b58-d4c095a4967f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

include only columns from selected related models in select_related query

2019-02-11 Thread Riccardo Magliocchetti

Hello,

I'm debugging views leaking lots of memory in django 1.11. It looks like there
is some connections with my usage of select_related(). But that's mail is not
about that, not sure about my findings yet :)

So I have looked again at the select_related documentation here:
https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related

and found this:
Book.objects.select_related('author__hometown').get(id=4) will cache the related
Person and the related City

Up until now i thought that only the related model i've specified would get
added to selected columns e.g. only the City because of hometown. But it looks
that's not how it is :)

Would it make sense to add a parameter to change select_related behaviour to
include only the columns of the related models specified? That could save quite
a lot of bandwitdh for some use cases.

What do you think?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

Re: Rate limiting failed login attempts/failed password changes

2017-11-15 Thread Riccardo Magliocchetti


Il 15/11/2017 12:07, Bernhard Posselt ha scritto:

Hi guys,

We've received a report from hackerone.com that our password change and login 
forms are not protected against brute forcing passwords. Since we re-use both 
the built-in password change and login form views from Django it feels like rate 
limiting for these views should work out of the box.


Using third-party extensions for this is certainly an option but I already have 
trouble to upgrade to newer versions with my existing 7 django extensions and it 
feels like this feature should be implemented for every Django installation that 
uses contrib.auth.


What are your thoughts on this?


Is there anything wrong on doing rate limit on the http proxy? There are good 
chances it's already implemented there.


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/91b95aaa-bf49-182f-f2e3-2cf571397da0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: migrations operation to alter model bases

2016-12-14 Thread Riccardo Magliocchetti

Hello,

thanks for the hints

Il 13/12/2016 19:51, Tim Graham ha scritto:

There are a few open tickets that may be related:

https://code.djangoproject.com/ticket/23521 - removal of concrete Model from
bases doesn't remove it from ModelState bases

Yeah, this looks like it. This also is an interesting read on the same argument
https://code.djangoproject.com/ticket/23818 . I've added a comment on the issue
to get some feedback.

https://code.djangoproject.com/ticket/26488 - migrate raises InvalidBasesError
if you rename a multitable inheritance base model

On Tuesday, December 13, 2016 at 12:40:45 PM UTC-5, riccardo.magliocchetti
wrote:

Hello,

on a journey to change a model from a concrete inheritance to an abstract
one
i've created a migration operation to change the bases of a model state in
the
migrations machinery. Is there a reason that there's not one in django?
Would it
be interesting to add it?

thanks in advance

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto: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/8f0e667d-6241-43f3-9ef6-ed899dac801f%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/8f0e667d-6241-43f3-9ef6-ed899dac801f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

migrations operation to alter model bases

2016-12-13 Thread Riccardo Magliocchetti


Hello,

on a journey to change a model from a concrete inheritance to an abstract one 
i've created a migration operation to change the bases of a model state in the 
migrations machinery. Is there a reason that there's not one in django? Would it 
be interesting to add it?


thanks in advance

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/81d664eb-8019-4c6f-c97f-4dd49fd9283a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: change commit message format to present tense?

2016-06-27 Thread Riccardo Magliocchetti

Il 27/06/2016 11:49, Reinout van Rees ha scritto:

Op 26-06-16 om 05:31 schreef Kevin Christopher Henry:

If anyone's put off by the hectoring tone of the imperative mood, it
might be better to think of it as the indicative mood. That is:

(This will) "add password validation to prevent the usage of...".

rather than

(You must) "add password validation to prevent the usage of..."!

"It might be better to think of it as...": it is exactly this extra thinkwork
that everyone reading the messages has to do. We write it once and read it many
times: what should we optimize for?
In our source code, the answer is clearly that you should optimize for
readability.
Why is it suddenly different for commit messages?

I think you are overthinking here :) just look at django commit history vs the
git or the linux one. Which commit message would you like to when chasing a bug?

They have a far better culture at that to what in my experience have found in
the python ecosystem. So let's just copy that :)

--
Riccardo Magliocchetti
@rmistaken

Re: thinking about the admin's scope and its description in the docs

2016-02-10 Thread Riccardo Magliocchetti


Hello,

Il 10/02/2016 00:25, Tim Graham ha scritto:

The introduction to the admin in the docs [0] reads:

"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."


I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface.
It reads metadata from your models to provide a quick and rudimentary
interface where trusted users can manage content on your site.


s/rudimentary/basic/ maybe? As a non native english speaker rudimentary does not 
sound positive.




The admin has many hooks for customization but beware of trying to use those
hooks exclusively. If your needs outgrow what the admin provides, it may be
simpler to write your own views. The admin’s recommended use is as an
organization’s internal management tool. It’s not intended for building your
entire front end around."


To me that the intended use of the admin as internal management tools has been 
kinda obvious given it's accessible to user flagged as staff.


[snip]

I know there have been some proposals of "admin2" but realistically I think the
admin has too many customizations points such that superseding it with something
new and innovative won't be feasible from a backwards compatibility standpoint.


Wasn't the plan to revise these customizations points and thus probably breaking 
backwards compatibility anyway?



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/56BAF8E2.3020706%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: admin: implementing list_prefetch_related

2015-12-31 Thread Riccardo Magliocchetti

Hi Marc,

fine, was thinking on supporting just the simple case without the Prefetch
object.

Il 31/12/2015 00:30, Marc Tamlyn ha scritto:

Hi Richard,

Overriding the queryset is a pretty simple method override, I'm not sure there
is sufficient need for prefetching here. In particular, the syntax for prefetch
related is much more complex than for select related, so it's less well suited
to this kind of shortcut.

Marc

On 30 Dec 2015 10:26 a.m., "Riccardo Magliocchetti"
mailto:riccardo.magliocche...@gmail.com>>
wrote:

Hello,

the need to list an m2m relationship serialized in the admin list view
happens quite often to me and overriding the queryset may not be as trivial
as a ModelAdmin attribute. It makes sense to me to match what is possible
with foreign keys and list_select_related.
Any opinion on implementing list_prefetch_related for ModelAdmin?

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

https://groups.google.com/d/msgid/django-developers/5683B12D.6000600%40gmail.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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto: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/CAMwjO1ECoZGJEkGttZtAZeSBUktHRoYCX_hOj-1ehYtGCRSLzw%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMwjO1ECoZGJEkGttZtAZeSBUktHRoYCX_hOj-1ehYtGCRSLzw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

admin: implementing list_prefetch_related

2015-12-30 Thread Riccardo Magliocchetti


Hello,

the need to list an m2m relationship serialized in the admin list view happens 
quite often to me and overriding the queryset may not be as trivial as a 
ModelAdmin attribute. It makes sense to me to match what is possible with 
foreign keys and list_select_related.

Any opinion on implementing list_prefetch_related for ModelAdmin?

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/5683B12D.6000600%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: admin: automatic link to files for FileFields in change_list breaks link to change_view (v1.8, #14497)

2015-12-07 Thread Riccardo Magliocchetti


Il 22/11/2015 22:02, Florian Demmer ha scritto:



On 2015-11-22 21:31, Riccardo Magliocchetti wrote:

Hi Florian,

Il 22/11/2015 21:14, Florian Demmer ha scritto:

Hi guys,

i am confused/surprised by this ticket and already merged feature. it took me a
while to find out what was happening in my admin:

https://code.djangoproject.com/ticket/14497

Imho, the automatically added link to the file should *not* have precedence over
`list_display_links` and definitely should *not* break the automatically added
link to the change_view, when the `FileField` happens to be first in
`list_display`.

What do you think?


Since you seem to care about this, any chance to open a pull request? The pull
request should contain updated tests to verify that the double  link is
fixed please. If not i'll give a try of fixing it later this week.


since both admin views use that same function, i am not sure how easy it will be
to fix without adding a whole bunch of more code just to detect the field type
and checking list_display_links etc... i'll probably not find the time to look
into that until next weekend either.

as a workaround i have added the 'id' field in first place to my list_display.


I finally found time to look at this and on master it does not break at least, 
am i missing something?


diff --git a/tests/admin_widgets/tests.py b/tests/admin_widgets/tests.py
index 46f2d2a..469a068 100644
--- a/tests/admin_widgets/tests.py
+++ b/tests/admin_widgets/tests.py
@@ -444,6 +444,12 @@ class AdminFileWidgetTests(TestDataMixin, TestCase):
 File widgets should render as a link when they're marked "read only."
 """
 self.client.login(username="super", password="secret")
+response = 
self.client.get(reverse('admin:admin_widgets_album_changelist'))
+self.assertContains(
+response,
+'href="/admin_widgets/album/1/change/">Hybrid Theory',

+html=True,
+)
 response = self.client.get(reverse('admin:admin_widgets_album_change', 
args=(self.album.id,)))

 self.assertContains(
 response,
diff --git a/tests/admin_widgets/widgetadmin.py 
b/tests/admin_widgets/widgetadmin.py
index 6b205b7..6287266 100644
--- a/tests/admin_widgets/widgetadmin.py
+++ b/tests/admin_widgets/widgetadmin.py
@@ -25,7 +25,7 @@ class EventAdmin(admin.ModelAdmin):


 class AlbumAdmin(admin.ModelAdmin):
-    fields = ('name', 'cover_art',)
+fields = ('cover_art',)
 readonly_fields = ('cover_art',)


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5665A30C.5040006%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: admin: automatic link to files for FileFields in change_list breaks link to change_view (v1.8, #14497)

2015-11-22 Thread Riccardo Magliocchetti


Hi Florian,

Il 22/11/2015 21:14, Florian Demmer ha scritto:

Hi guys,

i am confused/surprised by this ticket and already merged feature. it took me a
while to find out what was happening in my admin:

https://code.djangoproject.com/ticket/14497

- it was merged into 1.8, right? the ticket says 1.2.


That was set at the time of filing the issue supposedly
It's pretty clear it has been applied to master and then backported:
https://code.djangoproject.com/ticket/14497#comment:32


- there was no documentation in the patch, no info about it in the release notes
or did i overlook something?


If it's not in the release notes i think this has been considered as a minor 
change


- as far as i can see, the patch was not changed after paulcollins' remark on
the list_display-behaviour, so it was merged as is/was


Yep, it looks like i completely missed that


- it has great potential to break one's admin and requires some digging in the
source to find out why


indeed, fortunately using a file field as first element is not so common


So, what this new feature does is: it adds a link to the file of the `FileField`
in the change_list and read-only version of the form-field in the change_view.
In the change_list that link is also added, when the `FileField` is the first
column or it is in `list_display_links`.

The result is two a-tags in the resulting html, where the link to the file takes
precedence. There is no way to go to the change_view or pick the row in a raw_id
popup anymore. And there is no way to disable the feature.

Both change_list and change_view (for read-only fields) use
`display_for_field()`, that's why both are affected by the change. That might
not have been on purpose...


I usually don't break software on purpose :)


Imho, the automatically added link to the file should *not* have precedence over
`list_display_links` and definitely should *not* break the automatically added
link to the change_view, when the `FileField` happens to be first in 
`list_display`.

What do you think?


Since you seem to care about this, any chance to open a pull request? The pull 
request should contain updated tests to verify that the double  link is fixed 
please. If not i'll give a try of fixing it later this week.


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5652260E.1090608%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving our Contributor License Agreement process

2015-10-27 Thread Riccardo Magliocchetti


Il 27/10/2015 17:50, Tim Graham ha scritto:

I wonder if anyone has a recommendation for a third-party solution to solve
this? Our requirements are roughly outlined below.


Not a solution but for comparison Libreoffice requests a blanket statement sent 
on a public list then referenced on a wiki page:

https://wiki.documentfoundation.org/Development/Developers


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/562FAD9D.2070505%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: forcing a name for a sqlite in memory shared cache test db

2015-10-05 Thread Riccardo Magliocchetti


Hello Tim,

Il 05/10/2015 18:56, Tim Graham ha scritto:

I guess this is probably a use case that wasn't considered when writing that
patch. Feel free to submit a pull request.


Pull request opened here:
https://github.com/django/django/pull/5395

Problem now is i need this thing working in Django 1.8 :)

thanks


On Monday, October 5, 2015 at 9:55:14 AM UTC-4, riccardo.magliocchetti wrote:

Hello Andriy, all,

i need to being able to reference a sqlite3 shared in memory test database 
from
an outside process (a shell script calling django loaddata) during tests of 
a
django app. I don't care really about being in memory but using a sqlite
disk db
i get locked error even with 20 seconds timeouts.

Looking at the code in db.backends.sqlite3.creation.DatabaseCreation it 
looks
like for some reason it has been disabled since handling of shared cache db 
has
been added in 8c99b792. Does anybody know why?

thanks in advance


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5612B3B4.4090204%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

forcing a name for a sqlite in memory shared cache test db

2015-10-05 Thread Riccardo Magliocchetti


Hello Andriy, all,

i need to being able to reference a sqlite3 shared in memory test database from 
an outside process (a shell script calling django loaddata) during tests of a 
django app. I don't care really about being in memory but using a sqlite disk db 
i get locked error even with 20 seconds timeouts.


Looking at the code in db.backends.sqlite3.creation.DatabaseCreation it looks 
like for some reason it has been disabled since handling of shared cache db has 
been added in 8c99b792. Does anybody know why?


thanks in advance

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56128128.30603%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

2015-05-31 Thread Riccardo Magliocchetti


Hi Emil,

Il 31/05/2015 11:00, Emil Stenström ha scritto:

Hi,

On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:

Hi,

Il 30/05/2015 18:52, Emil Stenström ha scritto:
But your proposal keeps html and js separated. I think you are solving a
problem
for the one that just want to use a component but you are not solving the
problem for the one that is writing components. At least not in the react.js
way, especially from such a bold premise :)

I agree that I don't quite do it the same way as React. But that's not the point
here either, to somehow bundle Reacts ideas inside Django. My point is that
keeping the four parts that make a component closely together in the project
source, would make for a better structure. They only idea that comes from React
is thinking in components rather than nested templates and template tags, which
are Django's current way of solving this.


I see, but who are going to do a big js app without using a framework like 
angular / react.js / ember / whatever? I'm not saying your Component proposal is 
without merit but i can't see how it can fit where the js app is done with a 
framework.



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/556AD65D.7030707%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

2015-05-31 Thread Riccardo Magliocchetti


Hi,

Il 30/05/2015 18:52, Emil Stenström ha scritto:

Hi,

This is the first feature proposal as part of my general drive for getting
Django to work better for javascript heavy sites.


This is a bold premise :)


Template Components
---

React.js popularized the notion that in front-end development, code organization
should be based on interface components, not split up into HTML, Javascript and
CSS. Here's the original presentation and the rationale behind organizing around
components:
https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=2m7s


This is a nice react.js introduction:
https://facebook.github.io/react/docs/thinking-in-react.html

[snip]

... which define a kind of component, but one that is tied to a form field. My
suggestion is a new package: django.template.component, that builds on the Media
class from Form Assets, and allows you to define your components like this:

from django.template import component
class Calendar(component.Component):
 def context(self, date):
 return {"date": date}
 class Media:
 template = "app/components/calendar/calendar.html"
 css = {'all': ('app/components/calendar/calendar.css',)}
 js = ('app/components/calendar/calendar.js',)

component.register(name="calendar", component=Calendar)

... and later in your template:

{% load components %}
{% block extra_media %}{% component_dependencies %}{% endblock %}
{% block main %}
 {% component "calendar" date=custom_date %}
{% endblock %}


But your proposal keeps html and js separated. I think you are solving a problem 
for the one that just want to use a component but you are not solving the 
problem for the one that is writing components. At least not in the react.js 
way, especially from such a bold premise :)


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/556AC614.5010604%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

2015-03-24 Thread Riccardo Magliocchetti


Il 24/03/2015 12:37, Germano Gabbianelli ha scritto:


On 24/03/15 11:56, Riccardo Magliocchetti wrote:
With these sentences I was thinking about customizing the properties of the
ModelAdmin without editing the code. For example controlling what fields are
shown in the changelist view or even controlling what models are visible in the
admin interface.


So your proposal is to store them in the db right?


> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going
for a full ui framework (or least a very minimal one). Am Maintaining a
bootstrap based theme and it always end up with tons of bootstrap specific
classes on every tag thus making difficult to reuse upstream templates.

Better to coordinate with the recent css cleanup by Elky too.

Thanks for the hint, I was planning to use flexbox which seems supported by
almost all browsers ( http://caniuse.com/#feat=flexbox )


Uhm, missing IE9 support. It is the default browser on vista, which has extended 
support until 2017 :|



A final thought is about AdminWidget, whatever you end up with please think of
something different pattern than the Form's Media class as makes it impossible
to override css / js without touching python code.


This is one big problem to be honest and I don't think I would have the time to
solve it. There could also be some other student working on it, so I am not sure
about what is the best thing to do. My plan was to ignore the problem and
provide by default widgets that use only simple js or do not use js at all, and
let the user that wants to customize the admin choose how to handle the problem,
for example by using something like django-sekizai.


Well usually adding js / css in templates is enough to make theme people life 
easier :)



I have still not mentioned that I also plan to rewrite contrib.admin using class
based views.


You should well be aware of these projects, a reference of them in your
proposal would ne nice since you can possibly reuse a lot of code:
https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views


I am well aware of django-admin2 I also did a small patch for them, but they use
a lot of dependencies (i.e. restframework) and this makes it almost impossible
to be used as a base for contrib.admin I think.
... Unless someone decides that contrib.admin should not be included in django
anymore and have its own package (Thing that I would not necessarily disagree
with, as it would allow it to have external deps).


I didn't mean you need to follow admin2 design, i meant it's always nice to 
point out related prior work


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55115343.4030204%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

2015-03-24 Thread Riccardo Magliocchetti


Hi Germano,

Il 24/03/2015 11:11, tyrion-mx ha scritto:

Discussing on #django-dev with FunkyBob and others I concluded that refactoring
contrib.admin to become a generic management interface (and not a model-centric
one as it is now) could be a good thing, so I started a project proposal.
It still a draft and I hope to complete it in time, anyway I would like to know
as much as possible what others think about it :)


Cool project!


Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9


Unfortunately one cannot comment on specific lines of gists, c&p some text 
below.

>It is model centric and really hard to extend. For example there is no
> simple way to customize the admin homepage (which I will call dashboard from
> now on) by defining new widgets.

Please don't throw out the baby with the bath water :) It's quite cool to just 
register a model in the admin to have a crud interface.


>Editing the code is required for every, even aesthetical, customization. I
> think it would be better to allow managers (i.e. non-coders) to customize the
> appearence of the admin pages as much as possible without touching the code.
> This could be accomplished by storing part of the ModelAdmin options in the
> database.

I don't agree with "even aeasthetical" bits, there are themes available that 
does not touch any django code. Still there's quite a lot of annoyances, often 
reported in the ticketing system.


>It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going 
for a full ui framework (or least a very minimal one). Am Maintaining a 
bootstrap based theme and it always end up with tons of bootstrap specific 
classes on every tag thus making difficult to reuse upstream templates.


Better to coordinate with the recent css cleanup by Elky too.

A final thought is about AdminWidget, whatever you end up with please think of 
something different pattern than the Form's Media class as makes it impossible 
to override css / js without touching python code.



I have still not mentioned that I also plan to rewrite contrib.admin using class
based views.


You should well be aware of these projects, a reference of them in your proposal 
would ne nice since you can possibly reuse a lot of code:

https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views

BTW there was a recent discussion about the admin where people suggested they 
are just creating a thin rest api over models and reimplementing the ui from 
scratch. A use case you may want keep into account.


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/551142C7.1060406%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Having the app list available on every admin view

2015-03-13 Thread Riccardo Magliocchetti


Il 12/03/2015 21:41, Aymeric Augustin ha scritto:

2015-03-12 18:47 GMT+01:00 Riccardo Magliocchetti
mailto:riccardo.magliocche...@gmail.com>>:
Finally it looks to me that everything in the app_dict but the permissions
could be cached somehow. Would it make sense to cache the app_dict so it
would be cheaper to add the app_list in the other views?


Yes, it looks like there's room for optimization.

PR please? ;-)


I've taken at stab at it, but test_overriding_has_module_permission test fail. 
Looks like the deepcopy of the dict does not work but haven't debugged much.


https://github.com/django/django/compare/master...xrmx:admin_applist?expand=1

I don't like how the code ended up after the second patch though. Need to 
measure it is a gain or not.


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55036067.5070300%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Having the app list available on every admin view

2015-03-12 Thread Riccardo Magliocchetti


Hello,

i was thinking on export the app_list on every view in the admin to implement a 
left menu like the one in mezzanine (demo /demo):

http://mezzanine.jupo.org/it/admin/shop/productoption/

I've started looking in django.contrib.admin.sites and found a couple of issues, 
first at line 469, if app_label == model._meta.app_label is true,
shouldn't we add a break after we found an app_label? AFAIU with the django 1.7 
app registry rework the label is unique between applications we don't need to do 
more work once we have found one


Then there's obviously some duplication between index and app_index methods, 
would it make sense to add an helper method with an optional parameter to filter 
for the app_label?


Finally it looks to me that everything in the app_dict but the permissions could 
be cached somehow. Would it make sense to cache the app_dict so it would be 
cheaper to add the app_list in the other views?


thanks in advance

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5501D127.6060104%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin new look

2015-03-04 Thread Riccardo Magliocchetti


Il 05/03/2015 00:37, Curtis Maloney ha scritto:

Looks pretty slick, but brings with it all the hassles of the past attempts to
re-skin admin: it breaks legacy custom pages.


AFAIK the admin never promised an "API" (if we can call html that), at the time 
1.4 broke most of my custom admin templates.



I wish we could standardise a theming layer for admin... allow legacy templates,
or switching to new, clean, themable templates...


Elky demonstrated by changing only css that the current theme is themeable :)
Speaking of themes from my experience as django-admin-boostrapped maintainer 
once you choose an ui framework you end up adding custom classes that of course 
are different between frameworks. This means you have to redo all your templates 
anyway. Which sucks of course.



Perhaps this could be integrated with the work to break down admin into a
collection of CBGV?


That sounds like pydanny's django-admin2

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54F80988.9010807%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

2015-03-04 Thread Riccardo Magliocchetti


Il 04/03/2015 21:56, elky ha scritto:

Quick summary of the PR discussion <https://github.com/django/django/pull/4232>:

  * Everyone (ok, probably not) understands that current admin interface looks 
old
  * Green theme I used from djangoproject site isn't good idea - admin shouldn't
be associated with brand
  * It's better to keep default color scheme (most of apps uses this scheme in
their components/widgets)
  * CSS-only approach is good idea for the beginning


Looks good, thanks for your work! Looking forward for a blueish theme :)


--
Riccardo Magliocchetti

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54F786D1.9070301%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django admin: open popups as modals instead of windows

2015-02-24 Thread Riccardo Magliocchetti


Il 24/02/2015 20:12, Marc Tamlyn ha scritto:

I would suggest that a good modal implementation for these should still support
"open in new tab/window" properly, with control/command click not detected by
the overriding JavaScript. It may be possible to do this and keep the popup
functionality passing the new id back to the parent window.


uhm, that should be doable

[snip]



There are definitely better ways to deal with raw_id_fields than the popup
window in my opinion - utilising something like select2 with ajax loading and a
hook on the ModelAdmin would be ideal.


Yeah, reusing existing libraries in the admin would be really nice


In any case, it is fairly trivial to add options like this to the modeladmin and
make them opt in if that is desired.



Overall, I'm probably -0 on morals, but +1 on supporting an optional alternative
way to handle add buttons on related objects.


-0 on morals sounds good :) So i think it'll be better to keep the windows and 
focus on making experimentation with this widget possible for downstream users.


Thanks to everyone that partecipated in the discussion.

--
Riccardo Magliocchetti
Software Tinkerer
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54ECF0F1.1070301%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django admin: open popups as modals instead of windows

2015-02-24 Thread Riccardo Magliocchetti


Il 24/02/2015 16:18, Florian Apolloner ha scritto:

On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote:

I'm no UI/UX expert but modals are more or less the standard today,
windows looks like a relic from the 2000s.

That argument is based on what? I'd personally argue that windows are superior
cause I can easily switch between the page and the window -- something that does
not work with modals


Not really an argument, it's more an observation that ui frameworks like 
bootstrap, foundations, etc.. usually have a modal component. In data entry UI 
that may not be the case though but i have no clue. Personally I just want to be 
able to use modals or whatever just by overwriting templates. I get that, I am 
happy :)


thanks

--
Riccardo Magliocchetti
Software Tinkerer
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54EC9FC7.6010309%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

django admin: open popups as modals instead of windows

2015-02-24 Thread Riccardo Magliocchetti


Hello,

I've opened a ticket [1] to implement the popups in the admin as modal instead 
of windows. I'm no UI/UX expert but modals are more or less the standard today, 
windows looks like a relic from the 2000s.
Am also interested in decoupling the js from the admin to make possible for 
downstream theme maintainers to use another implementation if they please [2].
So have been asked by Tim to ask feedback for the idea here, your opinions are 
very welcome.


Rough, work in progress implementation here:
https://github.com/xrmx/django/commits/relatedcleanup

[1] https://code.djangoproject.com/ticket/24405
[2] 
https://github.com/django-admin-bootstrapped/django-admin-bootstrapped/issues/103


thanks

--
Riccardo Magliocchetti
Software Tinkerer
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54EC8950.90709%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating contributing documentation

2015-02-04 Thread Riccardo Magliocchetti

Hi Tim,

Il 04/02/2015 13:24, Tim Graham ha scritto:

Hi Riccardo,

Thanks for the feedback. Maybe adding a link to the patch review
checklist [1] to the contributing tutorial would be sufficient. Most of
the points you've covered are valid and are covered in the rest of the
contributing docs. I'd like not to duplicate information if possible,
but please do submit a pull request with changes you feel are appropriate.

[1]
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

Ah! here's the docs i need :)

Anyway here's a pull request that add a couple of cross references to
possible other interesting pages to the reader:

- from first patch tutorial to submitting patches, in case someone
looking for a patch checklist get here from a search engine
- adding a link to the aforementioned tutorial from the new contributors
page for newbies looking for the basics.

https://github.com/django/django/pull/4050

hth,
riccardo

Re: Updating contributing documentation

2015-02-04 Thread Riccardo Magliocchetti


Il 04/02/2015 10:15, Riccardo Magliocchetti ha scritto:

Hello,

I'd like to update the contributing (docs/intro/contributing.txt) docs
to make the process a bit smoother, here's some issues i've found:

- from my own experience it looks like that a pull request is required
for review. Documentation say patches in the bugtracker are fine but
have been asked to open pull request even with patches sitting in the
ticket.

- there's no mention on the ready for checkin bit, again from my own
experience there has been patches in the bugtracker for years because
without that bit sets the patch is off the radar of reviewers


Here i meant the "patch needs improvement" bit


- suggest to run pyflake8 on the file you changed, saves a review round
trip

- there should be some switch that makes deprecations warning fail on
djangoci but i don't see them when running tests on my machine. That
could easily done on developers machines to save a round trip while
reviewing. Any hint please?

If there's agreement with this i can open a pull request.

Thanks,
riccardo


--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54D1E6EA.4010401%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Updating contributing documentation

2015-02-04 Thread Riccardo Magliocchetti


Hello,

I'd like to update the contributing (docs/intro/contributing.txt) docs 
to make the process a bit smoother, here's some issues i've found:


- from my own experience it looks like that a pull request is required 
for review. Documentation say patches in the bugtracker are fine but 
have been asked to open pull request even with patches sitting in the 
ticket.


- there's no mention on the ready for checkin bit, again from my own 
experience there has been patches in the bugtracker for years because 
without that bit sets the patch is off the radar of reviewers


- suggest to run pyflake8 on the file you changed, saves a review round trip

- there should be some switch that makes deprecations warning fail on 
djangoci but i don't see them when running tests on my machine. That 
could easily done on developers machines to save a round trip while 
reviewing. Any hint please?


If there's agreement with this i can open a pull request.

Thanks,
riccardo

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54D1E33A.6060105%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Formalizing template loader and debug api's

2014-12-28 Thread Riccardo Magliocchetti


Hello Preston,

Il 28/12/2014 06:30, Preston Timmons ha scritto:

Hi all,

I've been working on #15053, which enables Django template loaders to extend
templates of the same name recursively. The most common use-case for this is
extending the admin templates without needing to copy the application
templates
into a project.


Thanks a lot for working on this!


### Loader API

[snip]

Loader.get_internal

Returns the contents for a template given a ``source`` as returned by
``get_template_sources``.


The name is a bit confusing to me, what about Loader.get_contents instead?

thanks,
riccardo

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54A0079A.2070907%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

2014-12-21 Thread Riccardo Magliocchetti


Hello,

Il 20/12/2014 20:40, Tim Graham ha scritto:

You can also see other tickets we are targeting for 1.8 with this
filter. This includes some of the remaining large features as well as a
couple code reorganizations we want to make closer to when cut the 1.8
branch to avoid creating conflicts with the large features that are in
progress.
https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha


Would be possible to add the better extends algorithm for templates to 
the desired stuff for 1.8 alpha? Code should be in pretty good shape but 
it's intertwined with Aymeric multiple template engine work.


Ticket: https://code.djangoproject.com/ticket/15053
PR: https://github.com/django/django/pull/3475/

thanks,
riccardo

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5496A32C.604%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

2014-08-06 Thread Riccardo Magliocchetti

Hello,

Il 06/08/2014 16:34, Robert Grant ha scritto:

Does Ikari  do what you want?
I'm not saying it should or shouldn't be in Django contrib itself, but
at least worth taking a look and seeing if that has any useful ideas.

Thanks for sharing, the patch discussed in thread could be a considered 
a building block for something like ikari.

On Wednesday, 30 April 2014 09:37:13 UTC+2, riccardo.magliocchetti wrote:

Hi Eduardo,

[adding Stephen McDonald to CC]

Il 29/04/2014 21:43, Eduardo Rivas ha scritto:
 > Mezzanine, a Django based CMS, has true multi tenancy. I've used
it and
 > works great. However, it's clear it's not something that should
be in
 > Django's core, for the reasons other have stated. I'm just
bringing it
 > up in case OP is still looking for something like this for his
projects;
 > not trying to restart the debate.
 >
 > http://mezzanine.jupo.org/docs/multi-tenancy.html

 >

https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/utils/sites.py#L12

Thanks for the info, was not aware of that. The functionality looks the
same as the patch below [1] attached to #15089 except they save the
site_id for the request in an external cache. It looks like if the
patch
goes in they could leverage get_current_site(request) with empty
settings.SITE_ID just fine.

Let me say again the what i'm pushing to have in django is to have
django.contrib.sites return a Site based on the request instead of the
one hardcoded in settings.SITE_ID.

thanks,
riccardo

[1]

https://code.djangoproject.com/attachment/ticket/15089/0001-Make-settings.SITE_ID-optional-for-django.contrib.si.patch

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53E243A4.20602%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

2014-08-02 Thread Riccardo Magliocchetti


Hello,

Il 01/08/2014 15:46, Thiago Avelino ha scritto:

Hi guys! Django admin has a few years, it works fine (meets the need)
only need to evolve the style following the evolution of UX today!

We have a plan for change?

What do you think of this style 
https://github.com/hersonls/djamin#screenshots ? Is django admin html +
custom css!


Better default css cannot hurt but i think making the admin more 
customizable is more of a priority:
- make it possible to extends admin templates and then make it easier to 
override by providing sensible blocks

- remove specific html / css dependencies from widgets
- make the default theme reasonably responsive / touch friendly

Maintaining admin themes is really a painful experience :)

thanks,
riccardo

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53DCBE2C.1010900%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

database specific checks in deserialization

2014-05-12 Thread Riccardo Magliocchetti


Hello,

as of 1.6.x loading fixtures with a blank=True IpAddressField field 
dumped from a db that allows empty string would fail on postgresql 
because its specialized field inet does not allow empty strings.


This issue has been reported in #6233 [1] that have been closed as 
duplicate of #5622 [2] which has been closed as wontfix because of 
https://code.djangoproject.com/ticket/5622#comment:61


So while one can fix the data with a sed one liner, still it would be 
handy to have django handle the situation gtracefully. So would be 
possibile to add database specific checks to loadata or somewhere upper 
in the chain as serializers.deserialize?


thanks in advance,
riccardo

[1] https://code.djangoproject.com/ticket/6233
[2] https://code.djangoproject.com/ticket/5622

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5370AD52.307%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

2014-04-30 Thread Riccardo Magliocchetti

Hi Eduardo,

[adding Stephen McDonald to CC]

Il 29/04/2014 21:43, Eduardo Rivas ha scritto:

Mezzanine, a Django based CMS, has true multi tenancy. I've used it and
works great. However, it's clear it's not something that should be in
Django's core, for the reasons other have stated. I'm just bringing it
up in case OP is still looking for something like this for his projects;
not trying to restart the debate.

http://mezzanine.jupo.org/docs/multi-tenancy.html
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/utils/sites.py#L12

Thanks for the info, was not aware of that. The functionality looks the
same as the patch below [1] attached to #15089 except they save the
site_id for the request in an external cache. It looks like if the patch
goes in they could leverage get_current_site(request) with empty
settings.SITE_ID just fine.

Let me say again the what i'm pushing to have in django is to have
django.contrib.sites return a Site based on the request instead of the
one hardcoded in settings.SITE_ID.

thanks,
riccardo

[1]
https://code.djangoproject.com/attachment/ticket/15089/0001-Make-settings.SITE_ID-optional-for-django.contrib.si.patch

--
You received this message because you are subscribed to the Google Groups "Django
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/5360A829.9000609%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

2014-04-03 Thread Riccardo Magliocchetti


Hello,

Il 03/04/2014 09:46, Riccardo Magliocchetti ha scritto:

Hello,

Il 03/04/2014 00:15, Russell Keith-Magee ha scritto:


On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti
mailto:riccardo.magliocche...@gmail.com>> wrote:

First we already have an initial patch sitting in this ticket:

https://code.djangoproject.__com/ticket/15089
<https://code.djangoproject.com/ticket/15089>

patch here:


https://code.djangoproject.__com/attachment/ticket/15089/__15089-missing-site_id.diff


I updated the patch to work againt latest git master, test passes [1] 
and doc builds fine.


https://code.djangoproject.com/attachment/ticket/15089/0001-By-using-the-request-to-do-the-Site-matching.patch

thanks,
riccardo

[1] Actually i have this "ERROR: test_righthand_power 
(expressions_regress.tests.ExpressionOperatorTests)"
there with "IntegrityError: NOT NULL constraint failed: 
expressions_regress_number.the_integer"  but it's completely unrelated 
to sites framework, traceback here http://pastebin.com/MSmu8mi9


--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/533DA7A0.1040802%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

2014-04-03 Thread Riccardo Magliocchetti


Hello,

Il 03/04/2014 00:15, Russell Keith-Magee ha scritto:


On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti
mailto:riccardo.magliocche...@gmail.com>> wrote:

Hi everyone,

i'd like to start a discussion about multi tenancy on this list.
I've been asked to move the discussion here by Aymeric in this ticket:

https://code.djangoproject.__com/ticket/17802
<https://code.djangoproject.com/ticket/17802>

First we already have an initial patch sitting in this ticket:

https://code.djangoproject.__com/ticket/15089
<https://code.djangoproject.com/ticket/15089>

patch here:


https://code.djangoproject.__com/attachment/ticket/15089/__15089-missing-site_id.diff

<https://code.djangoproject.com/attachment/ticket/15089/15089-missing-site_id.diff>

The patch basically change the SiteManager to return a Site based on
the request instead of the hardcoded settings.SITE_ID. Which while
useful for my usage is also making ticket 17802 obsolete since in
the mean time Sitemap has been switched to using get_current_site.

Another missing bit is having the request available everywhere, one
solution is to store in thread local storage that could be done
easily in a middleware without touching django core.


-1. Not. Going. To. Happen.

Search the archives of Django Developers if you want to know why. This
has been discussed to death.

Short version - it doesn't matter what pretty name you put on it, a
thread local is a global variable. We teach first year programmers not
to use globals, so why would we introduce them to Django as a core
framework idea?


I expected that :) i meant that if one wants that this can be done 
without touching django at all.



Another interesting thing (to me at least) would be being able to
use a different model for the Site so one can stores some site
specific configuration there (keeping in mind that in the patch
sites return but get_current_site are cached).

That could be obtained through this patch:

https://github.com/apollo13/__django/compare/ticket15089
<https://github.com/apollo13/django/compare/ticket15089>

or maybe like what is done for the custom User model.


What's the use case here? What additional data do you want to track?


For an ecommerce site "prices are without vat", "you need a vat id to 
register", something like that. Again this would nice but since one can 
use a separate model that's not a showstopper.




There's some more features for full multi tenancy listed here
https://code.djangoproject.__com/ticket/15089#comment:36
<https://code.djangoproject.com/ticket/15089#comment:36>

but the above will suffice for my usage so i will not dig into it.


Broadly speaking the approach you've described in #17802 makes sense to
me - that is, find somewhere where the request is needed, and make sure
it's available. I haven't dug in to the full consequences of introducing
the request where you've put it, but the broad strokes look right.


I was on the "add the request everywhere camp" until i've seen the 
15089-missing-site_id.diff patch. Lot of places have been converted to 
get_current_site so with the patch applied a site aware site would come 
for free. Let me mention that this does not change default behaviour.



Unfortunately, we're not going to rush into something here - once we add
or change an API, we need to support it, and we are committing to not
changing it - so before we make any changes, we need to make sure we're
not backing ourselves into a corner. That means solving the general
problem (or at least having an idea how we would address the general
problem), not just one small part of the problem.

The other approach that you haven't made mention of - Use a different
sites app altogether. Django's sites module isn't well designed for true
multi tenancy of the type that you're describing. However, it's also a
contrib app -- so it's entirely optional, and also replaceable. If you
have a specific set of requirements for multi tenancy, then write your
own third-party app to implement those changes, and use it.


It's entirely optional but lot of other contrib code knows about it 
(grep get_current_site). So using something else would be quite painful 
if you want to reuse other apps.



Also - Not Going to Happen. 1.7 beta has been released, so the window
for new features is closed. The best you can hope for at this point is
for inclusion in Django 1.8.


Yeah, thought about that after hitting enter :)

thanks,
riccardo

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to thi

On django multi tenancy

2014-04-02 Thread Riccardo Magliocchetti


Hi everyone,

i'd like to start a discussion about multi tenancy on this list. I've 
been asked to move the discussion here by Aymeric in this ticket:


https://code.djangoproject.com/ticket/17802

First we already have an initial patch sitting in this ticket:

https://code.djangoproject.com/ticket/15089

patch here:

https://code.djangoproject.com/attachment/ticket/15089/15089-missing-site_id.diff

The patch basically change the SiteManager to return a Site based on the 
request instead of the hardcoded settings.SITE_ID. Which while useful 
for my usage is also making ticket 17802 obsolete since in the mean time 
Sitemap has been switched to using get_current_site.


Another missing bit is having the request available everywhere, one 
solution is to store in thread local storage that could be done easily 
in a middleware without touching django core.


Another interesting thing (to me at least) would be being able to use a 
different model for the Site so one can stores some site specific 
configuration there (keeping in mind that in the patch sites return but 
get_current_site are cached).


That could be obtained through this patch:

https://github.com/apollo13/django/compare/ticket15089

or maybe like what is done for the custom User model.

There's some more features for full multi tenancy listed here
https://code.djangoproject.com/ticket/15089#comment:36

but the above will suffice for my usage so i will not dig into it.

So to summarize with just a couple of patches to the site framework and 
a dozen lines middleware one could build a basic django multi tenancy site.


How can I help to have this in 1.7?

thanks in advance,
riccardo

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/533C54E1.1060002%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

43 matches

Mail list logo