Suggestions and one semi-bug

Submitted by milliwatt on

I have moved from alpha4 to beta1 and reconfigured. I am releived that, from now on, there will be an upgrade path.

I appreciate the new relation between alert and notification.
But I would like this to go one step further: a notification should not be linked to an alert.
An alert is a visual tool of the GUI a notification is warning/recap sent by email.
I think it is common to want an immediate notification and, for example, a weekly summary notification for a view.
Thus, I would like to be able to set multiple notifications for a view and consequently each notification should have a separate schedule.

I would like the admin be able to set a default view for each Type other than All Issues

I don't understand why the Type attribute "Name" is mandatory for all views

The conditional filters for a date/time attribute now use a pop-up calendar.
My configuration is in French, unfortunately the variable [Today] of the pop-up is not translated.
I fiddled for some time before substituting the correct French string.

Thank you for a usefull product

I agree that there is still a lot to improve in the area of views, alerts and notifications. I will do that in the next version when I gather feedback from more users.

I will also investigate the bug in the French version.

Regards,
Michał

Just to be clear about the translation, I was referring to the WEB client

For that same client many strings don't appear translated in the interface but I checked the ts file and all strings are translated, which leads me to beleive either the line number reference is incorrect or there are missing strings in the ts file

I guess so, this is what my provider reports:

Architecture x86_64
Apache version 2.2.16
PHP version 5.2.14
MySQL version 5.0.92-community

That would explain the problem. It turns out that the crc32 function in PHP (on which my translation system relies) returns different values on 64-bit Linux platforms. Thanks for reporting this, I will fix it in the next release.

Regards,
Michał

Please add the following code before the foreach statement in line 154 of system/core/translator.inc.php and check if this solves this problem: 

if ( $crc > System_Const::INT_MAX )
    $crc = $crc - 2 * System_Const::INT_MAX - 2;

Regards,
Michał

The code you sent me gave a 500 internal server error

I was able to verify that
PHP_INT_MAX = 9223372036854775807
PHP_INT_SIZE = 8 (which seems to be consistent with a 64 bit system)
So I made the following substitution just to see
if (PHP_INT_SIZE == 8)
$crc = $crc - 2 * PHP_INT_MAX -2 ;
I got no errors but all strings were not translated

What is strange is that some strings are translated but not all
for example
the main admin window menu is : Administration Panel | Client Web | WebIssues 1.0-beta1 | Manual
The menu options for a folder are :
Ajouter un "Issue" | Renommer le Dossier | Move Folder | Supprimer le Dossier | Mark All As Read | Marquer Tout comme non lu
Add View | Manage Views | Gérer les Alertes

If it was a crc 64 bit issue would'nt all strings not be translated ?

It's related to this bug in PHP. The crc32 function returns wrong value in 50% of cases, that's why half the strings are translated correctly. See also this comment which shows a workaround. You can't use PHP_INT_MAX because it's a 64-bit value and you need to subtract the maximum 32-bit value, which is System_Const::INT_MAX. I have no idea why this code gives an internal error, could you enable debugging and post the details?

Regards,
Michał

The good news is your solution works !!

Yesterday,
I made a backup of the orignal file and inserted your code and got 500 error
I erased the file recopied the backup translator.inc.php and recopied the code

But I made the same error twice : I did not copy a « ; » ! ! !

Sorry for wasting your time

Bug fixed, thanks