Mantis BugTracker - Technical & Administrative Issues

[size=92]I believe Tow took care of that by simply renaming SVN to 0.75 (was the main release anyway). And now we have the that can always be used until the next rename (then recreated, a.s.o.). :wink: [/size]

Now, I’d like to propose the devs another convention, regarding closing reports on Mantis:

  1. Immediately closing for two categories (EDIT: I mean ‘categories’ in a generic way, not those in the “Category” column on Mantis):
  • NON-ISSUES: when investigation proves the behavior is identical with H3 (unless H3 was buggy on that item to start with), or if there is a difference, it’s a known VCMI enhancement actually; also reports simply created by mistake go here (an admin can delete those afterwards, if the case)
  • DUPES: but only when it’s an obvious dupe (to avoid closing a report which contains useful extra information)
  1. RESOLVED items are the third and last category which needs closing, but my proposal is that the dev applying the fix in SVN only marks it as Resolved, without closing, which should be done only after the next public release, if the fix is confirmed.

I came to the conclusion this approach may (probably) be best, after an exercise I did today: I went through more than half of all reports marked as Resolved, to see which of them can be indeed closed. And it proved useful from 4 points of view:
a) ~45 Resolved reports closed (cleaning a bit the queue, with the certainty that they’ve been properly fixed, as I did IMO all the necessary to reproduce them)
b) ~5 New/Assigned reports moved to Fixed and Closed: while testing the Resolved ones, I also checked their relationships, and it turned out some of those were fixed as well
c) ~5 Resolved reports left open, some moved to feedback, because 1 was not fixed at all, 3 partially fixed and 1 still has a related issue pending (not reported elsewhere) - IIRC
d) Last but not least, while trying to reproduce all these bugs, I ran into about 10 other bugs, which I wouldn’t have discovered otherwise through regular testing (at least most of them).

So if nobody minds, I’m gonna continue this approach, as it proved (for me at least) one of the most efficient testing exercises since I joined the project. But feel free to share if you prefer another approach. :wink:

Best regards,

issue 309 page is broken

look at


In which way? For me the page loads without a problem.

If we have such categories, we will loose information about the category assigned by reporter (town screen / battle etc.). What’s wrong with using status / resolution fields? We can set status to closed and resolution to duplicate / won’t fix (or add new resolution if possible - non-issue).

Works for me too.

Oh sorry, it seems the way I put it was a bit confusing. I definitely didn’t mean that we create new categories. All current settings/statuses/categories/etc are very good as they are, and nothing needs changing. Perhaps not even possible, as they may be standard on Mantis. I was just referring to dev/admin actions. Perhaps I should have better used the word “types”, or specify I’m not referring to Mantis categories, but using the term in a more generic way. :stuck_out_tongue:

