Hello everyone,

I can no longer get the Project Dashboard (TdB Projects) to work.

The overall configuration seems correct:

• WBS structure is defined
• Parent and child projects are configured
• Projects are selected and visible
• Activities contain data
• Time, priorities, statuses and tags are populated

However, the dashboard remains empty and I receive the following message:

"No data to display"

I have verified that:

• Projects exist and are active
• Activities are planned
• Portfolio and project hierarchy are available
• Project progress and workload data are calculated

Version: ProjeQtOr 13.0.1

Has anyone encountered this issue before or could suggest what else I should check?

Thank you for your help.

If i try to add attenddes to meeting then this error appears in Log. The application hangs on spinner.

Best regards

Markus

When we updated Projeqtor from V12.4.3 to V13.1.0, we lost all the customizations we had already made.
The customization plugin is at version V8.1.

However, when we recreate (in V13) the fields with the same original names (created in V12), the values entered for those fields are still there.

Is there a specific step we need to take to avoid this problem? 

RACI

• New management of RACI
• Definitiion of template RACI
• Use template on Project
• Select role for resources on Project

New "Document" interface

• Shows directories in tree like view
• Select directory show documents existing in the folder
• Select a document show detail (meta data, versions)

Filtering criteriea improvements

• Possibility to add filter criteria "at a given place"
• Possibility to have up to 3 (at least) levels of groups

• Add import progress
• Possibility to leave import screen during long import
• Preserve last import result and view it on import screen

Mention with @

• Pop-up opens to easily select resource/user
• Small icons will show what will be done depending of selected resource/user and user option

Project Dashboard

• Tornado graph on detail
• RACI on detail
• Button to download attached files
• Sort by end date
• Sort by creation date (most recent)

Global search

• New button to search globally on any item
• Will open result in Global List
• Can restrict to select projets or not (then extends to all visible projects)

New design for the application windows

• Change display for messages (save, control issue)
• Change display for alerts (bottom righ pop-ups)

Possibility to force addition of a note on status change

• Definition of status that will force a note on Type
• Opens pop-up to add a note
• Does not require note if a note already recently added (less than 5mn ago)

OTP system

• Possibility to request code sent to email adress
• Allows 2FA (2 Factors Authentication)
• Can request 2FA for connections of admin users
• Can request 2FA for direct connections when SSO in enabled
• Can request 2FA for new users on first connection
• Additional controls may use this system on next versions (validation from approver, some "signature", ...)

CRM improvments

• New Prospect quotation to estimate possible revenue from prospect
• Recors prospection actions on Client and Contact
• Concolidated Dashboard view from Prospects / Clients / Contacts
• Dashboard view lists all prospection actions from any source
• Dashboard view lists financial parts from Prospect (Quotations) and Client (Quotations, Commands, Invoices)

You can also consult the conplete changelog. 

If is now the last stable release.

This is the last patch on V13.0 as version V13.1 will come very soon.

Description

When editing a long text field that uses CKEditor (e.g. the Result field of an Issue) that already contains a large amount of rich HTML — specifically content pasted from Outlook/Word, which typically embeds several repeated <style> blocks throughout the body — saving any change to that field wipes out almost all of the existing content and leaves only a small fragment.

Example (minimal reproduction)

Field content before editing (simplified — imagine this pattern repeated many times in a real Outlook paste):

<div>Line kept before the bug strikes</div>
<div>
<style type="text/css">a { color: #464feb; }</style>
<div>Important paragraph #1 that should stay</div>
<style type="text/css">a { color: #464feb; }</style>
<div>Important paragraph #2 that should stay</div>
<style type="text/css">a { color: #464feb; }</style>
<div>Important paragraph #3 that should stay</div>
</div>

Same field after saving a small, unrelated edit:

<div>Line kept before the bug strikes</div>
<div>

Everything between the first <style> tag and the last </style> tag is silently deleted on save. On a real ~25 KB Outlook paste with many scattered <style> blocks, this wipes almost the entire field, leaving only the first line.

Root cause & fix

In model/persistence/SqlElement.php, method updateSqlElement(), a cleanup step meant to strip stray <style> blocks from pasted content uses a regex with a mistaken negative lookahead — it checks for </script> instead of </style> (looks copy-pasted from a <script> stripper). Since the input never contains </script>, the lookahead never blocks anything, so the pattern greedily matches from the first <style to the last </style> in the whole document instead of stopping at each tag's own closer — deleting everything in between. There's also no check on preg_replace()'s return value, so extremely large content could hit pcre.backtrack_limit and return NULL, wiping the field entirely.

I've already applied this fix locally:

 1769          if ($col_new_value&&$isText and $dataLength>4000 and pq_substr(getEditorType(), 0, 2)=='CK') {
 1770            // if (pq_strpos($col_new_value,'<script')!==false) {
-1771            $pattern='/<style\b*(?:(?!<\/script>)<*)*<\/style>/i';
+1771            $pattern='/<style\b*(?:(?!<\/style>)<*)*<\/style>/i';
 1772            $replacement='';
-1773            $col_new_value=preg_replace($pattern, $replacement, $col_new_value);
+1773            $newValueAfterStyleStrip=preg_replace($pattern, $replacement, $col_new_value);
+1774            if ($newValueAfterStyleStrip!==null) {
+1775              $col_new_value=$newValueAfterStyleStrip;
+1776            }
 1777            // }

This restores the intended behavior (strip each <style>...</style> pair individually) and prevents the field from being wiped if preg_replace() ever fails.

I'm sharing this so it can be added to your bug list and fixed in a future release.

Note: my fix may not be the "correct" solution from your perspective — it's just what let me keep editing the Result field in the meantime, until you come up with a proper fix for a future version.