MantisBT

[TM123]

Is it possible that uploading files as private answer does not work?

I added files, checked private, wrote a text and I got an error message when I tried to send.

[Kyle_Katarn]

No clue. I'll check

[scheff]

I've another issue resp. observation with MantisBT. Where do I find the documentation of the KC Softwares workflow defined and configured for its usage of MantisBT?
I couldn't find it. And I would expect it either in the overview section and/or in a separate section like help, tutorial or introduction.

[scheff]

I've another issue resp. observation with MantisBT. Its not only the documentation of the chosen workflow definition and configuration missing. It's also documentation of some other kind of configuration options.
It looks like there is a too aggresive configuration for suspected abuse. The wording of the attached MantisBT error message doesn't make sense neither. What's the relation between MantisBT and spam which has to do with inadvert emails?
I can't see any relation at all. As far as there is any relation between Mantis BT and email, this is configured by its user in the user control panel and hence cannot be considered inadvert. I didn't try if anonymous users can provoke any email. They should only have read access.
And why is such an undocumended configuration on activity related to events instead of activity?

I tried to create a new issue. That's one action. Why should this be considered excessive?
And how should I fix this single activity to get acceptable by this MantisBT configuration if this configuration is not accessible even not to registered active users?

I consider workflow configuration documentation relevant to all users, including unregistered anonymous ones.
If you don't want to provide access to further configuration aspects, it may be meaningful to limit access to registered users, not just administrators.

The single action chose was new issue creation in the mode of starting not with an empty entry but with cloning an existing one with already existing notes relevant also to the new issue.

[scheff]

BTW, the screenshot also showed the related issue.

Further observation revealed that MantisBT didn't seem preventing the action although claiming to do so but instead performed the single action never the less at least partially. So I even didn't see if the whole action was performed or only parts.

[Kyle_Katarn]

I've another issue resp. observation with MantisBT. Where do I find the documentation of the KC Softwares workflow defined and configured for its usage of MantisBT?
I couldn't find it. And I would expect it either in the overview section and/or in a separate section like help, tutorial or introduction.

there's no "formal" documentation of our workflow. Mantis documentation is available and i'm available for support if needed. No specific process applied here.
So far, I don't feel a need to go further on this and prefer to concentrate on the product developement and support to users.

Bug thanks for using our bug tracker and reporting "glitches" you've found !

[Kyle_Katarn]

I've another issue resp. observation with MantisBT. Its not only the documentation of the chosen workflow definition and configuration missing. It's also documentation of some other kind of configuration options.
It looks like there is a too aggresive configuration for suspected abuse. The wording of the attached MantisBT error message doesn't make sense neither. What's the relation between MantisBT and spam which has to do with inadvert emails?
I can't see any relation at all. As far as there is any relation between Mantis BT and email, this is configured by its user in the user control panel and hence cannot be considered inadvert. I didn't try if anonymous users can provoke any email. They should only have read access.
And why is such an undocumended configuration on activity related to events instead of activity?

I tried to create a new issue. That's one action. Why should this be considered excessive?
And how should I fix this single activity to get acceptable by this MantisBT configuration if this configuration is not accessible even not to registered active users?

I consider workflow configuration documentation relevant to all users, including unregistered anonymous ones.
If you don't want to provide access to further configuration aspects, it may be meaningful to limit access to registered users, not just administrators.

The single action chose was new issue creation in the mode of starting not with an empty entry but with cloning an existing one with already existing notes relevant also to the new issue.

Looks like specific MantisBT design. I'll report to their developpers if problem gets systematic.