Top Menu

Jump to content
Home
    Modules
      • Projects
      • Activity
      • Work packages
      • Gantt charts
      • Calendars
      • Team planners
      • Boards
      • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • News
  • Forums

Content

Development
  1. OpenProject
  2. Forums
  3. Development
  4. Searching workaround for bug #31940 (changing default pageSize)

Searching workaround for bug #31940 (changing default pageSize)

Added by Freddy Trotin over 5 years ago

Hi, I have set up my development environment in order to see if I can find a workaround to the bug #31940.

I noticed in the logs that "My page" calls "/api/v3/time_entries?filters=[{"spentOn":{"operator":">t-","values":["7"]}},{"user_id":{"operator":"=","values":["me"]}}]" and opening this URL gives me this output :

{"_type":"Collection","total":31,"count":30,"pageSize":30,"offset":1,"_embedded":...

So I think that the bug is due to the lack of paging in the "SPENT TIME (LAST 7 DAYS)" grid (there should be a "Page 2" link to "offset:2").

Waiting for this bug to be fixed, I thought I could make my own workaround by changing this default "pageSize:30" in some file (having pageSize:50 would do the trick for me).

So I used this command to find in which file this default value is set :

grep -R "pageSize.*30" /openproject

Which gave me these results :

/openproject/docs/api/apiv3/endpoints/grids.apib:                "pageSize": 30,

/openproject/docs/api/apiv3/endpoints/grids.apib:                        "href": "/api/v3/grids?offset=1&pageSize=30"

/openproject/docs/api/apiv3/endpoints/grids.apib:                        "href": "/api/v3/grids?offset=%7Boffset%7D&pageSize=30",

/openproject/docs/api/apiv3/endpoints/documents.apib:                "pageSize": 30,

/openproject/docs/api/apiv3/endpoints/documents.apib:                        "href": "/api/v3/documents?offset=1&pageSize=30"

/openproject/docs/api/apiv3/endpoints/documents.apib:                        "href": "/api/v3/documents?offset=%7Boffset%7D&pageSize=30",

/openproject/spec/requests/api/v3/user/user_resource_spec.rb:          .to be_json_eql((api_v3_paths.users + '?offset=1&pageSize=30').to_json)

/openproject/spec/lib/api/v3/work_packages/work_package_collection_representer_spec.rb:            expected_query = query.merge(pageSize: 30, offset: 1)

/openproject/spec/lib/api/v3/work_packages/work_package_collection_representer_spec.rb:              expected_query = query.merge(pageSize: 30, offset: 1)

/openproject/spec/lib/api/v3/work_packages/work_package_collection_representer_spec.rb:        let(:href) { '/api/v3/example?a=b&b=c&offset=1&pageSize=30' }

So I tried to replace "30" by "50" in each of these files and refreshed my page but it didn't change anything.

I don't know the ruby language so I don't know if what I try to do can work (maybe it needs compiling some files).

Does anybody know if it may work (in development and in production environment) ?


Replies (1)

RE: Searching workaround for bug #31940 (changing default pageSize) - Added by Henriette Darge about 5 years ago

In case somebody is still looking for this: 
The bug has been fixed with version 10.4.0. So with that version, there is no work around needed any more. 

Thanks a lot, Freddy, for your detailed ticket and description of this issue.

  • (1 - 1/1)
Loading...