My main concern was when do we close the Resolved reports. I felt that closing upon fixing is too soon (for me “closed” reports are those we shouldn’t worry about anymore, which was not the case for 10% of our resolved reports, from what I’ve seen yesterday). So far I’ve already applied the “immediate closing” policy for dupes, plus we had a few cases of non-issues (#75,198,212); and yesterday I closed about 50 Resolved reports, but only after verifying in 0.75 that they are fully fixed.

Basically I just wanted to know if the others are okay with the above approach, which is pretty much already applied. Perhaps as a sort of guarantee we won’t have the case one day that a partially fixed bug is overlooked (because the related report was closed before checking that everything works fine in the next release).

[size=84]PS: I can see why my proposal, from the perspective of changing all categories, and moving reports from one category to another in order to have them closed, sounded like a terrible headache, with no added value.[/size] :laughing:

in which way?
clicking on issue 309 gives me everytime blank page,
while the rest per-issue pages work as they should in 99% of time

so I’m sure it’s not problem with my conection (or at least not only that)
but some specific for 309

I think I figured out why. There was one note from me on that report, which I marked as “private”, because it was outdated (after I figured the cause of the crash, it wasn’t relevant anymore).

The reason why TowDragon could still see the report, is most probably because he’s an admin as well. That doesn’t mean it’s a correct behavior (IMO). The purpose of marking one attached note as “private” is of course not to hide the whole report from the others. I’ve made the note “public” again, so you should be able to see #309 now. Let me know if otherwise.

Meanwhile I’ll check if this bug is known to the Mantis devs or else report it.

EDIT: Yes, it’s a bug spotted by others as well in Mantis 1.2.0rc1 (which we are using). It has been fixed for RC2, but I don’t know if/when we’ll make that update as well. Making notes private in our project does not seem of much use though, so I guess an update just for this is not really needed for now.

We’re starting to get spam on Mantis. We had two such posts today on #174 and I think there was another case about a week ago (I saw a note from ‘anonymous’ deleted on another report by one of the devs some time ago - I guess it was the same case).

If this continues, we may have to restrict the access for anonymous users (perhaps give it ‘viewer’ profile, with possibility to only create reports, but not to add notes?).

I think it would be best if we could add some kind of authentication for anonymous users. I’ll discuss such possibility with Tow.

Now that became quite a problem.

I noticed. We’ve got about 10 spam notes in 24h.

I removed the right to add notes for anonymous users. They can still create reports though (I guessed that a bot can easily add a note, but less likely to fill in all the necessary fields for a new report). If I’m not mistaken, we didn’t have anonymous reporters anyway, just members of this forum forgetting to login when creating a report.

It’s a temporary solution to stop the spamming, until TowDragon & Tow take a decision upon it.

EDIT: There is a small “bug” (?) with this set-up though, namely that guests have to follow an external link to the “Report Issue” page. I’m not yet decided if that’s a good or a bad thing. On one hand it increases the chance that we get only genuine reporters, if they have to follow the links from our homepage (or the forum page); on the other hand, if one of these reporters prefers to stay anonymous and puts the Mantis View Issues page in their favorites, they won’t have the Report Issue link on top to use it. Actually, from what I’ve noticed, the “Report Issue” link may appear appear on top of their page if they recently used the external link (so they can create a couple of bugs in a row, w/o the need of going through our website), but it disappears after a while. Because of that behavior I’m not sure if it’s a bug, or implemented as a feature (against bots who “know” how to create reports).

Meanwhile I also found out that captcha codes for Mantis guest users have been already requested about 3 years ago (and acknowledged by the devs as useful), but they haven’t been implemented to this day in the application. There are however some .php files attached to report #7741. Perhaps Tow or TowDragon can see if they represent a solution.

I’ll try adding “project name” captcha (as well as upgrading script to latest version) when moving tracker to the new server. (Should be done within a month or sth, more info later)

So far it’s fine. Since I removed the access to add notes for anonymous users, we didn’t get any spam. They can still create reports, and for notes they could use the forum for the time being. Of course, ideally would be to allow them to also add notes, so if the scripts (or how are they called) from report #7741 will help (or sth similar), great. :slight_smile:

Btw, I also added the right for reporters to edit their own notes upon request from phomm. I’m not sure if we never had that, or we actually did, but you removed it for some practical reason. :question:

On a separate note:

I wanted to add two more columns in my “View Issues” page: Product Version and Fixed in Version, but due to a known bug from 1.2.0rc1, they are not displayed correctly. I see a fix is mentioned HERE. Tow/TowDragon - when you have time - can you figure out how to apply that to our bugtracker?

EDIT: I just found a related report, which says it’s fixed in 1.2.0rc2. So I guess when we make the upgrade it’ll be fine. Perhaps not before the next dev. release, but if you have some time before 0.8, maybe we can upgrade Mantis to 1.2.0rc2. What do you think?

Mantis has been finally upgraded to 1.2.0 stable release. Hopefully it will fix several issues discussed here. Sorry for the delay.

I’ve also added SVN integration plugin.
It seems to have made a little to much associations (some old bugs numbers messed with recent ones) but may be a useful addition for future :slight_smile:

Giving it second thought, it seems be making too much mess. I’ll remove it.

At the moment there are 128 bugs marked as resolved, which looks pretty messy. Some months ago Zamolxis used to deal with them, but I see he’s busy. How many testers have rights to close resolved issues?

You know, you can change the Hide Status filter to Resolved and it will look as if all the resolved ones are closed. :wink: :stuck_out_tongue:

But I’ll try to make some time soon and do some clean-out in Mantis. Last month I was either on holiday or very busy at work to complete things before the holiday. July will be more relaxed so I should have more time for VCMI.

I think that is should be possible to add notes even if issue is closed.
cause not every time it is needed to create new report, just should be possible to write that old issue should be opened i.e. #443 and #522
Second if you just want to add any note refers to exact issue i.e. #499. What does it mean “Fixed in Version: 0.81”? It isn’t fixed in 0,81. Maybe it will be in next release.

I believe you’re right about #499. I corrected it.

As for #443, you should have a “Reopen” button available if you are the reporter. Let me know if you don’t - it may be a conflict between 2 Mantis configuration settings. If yes, I think I might have a solution, but first pls check if you don’t have a “Reopen” below the Attached Files area.

Yes, you are right I have it. So can I use it if I think the issue is not fixed but it is marked as fixed?

Depends what you mean by “think”. I’d say use it if you have good reasons to believe it’s the same bug (e.g.: if it follows the same reproducibility pattern and leads to the same/similar results, or is only half-way fixed).