Re: [Django] #3860: AttributeError: 'module' object has no attribute 'myapp'

[Django]

#3860: AttributeError: 'module' object has no attribute 'myapp'
-+--
   Reporter:  Vinay Sajip|  Owner:  adrian
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Contrib apps
Version:  SVN|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
Changes (by pllee):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I noticed this error when I tried loading my admin page after a bunch of
 different commits.  It turns out that I removed a function that one of my
 urls called, even though it was never called in my front-end or back-end
 code.  I hope this helps someone out.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #12027: EmailField validation is incorrect, trailing dots fail

[Django]

#12027: EmailField validation is incorrect, trailing dots fail
-+-
   Reporter:  Klas H |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  email, regular
   Triage Stage:  Accepted   |  expression, validation
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * needs_tests:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #12027: EmailField validation is incorrect, trailing dots fail

[Django]

#12027: EmailField validation is incorrect, trailing dots fail
-+-
   Reporter:  Klas H |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  email, regular
   Triage Stage:  Accepted   |  expression, validation
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 #16310 was a duplicate. Note that this behaviour was introduced in
 changeset [11605], which itself was to fix a security issue where the
 email and url validation regular expressions could be exploited in public
 form submissions to cause a DOS. Therefore this should be treated very
 cautiously.

 I haven't done enough research to confirm whether this is a genuine bug or
 not. However, this behaviour (i.e. trailing dots) doesn't seem to be
 tested at all. So I'm accepting this ticket on the basis that at the very
 least it needs some tests.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16310: EmailValiadtor lets through [...].com. (dot at the end)

[Django]

#16310: EmailValiadtor lets through [...].com. (dot at the end)
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:  EmailValiadtor
   Triage Stage:  Accepted   |  validation email
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This is a dupe of #12027.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16751: GET variable names replaced by 'e'

[Django]

#16751: GET variable names replaced by 'e'
+---
   Reporter:  martopolis@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by julien):

 Custom filters only exist in the development version and will be available
 in 1.4. The redirection with "?e=1" is when some GET parameters are
 recognized as invalid; see:
 source:django/trunk/django/contrib/admin/options.py?rev=16602#L1102 (in
 dev version, but same in 1.3)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #12978: Support in syndication framework for CSS stylesheet links

[Django]

#12978: Support in syndication framework for CSS stylesheet links
-+-
   Reporter: |  Owner:  yuval_a
  intrepidweb| Status:  reopened
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  syndication css
Version:  1.1|  stylesheets
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Someday/Maybe  |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * status:  closed => reopened
 * resolution:  fixed =>
 * stage:  Ready for checkin => Someday/Maybe


Comment:

 Revert apparent triage error.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16751: GET variable names replaced by 'e'

[Django]

#16751: GET variable names replaced by 'e'
+---
   Reporter:  martopolis@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by anonymous):

 I've noticed this only happens when opening a model change list view.
 That is, if I try to load http://mysite/admin/?variable=1, there's no
 problem.  But when I try http://mysite/admin/myproject/model/?variable=1.
 the 'variable' portion gets rewritten as 'e'.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16751: GET variable names replaced by 'e'

[Django]

#16751: GET variable names replaced by 'e'
+---
   Reporter:  martopolis@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by jezdez):

 * status:  new => closed
 * resolution:   => needsinfo


Old description:

> I'm attempting to override the queryset() method to make a custom filter
> for the Change List Admin view.  The idea was to append ?myview=1 to the
> URL and then check it like so:
>
> if request.GET['myview'] == '1':
> ...
>
> But everything I pass via the URL string is being replaced by the key
> name 'e' in the GET dictionary:
>
> "Key 'myview' not found in "
>
> Curiously, this also happens in the final URL string.  That is, the URL
> gets rewritten and redirected to ?e=1 as well.

New description:

 I'm attempting to override the queryset() method to make a custom filter
 for the Change List Admin view.  The idea was to append ?myview=1 to the
 URL and then check it like so:

 {{{
 if request.GET['myview'] == '1':
 …
 }}}

 But everything I pass via the URL string is being replaced by the key name
 'e' in the GET dictionary:

 {{{
 "Key 'myview' not found in "
 }}}

 Curiously, this also happens in the final URL string.  That is, the URL
 gets rewritten and redirected to ?e=1 as well.

