New Bug Tracking System Installed (Defunct)

[Xaser]

Tested and reported in tracker-land.

I'm way less grumbly about how it's behaving after some time to stew on it, so things ought to be all right. I'm saying this as the one of us who isn't in charge of maintaining it, though, so I'm maybe a bit spoiled. D:

[Rachael]

No, I get your frustration. I am frustrated too because I never knew that the bug tracker was this restrictive.

[Leonard2]

I agree that not being able to comment on closed issues sounds terrible.

I could always use help researching these issues and knowing what values to change, if they are available. It's a pretty big document so it's a lot to review.

I think what you're looking for is here.
From there it seems you have a lot of options to solve this:

• Reopen an issue - The access levels required for a user to be able to re-open a resolved or closed issue.
• Status where an issue becomes readonly - Issues with such status and above are considered read-only. Read-only issues can only be modified by users with a configured access level. Read-only applies to the issue header information as well as other issue related information like relationships, attachments, notes, etc.
• Update readonly issues - The access levels required for a user to be able to modify a readonly issue.

And I didn't read it all.

This case is particularly problematic because the close reason was "code it yourself" and I was literally trying to be helpful and post the code. x:

I don't think issues should be completely closed just because the current devs are not interested.
I mean I read Eruanna say somewhere that any contribution is encouraged but that sounds like the opposite.
I think such issues need to remain opened and maybe even marked with a "needs to be assigned" status.
That would send a different kind of message. Just my thoughts..

[Graf Zahl]

This case is particularly problematic because the close reason was "code it yourself" and I was literally trying to be helpful and post the code. x:

I don't think issues should be completely closed just because the current devs are not interested.

Here's the problem: There's only one status level below 'resolved' and that's 'closed'. So in order to get rid of the visual distraction, setting it to 'closed' is the only option. There really needs to be one other level, like 'on hold' or something below 'resolved' and above 'closed', so that it can be filtered out from the view without filtering out 'resolved', otherwise we can forget about the whole thing.

[Leonard2]

That's also possible.
That was also why I was suggesting a "needs to be assigned" status.

[drfrag]

I can't register, clicking on the link sent to my email account gives an application error #200 (can't find a hash resource).

[Rachael]

I agree that not being able to comment on closed issues sounds terrible.

I could always use help researching these issues and knowing what values to change, if they are available. It's a pretty big document so it's a lot to review.

I think what you're looking for is here.
From there it seems you have a lot of options to solve this:

• Reopen an issue - The access levels required for a user to be able to re-open a resolved or closed issue.
• Status where an issue becomes readonly - Issues with such status and above are considered read-only. Read-only issues can only be modified by users with a configured access level. Read-only applies to the issue header information as well as other issue related information like relationships, attachments, notes, etc.
• Update readonly issues - The access levels required for a user to be able to modify a readonly issue.

And I didn't read it all.

I tried "Status where an issue becomes readonly" but it only has "closed" as an option, nothing beyond that.
However, I was able to change "Update readonly issues" - maybe that might be enough.

This case is particularly problematic because the close reason was "code it yourself" and I was literally trying to be helpful and post the code. x:

I don't think issues should be completely closed just because the current devs are not interested.
I mean I read Eruanna say somewhere that any contribution is encouraged but that sounds like the opposite.
I think such issues need to remain opened and maybe even marked with a "needs to be assigned" status.
That would send a different kind of message. Just my thoughts..

I really don't know what to say here. There's nothing that sounds absolutely ideal.

I can't register, clicking on the link sent to my email account gives an application error #200 (can't find a hash resource).

Can you post a screenshot?

[Xaser]

@Leonard2: I misspoke a bit. The "code it yourself" response in that case was a "code it yourself in ZScript, as all the features are exposed." Guess I need to say "script it yourself" to disambiguate now.

There really needs to be one other level, like 'on hold' or something below 'resolved' and above 'closed', so that it can be filtered out from the view without filtering out 'resolved', otherwise we can forget about the whole thing.

I'm quite fond of this idea, if it's possible.

[BFeely]

