View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0008137mantisbtbugtrackerpublic2007-07-10 14:582009-06-26 14:15
Reporteredwardgao Assigned Todhx  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.1.0a2 
Fixed in Version1.2.0rc1 
Summary0008137: Custom constants do not work
Description

Not like config_inc.php, you need to overwrite the default values.
In PHP, once a constant is defined, it can never be changed or undefined.

But in the core.php, 

# Load constants and configuration files
require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'core'.DIRECTORY_SEPARATOR.'constant_inc.php' );
if ( file_exists( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constant_inc.php' ) ) {
    require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constant_inc.php' );
}
Additional Information

Suggest adjust the sequence of constants definition.

As I redefined a customized "resolved" status, and the value is not '80' in $g_status_enum_string, the constant of "RESOLVED" caused an email problem. Because only '80' is unset in the email_api.php. Not my "resloved" status, even I changed the constants definition, as it is loaded after the default one, it does not work at all.

Also, I found there are some files (time tracking) use '80' directly instead of "RESOLVED" constant. This will bring much trouble when customized the status.

TagsNo tags attached.

Relationships

Relationship GraphDependency Graph
child of 0010330 closeddhx Remove all hardcoded enum levels from within Mantis code 

Activities

vboctor

vboctor

2007-07-10 23:26

manager   ~0014920

I've found the values used (rather than the constants) in the following files:

graphs\graph_by_cumulative.php
graphs\graph_by_daily_delta.php
graphs\graph_by_release_delta.php
graphs\graph_assigned_to_me.php
graphs\graph_by_severity.php
graphs\graph_by_severity_status.php
graphs\graph_reported_by_me.php

Please include any other files that does the same and not listed above.

At the moment is is not recommended to change the numbers of existing statuses, specially the resolved one. I typically define the other constants around it.

However, as a possible fix, we can include the custom constants first, and then in our constants we do define them if not defined already. Specially for the ones that we expect them to be customized by users.
brazo

brazo

2007-07-11 10:34

reporter   ~0014929

I notice that files in \graph\ folder are not used in Mantis.
edwardgao

edwardgao

2007-07-11 13:15

reporter   ~0014932

No, they are not used in current version.

My question is what if we have already customized RESOLVED to be 75, Should we go back to database to change all the statuses back to 80? Will this cause any problems? I believe I need to change the bug and bug_history table.

What is your estimation if I do not change the RESOLVED back to 80?

I suggest the "resloved" value to be customizable. because you never know what is a "resolved", some think after unit test, some think when moved to QA test, some think after QA test, some think after production depolyment.