Enumerations/constants, same functional value?

Get help from other users here.

Moderators: Developer, Contributor

Post Reply
Starbuck
Posts: 219
Joined: 14 Feb 2006, 02:53
Location: USA
Contact:

Enumerations/constants, same functional value?

Post by Starbuck »

There are cases where some ticket settings are functionally equivalent, though for context I'd like the text to be different.
For example:

With a Projection, all of the default terms assume something that exists is going to be changed:
Minor Fix, Major Rework, Redesign
But that doesn't apply to new efforts, where the functional equivalent could be:
Small New, Significant New, New Subsystem
In this case, I don't care if a change is a minor fix to existing code or a small new program, but I do want to see all "minor" stuff together when I do a search, and the projection enum would have the same value for Minor_Fix and Small_New.

So, we can add constants and enums with different enums, but is there any harm in adding a new contant or enum with the same value as another?

On the down-side of that practice, what if we actually do want to see just the tickets related to New code and not to existing code? A search for either will always return tickets for both, because the enum values are the same.

Someone could suggest that rather than adding new projection types it might be more appropriate to add a custom selection for New vs Existing code, and then change projections to Minor, Medium, and Significant. Sure, this is just an example.

As another example, what would happen if we added another developer role, that for current purposes is exactly the same as the default?
$g_access_levels_enum_string =
'10:viewer,25:reporter,55:database_developer,55:app_developer,60:senior_developer,70:manager,90:administrator';
define( DATABASE_DEVELOPER', 55 );
define( 'APP_DEVELOPER', 55 );
In this case, a search for anything assigned to APP_DEVELOPERs would return hits for tasks assigned to DATABASE_DEVELOPERs. The only way to separate those out is to have different values. Sure, we can easily add 1 to the values, but then we need to be careful about thresholds. Example:
define( 'DATABASE_DEVELOPER', 55 );
define( 'APP_DEVELOPER', 56 );
$g_notify_flags['new'] = array(
'threshold_min' => APP_DEVELOPER,
'threshold_max' => DATABASE_DEVELOPER,
);
In that scenario, the person modifying this threshold needs to know the value of the constants to ensure all developers are getting notifications ... that kinda defeats the purpose of a constant. That case leads to consideration of extra constants to ensure a "min/max range of developer types for a threshold":
define( 'MIN_DEVELOPER', 55 );
define( 'DATABASE_DEVELOPER', 56 );
define( 'APP_DEVELOPER', 57 );
define( 'MAX_DEVELOPER', 59 );
$g_notify_flags['new'] = array(
'threshold_min' => MIN_DEVELOPER,
'threshold_max' => MAX_DEVELOPER,
);
Is it better to structure like in that last example?

Unless someone can propose a better practice, I might go with that last model. An advantage is that it immediately allows for more refined reporting. A disadvantage (with this specific example) is that anyone who is searching or filtering needs to understand how that works, no longer just searching for "Developer" but App Developer OR Database Developer. It also leaves the UI with these generic "Min/Max Developer" fields which I wouldn't want people to use - and would probably need to remove them with a plugin.

This doesn't just apply to roles or projections. I have to-do items to make changes to other options as well, so I'd like to understand this in a general context.

Thanks.
Starbuck
Posts: 219
Joined: 14 Feb 2006, 02:53
Location: USA
Contact:

Re: Enumerations/constants, same functional value?

Post by Starbuck »

Bump? :oops:
If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!
Starbuck
Posts: 219
Joined: 14 Feb 2006, 02:53
Location: USA
Contact:

Re: Enumerations/constants, same functional value?

Post by Starbuck »

Um, this was a silly question. Please disregard.
If a value like "20" is stored in the database then on rendering it's probably going to result in listbox displaying the first entry with that value. So if I have something like 20:change,20,fix then in the UI it can only pull up one of those, and it will probably be the first one ...so anything logged by a reporter as a fix will still display as a change.

OK, I needed to go through the process, do some tests, and figure out for myself that this wasn't a great idea.

The MIN_DEVELOPER and MAX_DEVELOPER concept is still valid and I might pursue that later. But from my perspective this thread is closed.
If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!
Post Reply