Just as a heads-up I noticed you added the mantis.zdoom.org domain you your Letsencrypt certificate.
As a suggestion, while you were at it, you should have considered adding http://www.zdoom.org to the list so those who habitually add www to every domain do not get a certificate error.

Edit: Added Issue 53

[Rachael]

I hate to sound like a broken record, but please submit that on the tracker.

[Rachael]

If you are getting Error #200 in activating your account - take your email, HTML codes and all, paste it into an HTML file, and then run the HTML file in your browser and activate it from that page, instead. That is, until I can figure out what's causing it to send raw HTML.

[Torr Samaho]

That was dropped. After spending 2 months waiting in limbo and not getting updates or communications from their webhosts I cut ties with them.

I think I need to comment on this, since this sounds as if this was solely the fault of our webhosts. As far as I understood the situation, there was some misunderstanding that caused both sides to wait, just for different things.

I still very much would like to work with Torr and his team with other issues and projects - and the lines of communication remain open as far as I am aware.

Absolutely!

Here's the problem: There's only one status level below 'resolved' and that's 'closed'. So in order to get rid of the visual distraction, setting it to 'closed' is the only option. There really needs to be one other level, like 'on hold' or something below 'resolved' and above 'closed', so that it can be filtered out from the view without filtering out 'resolved', otherwise we can forget about the whole thing.

We added custom status levels to our tracker, so Mantis definitely allows this. AFAIK Blzut3 added them for us, so he should know how this can be done.

[Rachael]

It does seem like it can be done, but it is more complicated than adding one line to the config file. What's stopped me so far is knowing what workflow transitions I should use for each status - as well as knowing what internal name to define each one as.

[Blzut3]

To my recollection, I didn't bother with workflows on the Zandronum tracker. I just added the statuses that we needed which is something like one line in each of the three custom configuration files.

For reference this is what our config_inc looks like:

Code: Select all

<?php
        $g_hostname = 'localhost:5432';
        $g_db_type = 'pgsql';
        $g_database_name = 'redacted';
        $g_db_username = 'redacted';
        $g_db_password = 'redacted';

        $g_allow_anonymous_login = true;
        $g_anonymous_account = 'Anonymous';
        $g_favicon_image = '../favicon.ico';

        $g_top_include_page = 'redacted';
        $g_bottom_include_page = 'redacted';
        $g_css_include_file = '../res/tracker.dcss';

        $g_return_path_email = $g_from_email = 'noreply@zandronum.com';
        $g_administrator_email = $g_webmaster_email = 'webmaster@zandronum.com';
        $g_phpMailer_method = 2;
        $g_smtp_host = 'redacted';
        $g_smtp_username = 'redacted';
        $g_smtp_password = 'redacted';
        $g_smtp_connection_mode = 'ssl';
        $g_from_name = 'Zandronum Bug Tracker';

		$g_status_colors = array(
                'new' => '#600000',
                'feedback' => '#300060',
                'acknowledged' => '#603000',
                'confirmed' => '#606000',
                'assigned' => '#003060',
                'resolved' => '#006000',
                'needs review' => '#006976',
                'needs testing' => '#007C52',
                'closed' => '#404040'
        );
        $g_status_enum_string = '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:needs review,70:needs testing,80:resolved,90:closed';

        $g_resolution_enum_string = '10:open,15:waiting for zdoom,16:backport later,20:fixed,30:reopened,40:unable to reproduce,50:not fixable,60:duplicate,70:no change required,80:suspended,90:won\'t fix,91:denied,92:out of scope,93:invalid';
        $g_severity_enum_string = '10:feature,20:trivial,30:text,40:tweak,50:minor,60:major,70:crash,80:block,85:exploit';
        //$g_update_bug_threshold = 20;
        $g_default_avatar = 'identicon';
        $g_show_avatar = true;
        $g_show_avatar_threshold = 20;
        $g_allow_browser_cache = true;
        $g_roadmap_update_threshold = 40;

        $g_update_bug_assign_threshold = UPDATER;
        $g_tag_view_threshold = NOBODY;
        $g_tag_attach_threshold = NOBODY;
?>

Edit: Removed some file paths just in case even though I don't think anyone could do anything with that knowledge.

[Rachael]

Thank you, Blzut.