Menu

Portal Tickets - lazy loading, but anyway execution time exceed

2023-08-24
2024-07-31
  • Martin Sich

    Martin Sich - 2023-08-24

    Hello, can someone please advise me if they have encountered this? We have "lazy" loading set for both ongoing and closed tickets (in Portal), because we have around 1,500 ongoing and over 40,000 closed tickets. However, unfortunately, despite setting the max execution time to 45 seconds, it doesn't load (after 45 seconds there is message Error: Maximum execution time of 45 seconds exceeded (with &debug=true there is no additional information)...
    I have the feeling that all the tickets are loaded in the background tickets and individual pages are displayed accordingly, is this possible? Is there any way to change this to load only what is needed? in the back-office interface it's no problem...

    For completeness, here are parts from datamodel-production.xml file, where we have lazy loading set (for closed tickets, but the same way is used with ongoing tickets):

    <brick id="closed-tickets-for-portal-user" xsi:type="Combodo\iTop\Portal\Brick\ManageBrick" _altered_in="itop-tickets">
              <active>true</active>
              <rank>
                <navigation_menu>50</navigation_menu>
              </rank>
              <visible>
                <home>false</home>
              </visible>
              <width>12</width>
              <title>
                <default>Brick:Portal:ClosedRequests:Title</default>
              </title>
              <description/>
              <decoration_class>
                <default>fc fc-closed-request fc-2x</default>
              </decoration_class>
              <oql _altered_in="mediso-tickets-rules"><![CDATA[SELECT Ticket AS T WHERE operational_status = 'closed']]></oql>
              <!-- Can be either a class tag with the class name or an oql tag with the query -->
              <!-- <class>Ticket</class> -->
              <fields>
                <field id="finalclass"/>
                <field id="title"/>
                <field id="start_date"/>
                <field id="status"/>
                <field id="servicesubcategory_id"/>
                <field id="priority"/>
                <field id="caller_id"/>
              </fields>
              <grouping _altered_in="mediso-tickets-rules">
                <tabs>
                  <show_tab_counts>false</show_tab_counts>
                  <groups>
                    <group id="all">
                      <rank>1</rank>
                      <title>Brick:Portal:ClosedRequests:Title</title>
                      <condition><![CDATA[SELECT Ticket AS T WHERE operational_status = 'closed']]></condition>
                    </group>
                  </groups>
                </tabs>
              </grouping>
              <data_loading _altered_in="mediso-tickets-rules">lazy</data_loading>
              <export>
                <export_default_fields>true</export_default_fields>
              </export>
            </brick>
    

    Thank you very much in advance to everyone for any advice / possible solution :)

     
  • Thangaraj

    Thangaraj - 2024-03-25

    Hi did you find the solution? If yes please share the solution thanks.

     
  • selvambikai k

    selvambikai k - 2024-04-09

    please share the solution thanks.

     
  • Martin Sich

    Martin Sich - 2024-04-09

    Hi, unfortunately, I didn't find a solution - only a workaround, where I load only data from the last 2 years into the portal as part of closed tickets section, however, when someone needs to search for something historically, we always have to solve it within the back office interface...

     
    • Marah Alh

      Marah Alh - 2024-07-31

      Hi dear,
      did you find the solution?
      I face same problem even after upgrade to iTop 3.1.1 with php 8.1.29

       

      Last edit: Marah Alh 2024-07-31

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.