Code

Opened 6 years ago

Closed 5 years ago

#9798 closed (wontfix)

object_list paginated raise a http404 when a its a InvalidPage

Reported by: zodman Owned by: nobody
Component: Generic views Version: master
Severity: Keywords: page paginator object_list
Cc: askfor@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

on views.generic.list_details.object_list

        if not page:
            page = request.GET.get('page', 1)
        try:
            page_number = int(page)
        except ValueError:
            if page == 'last':
                page_number = paginator.num_pages
            else:
                # Page is not 'last', nor can it be converted to an int.
                raise Http404
        try:
            page_obj = paginator.page(page_number)
        except InvalidPage:
            raise Http404

Let me check this case when i have a page with this url

foo/bar/?page=10

on page ten i have 3 objects showed.

if i delete 3 objects the page its invalid not a Http404, because the page exist before erase ...

its better do the same validator a example on paginator, if the page not exist get the latest page/objects.

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

This is an intentional behavior, not a bug. A missing page is a 404.

comment:2 Changed 5 years ago by askfor

  • Cc askfor@… added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I came across the same problem.
User delete some objects and then redirect to the previous page, got a http404.
It would be better if we can control the behavior. (get the last page as zodman said or something else)
And all those date-based generic views have the "allow_empty" argument so that this behavior can be controlled by programmer.

comment:3 Changed 5 years ago by Alex

  • Resolution set to wontfix
  • Status changed from reopened to closed

You can control the behavior. Write your own wrapper function. In any event if you disagree the closure of a ticket by a core developer please do not reopen it, instead start a discussion on the django-developers mailng list.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.