Re: Possible bug in Django Admin site in tabular inline or stacked inline with datetime shortcuts

[Константин Попов]

If anyone is interested in this question, I have fixed this myself, with 
approach number 2.
I had to copy two js files from django to my project and then fix that 
files.

вторник, 19 апреля 2016 г., 15:02:30 UTC+3 пользователь Константин Попов 
написал:
>
> Hi, django users.
>
> I have found possible bug in django admin site, using tabular inline with 
> datetime field. The same bug exists in stacked inline as I can see form 
> code.
>
> I am not sure what is the best way to report the bug, so I decided to 
> write here first.
> Please, give me advice on my next steps.
>
> Now, about the bug.
>
> Any datetime field is supplied with calendar and clock 
> shortcuts. static/admin/js/admin/DateTimeShortcuts.js contains code, wich 
> generated all html markup for them, this code runs on page load event.
> This code makes both span class="datetimeshortcuts" and hidden div 
> class="calendarbox module" or class="clockbox module".
>
> TabularFormset and stackedFormset jquery plugins, that live 
> in static/admin/js/inlines.js, both need to reinit datetime fields in the 
> newly added formset rows.
> They do it with this function:
>
> var reinitDateTimeShortCuts = function() {
>
> // Reinitialize the calendar and clock widgets by force, yuck.
> if (typeof DateTimeShortcuts !== "undefined") {
> $(".datetimeshortcuts").remove();
> DateTimeShortcuts.init();
> } 
>
> };
>
>
> As anyone can see, this function removes datetimeshortcuts spans but doesn't 
> remove "calendarbox module" and clockbox module" divs.
>
> Then, call to the DateTimeShortcuts.init() again and again adds both the 
> spans and the divs for all datetime fields on the page.
>
>
> Thus, by adding 20 rows in formset, I have about 400 useless hidden divs on 
> my page.
>
>
>
> I see several ways to fix this bug.
>
>
> 1. Modify DateTimeShortcuts.js to use single hidden div for all datetime 
> fields on the page
>
> 2. Modify DateTimeShortcuts.js init function to check if the datetime field 
> is alreay initialized to avoid it's re-initialization, and exclude removing 
> any DOM elements from reinitDateTimeShortCuts 
>
> 3. Expand set of elements, removed in reinitDateTimeShortCuts and remove divs 
> together with spans. Maybe it would be better to add reinit function into 
> DateTimeShortcuts.js
>
>

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

Possible bug in Django Admin site in tabular inline or stacked inline with datetime shortcuts

[Константин Попов]

Hi, django users.

I have found possible bug in django admin site, using tabular inline with 
datetime field. The same bug exists in stacked inline as I can see form 
code.

I am not sure what is the best way to report the bug, so I decided to write 
here first.
Please, give me advice on my next steps.

Now, about the bug.

Any datetime field is supplied with calendar and clock 
shortcuts. static/admin/js/admin/DateTimeShortcuts.js contains code, wich 
generated all html markup for them, this code runs on page load event.
This code makes both span class="datetimeshortcuts" and hidden div 
class="calendarbox module" or class="clockbox module".

TabularFormset and stackedFormset jquery plugins, that live 
in static/admin/js/inlines.js, both need to reinit datetime fields in the 
newly added formset rows.
They do it with this function:

var reinitDateTimeShortCuts = function() {

// Reinitialize the calendar and clock widgets by force, yuck.
if (typeof DateTimeShortcuts !== "undefined") {
$(".datetimeshortcuts").remove();
DateTimeShortcuts.init();
} 

};


As anyone can see, this function removes datetimeshortcuts spans but doesn't 
remove "calendarbox module" and clockbox module" divs.

Then, call to the DateTimeShortcuts.init() again and again adds both the spans 
and the divs for all datetime fields on the page.


Thus, by adding 20 rows in formset, I have about 400 useless hidden divs on my 
page.



I see several ways to fix this bug.


1. Modify DateTimeShortcuts.js to use single hidden div for all datetime fields 
on the page

2. Modify DateTimeShortcuts.js init function to check if the datetime field is 
alreay initialized to avoid it's re-initialization, and exclude removing any 
DOM elements from reinitDateTimeShortCuts 

3. Expand set of elements, removed in reinitDateTimeShortCuts and remove divs 
together with spans. Maybe it would be better to add reinit function into 
DateTimeShortcuts.js

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

Bug in django admin: list_editable should be not editable if appear in readonly_fields

[Anton Danilchenko]

Hello dev team!

I think that if some field set to *readonly_fields* than we should display 
disabled field in *list_editable*.

Now I have set field "*price*" into *list_editable* and *readonly_fields*. 
And I see this field not editable in "change view" in admin panel, but I 
see it editable in "list view".