--

Comment:

 Without further explanation or concrete code example I can't reproduce
 this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
   Reporter: |  Owner:
  sebastian_noack| Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  mysql transaction
 Resolution: |  isolation
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by akaariai):

 According to my quick test, this only works if you have done no queries at
 all before taking the savepoint. No matter which table you select from
 before the SAVEPOINT p1. So, this would be only a minor improvement:
 get_or_create works correctly, but only if it is the first operation in
 the transaction. You can see this if you put any select above the SNAPSHOT
 P1; for process 1.

 The reason seems to be that MySQL takes the snapshot only when first
 needed. But if it happens to take the snapshot inside savepoint, for some
 strange reason it rolls the snapshot back when rollback to savepoint is
 called, and creates a new snapshot for the second select. If anything,
 that is a bug in MySQL, because you just had a non-repeatable read in
 repeatable read isolation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
   Reporter: |  Owner:
  sebastian_noack| Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  mysql transaction
 Resolution: |  isolation
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by clelland):

 * cc: clelland@… (added)


Comment:

 I believe that this can be fixed without changing the isolation level, if
 MySQL savepoints are properly implemented (cf. #15507).

 If we re-order the savepoint setting and the initial read in
 get_or_create, then rolling back to the savepoint in the exception handler
 releases the IX lock, effectively rolling back to a point *before the read
 happened*. At that point, the second SELECT is not constrained by the
 REPEATABLE READ isolation, and is free to read the current row from the
 database. I've tested this in the MySQL shell (MySQL 5.0.51a)
 {{{
 CREATE TABLE savepoint_test (a INT PRIMARY KEY);
 }}}

 Before:

 ||=Process 1=||=Process 2||
 || BEGIN; || ||
 || SELECT * FROM savepoint_test WHERE a=1; || ||
 || > 0 rows returned || ||
 || || BEGIN; ||
 || || SELECT * FROM savepoint_test WHERE a=1; ||
 || || > 0 rows returned ||
 || || INSERT INTO savepoint_test (a) VALUES (1); ||
 || || COMMIT; ||
 || INSERT INTO savepoint_test (a) VALUES (1); || ||
 || > ERROR: Duplicate entry for key || ||
 || SELECT * FROM savepoint_test WHERE a=1; || ||
 || > 0 rows returned || ||

 After:


 ||=Process 1=||=Process 2||
 || BEGIN; || ||
 || SAVEPOINT p1; || ||
 || SELECT * FROM savepoint_test WHERE a=1; || ||
 || > 0 rows returned || ||
 || || BEGIN; ||
 || || SAVEPOINT p2; ||
 || || SELECT * FROM savepoint_test WHERE a=1; ||
 || || > 0 rows returned ||
 || || INSERT INTO savepoint_test (a) VALUES (1); ||
 || || COMMIT; ||
 || INSERT INTO savepoint_test (a) VALUES (1); || ||
 || > ERROR: Duplicate entry for key || ||
 || ROLLBACK TO SAVEPOINT p1; || ||
 || SELECT * FROM savepoint_test WHERE a=1; || ||
 || > 1 row returned || ||

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16751: GET variable names replaced by 'e'

[Django]

#16751: GET variable names replaced by 'e'
+---
   Reporter:  martopolis@…  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Bad formatting, let's see if this works:

 {{{
 if request.GET['myview'] == '1': ..
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16751: GET variable names replaced by 'e'

[Django]

#16751: GET variable names replaced by 'e'
--+---
 Reporter:  martopolis@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  contrib.admin
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 I'm attempting to override the queryset() method to make a custom filter
 for the Change List Admin view.  The idea was to append ?myview=1 to the
 URL and then check it like so:

 if request.GET['myview'] == '1':
 ...

 But everything I pass via the URL string is being replaced by the key name
 'e' in the GET dictionary:

 "Key 'myview' not found in "

 Curiously, this also happens in the final URL string.  That is, the URL
 gets rewritten and redirected to ?e=1 as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #12027: EmailField validation is incorrect, trailing dots fail (was: EmailField validation is incorrect)

[Django]

#12027: EmailField validation is incorrect, trailing dots fail
-+-
   Reporter:  Klas H |  Owner:  nobody
   Type: | Status:  reopened
  Uncategorized  |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  email, regular
 Resolution: |  expression, validation
   Triage Stage: |  Has patch:  1
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Josh C):

 * status:  closed => reopened
 * severity:   => Normal
 * cc: joshcartme@… (added)
 * resolution:  invalid =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 I'm not convinced this should be closed.  Although DNS should correctly
 resolve a domain with a trailing dot according to the specification
 (documented at the beginning of page 7 here
 http://www.ietf.org/rfc/rfc1034.txt) sending emails to addresses that end
 with a dot fails at least in my case.  For example I tried sending an
 email to and from a google apps address of mine using thunderbird.  I was
 sent back a Delivery Status Notification (Failure).

 When trying to use EmailMultiAlternatives with a email address of this
 form, m...@domain.com. as an example, msg.send() breaks with the following
 error:
 SMTPRecipientsRefused: {'m...@domain.com.': (501, ':
 domain missing or malformed')}

 Here is a quote from RFC 5321 section 2.3.5
 (http://tools.ietf.org/html/rfc5321#section-2.3.5):

 "A domain name (or often just a "domain") consists of one or more
 components, separated by dots if more than one appears."

 I think the important word is separated, it does not say terminated
 therefore an email address should not be terminated by a dot.

 More discussion on that here: http://tech.groups.yahoo.com/group/postfix-
 users/message/244166.

 At the very least I think this needs to be revisited and properly
 discussed.  Emails with dots at the end do not send so why should they be
 validated by Django?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16749: Looking For A Job? Job Board Software Is The Answer

[Django]

#16749: Looking For A Job? Job Board Software Is The Answer
-+-
   Reporter:  elpmaxe|  Owner:  nobody
   Type: | Status:  closed
  Uncategorized  |  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  WebScribble, Web
 Resolution:  invalid|  Scribble, webscribble reviews
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by akaariai):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16750: Searching For A Work? Job Board Software May Be The Answer

[Django]

#16750: Searching For A Work? Job Board Software May Be The Answer
-+-
   Reporter:  elpmaxe|  Owner:  nobody
   Type: | Status:  closed
  Uncategorized  |  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  WebScribble, Web
 Resolution:  invalid|  Scribble, webscribble reviews
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by akaariai):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Where is my resolve as SPAM!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16750: Searching For A Work? Job Board Software May Be The Answer

[Django]

#16750: Searching For A Work? Job Board Software May Be The Answer
-+-
 Reporter:  elpmaxe  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Milestone:   |  Component:
  Version:  1.3  |  Uncategorized
 Keywords:  WebScribble, Web Scribble,   |   Severity:  Normal
  webscribble reviews|   Triage Stage:
Has patch:  0|  Unreviewed
UI/UX:  0|  Easy pickings:  0
-+-
 Once on a period, searching for a job meant limitless paper research,
 strolling down roads, tedious and nervous interviews. This conventional
 method of work hunting is extremely time intensive, drains ones assets as
 well as quite boring. Using the advent of technologies, us has changed
 tremendously, such as work hunting. It’s called on the internet search.
 They are saying it is the best work search procedure. All you have to do
 would be to sign-up inside your local or worldwide job panel and get your
 job opening alerts. You can find a job providing very quickly. This is
 true too for personnel hunting.

 One most useful software program site is Job Board Software. There,
 you’ll find all types of work accessible and all sorts of other data you
 need in addition to all available information about potential recruits.
 With the introduction of this software, the efforts, energy and time
 consumed for searching jobs looking for possible applicants from the broad
 pool has become very simple as well as pleasant. There is no lengthier a
 necessity to line up, at first to publish resumes, then, for interviews
 which could be dull and time consuming for HR people.
 [http://www.webscribblemarketing.com Webscribble reviews] do not lay,
 learn!

 [http://www.webscribblemarketing.com WebScribble] Job Board Software is
 basically an internet site that needs to implement and perform several
 hiring strategies. It's integrated with assorted features making it
 competent to execute the requisite functions in hiring. This software is a
 platform where the open public can find all the required info associated
 with work or work postings.

 Job Board Software and can be handled even by greenhorns. It is simple to
 install demands no technical instruction. It is allied with easy interface
 which can be navigated easily. It has been constructed so it can be easily
 mixed online with the other current websites.

 There are two main kinds of queries provided in this software program
 which are both extremely effective. They are Fast Search for job seekers
 out to consider a job and Sophisticated Research that is most helpful for
 professionals looking for specific projects.

 Web Scribble Job Board Software strives would be to keep up with the user
 interface to the minimal degree but at the same time accomplish the
 specified final results. It is frequently up-to-date to enable you to keep
 up with the most recent developments and innovations thereby making
 certain they stay throughout the world competitive. This likewise promotes
 users to get to it usually. This will make Job Board Software the most
 favored in the industry. This means a better number of users thus opening
 up widest and largest swimming pool of human resource when it comes to
 hiring and related works not just for could be employees and employers
 however the general open public too.

 With Job Board Software, the job of the Human Resource Division of any
 agency has been made simple and easy , cheaper for everybody. No more is
 there a need to find custom-made software when Job Board Software can be
 utilized by anybody anywhere anytime.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16749: Looking For A Job? Job Board Software Is The Answer

[Django]

#16749: Looking For A Job? Job Board Software Is The Answer
-+-
 Reporter:  elpmaxe  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Milestone:   |  Component:
  Version:  1.3  |  Uncategorized
 Keywords:  WebScribble, Web Scribble,   |   Severity:  Normal
  webscribble reviews|   Triage Stage:
Has patch:  0|  Unreviewed
UI/UX:  0|  Easy pickings:  0
-+-
 As soon as upon a time, searching for a job meant limitless newspaper
 research, strolling lower streets, tiresome and nervous selection
 interviews. This conventional method of work searching is very time
 intensive, empties types assets as well as very tedious. Using the advent
 of technology, us is different greatly, such as work hunting. It’s
 called online research. They say it is the most efficient work search
 process. All you need to do would be to register inside your nearby or
 worldwide job panel and get your work opening notifications. You'll find
 employment offering very quickly. This is correct as well for personnel
 hunting.

 1 best software program website is Job Board Software. There, you will
 discover all sorts of work accessible and all sorts of other information
 you need in addition to all accessible details about possible recruits.
 With the development of miracle traffic bot, the efforts, time and energy
 eaten for searching jobs looking for possible applicants from a broad pool
 has become very simple in addition to enjoyable. There is no longer a need
 to line up, at first to publish cv's, then, for selection interviews which
 could be boring and laborious for HR individuals.
 [http://www.webscribblemarketing.com Webscribble reviews] do not lay,
 learn!

 [http://www.webscribblemarketing.com WebScribble] Job Board Software is
 actually a website that needs to implement and perform multiple
 recruitment strategies. It is incorporated with various features which
 makes it competent to perform the requisite capabilities in recruitment.
 This software is a platform where the open public will find all the
 required information related to employment or work postings.

 Job Board Software and be handled even by greenhorns. It is possible to
 install requires no specialized instruction. It is allied with simple
 interface which can be sailed effortlessly. It's been built so it can be
 easily mixed on the internet using the other current websites.

 There are two main kinds of queries made available in this software which
 are both extremely effective. These are Quick Look for people looking for
 work out to look for employment and Sophisticated Research which is most
 helpful for professionals seeking for particular projects.

 Web Scribble Job Board Software strives is to keep up with the user
 interface towards the minimal level but simultaneously achieve the
 specified final results. It's frequently up-to-date to enable the users to
 keep up with the most recent developments and innovations therefore making
 certain they remain globally competitive. This likewise encourages users
 to get to it most often. This makes Job Board Software the most favored in
 the market. What this means is a far greater quantity of customers
 therefore opening widest and largest swimming pool of hr in terms of
 hiring and associated works not just for would be workers and employers
 but the common public too.

 With Job Board Software, the job from the Hr Division of any agency has
 been made simple and easy , cheaper for everybody. No more is there a
 require to search for customized-made software program when Job Board
 Software can be accessed by anybody anywhere at any time.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16748: Documentation on creating custom querysets

[Django]

#16748: Documentation on creating custom querysets
---+---
 Reporter:  lee@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 Currently Django's documentation describes how customize the manager's
 initial query set
 (https://docs.djangoproject.com/en/dev/topics/db/managers/#modifying-
 initial-manager-querysets), but not how to create filters that can be used
 on an existing query set, at any position in the chain of filters.

 Doing so requires subclassing the queryset object.  This blog post
 describes the issue in more detail and proposes a solution:

 http://zmsmith.com/2010/04/using-custom-django-querysets/

 It would be helpful if there were an officially approved way to subclass
 querysets or add custom chainable filters, and it was part of the
 documentation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #12978: Support in syndication framework for CSS stylesheet links

[Django]

#12978: Support in syndication framework for CSS stylesheet links
-+-
   Reporter: |  Owner:  yuval_a
  intrepidweb| Status:  closed
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  syndication css
Version:  1.1|  stylesheets
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by yuval_a):

 * status:  new => closed
 * easy:   => 0
 * milestone:  1.3 => 1.4
 * ui_ux:   => 0
 * resolution:   => fixed
 * stage:  Someday/Maybe => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+---
   Reporter:  reinout  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by jacob):

 Sounds like a good idea to me. I'd think Russ's second suggestion
 (`get_context_data` returning some sort of proxy object) is a bit too
 complex, but I do like having the view object be available as `{{ view }}`
 in the template.

 If anyone wants to work up a patch, one important part not to miss is a
 careful audit of all view methods for ones with side-effects; those should
 be marked as `alters_data`
 
(https://docs.djangoproject.com/en/dev/ref/templates/api/#s-rendering-a-context).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16741: Naming a model field to "num_connections" causes syncdb to seemingly ignore it (mysql)

[Django]

#16741: Naming a model field to "num_connections" causes syncdb to seemingly 
ignore
it (mysql)
-+-
   Reporter:  honn@… |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution:  invalid|   Severity:  Normal
   Triage Stage: |   Keywords:  model, field,
  Unreviewed |  syncdb, mysql
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by honn@…):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Darn, original reporter here. I just noticed something I didn't notice
 before. We had added a num_connection function on the model where this
 refused to work, that was the problem. When I changed the name of the
 field it naturally started to work as the there was no longer a conflict.
 So I am closing the bug.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #13125: login_required does not check User.is_active

[Django]

#13125: login_required does not check User.is_active
-+-
   Reporter:  Matt   |  Owner:  nobody
  Dennewitz | Status:  closed
   Type:  Bug|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.1|   Keywords:  login_required,
 Resolution:  wontfix|  authorization, users
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jacob):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix


Comment:

 See [comment:2 ramiro's comments above]. `is_active` is a hook for custom
 auth sources and custom auth logic; the built-in stuff doesn't check it.
 Yes it's a bit counter-intuitive, but changing it is going to break a
 number of expectations in users' code, so it's going to need to stay as
 is.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16745: Different times on fields with auto_now and auto_now_add

[Django]

#16745: Different times on fields with auto_now and auto_now_add
-+-
   Reporter: |  Owner:  nobody
  kantntreiber@… | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  auto_now,
   Triage Stage:  Accepted   |  auto_now_add, DateTimeField,
Needs documentation:  0  |  DateField, field
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by akaariai):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Accepted because, yes, it would be nice if the times matched. However I
 believe this will not get fixed soon, as there isn't a trivial (as in one-
 liner) fix, and for most developers this doesn't have a high priority.
 Unless of course somebody interested in fixing this creates a clean patch
 with tests.

 To get me interested in this ticket, an approach which would go along the
 lines of:
   - Record transaction start time in Django (something like PostgreSQL
 now())
   - Use that time in auto_now and auto_now_add

 In my opinion the approach is a good one because transaction start time
 has other uses than solving this ticket's problem, and it would be
 hopefully easy to solve this ticket's problem as a trivial one-liner as a
 side effect of having the transaction start time available. In addition,
 the transaction start time would make all objects saved in one transaction
 have the same time.

 Then again, I don't know if core developers would be interested in this
 approach...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #15923: Validate that IntegerField is a valid Signed value for databases that don't do it themselves.

[Django]

#15923: Validate that IntegerField is a valid Signed value for databases that 
don't
do it themselves.
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Petr Marhoun ):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Sorry, I can't read - now I see that this ticket is about hiding of an
 database error, not about this database error. So there is another ticket:
 #16747 - this one is closed again.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16747: IntegerField could validate too large numbers to work with PostgreSQL and MySQL be default

[Django]

#16747: IntegerField could validate too large numbers to work with PostgreSQL 
and
MySQL be default
-+-
 Reporter:  Petr Marhoun |  Owner:  nobody
 | Status:  new
 Type:  Bug  |  Component:  Database layer
Milestone:   |  (models, ORM)
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  0
UI/UX:  0|
-+-
 Be default (without some additional validation) integer fields in Django
 do not checks any intervals for inserted numbers. So for example, if
 someone try official tutorial from Django documentation and use
 recommended database (PostgreSQL), he can get uncatched exception
 ("!DatabaseError: integer out of range"). It would be nice to validate
 this range - it is problem not only for PostgreSQL but also for MySQL (but
 I do not know if these two databases are so important that they should
 define interval common for all databases).

 !BigIntegerField in Django checks interval [2 ^63^, 2 ^63^ - 1] so for
 consistency !IntegerField could check interval [2 ^31^, 2 ^31^ -1]. Also,
 for other main fields (for example char fields or float fields or decimal
 fields or date fields) it is quite difficult or impossible to get
 uncatched exceptions - but it is really easy for integer fields.

 I prepare patch with two tests - one (for !BigIntegerField) passes on all
 tested databases (PostgreSQL 8.4.8, MySQL 5.1.54 with InnoDB, SQlite from
 Python 2.7.1 - everything on Ubuntu 11.04 64bit). The almost same second
 one (for !IntegerField) failes on PostgreSQL with "!DatabaseError: integer
 out of range" and on MySQL with "!AssertionError" (saved number is
 truncated).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #15923: Validate that IntegerField is a valid Signed value for databases that don't do it themselves.

[Django]

#15923: Validate that IntegerField is a valid Signed value for databases that 
don't
do it themselves.
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  reopened
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Petr Marhoun ):

 * status:  closed => reopened
 * ui_ux:   => 0
 * resolution:  wontfix =>
 * version:  1.3 => SVN


Comment:

 I am not sure if I should reopen ticket closed by a core developer,
 especially after direct note. But I think that the resolution was based on
 invalid imformation - that only MySQL is broken, SQLite and recommended
 PostgreSQL are OK. But I think it is not true. Documentation of PostgreSQL
 say:  "integer  4 bytes  typical choice for integer 
 -2147483648 to +2147483647":

 http://www.postgresql.org/docs/9.0/interactive/datatype-numeric.html

 Moreover, !BigIntegerField in Django checks interval [2 ^63^, 2 ^63^ - 1]
 so for consistency !IntegerField could check interval [2 ^31^, 2 ^31^ -1].

 I prepare patch with two tests - one (for !BigIntegerField) passes on all
 tested databases (PostgreSQL 8.4.8, MySQL 5.1.54 with InnoDB, SQlite from
 Python 2.7.1 - everything on Ubuntu 11.04 64bit). The almost same second
 one (for !IntegerField) failes on PostgreSQL with "!DatabaseError: integer
 out of range" and on MySQL with "!AssertionError" (saved number is
 truncated). (But I do not know if these two databases are so important
 that they should define interval common for all databases.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
-+-
   Reporter:  haras  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Description changed by ramiro:

Old description:

> Try disabling an 'django.contrib.sites' app, (which as it is a contrib
> app, should be an optional), and you'll get an error in tests with
> django.contrib.auth.tests.forms.PasswordResetFormTest

New description:

 Disabling 'django.contrib.sites' app causes error in
 django.contrib.auth.tests.forms.PasswordResetFormTest when running
 `manage.py test`

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
-+-
   Reporter:  haras  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous coward):

 Why does this need tests when the diff fixes a failing test (TDD:
 "...first the developer writes a failing automated test case..."), and the
 change is 1 line.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16746: Include default reason phrases for WebDAV

[Django]

#16746: Include default reason phrases for WebDAV
---+---
 Reporter:  vfaronov   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  HTTP handling
  Version:  SVN|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+---
 Django ships a mapping of HTTP status codes to reason phrases in
 django/core/handlers/wsgi.py (they are not overridable; see ticket:12747).
 It covers codes defined in HTTP/1.1 (RFC 2616). I would like to extend
 this list with codes from the WebDAV protocol (RFC 4918). Some of these
 codes (such as 422) are useful when building HTTP APIs, and seeing a
 reason phrase in a response instead of "UNKNOWN STATUS CODE" aids
 development. WebDAV is a well-established protocol, and RFC 4918 is
 Proposed Standard at IETF.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16745: Different times on fields with auto_now and auto_now_add

[Django]

#16745: Different times on fields with auto_now and auto_now_add
-+-
 Reporter:  kantntreiber@…   |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer
  Version:  1.3  |  (models, ORM)
 Keywords:  auto_now, auto_now_add,  |   Severity:  Normal
  DateTimeField, DateField, field|   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 There is a little issue with using "auto_now" and "auto_now_add" together
 in one model. Because the time is set by calling datetime.now() in the
 pre_save method of the field, using together more than one such field
 would lead to different values for every field. This is bad, as one
 expects that the time is the time of the creation or change of the object
 and therefore should be identical across all of its fields.

 An example:

 {{{
 class FooModel(models.Model):
 time_changed = models.DateTimeField(auto_now=True)
 time_created = models.DateTimeField(auto_now_add=True)


 In [3]: from models import FooModel

 In [4]: o=FooModel()

 In [5]: o.time_changed

 In [6]: o.save()

 In [7]: o.time_changed
 Out[7]: datetime.datetime(2011, 9, 2, 11, 21, 37, 582956)

 In [8]: o.time_created
 Out[8]: datetime.datetime(2011, 9, 2, 11, 21, 37, 582857)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+---
   Reporter:  reinout  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by jonash):

 * cc: jonas-django@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+---
   Reporter:  reinout  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by jezdez):

 * stage:  Unreviewed => Accepted


Old description:

> Summary: `your_cbv_object.get_context_dict()` should include `{'view':
> self}`.
>
> Now that django has class based views, I was surprised that I don't get
> the view object in my template's context. And that I still have to hand-
> craft my context dictionary.
>
> What would be handier than setting attributes or adding methods to the
> view class and accessing them with `{{ view.my_attribute }}` and ``{{
> view.my_method }}`? Without having to do the double work of adding them
> by hand to the context dictionary? An additional benefit: you encourage
> to do even more in python and even less in the template by making it easy
> to add helper methods in your view.
>
> The solution could as simple as adding `{'view': self}` in the three or
> four spots in django itself where a `.get_context_dict()` is defined.

New description:

 Summary: `your_cbv_object.get_context_data()` should include `{'view':
 self}`.

 Now that django has class based views, I was surprised that I don't get
 the view object in my template's context. And that I still have to hand-
 craft my context dictionary.

 What would be handier than setting attributes or adding methods to the
 view class and accessing them with `{{ view.my_attribute }}` and ``{{
 view.my_method }}`? Without having to do the double work of adding them by
 hand to the context dictionary? An additional benefit: you encourage to do
 even more in python and even less in the template by making it easy to add
 helper methods in your view.

 The solution could as simple as adding `{'view': self}` in the three or
 four spots in django itself where a `.get_context_data()` is defined.

--

Comment:

 Corrected `get_context_dict` to `get_context_data`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+---
   Reporter:  reinout  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by reinout):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 As background, here's what Russ Magee said on the mailinglist about this
 after I asked about it:

   To the best of my knowledge, the only reason the view isn't included
   in the template context is because over more than two years of design
   discussion, I don't think the idea of including the view in the
   context was ever proposed.

   It seems like a reasonable idea to me, though, and it should be
   possible to accommodate in a backwards compatible fashion. The trivial
   fix would be to add a 'view' variable to the default context. It might
   also be possible to replace the default get_context_data
   implementation with something that reflects the attributes of the view
   object  itself -- however, this will obviously require a bit more
   design work to make sure there aren't any backwards incompatible
   implications.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
-+---
 Reporter:  reinout  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Generic views
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 Summary: `your_cbv_object.get_context_dict()` should include `{'view':
 self}`.

 Now that django has class based views, I was surprised that I don't get
 the view object in my template's context. And that I still have to hand-
 craft my context dictionary.

 What would be handier than setting attributes or adding methods to the
 view class and accessing them with `{{ view.my_attribute }}` and ``{{
 view.my_method }}`? Without having to do the double work of adding them by
 hand to the context dictionary? An additional benefit: you encourage to do
 even more in python and even less in the template by making it easy to add
 helper methods in your view.

 The solution could as simple as adding `{'view': self}` in the three or
 four spots in django itself where a `.get_context_dict()` is defined.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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