#942 0% Completed in all MS Project imported task

[Anonymous]

Importing a MS Project XML into a project doesn't compute the completed % correctly. All task are imported 0% completed.

[Anonymous]

Ok, found the parameter option in the admin. But if I try to change UpdatePercentCompletedP from 0 to 1 I get the following error:

The parameter could not be updated. The database returned the following error:

couldn't open "/web/projop/packages/intranet-ganttproject/intranet-ganttproject.info": permission denied

I've modified the file as root from console, but it doesn't seem to manifest the changes, even reloading the module AND the server. Probably loading the value from other path?

[Klaus Hofeditz]

Please make intranet-ganttproject.info writable for user 'projop' and try again.

[Anonymous]

I gave permissions to the user and now the paremeter is set correctly. But this does not change the behaviour, the project still gets imported with 0% :(

I tried editing tcl/intranetproject.tcl, and overriding the if in line 390. Same behaviour.

Any tip? I'm I doing someting wrong?

Thanks!

[Anonymous]

The % completed gets actually imported as blank, not 0%.

[Anonymous]

I have news, I could bypass the issue by changing packages/intranet-ganttproject/tcl/intranet-ganttproject-procs.tcl line 1390 to:
if {$save_percent_completed_p} { set percent_completed_sql "percent_completed = :percent_completed," } else { set percent_completed_sql "percent_completed = :percent_completed," }

This makes the imports use the xml complete percent. Apparently there's something that prevents the if sentence to be true. I tried setting the package parameter to 1 from the admin and even in the tcl file; but I can't figure out what is.

Hope this helps.

Cheers!

[Anonymous]

I'm getting a painfully slow performance now :(

The imported project had ~700 task, all imported correctly. But the project summary tab is really slow, ~88sec; and the Gantt tab too, takes 65-70 sec to load. I've vacummed the DB, and tested some PostreSQL.conf parameters, with no luck, takes the same amount of time.

I copy here the debug and the first query, notice how it takes 16 secs!:

Query:  &project_id=46795&view=default

Request Processor

+011.0 ms: Trying rp_serve_abstract_file /web/projop/www/intranet-ganttproject/gantt-view-cube
+011.0 ms: File /web/projop/www/intranet-ganttproject/gantt-view-cube: Not found
+011.0 ms: Applied transformation from /web/projop/www/intranet-ganttproject / gantt-view-cube -> ? - 0.0 ms
+011.0 ms: Trying rp_serve_abstract_file /web/projop/packages/intranet-ganttproject/www/gantt-view-cube
+012.0 ms: Served file /web/projop/packages/intranet-ganttproject/www/gantt-view-cube.adp with adp_parse_ad_conn_file - 62656.0 ms
+62670.0 ms: Applied GET filter: (for /intranet-ganttproject/gantt-view-cube ds_trace_filter) - 3.0 ms
    returned filter_ok

show RP debugging information

Headers

Host:   192.168.56.102
User-Agent:     Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Accept:     text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:    es-ar,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding:    gzip, deflate
Referer:    http://192.168.56.102/intranet/projects/view?project_id=46795
Cookie:     isExtendedCookie=0; ad_session_id=830853%2c624%2c1%2c1397061840+%7b82+0+36C16BB6BC61388B291B009B5D837F39E6736C16%7d; ad_user_login=624%2c1397055240%2c0367B9B91%2c1+%7b86+0+FABD4FA81AACF9EC1013E0A44EBE4BE99C6A2D05%7d
Connection:     keep-alive
X-Forwarded-For:    192.168.56.1

Output Headers

Expires:    Wed, 09 Apr 2014 16:47:46 GMT
Pragma:     no-cache
Cache-Control:  no-cache
MIME-Version:   1.0
Date:   Wed, 09 Apr 2014 16:47:46 GMT
Server:     AOLserver/4.5.1
Content-Type:   text/html; charset=utf-8
Content-Length:     94793
Connection:     keep-alive

Duration Command SQL
36,908 Total Duration (ms)
12084 ms select dbqd.intranet-ganttproject.tcl.intranet-ganttproject-procs.im_ganttproject_gantt_component.left: select pool1 nsdb0

select distinct
c.project_id,
c.project_name,
c.level,
c.tree_sortkey
from
(
select
h.*,
''||project_name||'' as project_name_link,
to_char(h.d, 'YYYY') as year,
'Q' || to_char(h.d, 'Q') as quarter_of_year,
'' || to_char(h.d, 'Mon') as month_of_year,
'W' || to_char(h.d, 'IW') as week_of_year,
'' || to_char(h.d, 'DD') as day_of_month
from (
select
1 as days,
tree_level(child.tree_sortkey) - tree_level(parent.tree_sortkey) as level,
child.project_id,
child.project_name,
child.project_nr,
child.tree_sortkey,
d.d
from
im_projects parent,
im_projects child,
( select im_day_enumerator as d
from im_day_enumerator (
to_date('2008-10-27', 'YYYY-MM-DD'),
to_date('2045-03-25', 'YYYY-MM-DD')
) ) d
where
parent.project_status_id in (76)
and parent.parent_id is null
and child.tree_sortkey between parent.tree_sortkey and tree_right(parent.tree_sortkey)
and d.d between child.start_date and child.end_date
and parent.project_id in (46795)
) h
) c
order by
c.tree_sortkey

Any advice? should I open another ticket? I'm running the 'official' VM downloaded from your website; with 4GB RAM. When the query runs, postgre uses 100% CPU, tried adding a second CPU to the VM, some result.

Thanks in advance.

[Klaus Hofeditz]

Did you notice that one of the dates used in the sql goes as far as the year 2045? ./k

[Anonymous]

Yes, I did. Is correct, that the lifespan of the project.

[Anonymous]

I ran the same query changing the end year to 2015 and it takes 6secs to complete. That's a much better performance, but sadly the project has the dates pasted in the previous post. Is there anyway of tunning the query to perform better? Limiting the Gantt to next 5 years for example? I think this scenario is valid and should be considered. What is your opinion, Klaus?