If field not editable - I should not edit this field in admin site. But, as 
I can see - I can edit this field in "list view", that creates some 
problems. Because it isn't what I wan to see.

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

Re: Bug in Django admin?

[Michael Radziej]

Hi Martin!


On Wed, 09 Mar 2011 15:58:54 +0100, Martin Tiršel  wrote:
> NO = False
> YES = True
> YES_NO_CHOICES = (
>  (NO, 'no'),
>  (YES, 'yes')
> )
> 
> to
> 
> 
> NO = 0
> YES = 1
> YES_NO_CHOICES = (
>  (NO, 'no'),
>  (YES, 'yes')
> )
> 
> Then I get 0 or 1 for filter instead of True or False and it works. I  
> think that the admin takes the True/False parameter in URL as string and  
> does't convert it to bool.

Aha! That's very interesting.

I'm not sure whether this is really a bug or not--SQL is a bit strange
about Boolean values sometimes--, but it looks like one, too. Would
you like to open a ticket for this, referring to the URL of this thread
in google groups?

Please also state your database engine.

I'd appreciate if you set Cc to my email address. ;-)



Kind regards

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Bug in Django admin?

[Martin Tiršel]

Hi Michael,

On Tue, 08 Mar 2011 11:05:40 +0100, Michael Radziej   
wrote:



Hi Martin!

Args--you're right. Stupid fingers :-)

I meant

.../admin/appname/booltest/?completed__exact=0

Does it work that way for you with 0 instead of False?



Yes, if I rewrite URL to ?completed__exact=0, then I get Completed with  
`no` choice.





This link is called after I click on `no` in filter category `By
completed`.


Hmm. I see a 0 here. I don't know the reason for the difference, I
checked it on a django 1.1 system. I vaguely remember a change.

What database and which version of Django are you using?




I have Django 1.2.5. But when I change choices definition from:


NO = False
YES = True
YES_NO_CHOICES = (
(NO, 'no'),
(YES, 'yes')
)

to


NO = 0
YES = 1
YES_NO_CHOICES = (
(NO, 'no'),
(YES, 'yes')
)

Then I get 0 or 1 for filter instead of True or False and it works. I  
think that the admin takes the True/False parameter in URL as string and  
does't convert it to bool.



Kind regards

Michael



Kind regads,
Martin

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Bug in Django admin?

[Michael Radziej]

Hi Martin!

> > It's the wrong URL, you should use
> >
> > .../admin/appname/booltest/?completed__exact=False
> >
> 
> It is the same link, I don't see a difference :)

Args--you're right. Stupid fingers :-)

I meant

.../admin/appname/booltest/?completed__exact=0

Does it work that way for you with 0 instead of False?


> This link is called after I click on `no` in filter category `By  
> completed`.

Hmm. I see a 0 here. I don't know the reason for the difference, I
checked it on a django 1.1 system. I vaguely remember a change.

What database and which version of Django are you using?


Kind regards

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Bug in Django admin?

[Martin Tiršel]

Hello,

On Mon, 07 Mar 2011 22:12:14 +0100, Michael Radziej   
wrote:



Ahoj Martin,

On Mon, 07 Mar 2011 12:49:32 +0100, Martin Tiršel   
wrote:

When I use filter in Django admin (that produces URL
.../admin/appname/booltest/?completed__exact=False), I get results which
are with completed=True. This is the SQL query generated by Django
admin:


It's the wrong URL, you should use

.../admin/appname/booltest/?completed__exact=False



It is the same link, I don't see a difference :)


(or has this changed since 1.1?)

Is there really a link somewhere in the admin to the "...=False" link,
or did you try to guess it?




This link is called after I click on `no` in filter category `By  
completed`.



Kind regards

Michael



Regards,
Martin

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Bug in Django admin?

[Michael Radziej]

Ahoj Martin,

On Mon, 07 Mar 2011 12:49:32 +0100, Martin Tiršel  wrote:
> When I use filter in Django admin (that produces URL  
> .../admin/appname/booltest/?completed__exact=False), I get results which  
> are with completed=True. This is the SQL query generated by Django
> admin:

It's the wrong URL, you should use

.../admin/appname/booltest/?completed__exact=False

(or has this changed since 1.1?)

Is there really a link somewhere in the admin to the "...=False" link,
or did you try to guess it?


Kind regards

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Bug in Django admin?

[Martin Tiršel]

Hello,

I have such model:

class BoolTest(models.Model):
NO = False
YES = True
YES_NO_CHOICES = (
(NO, 'no'),
(YES, 'yes')
)
name = models.CharField(
max_length=30
)
completed = models.BooleanField(
default=NO,
choices=YES_NO_CHOICES
)


and admin definition:

class BoolTestAdmin(admin.ModelAdmin):
list_filter = ('completed',)
list_display = ('name', 'completed')

admin.site.register(BoolTest, BoolTestAdmin)

When I use filter in Django admin (that produces URL  
.../admin/appname/booltest/?completed__exact=False), I get results which  
are with completed=True. This is the SQL query generated by Django admin:


SELECT `appname_booltest`.`id`, `appname_booltest`.`name`,  
`appname_booltest`.`completed` FROM `appname_booltest` WHERE  
`appname_booltest`.`completed` = 1  ORDER BY `appname_booltest`.`id` DESC


But when I do:


bt = BoolTest.objects.filter(completed__exact=False)


Then everything is ok:

SELECT `appname_booltest`.`id`, `appname_booltest`.`name`,  
`appname_booltest`.`completed` FROM `appname_booltest` WHERE  
`appname_booltest`.`completed` = 0  LIMIT 21


Is it a bug or I did something wrong?

Thanks,
Martin

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: possible bug in django-admin

[Benedict Verheyen]

Karen Tracey wrote:

> It's not trying to limit you to just one project.   It's just trying to
> prevent confusion by not letting you create and attempt to work with a
> new project when you're running in an environment already set up to
> manage a different project.  In those cases, simply unset the
> DJANGO_SETTINGS_MODULE environment variable, then issue the startproject
> command.
> 
> Karen

Karen,

thanks for the clarification.

Regards,
Benedict


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: possible bug in django-admin

[Karen Tracey]

On Wed, Sep 10, 2008 at 3:06 AM, Benedict Verheyen <
[EMAIL PROTECTED]> wrote:

>
> James Bennett wrote:
> > On Tue, Sep 9, 2008 at 4:15 AM, Benedict Verheyen
> > <[EMAIL PROTECTED]> wrote:
> >> i tried to do a django-admin startproject  and it
> >> said that startproject wasn't a valid command.
> >> Weird. django-admin help indeed didn't show the startproject command.
> >
> > This is currently intended behavior and I believe it's now documented
> > as well; the "startproject" command is disabled when django-admin.py
> > detects that you already have and are working with an existing
> > project, because "startproject" doesn't really make sense in those
> > cases. Generally speaking, if you've set DJANGO_SETTINGS_MODULE or
> > pass the "--settings" argument, the command will be disabled.
>
>
> OK, thanks for the info. I'll have a look at the documentation as it's
> not clear to me why one would only want one project.
>
>
It's not trying to limit you to just one project.   It's just trying to
prevent confusion by not letting you create and attempt to work with a new
project when you're running in an environment already set up to manage a
different project.  In those cases, simply unset the DJANGO_SETTINGS_MODULE
environment variable, then issue the startproject command.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: possible bug in django-admin

[Benedict Verheyen]

James Bennett wrote:
> On Tue, Sep 9, 2008 at 4:15 AM, Benedict Verheyen
> <[EMAIL PROTECTED]> wrote:
>> i tried to do a django-admin startproject  and it
>> said that startproject wasn't a valid command.
>> Weird. django-admin help indeed didn't show the startproject command.
> 
> This is currently intended behavior and I believe it's now documented
> as well; the "startproject" command is disabled when django-admin.py
> detects that you already have and are working with an existing
> project, because "startproject" doesn't really make sense in those
> cases. Generally speaking, if you've set DJANGO_SETTINGS_MODULE or
> pass the "--settings" argument, the command will be disabled.


OK, thanks for the info. I'll have a look at the documentation as it's
not clear to me why one would only want one project.

Regards,
Benedict


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: possible bug in django-admin

[James Bennett]

On Tue, Sep 9, 2008 at 4:15 AM, Benedict Verheyen
<[EMAIL PROTECTED]> wrote:
> i tried to do a django-admin startproject  and it
> said that startproject wasn't a valid command.
> Weird. django-admin help indeed didn't show the startproject command.

This is currently intended behavior and I believe it's now documented
as well; the "startproject" command is disabled when django-admin.py
detects that you already have and are working with an existing
project, because "startproject" doesn't really make sense in those
cases. Generally speaking, if you've set DJANGO_SETTINGS_MODULE or
pass the "--settings" argument, the command will be disabled.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

possible bug in django-admin

[Benedict Verheyen]

Hi,

i tried to do a django-admin startproject  and it
said that startproject wasn't a valid command.
Weird. django-admin help indeed didn't show the startproject command.

Checked
/usr/lib/python2.4/site-packages/django/core/management/__init__.py

And in the get_commands function, there is a del statement now that
removes the startproject command.
...
if project_directory:
# Remove the "startproject" command from self.commands, because
# that's a django-admin.py command, not a manage.py command.
del _commands['startproject']
...
However, deleting the command makes it unavailable via django-admin.py

Regards,
Benedict


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---