View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
27008 [mantisbt] other major always 2020-06-05 09:04 2020-06-05 17:34
Reporter: k.pradeep Platform:  
Assigned To: atrol OS:  
Priority: urgent OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Separate ID for each project and should start with 1
Description:

Is there a possibility to create Bug IDs to start with [ABC 0000001] instead of an incremental for different projects under same branch or Stream
(ie. Software branch has proj1, proj2 , proj3, .... every project's bug id should start with 1)
Let us know if there is any Customization available on this above feed.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064064)
atrol   
2020-06-05 17:34   

Not possible, see 0007739 and other duplicate / related issues.

Mighte help a bit, you could change the diplsay of the ID by writing a plugin that uses event EVENT_DISPLAY_BUG_ID, see https://mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.eventref.output.display



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25492 [mantisbt] printing feature always 2019-02-19 15:19 2020-06-04 10:03
Reporter: ChrisG Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Printing (print_all_bug_page) is a perf/security risk
Description:

Live profiling of our server showed that 20,182 queries may be executed by the trivially achieved operation of printing out from "view all issues" when there's no filter. This was an intensive 40 second web request.

There needs to be some kind of control of this. I'd suggest implementing a maximum printable issues feature, that is controlled by access level. If set to zero for an access level then there would be no print button at all. The default config would set it 0 for guests to stop spiders hitting it.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0061522)
ChrisG   
2019-02-19 15:21   

This is related to 0004798.

(0064063)
c_schmitz   
2020-06-04 10:03   

I second this is an issue. This alllows for a simple DDOS attack on Mantis instances that have a big number of bugs.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
27004 [mantisbt] administration feature always 2020-06-03 11:37 2020-06-04 09:20
Reporter: maturbet Platform: GEODE 2.24.1  
Assigned To: OS: debian  
Priority: normal OS Version: 10.4  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Switch back from manage_user_edit_page to view_user_page
Description:

Hello,

In the same way that view_user_page.php allows to go to manage_user_edit_page.php (for admin users), it would be interesting to be able to return to view_user_page.php from manage_user_edit_page.php.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0064062)
maturbet   
2020-06-04 09:20   

PR : https://github.com/mantisbt/mantisbt/pull/1679



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
27005 [mantisbt] time tracking feature always 2020-06-03 18:07 2020-06-03 18:09
Reporter: abc874 Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: User list in time tracking summary is not sorted
Description:

Using 'Get Time Tracking Information' button in every issue users appearing in 'random' order.

Alphabetical list is easier to use.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064061)
abc874   
2020-06-03 18:09   

Pull request #1674



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26919 [mantisbt] code cleanup minor have not tried 2020-04-26 00:03 2020-06-03 05:18
Reporter: vboctor Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Upgrade guzzlehttp/guzzle from 6.5.2 to 6.5.4
Description:

Pickup new release.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064059)
dregad   
2020-06-03 05:14   

New release 6.5.4 is out.

(0064060)
dregad   
2020-06-03 05:15   

PRs:



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
27003 [mantisbt] security minor N/A 2020-06-03 04:33 2020-06-03 04:57
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.24.2  
    Target Version: 2.24.2  
Summary: Update PHPMailer from 6.1.4 to 6.1.6
Description:

PHPMailer 6.1.6 fixes a vulnerability : Insufficient output escaping of attachment names (CVE-2020-13625), see the advisory for details.

PR: https://github.com/mantisbt/mantisbt/pull/1676

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26784 [mantisbt] email minor N/A 2020-03-16 03:15 2020-06-03 04:39
Reporter: vboctor Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Update PHPMailer from 6.1.4 to 6.1.5
Description:

Here is the PR:
https://github.com/mantisbt/mantisbt/pull/1631

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064058)
dregad   
2020-06-03 04:39   

Removing target version to avoid confusing information in Changelog, as this has been superseded by 0027003



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26966 [mantisbt] ui minor always 2020-05-18 06:12 2020-06-02 16:59
Reporter: Wma Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.23.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A user with the user right "Viewer" see not the public entries.
Description:

A user with the user right "Viewer" does not see all public entries.

I have created a user with the user right "VIEWER". Then I added this user to a public project as "VIEWER".
If I log in with this user, I do not see any entries.

All entries in this project are public.

The user himself cannot create any entries (that's OK and that's the intention).

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063998)
atrol   
2020-05-18 16:03   

Wma,

I was not able to reproduce your problem with a fresh install of the latest stable MantisBT release (2.24.1at the moment).
I recommend that you upgrade to the latest (download from [1]). If after doing so the problem persists, please provide detailed step-by-step instructions to reproduce the issue; the following additional information may also be useful:

  • Exact version of MantisBT, PHP, Database, Web server, Browser and Operating System
  • Relevant customizations (e.g. changes in config_inc.php, etc)
  • Installed plugins or custom functions ?
  • Was the MantisBT source code modified in any way ?

[1] http://mantisbt.org/download.php

(0064057)
atrol   
2020-06-02 16:59   

Wma,

You did not provide any feedback; I am therefore resolving this issue as "no change required".

Feel free to reopen the issue at a later time and provide the requested information.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26971 [mantisbt] webpage major always 2020-05-20 09:21 2020-06-02 16:58
Reporter: kanni1303 Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Login Page Broken
Description:

No info other than logo in the login page

The error log shown as below
[20-May-2020 13:11:38 UTC] PHP Fatal error: require_once(): Failed opening required 'admin/schema.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/asaimani/public_html/mantis/login_page.php on line 182
[20-May-2020 13:12:59 UTC] PHP Fatal error: require_once(): Failed opening required 'admin/schema.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/asaimani/public_html/mantis/login_page.php on line 182

In Admin folder
[20-May-2020 13:11:05 UTC] PHP Fatal error: require_once(): Failed opening required 'schema.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/asaimani/public_html/mantis/admin/index.php on line 27

Tags:
Steps To Reproduce:

open login_page.php

Additional Information:

Home itself broken unable to proceed with anymore

Attached Files: image.png (31,889 bytes) 2020-05-21 07:30
https://mantisbt.org/bugs/file_download.php?file_id=9103&type=bug
Notes
(0064009)
dregad   
2020-05-20 09:35   

This is most likely caused by your system's configuration or the way you installed Mantis.

(0064010)
kanni1303   
2020-05-20 10:08   

what is the resolution? I am not able to do anything.

(0064011)
kanni1303   
2020-05-20 10:27   

Even after adding the schema.php manually getting this error

[20-May-2020 14:23:30 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/login_cookie_test.php: 33: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

[20-May-2020 14:23:30 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/javascript_config.php: 30: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

[20-May-2020 14:23:35 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/my_view_page.php: 41: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

[20-May-2020 14:23:36 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/javascript_config.php: 30: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

[20-May-2020 14:23:52 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/view_all_bug_page.php: 39: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

[20-May-2020 14:23:53 UTC] Call to undefined function json_decode()
/home/asaimani/public_html/mantis/core.php: 319: - - - - collapse_cache_token()
/home/asaimani/public_html/mantis/javascript_config.php: 30: - - - - require_once( <string>'/home/asaimani/public_html/mantis/core.php' )

(0064012)
atrol   
2020-05-21 06:34   
(Last edited: 2020-05-21 06:35)

@kanni1303 does it work after enabling / installing PHP json extension ?

(0064013)
kanni1303   
2020-05-21 07:30   

Thank you, after enabling JSON it is working. But unable to open any bug.

showing following error whenever opening any bug.

(0064015)
atrol   
2020-05-21 07:49   
(Last edited: 2020-05-21 07:49)

Do you use an old Mantis database that contains old bug reports ?

If yes, did you upgrade by following the steps described in Admin Guide ? https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.install.upgrade
Especially, did you run the upgrade script ? http://yoursite/mantisbt-NEW/admin/install.php

(0064056)
atrol   
2020-06-02 16:58   

kanni1303,

You did not provide feedback; I am therefore resolving this issue as "no change required".

Feel free to reopen the issue at a later time and provide the requested information.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
27001 [mantisbt] General minor have not tried 2020-06-02 11:19 2020-06-02 14:24
Reporter: chawki Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Rename roles
Description:

Helle Team,

je veux changer le noms des roles des utilisateurs
Administration --> Administration
dev --> exp : consultant
viewer --> client

Pouvez-vous me dire comment

Merci d'avance

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064054)
chawki   
2020-06-02 11:19   

Helle Team,

je veux changer le noms des roles des utilisateurs
Administration --> Administration
dev --> exp : consultant
viewer --> client

Pouvez-vous me dire comment

Merci d'avance

(0064055)
atrol   
2020-06-02 14:24   

chawki,

This is not a bug or feature request for MantisBT (you are asking for help on how to configure the system). I am therefore resolving this issue as "no change required".

Please use the forums to get support on customizing and using MantisBT (refer to http://www.mantisbt.org/support.php for links and further details).

Start reading the documentation, especially
https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.customize.enums



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22408 [mantisbt] custom fields minor always 2017-02-22 06:38 2020-06-02 06:57
Reporter: jensberke Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Custom field's value logged as changed in history, when it wasn't changed
Description:

If a custom field of type "multiselection list" in an issue already has a value and you change another value in the ticket, the custom field's value also gets logged in the issue history though it hasn't changed.

Tags:
Steps To Reproduce:
  1. Assume a custom field of type "multiseletion list" with "possible values" set to "not relevant|relevant", and that this field is assigned to a project.
  2. Create an issue and set this custom field to "not relevant".
  3. Change the issue by editing any other field value but leave the custom field unchanged.
  4. Though the custom field hasn't changed, the issue history shows an entry for it with the custom field's name in column "field" and the value as "not relevant => not relevant" in column "change"
Additional Information:
Attached Files:
Notes
(0055738)
jensberke   
2017-02-22 07:35   

I just checked Mantis 2.1.0 and it happens there as well.

(0055741)
atrol   
2017-02-22 08:14   
(Last edited: 2017-02-22 08:14)

I just checked Mantis 2.1.0 and it happens there as well.

Right.
The same applies to check box fields

The problem is caused by the function that get executed when storing/restoring the values to/from database
'#function_value_to_database' => 'cfdef_prepare_list_value_to_database', '#function_database_to_value' => 'cfdef_prepare_list_database_to_value',

No time to have a deeper look at the moment.

(0055742)
dregad   
2017-02-22 10:50   

The root cause is that bug_update.php does not compare old vs new value when building the list of custom fields to update [1].

The problem can be fixed there or in custom field API [2], by adding a comparison between old and new values; the latter is less efficient (we can avoid calling custom_field_set_value() completely, since we already know the values), but would ensure consistent behavior from SOAP API, so maybe we should do both.

[1] https://github.com/mantisbt/mantisbt/blob/release-2.1.0/bug_update.php#L307-L308
[2] https://github.com/mantisbt/mantisbt/blob/release-2.1.0/core/custom_field_api.php#L1308

(0055743)
dregad   
2017-02-22 11:05   

PR https://github.com/mantisbt/mantisbt/pull/1035

(0055744)
atrol   
2017-02-22 11:21   
(Last edited: 2017-02-22 11:49)

@dregad, not sure if you are aware that it works for other custom field types because there is a comparison of old and new value in function history_log_event_direct [1]

The comparison fails in this case as we store the values by adding | at the begin and the end)

function cfdef_prepare_list_value_to_database( $p_value ) {
    if( '' == $p_value ) {
        return '';
    } else {
        return '|' . $p_value . '|';
    }
}

but compare after removing the |

function cfdef_prepare_list_database_to_value( $p_value ) {
    return rtrim( ltrim( $p_value, '|' ), '|' );
}

[1] https://github.com/mantisbt/mantisbt/blob/release-2.1.0/core/history_api.php#L78

EDIT (dregad) use Markdown `` instead of for proper formatting of the code

(0055746)
dregad   
2017-02-22 11:38   

@atrol I did not realize that, thanks for pointing me to it. I'll have a look at the logic there.

That being said, I think it makes sense to merge the proposed change anyway, as there is no point in executing an UPDATE query when it's not needed.

(0055747)
dregad   
2017-02-22 11:43   

I think the logic in the call to history_log_event_direct() in custom_field_set_value() is wrong.

  1. $t_value contains the new field value, in DB format
  2. old field value is converted to display value format

So history_log_event_direct() is effectively comparing apples with oranges.

(0055761)
dregad   
2017-02-23 05:48   

@atrol your feedback on 0022408:0055747 would be appreciated. Do you agree with my analysis ?

(0055763)
atrol   
2017-02-23 06:13   

I don't have time to have a deeper look and for tests.
So you think that call of history_log_event_direct has to be changed in function custom_field_set_value to

        history_log_event_direct( $p_bug_id, $t_name, $t_row[$t_value_field], $t_value );
(0055764)
dregad   
2017-02-23 06:18   

I didn't test either, but yes this is what I think

(0055776)
dregad   
2017-02-24 09:25   

@vboctor, what's your take on 0022408:0055747 ?

(0055785)
mantisiator   
2017-02-26 11:30   

Hi,
This fix is OK for me further to testing in version 2.0.0.
Thanks a lot !

(0055863)
MarcoW   
2017-03-02 06:55   

Hi,

i think the correct fix is in the function custom_field_set_value :

history_log_event_direct( $c_bug_id, $t_name, custom_field_database_to_value( $row['value'], $t_type ), $p_value );

So was this line in Mantis 1.2.10. So instead of $t_value it has to be $p_value, which is the new not formatted value.

(0056315)
vboctor   
2017-04-01 17:22   

@dregad seems reasonable since it seems to fix the issue :)

(0060948)
sandyj   
2018-11-12 20:01   

Hi! Any update on this issue? from the above history it looks like the PR is there but we're still seeing this issue so are there plans to roll it out?

(0060949)
atrol   
2018-11-13 02:12   

@sandyj there is a good reason that the PR is not merged, see my comment

(0062097)
jingshaochen   
2019-05-19 16:24   

In file custom_field_api.php, line 1352:

history_log_event_direct( $p_bug_id, $t_name, custom_field_database_to_value( $t_row[$t_value_field], $t_type ), $t_value );

can we call a db_affected_rows before it to see if a history is needed to be inserted?

(0062099)
jingshaochen   
2019-05-19 16:57   

created a pull request: https://github.com/mantisbt/mantisbt/pull/1514

(0063728)
chadmiss   
2020-03-03 05:16   

still happening in 2.23.0



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
23031 [mantisbt] auditing minor always 2017-06-19 05:51 2020-06-02 04:41
Reporter: aavagyan Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.3.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Issue History" not showing certain data
Description:

We have noticed that sometimes users receive email alerts that note was added to the ticket, but when looking on that ticket in Mantis UI they cannot find such a note. "Issue History" also not showing that note was added or deleted. Even with ADMIN account you are not seeing this in "Issue History".

While digging I discovered these details:

User A adds note. User B (monitoring the ticket) receives email alert that note was added to the ticket. Then User A deletes the note. User A can see in the "Issue History" that s/he added and then removed the note. User B goes to Mantis UI and cannot see the note and cannot see lines in "Issue History" about addition and deletion of note.

This is confusing experience. People feel that there is something happening in Mantis, which there are unable to see. The other strange thing is that even with ADMIN rights one cannot see these lines in "Issue History".

I then went to the code and found this in core/history_api.php:

                # bugnotes
                if( $t_user_id != $v_user_id ) {
                        # bypass if user originated note
                        if( ( $v_type == BUGNOTE_ADDED ) || ( $v_type == BUGNOTE_UPDATED ) || ( $v_type == BUGNOTE_DELETED ) ) {
                                if( !bugnote_exists( $v_old_value ) ) {
                                        continue;
                                }
...

Can this be changed so users see that note was added and removed? Otherwise "puzzle" of getting email alerts and then not seeing what was that will continue.

Thank you.

EDIT: dregad fix markdown

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0057096)
atrol   
2017-06-19 07:48   

The checking for bugnote existence has been added when implementing 0021878.
This is needed, as we need to get the privateflag information of the note later on.
I see no clean way to get what you want, at least as long as notes are deleted and not marked as deleted.

(0057099)
aavagyan   
2017-06-19 10:38   

I understand the complexity and that it is mostly caused by the fact that information on PUBLIC-PRIVATE is gone when bugnote is deleted. In this regards, can we at least show relevant lines in "Issue History" when user has rights to see PRIVATE notes? I understand this is not very clean, but at least power users (and admins) will be able to "solve" puzzle for lower-right users. Otherwise even with admin account there is no way to figure out what is going on.

(0058617)
PantsManUK   
2018-01-26 09:30   

@atrol: Yes, this is the issue we noticed as well (I'm "MLCrane" on the forum).

Would I be correct in assuming that this affects all bugnote actions in history when a bugnote has been deleted? Given there is no direct link in the history to the note in question (in 1.3.X, certainly), what harm could there be in (effectively) removing the "if( !bugnote_exists( $v_old_value ) ) {" test entirely? That reinstates the "missing" history lines for the users that should be able to see it, and as far as I can tell has no adverse side-effects.

(0058618)
atrol   
2018-01-26 10:16   

what harm could there

See 0023031:0057096
You could see history entries for deleted private notes even if you are not allowed to view private notes.
Probably for most of the users just a minor security issue.

(0058620)
PantsManUK   
2018-01-26 10:32   

@atrol many thanks. We've commented out the "continue"s for now and left the calls to bugnote_exists() intact, and for us that's a workable solution; our installation is behind our firewall, so we don't need to hide things overly. I'll keep thinking on a better solution; "extra pair of eyes" and all that.

(0064032)
polzin   
2020-05-28 12:13   

What about the solution suggested in 0023031:0057099: show relevant lines in "Issue History" when user has rights to see PRIVATE notes

This would be a helpful workaround.

(0064053)
maturbet   
2020-06-02 04:28   

We also are wating for it !



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26998 [mantisbt] plug-ins feature N/A 2020-06-01 10:43 2020-06-01 10:43
Reporter: c2pil Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Event on access level modifications
Description:

I would need to log every modifications on users access level on projets.
This is why an event on users access level modifications would be great so that a plugin could get it.
Unless I am mistaken, I don't see anything like that exists today.

Minimal information needed are users concerned by the access level modification and on which projects.
Additionnal information could be the old access level, the new one, who did the modifications and the date.

Thank you for your time.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26997 [mantisbt] plug-ins major always 2020-06-01 01:55 2020-06-01 04:10
Reporter: sundowatch Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.23.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New TelegramBot plugin
Description:

Hi,

I'm trying to use the https://www.mantisbt.org/bugs/view.php?id=24695 plugin. I've followed instructions and added to telegram's webhook. But my mantis doesn't send messages to the group.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064052)
atrol   
2020-06-01 04:10   

sundowatch,

This is not a bug or feature request for MantisBT (you are asking for help on how to run a 3rd party plugin). I am therefore resolving this issue as "no change required".

You could use the forums to get support (refer to http://www.mantisbt.org/support.php for links and further details).

This might be the issue you are encountering https://github.com/mantisbt-plugins/TelegramBot/issues/32



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26988 [mantisbt] preferences major always 2020-05-27 04:46 2020-05-29 18:08
Reporter: maturbet Platform: VM  
Assigned To: OS: debian  
Priority: normal OS Version: 10.3  
Status: confirmed Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: issue report TOO_MANY_REDIRECTS
Description:

There is a redirection loop at "issue report" when the default project rights have been removed for a viewer user.

Tags:

patch

Steps To Reproduce:
  1. Setup Mantis with just 3 private projects A, B and C
  2. Give "reporter" access on all 3 projects to a "viewer" user
  3. The user choose project B as default project in his preferences
  4. Remove access to the project B for the user
    4.1. User see "All Projects" as default project in his preferences
    4.2. Admin see B as default project in user preferences
  5. User click on "Report Issue"
    => redirection loop
Additional Information:
  1. User return to the previous page
  2. In his preferences, user click "Update Prefs" without changing annything
  3. User click on "Report Issue"
    => All is OK
System Description
Attached Files:
Notes
(0064033)
maturbet   
2020-05-28 12:19   

PR : https://github.com/mantisbt/mantisbt/pull/1677

(0064039)
dregad   
2020-05-29 05:03   

I tried on my dev box, but I'm not able to reproduce the problem.

After revoking REPORTER rights on project B (step 3), in my case the user preferences still show it as the default project (i.e. not All Projects), I guess because the user still has viewer rights to project B.

Trying to report an issue at that point, displays the Choose Project page (login_select_proj_page.php), where the only select-able project is A (other available projects are listed but grayed out).

Maybe I'm missing something ?

(0064040)
maturbet   
2020-05-29 05:21   

In our configuration, we have only private projects.
It seem to be OK with public ones.

(0064042)
dregad   
2020-05-29 08:11   

OK, I didn't consider private projects. So I setup a fresh install with 2 private projects, but still can't reproduce...

4.1. User see "All Projects" as default project in his preferences

Here I see that the default project is A, even though in the DB it is indeed still stored as B.

  1. User click on "Report Issue"

No error, issue gets created in project A, as expected.

(0064043)
maturbet   
2020-05-29 08:25   
(Last edited: 2020-05-29 11:36)

My bad ! I forget one (again) thing in the description.
Indeed, if there is only one project left, it becomes the default one and the bug doesn't happen.
Can you redo the test with a third project C ?

(0064051)
dregad   
2020-05-29 18:08   

OK now I can reproduce - updated the issue's description



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26996 [mantisbt] markdown feature always 2020-05-29 12:24 2020-05-29 12:24
Reporter: thE_iNviNciblE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Replacement of hashtag notice #0006856 to long HTML LINK TEXT of the topic
Description:

Replacement of #0006856 zu long TEXT and Link.

For example you want to link a topic in a notice you write down 0004444 (must exist). you build a link, but more suiteable would be to expand the 0004444 number to LINK "Replacement of hashtag # to long HTML LINK TEXT".

Tags:
Steps To Reproduce:

Write #0006856 in this textfield should replace #000111 with the thread id of a topic.

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26995 [mantisbt] email major always 2020-05-29 06:26 2020-05-29 10:19
Reporter: maturbet Platform: GEODE 2.24.1  
Assigned To: dregad OS: debian  
Priority: high OS Version: 10.4  
Status: resolved Product Version: 2.23.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "In-Reply-To" field malformation in the email header
Description:

After MantisBT upgrade to 2.41.1 (from 2.18) this field has changed :

Before :
In-Reply-To: <5db478f8f0f50bb69887094ebbb7a6d8@geode.asso-cocktail.fr>

After (furthermore in 2 lines) :
In-Reply-To: =?us-ascii?Q?<5db478f8f0f50bb69887094ebbb7a6d8@geode.asso-co?=
=?us-ascii?Q?cktail.fr>?=

Have I made something wrong ?

Tags:
Steps To Reproduce:
Additional Information:

This field is useful to display emails per conversation

System Description
Attached Files:
Notes
(0064041)
dregad   
2020-05-29 07:51   
(Last edited: 2020-05-29 07:52)

I would not qualify this as malformed - it is valid RFC2047 Q-encoding , which is folded (see RFC 822 section 3.1.1) to avoid header corruption when the lines are longer than 63 chars.

If your software is choking on that, then it means it is not standards-compliant.

The change in behavior was introduced in PHPMailer 6.1 (see https://github.com/PHPMailer/PHPMailer/pull/1840), MantisBT release 2.23.0.

(0064046)
maturbet   
2020-05-29 09:52   

Okay, I learned something today !

I'm not really surprised that Outlook isn't standards-compliant, but more about Zimbra and Thunderbird.
I might have something to do on my end...

(0064048)
dregad   
2020-05-29 10:14   

TBH, I'm not an expert, but PHPMailer's maintainer is so I'm pretty sure he fully validated that before merging the change.

BTW You have not explained what the actual problem is, on the mail client side.

(0064049)
maturbet   
2020-05-29 10:19   

Forgive me for not being explicit in the ticket.
The mails of the same ticket were grouped together in conversation in the mail client and are no longer grouped together since the upgrade we did.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26990 [mantisbt] filters major have not tried 2020-05-28 06:37 2020-05-29 08:40
Reporter: polzin Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Changing to a project should reset the projects default filter
Description:

This is one of the most annoying problems. I have with working with mantis with many projects.

What I done:

  • view_all_bug_page
  • Change project

What I expect:

  • Clean filter

What I see:

  • Mantis restores the filter I last used in that project. This could be a slow, complicated search. In a bad (but not untypical case) I have to wait 20 seconds until the page is visible and I can reset the filter.

By the way: I have searched if this is a dublicate, but without a more powerful search (like 0026447 :-)), I was overwhelmed.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064036)
dregad   
2020-05-29 03:50   

Mantis restores the filter I last used in that project

This is by design actually.

I understand your point, but in many use cases, returning to the previously used filter is the expected behavior. So I'm not convinced we should change this; at best this could be made configurable behavior.

Also, what exactly do you mean by "clean filter" be ? Equivalent of clicking the reset filter button ?

(0064044)
polzin   
2020-05-29 08:40   

@dregad, Thanks for commenting.

Yes, the equivalent of "reset filter".
A configuration would be already great for me. Do you know, where to change the behaviour?

In addition: Is there a way to get a feeling for what would be the better default funktionality? Do you have feedback from user users?

What would be a reasonable expectation? When I change a project, is it more likely that I
a) continue a work that I have previously done in that project or
b) is it more likely that I have a new topic why I go there.

From my feeling and working with mantis, everytime I go there, I would like to have a fresh context. In particular, if I chage a project.
If I want to persist the current context, I would you PermaLinks or Saved filters.

What's your experience? Or what would be an approach to find out?

From other software projects I know: It's easy to add options and leave the default behaviour as it is. But this renders into a nightmare of options, in particular some where the impact on the usability is not obivous. At least I hope that in this case the option has to be considered only on one place.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26992 [mantisbt] feature minor have not tried 2020-05-28 06:57 2020-05-29 03:55
Reporter: polzin Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mantis could be empowered with jQuery's select2 or a different select update
Description:

With large number of values, the classic "option/select" is not functional any longer.

We added select2 ( https://github.com/select2) to mantis and included some javascript:

function update_select2() {
        // leave manage_user_edit_page, because here the standard select has advantages
        if ( document.URL.indexOf(&quot;manage_user_edit_page.php&quot;) == -1 ) {
                jQuery(&quot;select&quot;).each(function() {
                    if (!this.disabled  && this.options.length > 12 ) {
                        jQuery(this).select2();
                    }
                })
        }
};

jQuery(document).ready(update_select2);

Perhaps this could have been integrated more beautifully in the code, but it works and gives beautiful results.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: grafik.png (5,413 bytes) 2020-05-28 07:07
https://mantisbt.org/bugs/file_download.php?file_id=9109&amp;type=bug
grafik-2.png (4,366 bytes) 2020-05-28 07:07
https://mantisbt.org/bugs/file_download.php?file_id=9110&amp;type=bug
grafik-3.png (5,279 bytes) 2020-05-28 07:07
https://mantisbt.org/bugs/file_download.php?file_id=9111&amp;type=bug
grafik-4.png (6,701 bytes) 2020-05-28 07:07
https://mantisbt.org/bugs/file_download.php?file_id=9112&amp;type=bug
Notes
(0064031)
polzin   
2020-05-28 07:07   

Works e.g. for versions, tags, usernames, ...

(0064037)
dregad   
2020-05-29 03:55   

Interesting idea.

That said, for me the main issue with standard SELECT is when the options list is very long (e.g. system with many thousands of users, see 0025666) as in this case it can even cause the browser to hang or crash. So if we were to use a widget like the one you're suggesting, it would need to be more tightly integrated than what just replacing existing selects, to be able to use remote datasets.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26994 [mantisbt] installation minor have not tried 2020-05-28 16:08 2020-05-29 03:35
Reporter: mcastrou Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: feedback Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problema en la vista Summary
Description:

Estimados:

Recientemente instale la versión 2.24 de Mantis y he realizado algunas prueba y cambios menores en el archivos config_ing.php

Versión de MantisBT 2.24.0
Versión de esquema 210
Versión de PHP 7.2.11
Controlador de base de datos mysqli
Versión de base de datos; Descripción 10.3.17, 10.3.17-MariaDB

Cuando quiero ejecutar lengüeta de Resumen (Summary) del menu principal me aparece este error, les ruego me puedan orientar en como solucionarlo.

INTERNAL APPLICATION ERROR

Utilice el botón «Atrás» de su navegador web para volver a la página anterior. Allí puede corregir los problemas que han sido identificados en esta notificación de error o seleccionar otra acción. También puede hacer click sobre una opción de la barra de menú para ir directamente a una nueva sección.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Error Internal.JPG (57,220 bytes) 2020-05-28 16:08
https://mantisbt.org/bugs/file_download.php?file_id=9113&amp;type=bug
Notes
(0064035)
dregad   
2020-05-29 03:35   

@mcastrou please post in English.

  1. Temporarily configure your system as follows:
    $g_show_detailed_errors = ON;

WARNING - SECURITY RISK: the 'show_detailed_errors' config can cause MantisBT to display sensitive information about your system. We recommend to restrict its activation to a Test environment, only for as long as necessary. If possible, do not turn it ON globally, instead limit it for specific user(s) using the Manage Configuration page.

  1. Reproduce the error

You should see a stack trace, indicating where the error was triggered.

  1. Check system log files for errors

INTERNAL APPLICATION ERROR is generally triggered by an unhandled exception. You may find additional information in the PHP error log.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26993 [mantisbt] security major have not tried 2020-05-28 15:50 2020-05-28 15:50
Reporter: polzin Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: bug_reminder_page inappropriately shows wrong view_status in some configurations
Description:

What I have done:

  • config_inc: $g_bug_reminder_threshold = REPORTER;
  • config_inc: $g_default_reminder_view_status = VS_PRIVATE;
  • User with Access "Reporter"
  • bug_reminder_page.php

What expected:

  • No view_status printed

What seen:

  • Visibility: internal
  1. This is inappropriate, because user does not have the right so set or see view status
  2. The information is even wrong, because as the user does not hav ethe right to set the view status, the final view status is "public", not "private"

This is not really a security risc, but a confusion about security, but only, if reports may send reminders.

Tags:
Steps To Reproduce:
Additional Information:

Fix:

Change in bug_reminder_page.php

        # Only display view status checkbox/info if reminders are stored as bugnotes
        if( $t_store_reminders ) {

to

        # Only display view status checkbox/info if reminders are stored as bugnotes
        # and there is a right to set the view status
        if( $t_store_reminders && access_has_bug_level( config_get( 'set_view_status_threshold' ), $f_bug_id ) ) {
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22558 [mantisbt] bugtracker major always 2017-03-21 10:14 2020-05-28 15:20
Reporter: rct Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problem with datepicker and custom date format
Description:

Hi,

I've noticed a problem when you use custom date format (french here) in the project version datepicker and the due date datepicker.
One fails with ERROR_INVALID_DATE_FORMAT and the other ignore the due date.
It seems to be ok when I let the default english date format.

For the project version it fails in the class VersionData method __set on function strtotime (Parse about any English textual datetime description into a Unix timestamp. http://www.php.net/manual/en/function.strtotime.php / the date is not in english format).
For the due date the problem also comes from the strtotime function in the bug_update.php.

I dig a little more and I think there is a problem with the date format design: if it is defined at the global level you cannot define a date format matching for example a country because if some users come from another country they will have an unknown date format for them (and if they use another language there are problems with some code using the user language to decode string date format to timestamp).

Why not defining those date format in the language files?

Tags:
Steps To Reproduce:

$g_short_date_format='d/m/Y';
$g_normal_date_format='d/m/Y H:i';
$g_complete_date_format='d/m/Y H:i';
$g_datetime_picker_format='DD/MM/YYYY HH:mm';

Additional Information:
Attached Files: 01-version-date-picker.png (105,176 bytes) 2018-10-30 14:23
https://mantisbt.org/bugs/file_download.php?file_id=8208&amp;type=bug
02-version-project-date-picker-code.png (115,709 bytes) 2018-10-30 14:23
https://mantisbt.org/bugs/file_download.php?file_id=8209&amp;type=bug
a.png (31,105 bytes) 2019-09-25 10:40
https://mantisbt.org/bugs/file_download.php?file_id=8759&amp;type=bug
date_patch.txt (676 bytes) 2019-12-11 16:20
https://mantisbt.org/bugs/file_download.php?file_id=8900&amp;type=bug
Notes
(0056156)
vboctor   
2017-03-21 22:01   

I wonder if this is fixed by 0008957.

(0056772)
rct   
2017-05-04 07:25   

Hello,
Any update on this?
Romain

(0060880)
JPK   
2018-10-30 14:23   
(Last edited: 2018-10-31 12:08)

I Confirm that bug in Mantis MantisBT 2.15.0

When you change date variable $g_normal_date_format in config/config_inc.php

   # --- date format settings --------
   # date format strings defaults to ISO 8601 formatting
   # go to http://www.php.net/manual/en/function.date.php
   # for detailed instructions on date formatting
   $g_normal_date_format   = 'd/m/y H:i';

a bug occurs in the project version datepicker
To resolve that, we modified the file manage_proj_ver_edit_page.php
line 103 :
remplace string_attribute( date( config_get( 'normal_date_format' ), $t_version->date_order ) )
by string_attribute( date( &quot;Y/m/d H:i&quot;, $t_version->date_order ) )

(0062906)
ralfiii   
2019-09-25 10:00   
(Last edited: 2019-09-25 10:01)

I can confirm that the bug is still in V2.22.0
JPKs solution works just perfect.
Only "real" quote-characters need to be used instead if the quot-html-stuff

(0062907)
ralfiii   
2019-09-25 10:40   

Attached you see the same server contacted from 2 different clients.
Date on right client totally spoiled.
Again, JPK's solution resolves that here.

(0063193)
syncguru   
2019-12-07 18:15   

PR: https://github.com/mantisbt/mantisbt/pull/1587

@rolfiii I'd appreciate if you can test this PR and report back if it fixed the issue you are running into.

(0063255)
polzin   
2019-12-11 16:16   
(Last edited: 2019-12-11 16:20)

Isn't the real problem, that the datepicker creates a format in the localized form, but version_api.php uses "strtotime", which only accepts english dates?

Fixed it for me:

/core/version_api.php b/core/version_api.php
remove
$t_value = strtotime( $p_value );
if( $t_value === false ) { ...
insert
$t_date = date_create_from_format( config_get( 'normal_date_format' ), $p_value );
if( $t_date === false ) {
throw new ClientException(
"Invalid date format '$p_value'",
ERROR_INVALID_DATE_FORMAT,
array( $p_value ) );
}
$t_value = $t_date->getTimestamp();

(0063256)
polzin   
2019-12-11 16:20   
(0064034)
polzin   
2020-05-28 15:20   

Still there in 2.24.1, patch still works



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26901 [mantisbt] administration feature always 2020-04-21 06:55 2020-05-27 08:15
Reporter: idvl Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shorten or filter obsolete version numbers in administration
Description:

In the administration -> project management, you can create version numbers with the following states :

  • nothing
  • released
  • obsolete

As the list of version numbers could be very long and not easy to manage, could you add a filter to display only released versions, only unreleased, only obsolete versions, released+unreleased versions...
Thanks

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063905)
maturbet   
2020-04-24 10:23   

Start of resolution
PR : https://github.com/mantisbt/mantisbt/pull/1663

(0063940)
maturbet   
2020-04-30 04:28   

A complement to the resolution :
https://github.com/Association-Cocktail/mantisbt/pull/2

If the precedent is accepted ...

(0063960)
idvl   
2020-05-06 08:10   

Hello,
The solution proposed above seems quite good to start to solve my concerns.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26985 [mantisbt] bugtracker minor always 2020-05-25 14:02 2020-05-27 04:03
Reporter: ciwu Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reopen issue problem with option "default_bugnote_view_status" set to VS_PRIVATE
Description:

If $g_default_bugnote_view_status is set to VS_PRIVATE users with no right for viewing private notes can't reopen issues.

Tags:
Steps To Reproduce:
Additional Information:

Solved it for me with adding
$t_bugnote_private = $t_bugnote_private && access_compare_level( user_get_access_level( auth_get_current_user_id() ), config_get( 'private_bugnote_threshold' ) );
after
$t_bugnote_private = $t_default_bugnote_view_status == VS_PRIVATE;
in bugnote_add_inc.php and bug_change_status_page.php

See also 0026627 and 0026699

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26699 [mantisbt] administration minor have not tried 2020-02-11 17:46 2020-05-27 04:03
Reporter: cproensa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Inconsistent options for setting public/private status
Description:

The definition for set_view_status_threshold, according to documentation:

threshold to set an issue to Private/Public

or config_defaults_inc:

Threshold needed to set the view status while reporting a bug or a bug note.

As an example scenario:

$g_default_bugnote_view_status = VS_PRIVATE;
$g_default_bug_view_status = VS_PRIVATE;
$g_set_view_status_threshold = MANAGER;

With a user having DEVELOPER access level:

  • Creating a new issue, the issue is created as private
  • Adding a note, from issue view page: the note form is rendered as private (yellow background), but after submitting the note is created as public
  • Adding a note, from group action page: the note form is rendered as private, but after submitting the note is created as public
  • Adding a note, from status change page: the note form is rendered as private (yellow background), but after submitting there's an error "access denied"
  • Adding a note, from issue edit page: (same results as status change page)

Additionally, there are other related options:

$g_change_view_status_threshold
Threshold needed to update the view status while updating a bug or a bug note

$g_bugnote_user_change_view_state_threshold
Threshold at which a user can change the view state of his/her own bugnotes

Wich can be confusing when putting them all together.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063620)
polzin   
2020-02-11 18:43   

Thanks for having a thorough look into that.

I think the desired behaviour should be, that if someone does not have the set_view_status_threshold, the user should not the right to create private notes. I see that this is not what is documented, but it used to be the behaviour, and me and @ciwu use it this way. The reasoning is that developers comments should be private by default, so that it requires a conscious action to publish something externally. The other way around, for the external submitters, the default should be public. Furthermore, the new addition that attachments can be private should not break the existing pre 0.23 which is not really related to the change, right?

And I think it's important to distinguish between minor issues and major issues. That a user, that is not able to change public/private notes, sees the wrong color, is a minor thing, because he sees only one color and is not confused by this. That a user cannot add notes while status change/edit issue, is a major thing.

And there is another aspect that is related: While "send a reminder" you have the same problem.

(0063634)
cproensa   
2020-02-14 12:10   

I think the desired behaviour should be, that if someone does not have the set_view_status_threshold, the user should not the right to create private notes.

As far as i can tell, there is not an option that prevent a user to set visibility to private. Those permissions are aimed to changing the visibility, but don't limit whether the target status is public or private

The reasoning is that developers comments should be private by default, so that it requires a conscious action to publish something externally

Configuring default_bugnote_view_status achieves that. Unchecking the private box is an action when the user wants it to be public instead.
However, that option can't be set for developers only. That would be doable by setting the option to specific users in the configuration table. Or better: have that option available to the user in "my account" preferences.

That a user cannot add notes while status change/edit issue, is a major thing.

"Adding a note, from status change page" fails with access denied. That fits the major issue criteria, so something should be done at this moment that the related code is being reviewed.

(0063636)
cproensa   
2020-02-14 12:18   

Regarding the note form and the initial private checkbox, i think this is what should be done to normalize the situation:

The form input should be always be visible and populated according to default_bugnote_view_status.
If the user meets set_view_status_threshold, and bugnote_user_change_view_state_threshold OR change_view_status_threshold, then the checkbox is editable.
Otherwise, the initial status should be shown, but not editable.

The result would be:
If default_bugnote_view_status is VS_PRIVATE, and the user can't edit the checkbox, the note will be created as private (instead of current behaviour: created as public or failed)

I would like to hear input from other developers.

(0063641)
dregad   
2020-02-17 04:02   

@cproensa I agree with your assessment in 0026699:0063636

(0063733)
polzin   
2020-03-05 08:44   

@cproensa, @dregad
From a practical point of view, I have a different opinion.
In our setting, we have internal developers - where the default should be PRIVATE, but for external issue submitters the default should be PUBLIC (because if their notes are set to private, even their colleges can't see their notes).

I understand your reasoning @cproensa, following the explicit words, the options "set_view_status" should only impact, if the view_status is editable. But practically, the resulting behaviour is not sensible (or can you think of users that should be forced to submit only private bugnotes?) and breaks existing, reasonable behaviour that could not be achieved any longer.

Therefore, I would strongly suggest not to go into that direction.

A compromise could be to add another option with the weird meaning default_bugnote_view_status_if_changing_view_status_is_forbidden.
Not really convincing.

Do you have a better idea?

(0064018)
ciwu   
2020-05-22 07:36   
(Last edited: 2020-05-25 14:03)

@cproensa, @dregad

I'm just testing 2.24.1 and merging our changes and I've seen this issue.

I agree with polzin.
Changing should not break the IMHO current useful workflow. If this requires additional options (with weird names), I have no problem with that.

In our setting only internal users (developer, support, sales ...) can add (and obviously see) private notes.

Forcing new note status to private is very useful, as most communication is internal and with automatic email notification, deleting accidentally public added notes is useless.
With the option set, the internal user has to actively intervene (tick the checkbox) if the customer should be notified.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26963 [mantisbt] ui minor always 2020-05-16 17:07 2020-05-26 12:41
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Username field in Monitor box triggers password managers
Description:

The password managers detect the username field as if it is a login username and this triggers dropdowns from password manager plugins and triggers iPads to jump to this field and show the iCloud / 1Password integration interface which is really annoying.

The work here is to change this enough to not be detected as username. This will involve:

  1. Removing the username label next to it.
  2. Changing the name of the text field.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: image.png (58,434 bytes) 2020-05-16 17:08
https://mantisbt.org/bugs/file_download.php?file_id=9100&amp;type=bug
Notes
(0063992)
vboctor   
2020-05-16 17:08   

Attached is a screenshot from a desktop browser. It is a lot more intrusive from iPad browser.

(0063993)
vboctor   
2020-05-16 17:15   

PR: https://github.com/mantisbt/mantisbt/pull/1669



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12798 [mantisbt] filters feature N/A 2011-02-23 05:48 2020-05-25 13:59
Reporter: Chevinge Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.2.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add a filter option [Something] as opposite of [None] i.e. field not null
Description:

currently [Any] shows Null or values,
[None] shows records with no value, would be useful to have a filter for anything that is non-null, suggest therefore
[None]
[Something]
[Any]

whilst there is a workaround multi-selecting items, for items that are continually changing such as Target Version it would be helpful to display everything with a target version, otherwise have to keep updating some filter(s) every time we add new versions.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064004)
l2m   
2020-05-19 09:09   

I've proposed a pull request on github : https://github.com/mantisbt/mantisbt/pull/1670
It covers a few issues concerning the filter :
Unable to filter on empty custom field value https://www.mantisbt.org/bugs/view.php?id=4864
New filter option: [Someone] for Assigned to and other filter fields https://www.mantisbt.org/bugs/view.php?id=8149
Add a filter option [Something] as opposite of [None] i.e. field not null https://www.mantisbt.org/bugs/view.php?id=12798



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8149 [mantisbt] filters feature have not tried 2007-07-13 08:13 2020-05-25 13:59
Reporter: jotango Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New filter option: [Someone] for Assigned to and other filter fields
Description:

Often I would like to filter for issues which are assigned to someone (i.e. the reverse of none).

I would propose adding the filter option [Someone] to the "Assigned to" drop down lists in the filter section.

The [Someone] option should only include issues who are assigned to someone.

Tags:
Steps To Reproduce:
Additional Information:

This should not be just for the user fields it should cover other fields where a 'Not Empty' query is needed.

Attached Files:
Notes
(0019047)
whobe   
2008-08-05 21:49   
(Last edited: 2008-08-05 21:49)

I'd like to say that this isn't exactly the same as my original suggestion too.
I'd suggest instead of "someone" use "set" or "not none" because someone implies it refers to a field which represents a person and I'd like to use this feature in other fields as well. I'd like it to be in all fields that currently have none as an option so I can filter on resolution and the like.

I propose something different which would seem to be all together more useful. That is an option to invert the meaning of any selection. That could mean If I choose "suspended" from the resolution and then check the "invert" or "not" checkbox next to the resolution, the meaning would be equivalent to requesting all tasks whose resolution is not "suspended"

This would work for assigned to to none as well. Just check "not" next to assigned to, select "none" from the dropdown and this would select all tasks which are assigned to someone.

I'd suggest having a checkbox next to each filter option for this purpose. It would leave the existing code essentially untouched and simply complement the select statement for that field.

(0039176)
atrol   
2014-01-25 09:37   

Unassigned after having been assigned for a long time without progress.

(0062428)
stevecharon   
2019-07-26 04:49   

Although this is still something I want to have, you could achieve this by using advanced filters in 2.x Version and Multi-Select all possible Values
and there you have your "not empty" filter.
Dont get me wrong. This is just a workaround! If you have a long list of values it really sucks this way. A single [notempty] is way better IMHO.
Workaround works in 2.5.2 and 2.21.1 (dont have other versions running).

(0064003)
l2m   
2020-05-19 09:09   

I've proposed a pull request on github : https://github.com/mantisbt/mantisbt/pull/1670
It covers a few issues concerning the filter :
Unable to filter on empty custom field value https://www.mantisbt.org/bugs/view.php?id=4864
New filter option: [Someone] for Assigned to and other filter fields https://www.mantisbt.org/bugs/view.php?id=8149
Add a filter option [Something] as opposite of [None] i.e. field not null https://www.mantisbt.org/bugs/view.php?id=12798



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26984 [mantisbt] api rest minor always 2020-05-24 18:03 2020-05-25 09:44
Reporter: vboctor Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: REST APIs allows new lines in issue summary field
Description:

This is not allowed by the UI and is not handled consistently. For example:

  1. Issue View page shows the summary as one line
  2. My View and View Issues pages show multiline.
  3. Updating the summary changes the value to a single line, with history that shows multi-line, etc.

Hence, the REST API should block use of multi-line summary fields.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064026)
dregad   
2020-05-25 09:44   

Do we need some kind of cleanup task to remove newlines, or maybe an admin check ?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22180 [mantisbt] markdown major have not tried 2017-01-12 07:12 2020-05-24 05:13
Reporter: dregad Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Markdown issues following implementation in 0017920
Description:

This is a parent issue to regroup various issues with Markdown rendering, that must be fixed prior to release (hence setting severity to major, so it shows on the blockers list)

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0055085)
vboctor   
2017-01-12 12:02   

The markdown feature is OFF by default. I don't see any markdown fixes as blocking. We can mention in the announcement that the markdown support is experimental and off by default. It is good to get more people playing it with and providing feedback.

(0055087)
dregad   
2017-01-12 12:26   

OK, I forgot it was off by default. Feel free to lower severity then.

(0055122)
vboctor   
2017-01-14 13:20   

@dregad, can we delete this issue in favor of "markdown" category and severities on such issues? We can't resolve it since it has child issues that are not resolved.

(0055140)
dregad   
2017-01-15 19:08   

I'd rather keep it. I like having a parent issue, for the following reasons:

  • it creates clear relationships between issues
  • the fixes are logically and visually grouped in the roadmap
  • using parent/child makes it clear that all issues are related, and avoids creating links in a chaotic way

Speaking of markdown category, I'm wondering if would not have been better managed with a tag, which is more horizontal as we can have markdown issues not only in the tracker, but also in e-mail notifications, RSS, etc.

(0055949)
Chris_Z   
2017-03-07 06:53   

the fixes are logically and visually grouped in the roadmap

...unless they belong to another sub-project. In that case all grouping is lost there. Selecting the parent project doesn't help either because 'atoms' in the list are separate projects regardless of their inter-project hierarchy, and despite the fact that they can and often do all share the same (i.e. inherited from parent) versions.

Of course it would be a nice feature request to get Roadmap and Change Log to work horizontally on the selected project level instead of mercilessly drilling downstream from the selected level. Should I create a separate issue for it?

(0055952)
dregad   
2017-03-07 07:43   

Should I create a separate issue for it?

You can if you want to, but don't get your hopes too high of seeing it implemented anytime soon ;-)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26920 [mantisbt] authorization minor have not tried 2020-04-26 15:35 2020-05-23 23:01
Reporter: GuyAvRM Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: reporter allowed to close
Description:

Sorry, this seems to be a FAQ but I can't find the final word.
I started a fresh brand new install of this excellent tool.
I allowed reporters to close issues ($g_allow_reporter_close = ON;)
Attachment 1 shows config OK.
Nevertheless, reporter Guy2 reporter does not see any way to close the issue he opened initially.
Any help welcome
Thanks

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: reporter allowed to close.PNG (22,123 bytes) 2020-04-26 15:35
https://mantisbt.org/bugs/file_download.php?file_id=9073&amp;type=bug
actual reporter not allowed to close.PNG (21,268 bytes) 2020-04-26 15:35
https://mantisbt.org/bugs/file_download.php?file_id=9074&amp;type=bug
Notes
(0063918)
atrol   
2020-04-26 16:21   

Regression introduced in 2.23.0

(0064025)
vboctor   
2020-05-23 23:01   

PR: https://github.com/mantisbt/mantisbt/pull/1673



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26982 [mantisbt] documentation minor N/A 2020-05-23 17:26 2020-05-23 19:36
Reporter: vboctor Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: REST API documentation not discoverable via https://explore.postman.com/
Description:

Figure out how to make it discoverable via the Postman explore page.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25998 [mantisbt] documentation major N/A 2019-08-14 09:48 2020-05-23 19:36
Reporter: dregad Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: REST API documentation
Description:

Currently, the REST API's documentation is hosted externally at https://documenter.getpostman.com/view/29959/mantis-bug-tracker-rest-api/7Lt6zkP

The source is not part of the MantisBT repository, and generally not available to the team since currently @vboctor is the only person having access to the Postman account.

We need to

  1. reference the documentation on http://mantisbt.org/documentation.php
  2. define a process so the team (and possibly contributors, if possible) can update and publish the documentation
Tags:
Steps To Reproduce:
Additional Information:

Record of a Gitter discussion on the subject

@dregad April 17, 2019 9:40 AM

@vboctor As I was reviewing PR 1506, I thought that this change should be reflected in documentation. That's when I realized that the REST API docs are not in the repository. What is the process to maintain / update that ?

@vboctor April 18, 2019 9:22 AM:

For the API documentation I do this via Postman and it may rely on my account being a paid one. I’ll explore options.

Attached Files:
Notes
(0062568)
dregad   
2019-08-14 09:55   

@vboctor I'm assigning this to you, as you're currently the only one who can take action on point 2.

If sharing Postman account turns out not to be an option, maybe we can consider other alternatives for REST API docs ?
Reference: https://pronovix.com/blog/free-and-open-source-api-documentation-tools

(0062612)
vboctor   
2019-08-20 02:13   

PR: https://github.com/mantisbt/mantisbt/pull/1546



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26962 [mantisbt] code cleanup minor N/A 2020-05-16 16:54 2020-05-23 18:10
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Remove unused bug_monitor_list_view_inc.php file
Description:

This file is no longer used after implementing 0025902

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063994)
vboctor   
2020-05-16 17:15   

PR: https://github.com/mantisbt/mantisbt/pull/1668



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6446 [mantisbt] relationships feature always 2005-12-01 05:03 2020-05-23 05:18
Reporter: Andreas Isenmann Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multiple selection for creation of parent/child relationship
Description:

"View Issues" gives the possibility to select multiple issues and these selected issues can for example be assigned to a developer.

It would be a great help if it would be possible to create a relationship in this way, too.

Tags:

patch

Steps To Reproduce:
Additional Information:

If you use a parent/child relationship for release planning you have to make the relationships one by one. Perhaps you want to solve 100 issues for the next release. In this case you have to create 100 relationships and this takes a long time.

It would be much faster if you just could check these wanted issues and then make all the relationships with a new function "Create relationship".

Attached Files: SetParentDJC.zip (39,852 bytes) 2006-05-03 20:52
https://mantisbt.org/bugs/file_download.php?file_id=1012&amp;type=bug
forceparent.zip (3,006 bytes) 2008-01-08 21:21
https://mantisbt.org/bugs/file_download.php?file_id=1612&amp;type=bug
Notes
(0012777)
djcarr   
2006-05-03 20:51   
(Last edited: 2006-05-03 21:07)

As mentioned at http://forums.mantisbt.org/viewtopic.php?t=745, I've implemented a "Set Parent" solution.

Purpose

Make it very simple and easy to move lots of issues between releases which are represented as Parent Issues.

Changes

  • an option "Set New Parent" added to combobox in "View Issues" page
  • after selecting issues (checkboxes) and hitting OK, next page loads
  • on this page, can enter an issue number for the new parent
  • all previous child-of relationships for these issues are deleted
  • all issues are assigned child-of the new parent issue

Problems

  • Existing child-of relationships will be deleted!! Remember that when you clone issues in mantis, they are made parent-child by default (why? I always use 'related-to'). So if you "Set Parent" on issues that happen to be a child-of another relationship, you'll lose that prior relationship. If this is a problem for you, you could add an "Old Parent" ID field to the dialog, and delete only relationships to that old Parent.

  • Only sets a Child-Of relationship. No provision for other relationship types, though 0006512 will help if you need to set multiple related-tos, for example.

  • NOT READY FOR INTEGRATION INTO MANTIS This is a crude solution for my purposes only, and has only been made available at the request of others. It is not intended to be a Mantis patch and may need to be reworked or rewritten completely.

Installation

I've attached the file as SetParentDJC.zip. It's not in patch format unfortunately, but contains the files I changed in Mantis 1.0.1, and every change I made is bracketed by comments. Search for 'DJC' to find these changes and you shouldn't have any problems applying them to your installation. Back up first! Usual disclaimers apply.

Feel free to modify/improve and repost your changes here.

(0016597)
djcarr   
2008-01-08 21:28   
(Last edited: 2008-01-08 21:34)

Reimplemented this in 1.1.0 using the new EXT_ plugin model, in attached file forceparent.zip.

WARNING: Before proceeding be aware that Mantis 1.1.0 supports Target Versions which is a better way of managing numerous issues against release versions. You should ONLY need or use this plugin if you still need to move many child issues from one parent issue to another.

ANOTHER WARNING: This includes DELETE queries. Back up your database! This has worked very well for me but you should test it thoroughly with yours.

To install:

  1. extract forceparent.zip to mantis main directory. This should produce bug_actiongroup_force_parent_inc.php in main dir and relationship_force_parent_api.php in /core subdirectory.

  2. Add the four custom strings into custom_strings_inc.php (or language file):

    $s_force_parent_title = 'Set New Parent';
    $s_force_parent_msg = 'Enter the Issue # to set as the new parent.[p/]NOTE : THIS ACTION WILL REMOVE ALL EXISTING PARENTS FOR THE SELECTED ISSUES.[p/]This is a custom feature designed to help with the obsolete "Parent Issue as a Target Version" approach. Mantis now properly implements Target Versions. You should not continue unless you know what you are doing.';
    $s_force_parent_button = 'Set New Parent';
    $s_actiongroup_menu_force_parent = 'Set New Parent';

    (naturally, change square brackets to angle brackets)

  3. Add the action to config_inc.php:

    $g_custom_group_actions = array(
    <<any other custom group actions you have>>,
    array( 'action' => 'EXT_FORCE_PARENT',
    'label' => 'actiongroup_menu_force_parent' )
    );

(0016697)
boesman   
2008-01-17 06:30   

Hi need some assistance with update. I get the following error when running the function

PPLICATION ERROR #18

Page redirection error, ensure that there are no spaces outside the PHP block (<?php ?>) in configinc.php or custom*.php files.

Top of screen: APPLICATION WARNING #100: Configuration option '70' not found.

Relationships are created successfully

(0016708)
djcarr   
2008-01-17 17:16   

Hi boesman,

This sounds like 0008212

Can you check custom_strings_inc.php and config_inc.php again? Sounds like something wrong with or around the <?php and ?> markers.

(0016740)
boesman   
2008-01-20 23:44   

Hi djcarr, i lookded at it but could not find any white spaces in the two files.

i also get the APPLICATION WARNING #100: Configuration option '70' not found. error showing at the top of the page.

(0016754)
djcarr   
2008-01-21 22:33   

beats me sorry! does anyone else have this problem applying this plugin to 1.1.0?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25666 [mantisbt] ui feature have not tried 2019-03-29 09:33 2020-05-22 11:07
Reporter: dregad Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Replace user selection list with an autocomplete widget progressive remote search
Description:

The current user selection widget relies on an HTML SELECT widget, which is fine when there is a small number of entries in the list. However, when there are many users in the system (e.g. on this tracker, which has nearly 40K users as of this writing), the list is unwieldy or even useless, and causes a significant performance issue as it takes a significant amount of time for the server to load the list and the browser to render it (about 40 seconds on the computer I'm using now).

It should be replaced with another mechanism, e.g. an INPUT with autocomplete / progressive search, such as jQueryUI https://jqueryui.com/autocomplete/ or similar.

Although this topic has been discussed several times in the past (0017577, https://github.com/mantisbt/mantisbt/pull/1486 come to mind, but there are probably others references as well), it was never formally logged as a distinct issue AFAICT.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0061797)
dregad   
2019-03-29 09:43   

For reference, here's an old attempt at tackling this https://github.com/dregad/mantisbt/commits/dynamic-reporter-select (probably a half-baked, semi-functional work-in-progress, I haven't actually looked at this code since 2015).

(0061798)
cproensa   
2019-03-29 10:19   

This has a dependecy on 0025658
A static alternative can't be offered without defeating this purpose:

  • Cant provide the current selection list as fallback, that's what we want to avoid
  • Cant provide some kind of popup strategy, because that also need js.

Regarding implementation:

  • We removed jqueryui time ago.
  • i see we already include typeahead, iirc, it's only used for very isolated cases. However, if we have a better alternative, those could be migrated too.
  • the server side is probably expected to be implemented by rest api
(0061799)
dregad   
2019-03-29 11:08   

This has a dependecy on 0025658
A static alternative can't be offered without defeating this purpose:
Cant provide the current selection list as fallback, that's what we want to avoid

I tend to agree, but at the same time someone intent on not using JavaScript has to accept that Mantis will work in degraded mode, so I would not qualify this as a hard dependency. In other words, I think falling back to the current selection list would be acceptable in this case.

We removed jqueryui time ago.

I know, I just gave that as an example of what I meant by "autocomplete".
I have no particular preference or recommendation with regards to what library to use.

the server side is probably expected to be implemented by rest api

Right.

(0064019)
c_schmitz   
2020-05-22 11:07   

We have now almost 200,000 users. Certain parts of the admin interface are now blocking/unusable due to this issue, because when 200,000 names are loaded into a dropdown the browser crashes and a small kitten is killed somewhere.
We are now in 2020 and this issue existed since 2014.

Is there anything we can help with to resolve this issue?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26974 [mantisbt] installation minor always 2020-05-21 07:19 2020-05-22 05:45
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Required PHP json extension not documented and checked
Description:

Starting from early 1.3.0-beta.1, functions that are part of PHP json extension have become essential to run MantisBT.

This was not documented and is not checked in admin checks.
On most PHP installations, the extensions is enabled, so there was hardly any user affected until now.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0064014)
atrol   
2020-05-21 07:38   

PR https://github.com/mantisbt/mantisbt/pull/1672



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8957 [mantisbt] custom fields feature N/A 2008-03-12 14:52 2020-05-20 13:35
Reporter: phoenixcreation Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.1.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Date Selector for Custom Fields
Description:

In the class.period.php file there are functions for a date selector (shows up on Arbitrary Dates selector within the graphs pages / bug_graph_page.php).

Would it be possible to add this to the Date custom field entry? Would make it far easier for users to enter dates.

Tags:

patch

Steps To Reproduce:
Additional Information:
Attached Files: date_picker.patch (244,032 bytes) 2011-04-13 05:32
https://mantisbt.org/bugs/file_download.php?file_id=3336&amp;type=bug
Custom_date_field_date_picker.php (5,675 bytes) 2012-08-08 02:27
https://mantisbt.org/bugs/file_download.php?file_id=3986&amp;type=bug
Notes
(0028611)
philou2024   
2011-04-13 05:39   

My first patch on Mantis, Hope it's ok ;)
Tested on 1.2.4 and 1.2.5

Added
global variable date_picker, already used in another date patch
$g_use_date_picker_javascript = OFF;
and another variable to configure jscalendar as you like it
$g_date_picker_configure = array(
'timeFormat' => 24,
'firstDay' => 0,
'cache' => 'true',
'showsTime' => 'true',
);
Then I modified core files date_api and gpc_api in order to setup date (one field in place of three) before saving.

(0028884)
M.C.S.   
2011-06-01 04:21   

I'd really like to see this functionality in Mantis. Current date picking with three dropdown lists is quite ugly.

(0029284)
atrol   
2011-07-24 05:31   

philou2024, thanks for the contribution.
I noticed that your patch is quite large, showing a lot of differences which are not related to this issue (maybe the diff is based on wrong branch)

You can fork from https://github.com/mantisbt/mantisbt and send a message to the developer mailing list to discuss / review your changes

(0029582)
markusobrist   
2011-08-29 05:55   

+1 for implementing this in core. philou2024 wrote here about the patch: http://www.mantisbt.org/forums/viewtopic.php?f=3&amp;t=9924. Has it ever been corrected?

(0029583)
marcel_paasch   
2011-08-29 07:04   

+1 for implementing this in core, too.

(0030021)
phoenixcreation   
2011-10-21 10:31   

philou2024 (or others): After implementing this I noticed that when I try to filter by one of these custom fields, the filter area attempts to use the date picker.

But when you click on it, it just refreshes the screen rather than applying the date. If you manually type the date, all is well, but the date picker does not tie to the filters area.

Thoughts?

(0030024)
phoenixcreation   
2011-10-21 14:16   

Another odd question: With these in place, it automatically puts a date in those fields as soon as you create or update the job. Is it possible for the fields to allow NO date to be present?

(0030150)
ahmadluky   
2011-11-03 01:13   

can i know the steps to do it. I do not understand

URGENT

(0031258)
brahms   
2012-02-20 05:40   

MyVersion: 1.2.8. I customized a date field, I need to input and display date like this "Y-m-d H:i", how could I do it?

(0032496)
cas   
2012-08-08 02:29   

Added the actions to make this work under 1.2.10.
Just reviewed the work of Philou and took out what was not needed.

(0033302)
atrol   
2012-10-24 16:59   

We got a pull request for it https://github.com/mantisbt/mantisbt/pull/64

(0033304)
M.C.S.   
2012-10-25 02:12   
(Last edited: 2012-10-25 02:33)

After some "real-world testing", I found some things that made me cancel the pull request:

  • The calendar used a date format that also contained a time part, although this is not used by custom date fields.
  • The calendar allowed to choose a time part which is not needed for the same reason.
  • If there were more than one date fields within a form, only the first icon was rendered with a space between text input and calendar icon.

For this reason, I made some additional code changes which should fix these issues. As far as I could see this does not affect the "Due date" functionality (at least I could not find any side effects after some manual tests).

New pull request: https://github.com/mantisbt/mantisbt/pull/65

(0033385)
santy143all   
2012-10-31 08:13   

how can i edit the output provided by the datepicker

(0034285)
rombert   
2012-11-10 14:50   

I'll take a look at this after 1.2.12 is released.

(0034868)
d3monsou1   
2013-01-22 22:48   

I am able to get date picker working, however I am also one step short of meeting my full objective. Which part of the configuration/code do I need to amend in order to not display the "today" date in the custom field by default.

I require the custom date fields to be empty by default and the date to only appear when I select it.

Anyone able to assist?

(0038110)
homework   
2013-09-25 09:16   

Date Selector for Custom Fields works fine. But there is a Issue with Date Selector itself when using https. 0016406

(0038114)
dregad   
2013-09-25 12:31   

there is a Issue with Date Selector itself when using https

I can't reproduce this.

(0038115)
atrol   
2013-09-25 13:51   

@homework, do you use a reverse proxy?

(0040620)
markusobrist   
2014-05-22 01:31   
(Last edited: 2014-05-22 01:57)

I agree with @d3monsou1, an empty date has to be displayed empty and not be set to today.
To change this, adjust the function print_date_selection_set in date_api:

replace:
$p_date = is_numeric( $p_date ) ? $p_date : time();

with:
if(is_numeric( $p_date )) {
$t_date = preg_split( '/-/', date( 'Y-m-d', $p_date ), -1, PREG_SPLIT_NO_EMPTY );
$t_date_to_display = $t_date ? $t_date[0] . "-". $t_date[1] . "-". $t_date[2] : '';
} else {
$t_date_to_display = '';
}

Also, the calendar generally only supports english as of now (language and date format). This should be changed to allow other languages too

(0054810)
dregad   
2016-12-20 12:57   

@syncguru, in the frame of replacing jscalendar by bootstrap widget, you might want to tackle this one too, together with 0021873 and 0021874.

(0055682)
syncguru   
2017-02-14 23:51   

https://github.com/mantisbt/mantisbt/pull/1032

(0056586)
cproensa   
2017-04-16 18:41   

Reopened. Due to regressions, the changes have been reverted and will be targeted to next release

(0058588)
Padraig   
2018-01-22 06:40   

Has anybody an update on this ticket? The target versions seems to just be bumped to the next release each time.
I know this is a child of 0015281 but I think any proper date selector for custom fields will be much better than the 3 box model we have now.

(0062864)
MPAA   
2019-09-19 02:59   

Any news? duplicate with 0017976

(0063195)
syncguru   
2019-12-07 23:57   
(Last edited: 2019-12-07 23:58)

@cproensa What are the regressions scenarios that resulted in the revert of this code?
After fixing this 0022558, I think the issues with date picker should be fixed.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21820 [mantisbt] attachments minor have not tried 2016-10-23 02:29 2020-05-20 00:50
Reporter: vboctor Platform:  
Assigned To: cproensa OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Support adding an attachment when editing an issue
Description:

When editing an issue it is possible to add a note, but not to add an attachment.

Tags:

mantishub

Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0057225)
TomR   
2017-07-14 11:59   

Any Target version?

(0058083)
SchaefT   
2017-10-30 06:18   

This feature would be very, very useful

(0063371)
cproensa   
2020-01-06 17:31   

PR: https://github.com/mantisbt/mantisbt/pull/1606

(0064008)
thE_iNviNciblE   
2020-05-20 00:50   

+1



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21819 [mantisbt] attachments feature N/A 2016-10-23 02:28 2020-05-20 00:50
Reporter: vboctor Platform:  
Assigned To: cproensa OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Support adding an attachment from change status page
Description:

When changing status of an issue, it is possible to add a note and time tracking, but it is not possible to add an attachment. We should support that.

Tags:

mantishub

Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0057226)
TomR   
2017-07-14 11:59   

Any Target version?

(0058082)
SchaefT   
2017-10-30 06:17   

This feature would be very, very useful

(0060097)
cem   
2018-06-18 04:28   

I confirm it is similar in the version 2.10.0

(0063370)
cproensa   
2020-01-06 17:31   

PR: https://github.com/mantisbt/mantisbt/pull/1606

(0063373)
dregad   
2020-01-07 03:33   
(0064007)
thE_iNviNciblE   
2020-05-20 00:50   

+1



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4864 [mantisbt] filters minor always 2004-11-15 08:10 2020-05-19 14:27
Reporter: vboctor Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 0.19.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to filter on empty custom field value
Description:

For an enumeration custom field which allows the user to choose a combo box to choose a target release, I wasn't able to filter the issues that have the custom field set to the value of empty string (which is one of the enumeration values). I am only able to filter on "any" or specific values.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011381)
warde06   
2005-09-16 14:52   

We are using 1.0.0rc1 and this problem seems to still exist. Do you know if there are any plans to fix it or if there might be a workaround?

We are using an enumerated custom field set to "=versions" and so we are unable to filter on those that do not have a version set yet.

Your help is greatly appreciated!

(0011389)
ryandesign   
2005-09-18 10:56   

If you set up a custom enumeration field and set its possible values to "=versions" then, when creating or updating an issue, for this field, you get a drop-down menu containing all the versions for that project. What you don't get is an option to assign none of these versions to that field's value -- you must select one of them. So the only possible way you could have an issue where this field is empty is if the field was added to the project after the issue had already been created, and the issue has not been updated since then (because if you were to update the issue afterwards, the version field would get filled in with something). Am I understanding this right? Is this the situation we're talking about?

Is it desirable to have a custom enumeration field showing the project's versions, yet also allow the possibility for the user to select "none of these"? If it is, then that should also be programmed, and would make the request in this issue more relevant, IMHO.

(0011395)
warde06   
2005-09-19 17:19   

Yes, this is the situation that I am talking about. We have a custom field for Target Version, but it is not required. We were having a problem when someone updated a bug, because if they click the "Update" bug button then it would automatically assign the first version in the list. Since this is not always the correct version, I added a blank as the first value so that it will automatically assign blank unless they select something else.

I have created an override function for custom_function_default_enum_versions and added the following line:

$t_possible_values = '|'.$t_possible_vales;

This part is working fine now, but they are unable to filter on bugs that do not have a version selected yet.

We have 1000s of issues already created (Mantis is awesome and we have been using it for several years now), but we just added the target version field with the release of 1.0.0rc1 in the last month or so.

So that is why we need the "none of these" option.

Thank you for your help!

(0022136)
siebrand   
2009-06-13 04:24   

Unassigned after having been assigned for multiple years without progress.

(0024713)
dhx   
2010-03-12 09:00   

Alex has provided an updated patch at http://git.mantisforge.org/w/mantisbt/gtz-et.git?a=shortlog;h=refs/heads/mantisbt-issue11476

Not tested yet.

I think the "require" flag may be a better approach to deciding whether or not a blank value is allowed for enumeration (and other list-type) fields.

(0024722)
am-gtz   
2010-03-12 09:28   

Actually the intention of my patch was a bit different i.e. even for required fields, the (select) value should be included, just the way like this is for Categories and so on.

We just do not want to pre-select an existing value to require users to choose the correct values (instead of not touching the drop-down box and thus choosing a wrong value).

(0035921)
vovella   
2013-03-20 03:08   

I have this problem too.

Can't access to patch!

(0063779)
bluescreenterror   
2020-03-19 16:05   

Hi,

stumble on this issue in recent Version 2.24.0. Created a pull request on github: https://github.com/mantisbt/mantisbt/pull/1633
Minor changes as far as I can see, please review. thx

(0063841)
l2m   
2020-04-15 11:04   

The patch in the previous note matches my need. I posted also a comment on github. For now I have removed the test (core/filter_form_api.php line 1961) on my mantis instance.
In my opinion, the "none" value for filter should always be available.
Some users would even like to have the "not empty" value available but it might have more impact on the code.

(0064002)
l2m   
2020-05-19 09:09   

I've proposed a pull request on github : https://github.com/mantisbt/mantisbt/pull/1670
It covers a few issues concerning the filter :
Unable to filter on empty custom field value https://www.mantisbt.org/bugs/view.php?id=4864
New filter option: [Someone] for Assigned to and other filter fields https://www.mantisbt.org/bugs/view.php?id=8149
Add a filter option [Something] as opposite of [None] i.e. field not null https://www.mantisbt.org/bugs/view.php?id=12798



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26964 [mantisbt] bugtracker minor sometimes 2020-05-17 09:53 2020-05-19 04:03
Reporter: lega4 Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Admin check always has "WARN" for magic_quotes checks (PHP 7.4)
Description:

Seems like magic quotes check are always raising a warning no matter what.

magic_quotes_gpc php.ini directive is disabled WARN
DEPRECATED: Function get_magic_quotes_gpc() is deprecated
Raised in file /var/www/html/admin/check/check_php_inc.php on line 120

I've tried to add explicit settings to my php.ini, but it doesn't change anything, also as per https://stackoverflow.com/a/18683025/1657819, magic quotes are permanently disabled since PHP 5.4.
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off

Suggestion => remove magic quotes checks completely as they're not relevant in 2020 any more

Tags:
Steps To Reproduce:
  1. Install MantisBT in a clean PHP 7.4 environment
  2. Go to /admin/check pages
Additional Information:

Doesn't seem to be reproducible with PHP 7.2, at least I have another environment and don't see it there... Might be some other issue, no idea :(

Attached Files: image.png (51,761 bytes) 2020-05-17 09:53
https://mantisbt.org/bugs/file_download.php?file_id=9101&amp;type=bug
Notes
(0064001)
atrol   
2020-05-18 16:47   

Thanks @lega4 for reportimg the issue.

PR https://github.com/mantisbt/mantisbt/pull/1671



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21584 [mantisbt] customization minor have not tried 2016-08-02 14:15 2020-05-17 09:55
Reporter: atrol Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: core_path directory can't be moved outside the web root
Description:

After a fresh install running admin/check.php gives WARN for check:
core_path configuration option is set to a path outside the web root
For increased security it is recommended that you move the core_path directory outside the web root.

Moving the directory outside the web root does not work as there is a hardcoded path in core.php
require_once( dirname( FILE ) . DIRECTORY_SEPARATOR . 'core' . DIRECTORY_SEPARATOR . 'constant_inc.php' );

constant_inc.php has been moved to core folder in 2003, see commit 5cad7a7e23fba2a51a369a764daf33aeee232ddd
At first sight it seems that $g_core_path can't be changed since that time.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0058351)
darkwind   
2017-12-07 11:11   

This problem occurs because when core.php is loaded the config file has not been read yet. So if you set $g_core_path in /config/config_inc.php the variable is still not defined at that moment.

A work around is to move the whole core directory to an outside path. Then recreate the core folder and copy the file constant_inc.php to that newly created core folder from the outside path core folder. This will result in an empty core folder that only contains constant_inc.php.

You can also move the config folder to the outside location. And then you have to still keep the config folder and /config/config_inc.php. But you can edit that new config and change its content to only the paths and the include_once( $g_config_path . 'config_inc.php' ).

Here is the snippet:
<?php
$g_config_path = '/opt/mantisbt_outside/config/';
$g_core_path = '/opt/mantisbt_outside/core/';
$g_class_path = '/opt/mantisbt_outside/core/classes/';
$g_library_path = '/opt/mantisbt_outside/library/';
$g_language_path = '/opt/mantisbt_outside/lang/';

include_once( $g_config_path . 'config_inc.php' );

Hope this helps anybody who had the same problem.

(0058831)
lxfo6njcyc6ze24kp1h9   
2018-02-11 15:16   

I tried this with 2.11.1 but when I tried to go to the login page, I get a blank. only when I put the config back in the mantisbt root directory does this work. This also happens when i move the core as well. Please advise as to what I could be doing wrong.

(0059791)
123   
2018-05-15 04:58   

Note the variable $ t_local_config = getenv ('MANTIS_CONFIG_FOLDER') in config_defaults_inc.php

It extracts the path to your "config" folder from the environment variable of your web server.
Add the following line to your web server's configuration file:
SetEnv MANTIS_CONFIG_FOLDER /path to your config folder/

(0059792)
123   
2018-05-15 05:17   

Indeed, there is a problem. Sorry...

(0063957)
amphetamine   
2020-05-05 01:44   

still there in 2.24.1

(0063995)
lega4   
2020-05-17 08:57   
(Last edited: 2020-05-17 09:31)

Even if one updates the variables to point to the outside, apparently path to "core" folder is hardcoded at https://github.com/mantisbt/mantisbt/blob/master/core.php#L67, so it makes no sense to copy core folder outside of webroot.

Update: found several more hardcoded paths:

=> so those checks don't make any sense now, there is no way to fix them. Please remove them until it's possible to make them green without dirty hacks.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3444 [mantisbt] feature feature N/A 2003-12-03 03:44 2020-05-16 06:13
Reporter: TomWalter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add user groups to streamline user management
Description:

It would be nice to have user groups, to which Access levels and Projects could be assigned, rather than assigning those things individually. For example in the case where you are tracking several projects from different clients, and each client has multiple users, and you want to be able to easily assign all the users from that client to the one project.

Tags:

usergroups

Steps To Reproduce:
Additional Information:
Attached Files: diff_from_RELEASE_0_18_3_20040512.diff (62,093 bytes) 2004-05-26 14:12
https://mantisbt.org/bugs/file_download.php?file_id=172&amp;type=bug
group_new_files.zip (13,881 bytes) 2004-05-26 14:13
https://mantisbt.org/bugs/file_download.php?file_id=173&amp;type=bug
group_tables.sql (1,080 bytes) 2004-05-26 14:13
https://mantisbt.org/bugs/file_download.php?file_id=174&amp;type=bug
usergroups_diff_from_0_19_CVS_20040529.zip (29,830 bytes) 2004-09-05 18:03
https://mantisbt.org/bugs/file_download.php?file_id=405&amp;type=bug
Creating groups in Mantis.pdf (92,496 bytes) 2009-10-09 04:55
https://mantisbt.org/bugs/file_download.php?file_id=2512&amp;type=bug
Snap3.jpg (68,874 bytes) 2015-04-09 02:58
https://mantisbt.org/bugs/file_download.php?file_id=6280&amp;type=bug
Notes
(0005532)
lauploix   
2004-05-18 06:57   

I agree. We have 15+ projects, and mainly 5+ user groups (sales, programmers, consulting, ...).

It would be so nice to be able to manage the rights at group level... and just add a user to a group when a new user arrives.

(0005574)
dwoods   
2004-05-24 13:08   

I have implented something similar in some customizations a while ago. We have a number of distibutors of our product, and it's not always desirable for them to see ongoing issues with other distibutors (at least in management's eyes).

Basically, each bug has "group view list" associated with it. Only users in those groups can see the bug (it gets filtered out of the view_all pages as well). There is a new [Manage Groups] link to a new page in the Manage screen.

I made these changes based on 0.18.0a4, and am just in the process of porting my changes to 0.18.3. I could post it here when I'm finished if anyone's interested.

(0005580)
lauploix   
2004-05-25 01:59   

Hi dwoods, I think this is also interesting to have a 'per bug' right management sometimes. In fact, I sometimes want to enable a specific user to view/update/... a bug that he has no right on.

Pb is I usually have sg like 150+ open issues, in 15+ different projects, with 100+ users in 5+ user groups. Mantis is really great for that. But that means that I cannot manage all rights on a per bug basic.

What would be so great would be : once I have a new user, I just put him in several "groups" and he gets all the update/view/manage/... rights that the groups have.

But this is no contradiction with a more specific 'per user' or 'per bug' user rights management for specific purposes.

(0005583)
nuclearspike   
2004-05-25 10:23   

in a somewhat related note, also have the auto-assignment of new issues be able to go to a user group/role. A customer enters a new problem, it first should get assigned to the triage group who verifies the bug before it gets assigned to the developer who works on that category. If it first goes to one person, that person is sometimes gone for weeks on the road and other people need to handle the triage. Our current solution is sort of hackish. We create a "Triage" user, have things assigned to them, then the triage group just checks for things assigned to that user, rather than to themselves. this, however, means that all new bugs go there and we cannot use the category auto-assignments for the actual developer. Auto-assignments may be best on a per-status level. New -> Triage, Confirmed -> Manager of the project or may go directly to the developer of that category. That's getting more into workflows... which is a separate request entirely. :D

(0005594)
dwoods   
2004-05-26 14:31   
(Last edited: 2004-05-26 14:32)

I've attached a diff from 0.18.3, as well as all new files in a .zip (diff includes new files) and an sql file to create new tables.

As it is right now, it doesn't actually filter out the issues in the view_all_page according to the group 'view list'. I wanted to change how i was doing this before I add it in.
Basically it went something like:

for each bug passed though all other filters
get the group_view_list for that bug
for each group
if current_user is in group
show bug
if current_user is reporter
show bug

Also, the only way to add/remove groups to an issue is in the bug_view_advanced_page, which is clearly the wrong place. It should be in the bug_advanced_update_page.
Also I would like to add the ability to add a group to multiple bugs at the same time (via the checkboxes).

Also each user should have a 'default' group, that get added to the view list automatically when they submit new issue.

Still working on it.. :)

edited on: 05-26-04 14:32

(0007363)
nuclearspike   
2004-09-01 13:34   

this is nice, but it adds groups to be able to see individual bugs, is there a way an entire group can be associated with a project?

(0007448)
dwoods   
2004-09-05 18:03   

I have updated the patch since my posting, but forgot to update the post.
It's now diff'd from the latest from HEAD as of about a 2 months ago.

My company also wanted me to make additional modifications to allow 'projects' in addition to 'issues' (where are project is actually just another issue, only originating from within the company for one of our developers to handle). And the projects as they are now I have changed to 'products'.

Anyway, the patch I'm including has these changes in there as well. I apologize for this, but hope this at least some of the code I have written may be of some use. The user group stuff is fairly self-contained.

The user groups are only used right now for implementing an 'access-list' on a per-issue basis, as mentioned in a previous note, but it would also be nice if an issue could be assigned to a group of users. I think the basic framework is there...

I also attempted to add to the upgrade scripts to create the new tables. They seemed to work for me okay.

(0021906)
djcarr   
2009-05-24 23:31   
(Last edited: 2009-05-24 23:35)

With 100+ projects and 100+ users this is an area where the administration workload starts to become difficult. Being able to assign roles (or "user groups") to projects and then giving users one or several roles, would really bring Mantis into the realm of corporate applications.

Could others desiring this feature please also put a little encouragement in.. thank you :)

(0021931)
tk   
2009-05-27 01:35   

Just for comment:

As a partial workaround, I implemented "assignment groups" by creating fake users which have a mailing list as email destination. The mailing list contains all people in that group.
In that way I can assign issues to groups of people. Now since the group members are all of level developer (otherwise assignment of an issue to them would make no sense) the actual user-in-charge can assign the issue to himself as soon as he starts working on it.

(0022027)
djcarr   
2009-06-01 19:08   
(Last edited: 2009-06-01 19:15)

Thanks for the input 'tk' - perhaps the scenario you are talking about is covered by 0000955 or 0006644? While I can see how that may be useful it is still somewhat different to this issue which is for a users-roles-privileges engine.

(0023105)
sveyret   
2009-10-09 04:57   

Hi, I have made specifications about what I think could solve all the problems (see attached PDF file). Can you tell me your opinion about it? I hope I will find time to work on that issue soon.

Thank you.

(0023199)
sveyret   
2009-10-15 04:59   

Specifications are now added to the Wiki page so everyone can work on it…

(0027115)
andy778   
2010-10-22 02:31   

Any idea when this will be developed and how much sponsoring would this require to get this done?

(0028016)
tiliarou   
2011-01-20 08:18   

I'm very interested by this feature ! Adding group management to Mantis would make it so much better !
Is someone still working on this issue ? Does he need more sponsoring ?

(0028022)
djcarr   
2011-01-20 17:53   
(Last edited: 2011-01-20 17:58)

The specs in the wiki are very detailed but represent a very large amount of work. I am not sure why the login authentication code needs to be modified.

A simpler approach to address the original request:

  • New table 'mantis_role_table' with fields: role_id, name, access_level
  • New table 'mantis_project_role_table' with fields: project_id, role_id, access_level
  • New table 'mantis_user_role_table' with fields: user_id, role_id
  • Change all access level lookups in code to include these tables as well
  • Use the highest access level found for that user and project

This is a relatively straightforward change that will provide big benefits to administrators and doesn't require migration of existing data to a new structure.

(0028101)
sveyret   
2011-01-27 03:28   

I stopped working on this feature after a very big code loss at a time I was still trying to make git working… :-(
I will have no time to restart this job for the moment.
There are Mantis developpers currently working to re-write Mantis using the Zend framework. As Zend framework has got an easy way to manage access controls, this will probably be a good occasion to include group management.

(0029464)
andy778   
2011-08-11 11:51   

What is the current plan with this?

(0029467)
cas   
2011-08-12 03:00   

Perhaps it will show up in a later version but so far there is little feedback on this. There are a few smaller patches around to group users and/or assiging sub tasks within one issue. if thos are usable for you, very much depends on your requirements

(0029470)
andy778   
2011-08-12 11:26   

We have over 300 mantis users and over 100 projects and the projects are private so what we would like is to add users to groups alias and groups should then be added under each project. Also ldap/AD authentication is needed. Sponsoring is also possible to arrange if needed.

(0032842)
cas   
2012-09-14 02:02   

Now creating a plugin that will allow users to be connected to multiple groups (which can be defined seperately).
My tasks plugin will allow to assign tasks to one of those groups. Each task can then be handled by anyone from that group. System will register which user in the end will complete the task.
Although not full group management, it will be enough for our purposes.

(0032872)
cas   
2012-09-19 01:45   

For those interested, the plugin is available and released together with an updated version of the Tasks plugin.
See:
http://www.mantisbt.org/bugs/view.php?id=14716

(0039801)
HeikoSL   
2014-04-01 04:37   

I have created another plugin for usergroups:
This plugin can be used to create groups of users in your mantis bugtracker. You may use nested groups and you can decide if groups can handle a bug. Notifications will be send to all group members.

The plugin creates one table that holds the groups with their members. But: To use this plugin you must edit some core functions!

See: https://github.com/langerheiko/ManageUsergroups

(0040114)
hincelin   
2014-04-17 08:42   

@ HeikoSL,
Thanks for this new plungin.
Can it be used with 1.2.17 ?
Sincerely

(0040132)
HeikoSL   
2014-04-22 07:57   

I am running it on 1.2.14, but I tested it with 1.2.17. It's working.

(0049366)
zhanghongquan   
2015-04-09 02:55   

Thank you
There is no Groups management,Please see the Screenshot

(0049367)
zhanghongquan   
2015-04-09 02:56   

sorry,my version is 1.2.18

(0060112)
titovetch   
2018-06-19 07:00   

it will be a huge great feature if this implementing

(0063984)
polzin   
2020-05-14 16:36   

With a large number of users and projects, this would definitely be a big improvement.
Any chance this gets implemented?
The attached plugin does not work any longer... :-/

(0063985)
cas   
2020-05-15 04:06   

@polzin, which plugin is not working?

(0063986)
polzin   
2020-05-15 05:05   

@cas, thanks for asking,

The one from @HeikoSL looked promissing, but is not compatible with Core 2.0.

I tried your plugins, but a) I did not find the documentation on your homepage, I did not understand if the usergroups for accessrights work without the tasks extension. b) when testing out I received 404 error when editing a group and did not find a way to add users to a group.

(0063988)
cas   
2020-05-15 05:55   

@polzin, my plugin works differently although can be used without the tasks module.
I do like the one from Heiko so have tried to reach him to see if he still supports this plugin.
If not, I will have a look to see if it can be easily transferred to 2.X
As for mine, there should be a readme available ( but I do not think it suits your purpose).

(0063989)
polzin   
2020-05-15 09:33   

@cas, can you post the link to your readme?
My purpose (as the one of this issue) is: Large number of users and projects, assign users to groups and assign access rights to groups. Can your plugin do this?

(0063990)
cas   
2020-05-15 09:57   

@polzin, my plugin does not allow to grant access rights to groups, is still userbased. Did get a reply from Heiko and he has no problem that I review his plugin for version2.x.

(0063991)
polzin   
2020-05-16 06:13   
(Last edited: 2020-05-16 06:13)

@cas, that would be great, thanks!

If there is anything I could help, please drop me a note.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22839 [mantisbt] authentication major N/A 2017-05-06 17:25 2020-05-15 19:53
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Deprecate MD5 login method and replace with BCRYPT hash
Description:

For many years, Mantis has been using MD5 as the default and "best" hashing algorithm to store users passwords in the database.

Since 2.x requires PHP 5.5.9, we can now use the password_hash() function, which relies on the modern and safe BCRYPT hashing algorithm for better security.

Tags:
Steps To Reproduce:
Additional Information:

This basically makes several old issues in the tracker that aimed at replacing MD5 by SHA1/SHA256 obsolete, including 0010172, 0011250 and possibly others as well.

Attached Files:
Notes
(0056785)
dregad   
2017-05-06 17:34   

PR https://github.com/mantisbt/mantisbt/pull/1048

(0061073)
hockeyfan   
2018-12-12 10:56   

We appreciate your efforts on this project, and understand that you haven't been able to integrate this patch into the project yet. We would like to know if there is something that we can do to encourage you to find time to fix this serious issue. How do you feel about a significant bounty here: https://www.bountysource.com/issues/56540151-deprecate-md5-login-method-and-replace-with-bcrypt-hash ?

We are willing to contribute $500 USD for a released fix by the end of 1Q 2019. We would also encourage others to contribute as well. If some other mechanism works better for you, please let us know.

(0061695)
rogueresearch   
2019-03-18 16:20   

I'd love to see this fixed too. Could contribute at least $100 USD also.

(0062264)
rogueresearch   
2019-06-17 19:00   

Seems this bug got some press today:

https://it.slashdot.org/story/19/06/17/182208/a-quarter-of-major-cmss-use-outdated-md5-as-the-default-password-hashing-scheme

https://www.zdnet.com/article/a-quarter-of-major-cmss-use-outdated-md5-as-the-default-password-hashing-scheme/



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24535 [mantisbt] authentication feature have not tried 2018-06-11 13:39 2020-05-15 11:41
Reporter: V1pr Platform:  
Assigned To: community OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Extend auth plugin support: enable autoprovision and add authenticator page support
Description:
  • authenticator page support (changes the form destination in login_password_page to plugin page)
  • user autoprovisioning support for CredentialsPage
  • SampleAuth plugin extension to make a better example
Tags:
Steps To Reproduce:
Additional Information:

PR https://github.com/mantisbt/mantisbt/pull/1333

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26961 [mantisbt] custom fields feature always 2020-05-15 05:18 2020-05-15 05:19
Reporter: hans peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: enable remove of custom field from multiple projects
Description:

haven't found an existing issue for this so:

we have a custom field linked to ~ 300 projects.
now i want to remove the link to ~ 200 projects, but keep the rest.
i'd have remove every single link, and accept the removal in next dialog.

my ideas:

  1. create an "remove from all projects" button
    simply add a button to e.g. bottom of list, so i can remove all links and re-link again to just the projects i need.

  2. enable possibility to "re-select" new link list
    instead of selecting links from the projects list and adding new links,
    replace the project links.
    e.g.
    i have ~ 300, so i select only the ~ 100 i want to keep, select "link custom field", and now only my ~ 100 projects are linked to the custom field.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063987)
hans peter   
2020-05-15 05:19   

if there is a simple way to accomplish my requirement with current version, please let me know.
but i haven't found yet.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26950 [mantisbt] installation minor always 2020-05-09 06:30 2020-05-14 08:49
Reporter: thomasjfox Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't verify gpg signature 2.24.1 release tarball
Description:

Thanks for providing gpg keys to check the signature of a mantis release.
For some unknown reason the gpg signature of mantisbt-2.24.1.tar.gz doesn't check out:

$ gpg2 --verify mantisbt-2.24.1.tar.gz.asc mantisbt-2.24.1.tar.gz
gpg: Signature made Sun 03 May 2020 10:29:05 AM CEST
gpg: using RSA key 5769AA4978E571A7BADB2A4DD4EAE2390A45E2D6
gpg: BAD signature from "keybase.io/vboctor <vboctor@keybase.io>" [ultimate]

Interestingly the signature for the ZIP archive is ok:

$ gpg2 --verify mantisbt-2.24.1.zip.asc mantisbt-2.24.1.zip
gpg: Signature made Sun 03 May 2020 10:29:06 AM CEST
gpg: using RSA key 5769AA4978E571A7BADB2A4DD4EAE2390A45E2D6
gpg: Good signature from "keybase.io/vboctor <vboctor@keybase.io>" [ultimate]

No content has been tampered with:
diff -u -r -p mantisbt-2.24.1.from-zip/ mantisbt-2.24.1.from-tar/

Checksums of the files:

$ shasum mantisbt*
f4ecf2ef8316e530bcfe501a0068110f28361b8d mantisbt-2.24.1.tar.gz
023988a9c8fe1602022a840d9feedee94230e323 mantisbt-2.24.1.tar.gz.asc
$ shasum -c mantisbt-2.24.1.tar.gz.digests
mantisbt-2.24.1.tar.gz: OK

I also tried if f.e. the signature was just for mantisbt-2.24.1.tar instead of mantisbt-2.24.1.tar.gz
or if the xx.digest file was signed by accident.

Can someone reproduce the issue?

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063965)
thomasjfox   
2020-05-09 06:32   

Related gpg key issue (I can't add related issues myself):
https://mantisbt.org/bugs/view.php?id=22269

(0063967)
dregad   
2020-05-11 04:00   

I confirm the problem with the bad signature for the tarball.

Our standard release publication process relies on a script to build the zip/tarballs, then generate the corresponding ASCII-armored signature files, so I really can't explain why one of them is valid while the other is not... Very strange. Maybe @vboctor signed the release manually, or errors occured during script execution, and he failed to notice.

Anyway he's the only one who can fix this.

(0063982)
jweberhofer   
2020-05-14 08:49   

Would be great, @vboctor if you could correctly sing the file!



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
23195 [mantisbt] bugtracker major have not tried 2017-08-07 11:56 2020-05-11 11:33
Reporter: mxit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clone Issue modifies notes modified date in history
Description:

Hello, in our company we are using quite often the feature to clone issues including their notes. Now we always struggle with the fact that notes are added to the cloned issue, but their timestamps in issue history is destroyed, because all notes get last modified from the moment when the issue is cloned. This is an issue because sometimes the order of adding notes is relevant. Is this working as designed, or is there a possible tweak to keep history timestamps for cloned issues?

kind regards,
Dieter Tontsch
mobileX AG

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0057450)
atrol   
2017-08-13 09:53   

Is this working as designed

I am not sure if it's designed, but that's the way it's implemented at the moment.

Cloning issues including notes looks always a bit strange, as the clone does not reflect the real workflow.
Wouldn't it look even more strange, if the dates of the notes are older than the issue?

(0063927)
mahindra   
2020-04-28 06:06   
(Last edited: 2020-04-28 06:08)

@atrol
In 0025792:0063919 I wrote

It is not enough to add the seconds based on the order and write them in the change references copied from the old ticket.

The reason is that the copied notes were written by other users before the new ticket was copied, cloned or so on.
Therefore, it is OK if the note date is before the new ticket, because it is from an older one!!!

The change history should include a note copied from ID-old and the author (copier) of the new ticket.

So everyone knows their way around.

The author and the date of entry of the note or attachment must not be lost.
"The copyright is at the time before the new ticket" - that's OK only in this case this case if the issue history shows the Copy from ID and URL.

(0063970)
mahindra   
2020-05-11 11:33   

If you copy an ID with Checkbox in view_all_bug_page.php - the timestamps are correct.
So please realize the same in the clone issue function.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25792 [mantisbt] bugtracker tweak always 2019-05-24 12:07 2020-05-11 11:33
Reporter: Ansgar Arbeiter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.20.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: in cloned issue the order of comments and pictures is not kept
Description:

in clone, the pictures are first, then the comments

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ClonedPictureOrder.png (217,646 bytes) 2019-05-24 12:07
https://mantisbt.org/bugs/file_download.php?file_id=8557&amp;type=bug
Notes
(0062158)
Ansgar Arbeiter   
2019-05-29 08:49   

suggestion (if not wanted to keep the original timestamps):
use time of cloning as start time and for each picture or comment increase one second.
then the order is kept (without any extra handling) and there are no dates from the past.
(regarding 0023195)

(0062164)
dregad   
2019-05-29 12:13   
(Last edited: 2019-05-29 12:13)

Keeping the original timestamps means that you would have bugnotes / attachments (hereafter: activities) that are older than the bug itself... That would be weird.

Your suggestion to bump the time +1s for each activity causes problems as well :

  1. Currently, attachments are linked to the bug itself, not to a bugnote (see 0021733); we just display them inline with the bugnotes for convenience, based on the file's timestamp (that's done by Activity API). Since they are handled differently within MantisBT core, there are two distinct processes to copy them (look at IssueAddCommand.php, around line 380). I guess we could rely on Activity API (used to display bugnotes in the correct order on bug view page) to refactor this code per your suggestion, but see point 2
  2. It implies that activities would be created with a timestamp in the future, which could result in a situation where a bugnote added shortly after the issue has been cloned, could appear in the middle of the cloned activities (this risk increases with the number of activities the master issue has)
(0062165)
Ansgar Arbeiter   
2019-05-29 12:36   
(Last edited: 2019-05-29 12:38)

bugnote added shortly after the issue has been cloned

that is correct but probably not the normal situation. if i have 20 comments and attachments, then i have to add new comments or attachments within 20 seconds after cloning to break the order.
(i personally first remove now unused comments and attachments in cloned issue first, before adding new)

one modification could be to have the clone timestamp as start time and go backward. go from last item to first and for each decrement one second.
(it will lead to item times before clone time, but i think the user can bring this little time range together in mind)

my suggestion was meant to have little effort to solve the problem.

if you want to make it proper then i would add an order index per attachment (would also offer to change the comment order after adding, the date can still be present)
or assign a comment ID also to attachments and then sort by date + comment ID (if dates are same, use ID).

(0063919)
mahindra   
2020-04-27 03:58   
(Last edited: 2020-04-28 05:57)

It is not enough to add the seconds based on the order and write them in the change references copied from the old ticket.

The reason is that the copied notes were written by other users before the new ticket was copied, cloned or so on.
Therefore, it is OK if the note date is before the new ticket, because it is from an older one!!!

The change history should include a note copied from ID-old and the author (copier) of the new ticket.

So everyone knows their way around.

(0063926)
mahindra   
2020-04-28 06:03   

@dregad - Best procedure inserted above - the author and the date of entry of the note or attachment must not be lost.
"The copyright is at the time before the new ticket" - that's OK only in this case this case if the issue history shows the Copy from ID and URL.

(0063969)
mahindra   
2020-05-11 11:33   

If you copy an ID with Checkbox in view_all_bug_page.php - the timestamps are correct.
So please realize the same in the clone issue function.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26447 [mantisbt] filters feature N/A 2019-12-09 10:16 2020-05-11 09:03
Reporter: polzin Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Enhancement of free text filter function: Search for custom fields, summary-only, id-only and mixing AND and OR.
Description:

Attached is a patch for improved free text filter function.

Examples:
i:123 OR s:summary c:custom s:"test test" "jo jo"

i:123 searches only for the bug id (useful if you have a list of IDs and create a search link with 'xargs -n 1 printf "i:%s OR "')
c:text searches only the custom fields
s:text searches only the summary (faster and more focussed results).
OR allows mixing AND and OR in one query

Necessary improvements for incorporation:

  • end-user documentation
  • possible extension to AND
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: filter_patch.txt (4,578 bytes) 2019-12-09 10:16
https://mantisbt.org/bugs/file_download.php?file_id=8893&amp;type=bug
564564564.jpg (99,255 bytes) 2019-12-10 06:21
https://mantisbt.org/bugs/file_download.php?file_id=8897&amp;type=bug
Notes
(0063215)
dregad   
2019-12-09 10:53   

@polzin thanks for your contribution

Would you mind submitting your patch as a pull request on Github, to make it easier to test and review ?

(0063221)
polzin   
2019-12-09 17:15   
(Last edited: 2019-12-15 06:01)

Pull request see https://github.com/mantisbt/mantisbt/pull/1597 (updated)

(0063227)
dregad   
2019-12-10 05:29   

Thanks !
Are you planning to develop and provide the "necessary improvements" described in the above description ?

(0063231)
emil-tsl   
2019-12-10 06:21   

Work for me. Tested on 2.22.1

Do you mind if I add a suggestion?
Drop-down Search button where you can choose what I want to search for.

(0063237)
polzin   
2019-12-10 07:39   

@dregad Do you have a suggestion, how to implement the end-user documentation? The placeholder has probably not enough space for a syntax description. The tooltip describing the syntax would be an easy addition. If that's wanted, I can do it.

For the other improvement "possible extension to AND" , I checked the code and noticed that it was a mistake to think there is something missing. AND is the default, therefore no further extension is necessary.

I would not use a drop-down, as suggested for @emil-tsl, because this is a different gui concept.

(0063241)
atrol   
2019-12-10 09:16   

I don't have time for a deeper look, but please consider my warning 0007183:0059789 and the discussion around previous PRs
https://github.com/mantisbt/mantisbt/pull/1168
https://github.com/mantisbt/mantisbt/pull/1140

Especially the following comment concerning performance and security
https://github.com/mantisbt/mantisbt/pull/1140#issuecomment-320712837

(0063266)
emil-tsl   
2019-12-13 05:00   

@polzin
How to do it so that using the prefix c: I would not only search for custom fields but everything (I mean topic title, description + custom fields). I need it so much.

(0063269)
polzin   
2019-12-13 06:44   

@emil-tsl You could do this using "c:TEST OR TEST"

(0063270)
polzin   
2019-12-13 06:49   

@atrol As the default behaviour is not changed, the performance is not an issue. In fact, for big repositories it is a relevant performance advantage to use "s:XXX" for a search only in the summary.

(0063282)
polzin   
2019-12-15 06:04   

I updated to pull request, so that it contains only one commit and changed the author.email.
https://github.com/mantisbt/mantisbt/pull/1597

(0063283)
atrol   
2019-12-15 07:29   

@atrol As the default behaviour is not changed, the performance is not an issue.

Yes concerning existing functionality.
No concerning new functionality, as it allows users to stress your database server in a quite easy way. But I think this is acceptable

There is still the security aspect I mentioned in the old PR

Independant from that, there is a serious conceptual issue.
After the changes, you are able to search based on data where you are not allowed to view the data.

E.g. set Read Access of a custom field to access level manager.
Log in as a developer and search by text.
You will see issues in the list where you are not allowed to see the custom field.

(0063291)
polzin   
2019-12-17 16:54   

@atrol Thanks for the feedback.

The security problem is fixed and tested with a user being able to see the issue, but not the custom field.

The performance is still okay in a setting with > 60000 issues and > 50 custom fields (where > 15 string custom fields are searched):
Search for a word in all issues without prefix (current search) : approx. 8 second
Search for a custom field ("c:"): approx. 4 second
Search for a summary ("s:"): approx. 0.1 second

(0063294)
cproensa   
2019-12-17 18:10   

As the default behaviour is not changed, the performance is not an issue. In fact, for big repositories it is a relevant performance advantage to use "s:XXX" for a search only in the summary.

I think performance may be relevant
For each custom field that need to be filtered, a new join for custom-fields-table is added. The complexity of each of those joins (which accounts for project specific permissions) has not changed. However, previously we only added those joins when a field is explicitly filtered.
With your proposal, the default behaviour is to search in all available custom fields, so we have N complex joins always added for a text search... Unless the user explicitly uses the s:, etc, modifiers, which is not very user friendly for plain users.

(0063295)
cproensa   
2019-12-17 18:20   
(Last edited: 2019-12-17 18:21)

Previously, when this topic has been discussed, the proposals are inthe line of:

  • add some kind of flags or checkboxes where the user can choose whether the search will look in one or several targets: summary, description, notes, custom fields, etc.

your proposal has the potential to do more complex searches, like selectively target different terms in each target: "s:something OR c:otherthing" right?
At the expense of a more complex parsing of the search query.
We need to make sure we want that complexity, as we would need to live with that and support it for the future.

With your scheme, should we have a mapping of the old searches (eg, stored filters), so that the old search for somethingbecomes s:something?
Otherwise the behaviour of pre-existing filters may change.

(0063296)
polzin   
2019-12-17 19:17   
(Last edited: 2019-12-17 19:21)

@cproensa: I am not sure if there is a misunderstanding: The current behaviour is not changed (if not a "[sci]:" or "OR" is used). If a user or a stored filter looked for something, it will now find the same results, with the same joins and the same search performance.

By the way: Compared to the checkboxes, one very usefull sideeffect for power users is: You can use this browser shortcuts/keywords, such that CTRL-L + mantis s:something brings you in fast pace to relevant search result.

(0063297)
cproensa   
2019-12-17 19:42   

ok, sorry, i thought that this searches within custom fields (along all other contexts) by default.

so, would it make more sense for this to include custom fields by default?
Would your current definition have the following behaviour?
For a given text "XXX" in the summary:

  • search for "XXX": found
  • search for "s:XXX": found
    But given text "CCC" in custom field:
  • search for "CCC": not found
  • search for "c:CCC": found
(0063298)
polzin   
2019-12-17 20:12   

@cproensa: Add custom filters by default would bring you: perfomance drops, changes of existing filters, more complex sql by default, all those things you probably don't want to have. :-)

(0063520)
polzin   
2020-01-27 13:36   

@atrol, @cproensa, @dregad: see 0026447:0063291, I think all security and performance issues are addressed now. How do we proceed?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26951 [mantisbt] filters feature always 2020-05-09 18:23 2020-05-09 20:38
Reporter: K0media Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sort/Filter by number of comments on issues page
Description:

I see that there are filters to sort by Status, Priority, Updated, etc.

What about sorting by number of comments for each issue?

I'm surprised that nobody asked this so far. If someone did, I tried to find, but nothing related shower up.

What do you say?

Tags:
Steps To Reproduce:
  1. Access Issues page;
  2. Scroll down page to see the filters and sort options
  3. Click to filter/sort by number of comments in an issue (either the small balloon - #bugnotes) or filters that can be set up above.
Additional Information:

Sorting by descending/ascending order would also be nice.

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12422 [mantisbt] filters feature have not tried 2010-10-04 02:56 2020-05-09 20:37
Reporter: petertc Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.2.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Patch: sort by bugnotes count
Description:

This patch add ability to sort issues by bugnotes count in View Issues page.

Attach is my patch in git format, Thank you for your review.

Tags:

patch

Steps To Reproduce:
Additional Information:
Attached Files: feature_branch.patch2 (5,263 bytes) 2010-10-04 02:56
https://mantisbt.org/bugs/file_download.php?file_id=3054&amp;type=bug
Notes
(0026942)
jreese   
2010-10-04 09:33   

I'll look into merging this into the 1.3.x development branch.

(0027124)
dhx   
2010-10-22 07:40   

Thanks for the patch Peter, you've identified a good improvement to be made!

@jreese: need a hand reviewing this one? You know more than me about filter_api but if you're busy I can give it a shot.

(0027137)
jreese   
2010-10-22 12:37   

If you want to take a look, go ahead. :)

(0031332)
grangeway   
2012-02-26 16:31   

Fixed

(0031463)
atrol   
2012-03-14 18:12   

Reopened, the issue is not fixed in master-1.2x or master branch at the official repository.
There is no patch / changeset attached which will confuse any user who has a look at this issue.

(0031497)
blue1   
2012-03-20 06:05   

will be fixed in next build

(0033289)
grangeway   
2012-10-20 19:59   

this is fixed in the mantis-2.x branch

(0036222)
grangeway   
2013-04-05 17:56   

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26933 [mantisbt] plug-ins minor always 2020-05-03 11:43 2020-05-03 12:12
Reporter: NINI1988 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugins are not able to validate custom_fields
Description:

Plugins are not able to validate custom_fields values at EVENT_REPORT_BUG_DATA.
Only BugData is passed in this event.
This also applies to EVENT_UPDATE_BUG_DATA.

I want to implement a plugin which validates a custom_field for unique values in that column.
So the plugin is not able to validate this value.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26932 [mantisbt] ui feature N/A 2020-05-03 05:23 2020-05-03 05:23
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.24.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Integrate React and Typescript
Description:

Add support for leveraging React, Typescript, and JSX to enhance the UI.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26931 [mantisbt] api rest feature N/A 2020-05-02 23:50 2020-05-02 23:55
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: REST API support for returning diagnostics headers for db queries
Description:

To help with understanding the queries executed as part of running an API, enable returning the following headers:

  • X-Mantis-QueriesCount - always include when show_queries_count is enabled.
  • X-Mantis-Queries - show when show_queries_count is enabled, log_level includes LOG_DATABASE, and current user is administrator.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063947)
vboctor   
2020-05-02 23:55   

PR: https://github.com/mantisbt/mantisbt/pull/1666



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26903 [mantisbt] code cleanup feature N/A 2020-04-21 16:59 2020-05-02 15:24
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Move release scripts to main repository
Description:

Move release packaging scripts from mantisbt-tools to mantisbt main repository. This is useful in the following ways:

  1. It makes it easy to co-commit changes to MantisBT with changes to package it.
  2. The command line to create a release package remains consistent, while the implementation can be different based on the branch.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063885)
vboctor   
2020-04-21 17:01   

PR: https://github.com/mantisbt/mantisbt/pull/1661



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26888 [mantisbt] code cleanup tweak N/A 2020-04-18 05:52 2020-05-02 15:13
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Refactor printing of project selection menus
Description:

While working on fixing 0026887, I realized that the code to display the project name and link to set_project.php in the project selection menu (layout_navbar_projects_menu()) and the project menu bar print_project_menu_bar() is very similar, and repeated several times (as we need to handle the ALL_PROJECTS and subprojects cases).

It would make sense to move the logic to a dedicated function to reduce code duplication.

Tags:
Steps To Reproduce:
Additional Information:

This was inspired by the analysis for 0026886:0063843.

Attached Files:
Notes
(0063846)
dregad   
2020-04-18 07:01   

PR https://github.com/mantisbt/mantisbt/pull/1654



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26887 [mantisbt] sub-projects tweak always 2020-04-18 05:23 2020-05-02 15:13
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Project Menu Bar does not indent subprojects properly
Description:

While analyzing 0026886, I noticed that when there is more than one level of subproject, the Project Menu Bar always displays the subprojects with a single » instead of properly "indenting" them with as number of » characters equal to the subprojects' level in the hierarchy.

Tags:
Steps To Reproduce:

Given the following project hierarchy

Subprojects tests
» sub-1
» » sub-1.1
» sub-2

Set $g_show_project_menu_bar = ON; in config_inc.php and display any page, project menu bar is shown as per attached screenshot (notice the single » for level 2 subproject sub-1.1).

Additional Information:
Attached Files: image.png (3,238 bytes) 2020-04-18 05:23
https://mantisbt.org/bugs/file_download.php?file_id=9061&amp;type=bug
Notes
(0063847)
dregad   
2020-04-18 07:01   

PR https://github.com/mantisbt/mantisbt/pull/1654

(0063939)
thE_iNviNciblE   
2020-04-30 04:03   

is a nice option.

Ist it possible to disable some projekts ?

i see to many no more needed projects.

would also be quite nice if the Nav-Projekt-Menue also only shows active projects



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26930 [mantisbt] code cleanup tweak N/A 2020-05-02 12:12 2020-05-02 12:41
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Use user_is_login_request_allowed() instead of duplicating the logic
Description:

manage_user_edit_page.php doesn't use existing API function user_is_login_request_allowed() to check whether the user's account is locked, and duplicates the logic.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26884 [mantisbt] administration minor always 2020-04-15 18:34 2020-05-02 12:14
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Misleading e-mail notification following password reset by admin
Description:

When a user's password is reset by an administrator - either via manage_user_reset.php page, or with REST API (since 0026632), they are sent the following notification by e-mail:

Someone (presumably you) requested a password change through e-mail
verification. If this was not you, ignore this message and nothing will happen.

If you requested this verification, visit the following URL to change your
password:

http://example.com/mantis/verify.php?id=USER_ID&amp;confirm_hash=HASH

Username: USERNAME
Remote IP address: xxx.xxx.xxx.xxx

Do not reply to this message

That message only makes sense when using the Lost password functionality. In the context of a password reset by an admin, it is misleading, for the following reasons

  1. Saying ignore this message and nothing will happen is wrong - the password reset command (UserResetPasswordCommand) calls user_reset_password(), which actually generates and stores a new random password, before sending the notification (via email_send_confirm_hash_url() function), so the user effectively cannot login with their previous password anymore, and must reset it with the given link.
  2. Considering that resetting a user's password requires a privileged account having manage_user_threshold , the statements Someone (presumably you) requested a password change and If you requested this verification are most likely incorrect, because the administrator is unlikely to use the reset password feature for their own account.

A specific notification text should be used for the password reset by admin case.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063850)
dregad   
2020-04-18 07:16   

PR https://github.com/mantisbt/mantisbt/pull/1656



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26929 [mantisbt] api rest feature N/A 2020-05-02 11:27 2020-05-02 11:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Support user account unlock via REST API
Description:

Following introduction of UserResetPassword Command in 0026632, and the subsequent discussion in PR https://github.com/mantisbt/mantisbt/pull/1655 it was decided that a separate Command and REST API endpoint to unlock a user's account was necessary to provide the ability for the client to request one operation or the other, without having to second-guess what the API would do based on the account's status and the system's configuration.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26840 [mantisbt] preferences minor always 2020-04-01 15:00 2020-04-29 17:01
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Non existing field name os_version used where os_build should be used
Description:

There are some places in source code where os_version is used as a field name.

The name is finally defined in class BugData

    protected $os_build = '';

and is sometimes deliveresd by

function columns_get_standard( $p_enabled_columns_only = true ) {
    $t_reflection = new ReflectionClass( 'BugData' );

but also sometimes as hardcoded strings in arrays.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063813)
atrol   
2020-04-01 15:24   
(Last edited: 2020-04-01 15:25)

As there would be conflicts with current master, and as this is not a regression, I decided to fix it in 2.25.0 but not 2.24.1.
I will provide a PR for master / 2.25.0 after 0026838 is merged to master-2.24 and master.

(0063824)
atrol   
2020-04-03 11:42   

PR https://github.com/mantisbt/mantisbt/pull/1646

(0063922)
polzin   
2020-04-28 04:32   

@atrol Are you sure? See my note in https://mantisbt.org/bugs/view.php?id=26838#c63921

(0063931)
atrol   
2020-04-29 15:07   

@polzin not sure if you read the discussion in the PR.

(0063934)
polzin   
2020-04-29 17:01   

@atrol, thanks for pointing me to the discussion in the PR. My point was that there are more examples, where the $t_issue[] name and the $t_flags[] name differ ( product_version/version, product_build/build, I guess thats all) and that the config names should not differ from the GUI. But if you thought about it, and find it better to harmoize the names in a different way, than I guess everything is okay.
Thanks for your work!



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26892 [mantisbt] administration feature N/A 2020-04-19 13:58 2020-04-26 04:55
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Attachment settings not available on "Workflow Thresholds" page
Description:

Attachment configuration options can't be set using UI on "Workflows Thresholds" page.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063855)
atrol   
2020-04-19 14:04   

PR https://github.com/mantisbt/mantisbt/pull/1658



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26891 [mantisbt] api rest minor always 2020-04-18 16:13 2020-04-26 00:00
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: /config REST API endpoint reports users as not found when they exist
Description:

The error is in the code below (api/rest/restcore/config_rest.php) :

if( $t_user_id != ALL_USERS && user_exists( $t_user_id ) ) {
    return $p_response->withStatus( HTTP_STATUS_NOT_FOUND, &quot;User with id '$t_user_id' not found&quot; );
}

Note that there is a missing ! before the user exists check.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063852)
vboctor   
2020-04-18 16:37   

PR: https://github.com/mantisbt/mantisbt/pull/1657



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26890 [mantisbt] code cleanup minor N/A 2020-04-18 16:10 2020-04-26 00:00
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Implement LocalizedStringsGetCommand and use from REST API
Description:

Refactor the implementation of the REST API into a command.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063854)
vboctor   
2020-04-18 16:37   

PR: https://github.com/mantisbt/mantisbt/pull/1657



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26889 [mantisbt] code cleanup minor N/A 2020-04-18 16:09 2020-04-26 00:00
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Implement ConfigsGetCommand and use from REST API
Description:

Implement the ConfigsGetCommand and refactor REST API to use it.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063853)
vboctor   
2020-04-18 16:37   

PR: https://github.com/mantisbt/mantisbt/pull/1657



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8986 [mantisbt] email feature always 2008-03-19 18:06 2020-04-24 10:41
Reporter: thE_iNviNciblE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: customized eMail subjects
Description:

customized eMail subjects

i can't find any option in the default_config.php

Now it's like this:
"[Main Project - Category 0000202]: Title Name"

it would be very cool if you can customize it like this

  • "[Main Project - Category 0000202]: ~Opened ~ Title Name"
  • "[Main Project - Category 0000202]: ~Closed ~ Title Name"

$eMailSubject = [###PROJECT### - ###CATEGORY### - ###BUGID###]: ~###STATUS###~ ###TITLENAME###

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: CustomizeEmailSubject.zip (8,639 bytes) 2014-01-11 11:59
https://mantisbt.org/bugs/file_download.php?file_id=4882&amp;type=bug
2019-04-13 07_30_51-Plugins verwalten - Projektverwaltung maiwell.png (11,515 bytes) 2019-04-13 01:32
https://mantisbt.org/bugs/file_download.php?file_id=8509&amp;type=bug
2019-04-13 07_43_08-Plugins verwalten - Projektverwaltung maiwell.png (8,150 bytes) 2019-04-13 01:44
https://mantisbt.org/bugs/file_download.php?file_id=8510&amp;type=bug
Notes
(0026840)
M.C.S.   
2010-09-22 08:10   

I would appreciate this kind of customization, too. It would help to sort incoming notification emails by (for example) the ticket priority.

(0028763)
anstifan   
2011-05-09 06:02   

It would be useful also for my team. we'd need to have the "status" and the "assigned to" in the subject in order to quickly understand the priority of the mail.

(0029487)
zdroyer   
2011-08-16 07:38   

look here: http://www.mantisbt.org/bugs/view.php?id=12830
It is not exactly you need, but you can customize it or wait a bit - maybe someone will develop this template

(can some developer create a relationship between this and 12830 issue?)

(0036627)
stojex   
2013-04-18 10:16   

Hey,
You can edit file core/email_api.php in function email_bug_info_to_one_user()

Add line:
$t_status_NEW = $p_visible_bug_data['email_status']; //New variable

Edit variable $t_subject
$t_subject = '[' . $p_visible_bug_data['email_project'] . ' ' . bug_format_id( $p_visible_bug_data['email_bug'] ) .']: ~'. get_enum_element( 'status', $t_status_NEW ) . ' [' . $p_visible_bug_data['email_handler'] . '] ~'. $p_visible_bug_data['email_summary'] . ;

(0039017)
Yvotetac   
2014-01-11 12:17   

Hello,

I modified the plugin "CustumizeEmailSubject" Mantis BT for 1.2.15.

Changes are:

  • Upgrade Version 0.1.2 to 0.1.3.
  • French Language for the Plugin
  • Language support in "Manage Plugins"
  • Fixed display bug in "Settings for Customized Email Subject / Subject Email Template" => <? echo plugin_config_get('email_subject_template', '') ?>
  • Fixed bug "/ / plugin_lang_get is not working in hook functions" in "CustomizeEmailSubject.php"

Good day: o)

NB: Both patches are always necessary.

(0039018)
atrol   
2014-01-11 14:37   

Yvotetac,
this is the right place to make changes of this plugin
https://github.com/mantisbt-plugins/CustomizeEmailSubject

(0055363)
thE_iNviNciblE   
2017-01-27 02:54   

very nice :-)

(0057587)
yfedorina   
2017-09-01 05:18   

Hi!

Did someone test this plugin on 2.5 version?

(0061752)
thE_iNviNciblE   
2019-03-23 14:21   

is it feature 2.1.x in the core?

(0061916)
thE_iNviNciblE   
2019-04-13 01:32   

@atrol: the github download isn't working with 2.x

(0061917)
thE_iNviNciblE   
2019-04-13 01:41   

@Yvotetac: Also nice...

https://github.com/mantisbt-plugins/EmailReporting

http://www.mantisbt.org/wiki/doku.php/mantisbt:plugins:emailreporting

(0061918)
thE_iNviNciblE   
2019-04-13 01:44   
(Last edited: 2019-04-13 01:44)

i can't install "Email Reporting" under actual release of mantis 2.2.0, nothing is happen, also no crash.

(0061920)
atrol   
2019-04-13 05:58   

@atrol: the github download isn't working with 2.x
i can't install "Email Reporting" under actual release of mantis 2.2.0, nothing is happen, also no crash.

This is not the right place to deal with those issues.

Please use
https://github.com/mantisbt-plugins/CustomizeEmailSubject/issues
https://mantisbt.org/forums/viewforum.php?f=13

(0063834)
maturbet   
2020-04-10 05:10   

PR : https://github.com/mantisbt-plugins/CustomizeEmailSubject/pull/6



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26907 [mantisbt] feature minor have not tried 2020-04-23 03:15 2020-04-23 05:06
Reporter: sadovsf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add Version author
Description:

It would be nice to see who created version similar way as you see it in case of bugs. Maybe even history although that is not that common.

We just did run into situation that someone created really badly described version and its not possible to find out who to educate him for the future.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063900)
dregad   
2020-04-23 05:06   

I can think of 2 ways to approach this

  1. add a created / last modified by field in the version table
  2. implement a proper, global audit trail similar to issue history

The first option is probably simpler overall if we limit it to versions, but it would make sense to generalize it to other entities as well (projects, users, etc) in that case it could become painful to maintain. Second option is more generic, but is more complex to implement initially.

In any case, not something that is likely to happen any time soon without a community contribution.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26908 [mantisbt] filters minor always 2020-04-23 03:37 2020-04-23 03:59
Reporter: jacekwww Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Not all users are available in the filter
Description:

Hello,

Unfortunately my English is not that good, I write the text in German. Thanks for your understanding.

Problem:
ich habe das Problem in der MantisBT 1.21.1 erstmals entdeckt, in der Version 2.24.0 tritt es ebenfalls auf.

Die Auswahl „Assigned To“ zeigt nicht alle Benutzer an (vgl. Screenshot)

Aus dem MySQL-log geht hervor, dass das Ergebnis folgender Anfrage:

„SELECT DISTINCT p.id, ph.parent_id, p.inherit_global, ph.inherit_parent
                  FROM mantis_project_table p
                  LEFT JOIN mantis_project_hierarchy_table ph
                    ON ph.child_id = p.id
                  WHERE p.enabled = '1'“

+-----+-----------+----------------+----------------+
| id  | parent_id | inherit_global | inherit_parent |
+-----+-----------+----------------+----------------+
{...}
| 170 |       111 |              0 |              0 |
| 171 |      NULL |              0 |           NULL |
| 173 |      NULL |              0 |           NULL |
| 185 |       119 |              0 |              0 |
| 185 |       592 |              0 |              1 |
| 187 |       119 |              0 |              0 |
| 187 |       592 |              0 |              1 |
{...}
| 988 |      NULL |              1 |           NULL |
| 989 |      NULL |              1 |           NULL |
| 990 |       929 |              1 |              1 |
| 992 |      NULL |              1 |           NULL |
| 993 |      NULL |              1 |           NULL |
| 994 |       187 |              1 |              1 |
| 995 |       187 |              0 |              0 |
| 996 |       929 |              1 |              1 |
+-----+-----------+----------------+----------------+
586 rows in set (0.001 sec)

viel mehr Projekte anzeigt, als später abgefragt werden:
(hier wird das Projekt 173 und danach 189 abgefragt, alles da zwischen wird übersprungen)

            44 Query    SELECT u.id, u.username, u.realname, l.access_level
                FROM mantis_project_user_list_table l, mantis_user_table u
                WHERE l.user_id = u.id
                AND u.enabled = 1
                AND l.project_id = 173
            44 Query    SELECT * FROM mantis_project_table WHERE id=189
            44 Query    SELECT id, username, realname, access_level
                FROM mantis_user_table
                WHERE enabled = 1
                    AND access_level >= 90
            44 Query    SELECT u.id, u.username, u.realname, l.access_level
                FROM mantis_project_user_list_table l, mantis_user_table u
                WHERE l.user_id = u.id
                AND u.enabled = 1
                AND l.project_id = 189
SELECT u.id, u.username, u.realname, l.access_level
                FROM mantis_project_user_list_table l, mantis_user_table u
                WHERE l.user_id = u.id
                AND u.enabled = 1
                AND l.project_id = 1
{…}

und so weiter (vgl. Anhang log.txt)

Hier die Daten von einem betroffenen User (ID = 5635)

select * from mantis_project_user_list_table where user_id = 5635;
+------------+---------+--------------+
| project_id | user_id | access_level |
+------------+---------+--------------+
|        185 |    5635 |           60 |
|        199 |    5635 |           60 |
|        330 |    5635 |           60 |
|        731 |    5635 |           25 |
|        931 |    5635 |           60 |
|        969 |    5635 |           60 |
|        990 |    5635 |           60 |
+------------+---------+--------------+
7 rows in set (0.001 sec)

Demanch sollte der User 5635 in der Auswahl stehen, da er auch im Projekt 185 drin ist und auch zugewiesene Ticket hat:

 select project_id, handler_id, status from mantis_bug_table where handler_id = 5635;
+------------+------------+--------+
| project_id | handler_id | status |
+------------+------------+--------+
|        185 |       5635 |     50 |
|        185 |       5635 |     50 |
+------------+------------+--------+
2 rows in set (0.469 sec)

Detailliertes MYSQL-Logfile aus dem Aufruf von

curl -q -k -b mantis.cookies -c mantis.cookies  &quot;${host}/return_dynamic_filters.php?filter_target=handler_id_filter&filter_id=18537&_=1587366232945&quot;

lege ich im Anhang bei.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Auswahl_112.png (29,311 bytes) 2020-04-23 03:37
https://mantisbt.org/bugs/file_download.php?file_id=9068&amp;type=bug
log.txt (72,054 bytes) 2020-04-23 03:37
https://mantisbt.org/bugs/file_download.php?file_id=9069&amp;type=bug
select.txt (7,965 bytes) 2020-04-23 03:58
https://mantisbt.org/bugs/file_download.php?file_id=9070&amp;type=bug
Notes
(0063897)
jacekwww   
2020-04-23 03:58   
(Last edited: 2020-04-23 03:59)

Output attached from:

SELECT DISTINCT p.id, ph.parent_id, p.inherit_global, ph.inherit_parent
                  FROM mantis_project_table p
                  LEFT JOIN mantis_project_hierarchy_table ph
                    ON ph.child_id = p.id
                  WHERE p.enabled = '1'


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22323 [mantisbt] feature major always 2017-02-06 09:37 2020-04-21 23:08
Reporter: aavagyan Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing whole "Attached Files" section
Description:

With all the great improvements in new MantisBT 2.x, me and my users (piloting new version with selected users) are confused about not finding "Attached Files" section, as well as central "Upload file" box (only under the 'add note' - something we have disabled in MantisBT 1.2.x). We use MantisBT more like case management system - and we use attachments extensively. People opening the case would like to see the case with all the supporting attachments. Now attachments are mixed-up with notes. It means that one needs to travel over all notes to collect attachments!? Some of our tickets have up to 200 notes and dozens of attachments. With new setup these cases are basically unmanageable - only 'small' tickets are more-or-less OK - while still not convenient.

Can we have config option to re-enable display of attachments displayed in the old way - grouped together and not scattered in "Activity" messed-up with notes?

Thank you,
Avetis

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: AttachedFiles.JPG (88,216 bytes) 2017-02-17 10:35
https://mantisbt.org/bugs/file_download.php?file_id=7204&amp;type=bug
image.png (177,084 bytes) 2019-08-26 10:52
https://mantisbt.org/bugs/file_download.php?file_id=8675&amp;type=bug
image-2.png (39,586 bytes) 2019-08-30 05:58
https://mantisbt.org/bugs/file_download.php?file_id=8682&amp;type=bug
Notes
(0055518)
cas   
2017-02-07 03:25   
(Last edited: 2017-02-22 13:07)

In case you need this functionality, do the following:
add in config_inc.php, the following line:

$g_show_attachments     =   ON;

This makes it configurable, not absolutely neeeded but good practice,
Now open up bug_view_inc.php and goto line 727.
This is right after this section:

if( $t_custom_fields_found ) {
    # spacer
    echo '&lt;tr class=&quot;spacer&quot;>&lt;td colspan=&quot;6&quot;>&lt;/td>&lt;/tr>';
    echo '&lt;tr class=&quot;hidden&quot;>&lt;/tr>';
}

Just behind this section, add the following code:

# Attachments
if ( ON == config_get('show_attachments') ) {
    echo '&lt;tr ', helper_alternate_class(), '>';
    echo '&lt;td class=&quot;category&quot;>&lt;a name=&quot;attachments&quot; id=&quot;attachments&quot; />', lang_get( 'attached_files' ), '&lt;/td>';
    echo '&lt;td colspan=&quot;5&quot;>';
    print_bug_attachments_list( $t_bug_id, null);
    echo '&lt;/td>&lt;/tr>';
} 

Here you are, your list is back in the main screen.

(0055519)
cas   
2017-02-07 03:27   

This way it looks a bit funny because of the HTML thing.
In reality both the words 'spacer' and 'attachments' are prefixed with a '#' sign

(0055520)
cas   
2017-02-07 03:34   
(Last edited: 2017-02-07 05:32)

Changed 2 more lines to be in line with new lay-out, so it should read:

if ( ON == config_get('show_attachments') ) {
    echo '&lt;tr ', helper_alternate_class(), '>';
    echo '&lt;th class=&quot;bug-attachments category&quot;>', lang_get( 'attached_files' ), '&lt;/th>';
    echo '&lt;td class=&quot;bug-attachments&quot; colspan=&quot;5&quot;>';
    print_bug_attachments_list( $t_bug_id, null);
    echo '&lt;/td>&lt;/tr>';
}
(0055521)
aavagyan   
2017-02-07 05:20   

Thanks a lot! Works nicely.

Users can possibly use file attach under the 'add note' - doesn't seem to be a big problem. The only missing thing is date next to the attached file, but I looked into functions - it is removed in version 2.x so 'hack' needs to be deeper. My users would possible agree to live without date displayed in this box.

Can these changes be made part of next release?

(0055523)
dregad   
2017-02-07 05:39   

@cas I edited your notes to add the markdown formatting so the code is displayed raw.

It was the decision of @vboctor to handle attachments upload and display at note level moving forward, so I let him comment on the eventuality of adding back the notion of "issue-level" attachments.

I have to say that I personally do not like the fact that a document uploaded as part of an issue's initial report appears as a separate bug note; this is made worse by the fact that I like to have notes sorted reverse (most recent first), so the initial attachments appear last.

It's worth mentioning that the current data model would not allow us to differentiate a note vs an issue attachment (currently this is an arbitrary link is based on the upload timestamp).

(0055527)
cas   
2017-02-07 06:37   

@aavagyan, it makes sense that the date is taken away since that is visible within the note. Can be added but most likely then also will show up within the note which is not desirable.
@dregad, would agree with you, that is why I dived into this since I have the same wish. Not being able to distinguish between note vs issue attachment does not bother me too much. It is still visible within the notes.
@vboctor, I do understand where you are coming from, that is why I made the switch. Why not incorporate with default switch set to OFF? Saves us from hacking each version and more people happy (overal this version 2 is a step in the right direction anyway).

(0055528)
aavagyan   
2017-02-07 06:44   

I strongly believe that "ticket" or "issue" or "case" (no matter what is the term used) needs to have the main information, with supporting documentation (files) as "core" informational unit, whereas notes and the rest (e.g. change-sets, time-tracking info, issue log, etc.), can be appended to it as needed. It looks like it can be achieved more or less easily by displaying "File attachments" block. Config option would be even better to satisfy different needs, e.g.:

  • option 1: show attachments only centrally (don't know if central 'upload' is needed or "upload-in-note" is OK);
  • option 2: show attachment centrally, but also as "activity" item;
  • option 3: show attachments only as "activity" item.

Wikipedia:
"Mantis Bug Tracker is a free and open source, web-based bug tracking system. The most common use of MantisBT is to track software defects. However, MantisBT is often configured by users to serve as a more generic issue tracking system and project management tool."

I think that change is especially needed if we would like to keep last sentence valid.

(0055610)
dnewman   
2017-02-09 05:11   

This is something that my department would also like to see reinstated. I agree with @aavagyan that for use as a project management tool having all attachments collated within one area is immensely useful.

When uploading items such as: functional or business requirements, this could prove quite costly if they were missed. This is more likely to occur if they are 'hidden' away within the notes/activities section.

A configuration option would be ideal.

(0055611)
dnewman   
2017-02-09 05:13   

@cas I will test out those options on a test build of Mantis. Thank you for the effort.

(0055643)
aavagyan   
2017-02-10 10:51   

Discovered small glitch with this fix. Opening inline (+ sign) shows image in the top-block and not showing it in 'activity' block...

(0055718)
udaymantis   
2017-02-17 10:35   

The fix provided above works great, except that the details are coming on multiple lines as shown in the attachment here. Is there a way to make the details come on one line?

(0055748)
cas   
2017-02-22 12:46   

Just change this line:
echo '<td class="bug-attachments" colspan="5">';
into:
echo '<td class="bug-attachments" colspan="7">';

Should do the trick!

(0055749)
dregad   
2017-02-22 13:11   

in 0022323:0055518

echo '<tr ', helper_alternate_class(), '>';

Please note that helper_alternate_class() function is deprecated and will be removed in a future version of MantisBT

(0055767)
cas   
2017-02-23 11:07   
(Last edited: 2017-02-23 12:22)

In order to be future compliant, I think that the line:
echo '<tr ', helper_alternate_class(), '>';
should read:
echo '<tr class="bug-attachments">';
So, the correct adjustment would be:

# Attachments
if ( ON == config_get('show_attachments') ) {
   echo '&lt;tr class=&quot;bug-attachments&quot;>';
    echo '&lt;td class=&quot;category&quot;>&lt;a name=&quot;attachments&quot; id=&quot;attachments&quot;>', lang_get( 'attached_files' ), '&lt;/td>';
    echo '&lt;td class=&quot;bug-attachments&quot; colspan=&quot;7&quot;>';
    print_bug_attachments_list( $t_bug_id, null);
    echo '&lt;/td>&lt;/tr>';
}
(0055777)
aavagyan   
2017-02-24 09:34   

@cas I think it is colspan=5

(0057637)
helfy022   
2017-09-07 10:14   

Hello,

Is there an official means of making available the "Attached Files" section without modifying the core configuration suite?

Thanks,
Ryan.

(0057646)
dzaggiel   
2017-09-08 09:44   

@cas thanx for tip but how to delete comments with attachments since they are already in the attached file box?

(0057648)
cas   
2017-09-10 05:15   

@dzaggiel, the attachements will show up on both places. Not much to do avbout that.

(0057673)
dzaggiel   
2017-09-11 05:25   

@cas ahh :( It is possible to add a date and time to attachements?

(0057685)
helfy022   
2017-09-11 21:29   

Hello,

In addition to the previous question, please also comment when possible on the question posed in this comment:

https://www.mantisbt.org/bugs/view.php?id=22323#c57637

Thanks very much,
Ryan.

(0057689)
cas   
2017-09-12 02:51   

@ Ryan,
the direction of Mantis is set by the development team, see also https://www.mantisbt.org/bugs/view.php?id=22323#c55523 .
Hopefully they follow the suggestion made by myself but there is no guarantee for that.

@dzaggiel,
adding date/time requires adjustment of core functions which I wouldlike to avoid.
First and formost, I hope that this section is re-enabled again.

(0057709)
ycap   
2017-09-13 04:13   

Hello,
I have the same need.
The attached file section was very usefull in Mantis v1.2.15, it's almost indispensable for my use.
Do you know if it is planned to be added in a future version ?
Thanks
Yannick

(0057715)
cas   
2017-09-14 15:56   

really no clue. for now this is an easy fix!

(0061027)
123   
2018-11-29 22:44   

I also speak in favor of the possibility of choosing how to display attachments.

(0062421)
j2gl   
2019-07-23 23:45   

I just upgraded mantis and I'm having a lot of complaints from the users on how the attachments are organized. Please would you add the feature to choose how to display the attachments.
Thanks

(0062426)
cas   
2019-07-24 15:21   

Since it is not being added to core yet, i suggest you follow my instructions on how to actieve the “old” way�

(0062662)
andresrom   
2019-08-26 10:52   
(Last edited: 2019-08-26 10:53)

Hi guys, i'm getting an error.
Please, can you guide me on how to solve it?
@cas
Thanks

(0062669)
cas   
2019-08-27 02:32   

@andresrom,What exactly is the error message?

(0062671)
andresrom   
2019-08-27 09:50   

Hi @cas
In the section where the attachments are displayed, html tags <td> and <tr> are shown.

(0062693)
wuqixin   
2019-08-30 05:58   
(Last edited: 2019-09-02 02:41)

@andresrom

if ( ON == config_get('show_attachments') ) {
echo '<tr>';
echo '<th class="bug-attach-tags category">', lang_get( 'attached_files' ), '</th>';
echo '<td class="bug-attach-tags" colspan="5">';
print_bug_attachments_list( $t_bug_id, null);
echo '</td></tr>';
}

(0062861)
andresrom   
2019-09-18 09:05   

@wuqixin
Thank you! Works great.

(0063524)
ciwu   
2020-01-28 03:53   

If "print_bug_attachments_list" is used, clicking the "chevron" on attachment in the note expands the attachment in the list (duplicate id?).

(0063574)
polzin   
2020-02-04 11:13   
(Last edited: 2020-02-04 11:14)

Be aware that with 2.23 the suggested patch ignores that privacy of attachments, because of security issue https://mantisbt.org/bugs/view.php?id=26631

(0063879)
pdx   
2020-04-21 08:35   

This patch worked great until we upgraded from 2.17 to 2.24. Now the Attached files section is there but no attachments listed. Can someone tell me if it works in 2.24 and if there is anything that I need to configure to make it work?

(0063881)
cas   
2020-04-21 09:44   
(Last edited: 2020-04-21 11:39)

For version 2.24 please use the following code at line 612 in bug_view_inc.php:

if ( ON == config_get('show_attachments') ) {
    echo '&lt;tr>';
    echo '&lt;th class=&quot;bug-attach-tags category&quot;>', lang_get( 'attached_files' ), '&lt;/th>';
    echo '&lt;td class=&quot;bug-attach-tags&quot; colspan=&quot;5&quot;>';
    print_bug_attachments_list( $f_issue_id, null);
    echo '&lt;/td>&lt;/tr>';
}

This is after the custom fields section just before the closing 'body' statement.

Do not forget to set the variable in core/config_inc.php:
$g_show_attachments = ON;

(0063882)
pdx   
2020-04-21 10:18   

That fixed it. Thank you!



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26894 [mantisbt] api rest minor N/A 2020-04-19 17:49 2020-04-21 19:02
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Issue note files should show up within the notes in REST API
Description:

When retrieving an issue, the note attachments should show up within each note.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12557 [mantisbt] bugtracker feature N/A 2010-11-23 16:22 2020-04-21 06:03
Reporter: dregad Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.2.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug view page: add monitoring for user select from list
Description:

It would be nice when adding users to the monitoring list of an issue, to be able to select them from a list instead of having to type the username blindly, particularly when Mantis is configured to display Realnames.

Tags:

patch

Steps To Reproduce:
Additional Information:
Attached Files: 0001-Fix-#12557:-Select-user-from-list-when-making-them-monitor-an-issue.patch (6,454 bytes) 2010-11-23 16:26
https://mantisbt.org/bugs/file_download.php?file_id=3157&amp;type=bug
Screenshot.png (7,997 bytes) 2010-11-23 16:32
https://mantisbt.org/bugs/file_download.php?file_id=3158&amp;type=bug
0001-Fix-12557-for-mantis-1.2.5.patch (6,026 bytes) 2011-04-06 05:30
https://mantisbt.org/bugs/file_download.php?file_id=3323&amp;type=bug
screenshot-12557-for-2.22.0.png (7,766 bytes) 2019-06-05 09:26
https://mantisbt.org/bugs/file_download.php?file_id=8576&amp;type=bug
0001-fix-12557-for-mantis-2.22.0-dev.patch (6,301 bytes) 2019-06-05 09:26
https://mantisbt.org/bugs/file_download.php?file_id=8577&amp;type=bug
0001-fix-12557-for-mantis-2.24.0-dev.patch (6,395 bytes) 2020-04-20 11:37
https://mantisbt.org/bugs/file_download.php?file_id=9064&amp;type=bug
Send_a_reminer-Erinnerung_senden.png (5,911 bytes) 2020-04-20 12:02
https://mantisbt.org/bugs/file_download.php?file_id=9065&amp;type=bug
Notes
(0027465)
dregad   
2010-11-23 16:32   

Attached is my first shot at implementing this. It works but I am not fully satisfied by the code as it duplicates a lot of the logic in print_user_option_list.

I am also not sure about the wording for the button, and whether there should be an explanatory text in front of the selection list.

Feedback welcome.

(0028543)
dregad   
2011-04-06 05:30   

Updated patch (applies on top of 1.2.5) attached

(0029631)
jsiegel5   
2011-09-02 20:24   

Hi dregad,
Thanks for updating the patch to work with 1.2.5 and later. I spent an hour trying to figure out how to apply the older patch to 1.2.7 before it occurred to me to check this ticket for an update. My team really likes thie feature!
Regards, Jeff

(0029670)
dregad   
2011-09-09 10:53   

An alternate and maybe better way of implementing this feature could be to use the same code as proposed by daryn in 0012677:0028099 - it would at least avoid the code duplication from print_user_option_list (but only works in 1.3.x).

(0031678)
baamster   
2012-04-18 03:28   

Hi, I have no clue how to impelment a .patch file. Any tips?

(0031681)
dregad   
2012-04-18 04:15   

http://lmgtfy.com/?q=apply+patch

(0051320)
Discotechnica   
2015-08-27 17:57   
(Last edited: 2020-04-20 11:37)

Do these patch files work for MantisBT 1.2.15?
I renamed the files above a.patch and b.patch for easier typing and tried the following command. It did not work unfortunately:

/home1/MYSITE/public_html/bugs$ patch --dry-run &lt; a.patch
patching file bug_monitor_add.php
patching file bug_monitor_list_view_inc.php
Hunk 0000001 FAILED at 37.
Hunk 0000002 succeeded at 54 (offset -15 lines).
1 out of 2 hunks FAILED -- saving rejects to file bug_monitor_list_view_inc.php.rej
can't find file to patch at input line 154
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/lang/strings_english.txt b/lang/strings_english.txt
|index eb21912..da61f2e 100644
|--- a/lang/strings_english.txt
|+++ b/lang/strings_english.txt
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored
(0051321)
dregad   
2015-08-28 03:33   

Hello,

I just double-checked and can confirm that the patch does apply cleanly on latest 1.2.20dev (so it most likely does on 1.2.15 as well).

When applying git-formatted patches, as mentioned in the error message you got, you need to use the -p option, like so:

<pre>
dregad@dregad ~/dev/mantisbt (12x) $ patch --dry-run -p1 <12557.patch
checking file bug_monitor_add.php
checking file bug_monitor_list_view_inc.php
checking file lang/strings_english.txt
Hunk 0000001 succeeded at 1266 (offset 18 lines).
</pre>

HTH

(0051323)
Discotechnica   
2015-08-28 13:58   
(Last edited: 2020-04-20 11:39)

Thanks dregad for the help. I have no experience with .patch and I don't want to accidentally break my mantis install so I'm a bit cautious!

I ran the patch with the flags you suggested and got the error and output shown below. (I have rolled back the patch for the time being).

From googling it suggests manually patching the file with the details from the .rej file but I was unable to find "$t_users = array();" in my original file. I also downloaded mantis 1.2.19 and checked the same file there and also could not find that string.

-------RUNNING THE FIRST PATCH-------

/home1/MYSITE/public_html/bugs$ patch -p1 &lt; a.patch
patching file bug_monitor_add.php
patching file bug_monitor_list_view_inc.php
Hunk 0000001 FAILED at 37.
Hunk 0000002 succeeded at 54 (offset -15 lines).
1 out of 2 hunks FAILED -- saving rejects to file bug_monitor_list_view_inc.php.rej
patching file lang/strings_english.txt
Hunk 0000001 succeeded at 1265 (offset 17 lines).

-------bug_monitor_list_view_inc.php.rej FROM FIRST PATCH-------

--- bug_monitor_list_view_inc.php
+++ bug_monitor_list_view_inc.php
@@ -37,12 +37,12 @@
    $result = db_query_bound($query, Array( $c_bug_id ) );
    $num_users = db_num_rows($result);

-   $t_users = array();
+   $t_users_monitoring = array();
    for ( $i = 0; $i &lt; $num_users; $i++ ) {
        $row = db_fetch_array( $result );
-       $t_users[$i] = $row['user_id'];
+       $t_users_monitoring[$i] = $row['user_id'];
    }
-   user_cache_array_rows( $t_users );
+   user_cache_array_rows( $t_users_monitoring );

    echo '&lt;a name=&quot;monitors&quot; id=&quot;monitors&quot; /><br />';
(0051324)
dregad   
2015-08-29 04:21   

I don't have time to look into details atm, but I suspect you're attempting to apply the old patch (for Mantis <= 1.2.4). Try again with 0001-Fix-12557-for-mantis-1.2.5.patch

(0051336)
Discotechnica   
2015-08-31 14:41   

That worked. Thanks dregad!

====== Summary for future readers: ======

  • If you are patching a mantis version that is greater than or equal to 1.2.5 then just run 0001-Fix-12557-for-mantis-1.2.5.patch
  • As of this post, this patch has been tested up to mantis 1.2.20

====== How to patch (for noobs): ======

  • Note you can break stuff if you don't know what you're doing, likely even if you follow these instructions.
  • Make a backup of your site.
  • This site has useful information http://www.thegeekstuff.com/2014/12/patch-command-examples/
  • On Windows, I used WinSCP to connect to my site's FTP address.
  • Browse to the root directory of your mantis install, (www.mysite.com/bugs/).
  • Copy the patch file to this root directory from your computer.
  • Open a terminal window via WinSCP (Ctrl+T, or the black button with a > in it)
  • You may need to enable shell access from your domain host. (I had to enable mine via the domain billing site, not via cpanel. This is likely up to your webhost.)
  • Test run your patch by using: patch --dry-run -p1 < patchFileName.patch
  • Use flag -p1 in your patch command.
  • Run the patch with this command patch -p1 < patchFileName.patch
  • Delete the patch file.
(0051338)
dregad   
2015-09-01 02:35   

Glad you could sort things out, and thanks for posting your feedback.

(0055100)
cid   
2017-01-13 04:34   

Hello,
is it possible to update patch add monitoring for user select from list for Mantis version 2.0.0 ?
Thanks

(0055142)
libregeek   
2017-01-16 00:33   

@cid
You can use this simple plugin to make the user monitoring input box into an autocomplete with multiple values. https://github.com/ejyothi/MantisBT-AjaxUserMonitoring

(This works with MantisBT-1.3 ( use master-1.3.x branch) and MantisBT-2.0 (master branch)

(0055257)
elftron   
2017-01-22 19:24   

@libregeek; I have tried the plugin but it says it needs MantisBt Core2.0.0 and I am using 1.3.5
How do I get it to work with 1.3.5. I am not very experienced with plugins so I am probably missing something obvious.

Thanks

(0055462)
libregeek   
2017-02-03 01:42   

@elftron Try master-1.3.x branch instead of the branch. You can get it directly from https://github.com/ejyothi/MantisBT-AjaxUserMonitoring/tree/master-1.3.x

(0055497)
elftron   
2017-02-05 16:56   

@libregeek Thank you., Works perfectly and I now have a greater understanding of the Master Tree system

(0056763)
JackBeauregard   
2017-05-03 02:22   

Hello, since all my projects in Mantis are private I'd like to see only users who belong to the current project, tried this plugin but everyone sees every user to add in the box. Any idea?

(0059441)
sneuf   
2018-04-05 06:40   

@dregad
Is it possible to integrate "add monitoring user select from drop down list" into Mantis (Version 2.13.x / 2.14.x)?
Thanks

(0059851)
mahindra   
2018-05-19 03:25   

related to
0024139
0024436 urgent set this on hold please
0023375
0024435
0024378
0024087
0024432

and the cause for Realnameproblems since 2.12.0 which are solved by this https://mantisbt.org/bugs/view.php?id=24139#c59850

(0059942)
mahindra   
2018-05-25 13:32   

https://github.com/mantisbt/mantisbt/pull/1351#issuecomment-391495880 @atrol - great Job!

(0061801)
joseba.ortega   
2019-04-01 02:19   

Hi: Is there any patch for version 9.3.3 ? drop list of users for monitoring a issue.

Thanks in advance

(0061802)
mahindra   
2019-04-01 02:55   

Update to latest version.
You will be able to write username or realname to ad them

(0061803)
joseba.ortega   
2019-04-01 03:17   

Hi again:
I'm sorry.
9.3.3 is the version of my Glpi :).
Our version of mantis is 2.9.0.
I understand that i can add a user for monitoring a issue using realname or username. That's great.
When you want to add a new user for monitoring, could you see the drop list of all users?

Thanks a lot

(0061804)
mahindra   
2019-04-01 03:28   

It depends on your rights

You can send an reminder there is a drop down
If you are able to assign IDs - you can see the users there
Or make a New tap and use Reporter or assigned to fields to check it out

(0061805)
mahindra   
2019-04-01 03:29   
(Last edited: 2019-04-01 03:29)

A Combo to select users will be nice as written above

(0062193)
a.zhivotovskiy   
2019-06-04 19:59   
(Last edited: 2019-06-04 20:00)

Mantis 2.21.0
copy patch into Mantis root directory
execute: sudo patch --dry-run -p1 <0001-Fix-12557-for-mantis-1.2.5.patch

Error:
checking file bug_monitor_add.php
Hunk 0000001 FAILED at 34.
1 out of 1 hunk FAILED
checking file bug_monitor_list_view_inc.php
Hunk 0000001 FAILED at 51.
1 out of 1 hunk FAILED
checking file lang/strings_english.txt
Hunk 0000001 FAILED at 1248.
1 out of 1 hunk FAILED

Please, can you check?

(0062205)
dregad   
2019-06-05 09:26   

I am not using this functionality anymore - with a large number of users it becomes counterproductive to have a selection list vs typing the users' names in the field.

Anyway, here's an updated version of the patch. Note that this is against current dev-master (commit afb40dca79e54ff9c453d8bbe1b747c972e38f6f). NOTE: I did not test with older versions, and in fact it may not apply cleanly on 2.21.0 and older, because of changes introduced in 0025815.

(0062209)
a.zhivotovskiy   
2019-06-05 10:59   

sudo patch --dry-run -p1 <0001-fix-12557-for-mantis-2.22.0-dev.patch
checking file bug_monitor_add.php
checking file bug_monitor_list_view_inc.php
Hunk 1 FAILED at 119.
1 out of 1 hunk FAILED
checking file lang/strings_english.txt

(0062210)
dregad   
2019-06-05 11:32   

Yeah well as I said before

it may not apply cleanly on 2.21.0 and older

QED.

I'm not going to adapt the patch for compatibility with earlier versions. Feel free to do so yourself if you need it.

(0062277)
dduminy   
2019-06-20 06:03   

Thanks so much for your patch. I think it should be integrated in the next version. The feature is really cool and expected.
I understand that it might be faster to type the login of the newly added user , but perhaps, you can consider to make it configurable

(0063861)
cathbis   
2020-04-20 02:56   

Hello,
It is my firt contribution (so sorry for my English).
We are interesed for this feature. It is planned into the 2.21 . (see the last dregad's note (2019-06-05).

Why the resolution of this issue is not resolved ?

The version actually in developpement is the 2.24.1 so > 2.21.

Currently we prepare a big upgrade (1.2.10 to the last stable version) so It will be nice to me to know if this feature is ready or not ?

Thank a lot for your answer. and have a good Week.

(0063868)
dregad   
2020-04-20 11:37   

@cathbis

It is planned into the 2.21 . (see the last dregad's note (2019-06-05).

It is not planned at all, I think you misinterpreted what I wrote.

Why the resolution of this issue is not resolved ?

Because it is not resolved... and unlikely to be in the near future too.

@dduminy

I think it should be integrated in the next version. The feature is really cool and expected.

It will not be integrated into MantisBT core in its current form, for the reasons explained in earlier notes

  1. 0012557:0027465: _It works but I am not fully satisfied by the code as it duplicates a lot of the logic in print_user_optionlist.
  2. 0012557:0062205: with a large number of users it becomes counterproductive to have a selection list

Anyway for convenience, please find attached an updated patch for 2.24.0

(0063869)
mahindra   
2020-04-20 11:44   

@dregad - there is a similar list in "send a reminder" function, which is easy and smooth to use.
Maybe it is possible to use this here?

(0063870)
cathbis   
2020-04-20 11:50   

Hello @Dregad, thank a lot for your quick response. It is clearly.

For my opinion the most useful feature it should be the automatic completion by first name or by last name.

@ Mahindra : I Don't know what it is a "send a reminder" function, it is perhaps a useful solution too.

(0063871)
mahindra   
2020-04-20 12:02   
(Last edited: 2020-04-20 12:06)

@cathbis The function depends on your rights and is not visible here (maybe in your mantis)
@dregad the direct URL is https://www.mantisbt.org/bugs/bug_reminder_page.php?bug_id=12557

(0063877)
dregad   
2020-04-21 04:48   

@mahindra I know about the reminder feature, thanks.

I'm not sure I get your point though - this is essentially the same UI as the one used in my patch, and suffers from the same problem and limitation I outlined in 0012557:0063868 (point 2). It is not an issue there, because the list of recipients for reminders is usually quite short as it's limited to developers by default, but if you take for example an instance like mantisbt.org where we have nearly 40'000 users with 99.9% of them being reporters, selection lists are simply not an option - just retrieving the data and having the browser render it can take several minutes.

The proper solution for this issue, as mentioned by @cathbis, is to use a text field with automatic completion.

(0063878)
mahindra   
2020-04-21 06:03   

@dregad thank you - I think you are right.
In our projects we only have max. 100 users - so this is not a such point.
Automatic completion für UID or Username would be really nice :)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26879 [mantisbt] ldap minor N/A 2020-04-14 05:36 2020-04-21 04:34
Reporter: maturbet Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add plugin EVENT in ldap_cache_user_data
Description:

As proposed in a PR (https://github.com/mantisbt/mantisbt/pull/1637#issuecomment-612309096), an EVENT in the LDAP api function will allow plugins to add fields to cached LDAP user data.

Tags:
Steps To Reproduce:
Additional Information:

It may replace core code proposition : https://www.mantisbt.org/bugs/view.php?id=26809

Attached Files:
Notes
(0063876)
maturbet   
2020-04-21 04:34   

PR : https://github.com/mantisbt/mantisbt/pull/1660



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11296 [mantisbt] security major always 2009-12-21 11:46 2020-04-18 12:12
Reporter: Buffer Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 1.1.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mantis BT is using fix cookies in the DB
Description:

Dear Mantis developers,

During testing Clientless SSL VPN vulnerability, with a malicious webpage to steal cookie through SSL VPN, I found something a little bit bizarre in Mantis BugTracker.

In fact, the cookie for each user is fixed and never changes. As I remember, cookie must change for each server session, and must be unique for each server session.

This is the not the case with your BT application, because cookie is simply fixed and stored in the database. Just for advise, I'm not sure this is the right design, as anyone can steal cookies using XSS or many other attacks' vectors. When the cookie is stolen, even if you click on logout, session never expired.

With Tamper Data or any Firefox plugin, I just logged in as the user I want just by filling HTTP Cookie header with MANTIS_STRING_COOKIE right value, for targeted user (and even if the user logout before!).

Tags:
Steps To Reproduce:

Login as a known user
Copy the MANTIS_STRING_COOKIE value available in HTTP Cookie Header, or copy the "cookie_string" value for the specified user in the SQL table "mantis_user_table".
Click logout when viewing my_view_page.php (normally at this time, cookie string must be destroyed/changed as the session or any authentication value).
Set the value MANTIS_STRING_COOKIE when viewing the login page with the stolen cookie, with TamperData/LiveHeaders or any Firefox plugin to alterate HTTP headers/data.
Now you're login fraudulently without login / password provided ! Moreover, you can change user options, user password or profile, without providing any form of authentication ... just great for hackers ...

Additional Information:

Waiting for your update / ack or patch / release information before Full-Disclosure on SecFocus(BugTraq), as it's an important security issue.

Attached Files:
Notes
(0023987)
Buffer   
2009-12-26 12:41   
(Last edited: 2009-12-26 12:44)

Any news / ACK to this potential vulnerability ?

If no quick update, will be published next week on SecFocus FD Mailing ...

(0023988)
vboctor   
2009-12-27 04:31   

We've done the work to protect the cookie in 1.2.0rc2 (issue 0010709). We currently change the cookie when the user changes their password. However, we could potentially do that more often, i.e. for each session.

If we do that, we should make sure that a SOAP login doesn't log the user out of a web session.

That would also mean that if a user logs in, the user would be automatically logged out on other browsers / computers.

(0023990)
jreese   
2009-12-27 08:27   

First, there is a user-controlled option already to limit sessions to a single IP address, and is allowed to be disabled by the user in cases where the user is behind a proxy setup with multiple exit points. Secondly, I think the real solution is to not store the user's cookie in the database. This is what the user's session ID is for, and I really think Mantis' existing concept of verifying the user's cookie from a value stored in the database is useless and outdated.

The real question is exactly how do we proceed from this point forward? I personally would like to see the current cookie verification routines replaced by special handling in the session API. Thoughts?

(0023993)
vboctor   
2009-12-28 03:19   

@jreese, I agree with your suggestion and I like the fact that it supports multiple sessions.

However, I like the currently ability for a user to expire all their active sessions independent on the computer / browser by changing their password. The actual change of password doesn't affect the cookie, but at one point I've made this roll a new cookie. This is useful if a user remembers that he/she forgot to logout on some other machine they used.

Hence, I think it would be great if we would be have a solution to support both. But, for simplification, I'm OK with compromising the remote logout feature if necessary.

(0023994)
giallu   
2009-12-28 03:51   

I've just read the Zend_Session class docs, in particular http://bit.ly/5m92La and they suggest regenerating a new session ID at each client request with the regenerateId() static method.

I wonder if we could let our MantisSession class derive from Zend_Session, call regenerateId() early in the page generation and be done with this.

(0023995)
vboctor   
2009-12-28 04:08   

The technique they are using looks good, but I expect that we are looking at fixing this for 1.2.x and maybe 1.1.x and hence we shouldn't be taking a dependency on ZF.

(0023999)
dhx   
2009-12-28 07:51   

One of the problems with using PHP sessions is that the lifetime of the PHP session cookies is (generally) set with a global PHP option. One of the use cases of MantisBT is that someone may leave a message half typed on a Friday afternoon with the expectation that they can finish it off on Monday and submit it. You may have PHP setup differently for another application where you want much shorter session expiry times. I'm fine with requiring them to reauthenticate due to an expired session cookie - as long as the data they're posting isn't lost.

Users may login to the same account simultaneously from different devices (a mobile phone and a desktop computer for example). Therefore we can't just delete a session cookie that may still be in use by another device/login instance. We really need to remember a session key for each session (in the previous example, once for the mobile phone and then again for the desktop computer).

Changing the session ID won't work as giallu suggested because users may open up 10 forms/pages in Mantis and submit them in any random order. We can't assume that users are browsing within their session using a linear one-page-at-a-time approach. Unless of course giallu was just referring to creating a new session key upon a new login, and using this key for all page requests until the user logs out.

PHP's inbuilt session support would be the ideal method to use if we can figure out the maximum session lifetime correctly. In other words, we need to ensure all submitted forms remain intact while re-authentication is occurring.

In the future I'd really like to add user audit logs that are viewable by not only administrators, but the users themselves. This would allow users to see the last 5 times they logged in, where those logins originated from, etc. The users would also be able to view all current sessions they've got open, with the ability to terminate any or all of them.

(0024000)
jreese   
2009-12-28 09:25   

Perhaps we could reuse the existing reauth methods, and combine the existing db-stored cookie with a per-session id. If the user's PHP session get's flushed/expired before submitting a form, we could pop the reauth dialog to make sure the user knows the correct password. This would also solve the underlying security issue, such that when a malicious user starts a new session with someone else's db cookie, it will trigger a reauth rather than simply giving them access.

Thoughts?

(0024001)
giallu   
2009-12-28 09:34   

@dhx: I'm no expert here, but as I understand it, the approach Zend advocates is something like:

  1. login, your browser get a session with a certain ID
  2. browse to another page, your browser is given another random ID so it's nearly impossible to spoof it

@vboctor, 1.1 is tricky but if we think the approach is good and the PHP requirement matches ours I can't see why we shouldn't; I checked and this particular class does not depend on anything else in the ZF.

Alternatively, we could just grab the logic and implement it in our classes.

(0063851)
dregad   
2020-04-18 12:12   

Community-proposed PR https://github.com/mantisbt/mantisbt/pull/1653

As per my review comment, I think the proposed change is not acceptable as it prevents simultaneous sessions from multiple devices.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26861 [mantisbt] ui minor always 2020-04-11 11:07 2020-04-18 07:19
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: "Move" functionality offered for users that have just access to a single project
Description:

The "Move" button on "View Issue" page is useless if a user has just access to a single project.
The same applies to the "Move" operation on "View Issues" page

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063835)
atrol   
2020-04-11 11:10   

PR https://github.com/mantisbt/mantisbt/pull/1648



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26823 [mantisbt] ui minor have not tried 2020-03-28 17:31 2020-04-18 07:17
Reporter: syncguru Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Upgrade to fontawesome version 4.7.0
Description:

Version 5.0 of fontawesome is a complete rewrite of the library. In addition, it introduces a freemium model that limits the value of the free version. For this reason, we could stick with version 4.0+ for a longer time thus it is worthwhile to upgrade to the most recent version prior to v5.0 which is v4.7.0

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063802)
atrol   
2020-03-29 06:13   

PR https://github.com/mantisbt/mantisbt/pull/1640



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11977 [mantisbt] filters feature N/A 2010-06-02 06:20 2020-04-17 15:18
Reporter: jurgenhaas Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Is it possible to filter by due_date?
Description:

The title says it all. It would be nice to exclude issues from the list which aren't due yet. Something like "Show all" or "Show Issues that become due in 2 days only" with a possibility to have multiple notice periods.

Any chance for getting this in a future release or is it already possible?

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: SNAG-001.gif (20,178 bytes) 2012-09-19 01:24
https://mantisbt.org/bugs/file_download.php?file_id=4060&amp;type=bug
filter.JPG (82,572 bytes) 2019-04-18 05:59
https://mantisbt.org/bugs/file_download.php?file_id=8519&amp;type=bug
Notes
(0025796)
M.C.S.   
2010-06-10 08:36   

This would be a really good thing :-)

(0028494)
cas   
2011-03-29 02:44   

I have added this field to the view_all_bug_page so I can sort on it, that gave me enough options.

(0032870)
shiroamada   
2012-09-18 22:23   

Hi cas,
Can you attached your view_all_bug_page.php file here, I would like to know how you implement it?

Thanks!

Best Regards,
Shiro

(0032871)
cas   
2012-09-19 01:26   

@Shiro,
see attached. This is standard Mantis so available right away.
Just add field to fieldlist for this page.
(Manage->Manage Configuration->Manage Columns)

(0032873)
shiroamada   
2012-09-19 02:22   

@Cas,
Thank you for your fast response! It is amazing!
How about if I want to filter with due date filter?
Currently the system only allow "Use Date Filters:" <- Last Updated Date.

Thank you so much!

(0032875)
cas   
2012-09-19 03:10   

Do not think that is available.

(0036581)
paulo_x   
2013-04-12 11:19   

Any update on this issue? It would be rather useful. Thank you

(0038179)
lucenic   
2013-10-02 03:36   

Hello, I also prefer to have this sort thing to behave a bit specific to the 'due date' field semantics: to sort issues ASC based on this field is supposed to list all fields that have set the due date first and the issues with no due date at the end of the list. It is rather confusing to wish to list all issues that are due/overdue and see all the issues not having due date as first...

I vote for filtering on this field as well :-)

(0038180)
atrol   
2013-10-02 03:47   

lucenic, the sorting is handled in 0016259

I vote for filtering on this field as well :-)
Submitting a patch is always a good idea, as it increases the chances of improvement eventually making it into MantisBT core. All contributions are welcome and greatly appreciated.

Patch submissions can be made in several ways. In the order of preference:

  1. Send us a Pull Request on our Github repository [1]
  2. Attach a GIT patch to the issue
  3. Attach a Unified Diff, clearly specifying the patch's base release

Kindly avoid to upload entire modified PHP files.

Please make sure that your submissions adhere to our Coding Guidelines [2], if they don't your patch might be rejected.

[1] https://github.com/mantisbt/mantisbt
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

(0039266)
atrol   
2014-02-01 06:10   

Unassigned after having been assigned for a long time without progress.

(0057643)
helfy022   
2017-09-07 14:20   

Hello,

Just to confirm, is there no built-in means of filtering on Due Date (as you would for any custom field of type Date)? To be clear, I'm referring to the ability available to custom date fields to find issues based on a due date being on, between, etc. a range of dates.

Thanks,
Ryan.

(0061647)
sandyj   
2019-03-07 18:19   

It would be good to have an 'any' and 'today' option for from and to date filters to allow you to find any overdue tickets and save it as a recurring filter.

(0061938)
stevecharon   
2019-04-15 08:21   

@sandyj You can implement Reminder plugin to have email reports to developers or managers.
It is based on mantis 1.3 but still works on 2.x

(0061961)
cas   
2019-04-18 03:38   

I have extended the filter page with the Due-Date option.
Still need to create the patch (so it may end up in a future release) but for those who cannot wait, i can make available the scripts that needs to be changed

(0061972)
cas   
2019-04-18 05:59   

This how it looks

(0062701)
lexlogos   
2019-09-01 07:17   

Hi, @cas can you share the script ? Thank you.

(0062778)
lexlogos   
2019-09-12 10:53   

Hi @atrol, can you please tell me if cas's solution can be found elsewhere? Thank you

(0062780)
stevecharon   
2019-09-12 11:02   

Hello @lexlogos,

here it is: https://mantisbt.org/bugs/view.php?id=24706#c60582
Version 2.0 is in the official plugin-repo here https://github.com/mantisbt-plugins/Reminder

(0062781)
lexlogos   
2019-09-12 11:07   

Hi @stevecharon, thank you so much for your help.

(0062792)
lexlogos   
2019-09-13 15:05   

Hi @stevecharon, Reminder plugin can do filter page with the Due-Date option? I need this funtion in mantis. Thank you in advance.

(0062863)
stevecharon   
2019-09-18 10:56   

Hi @lexlogos,

apparantly not, I am afraid. Reminder plugin only gives you notifications of issues which are due to resolve.
Because of that this issue is here!
I reworked the Reminder Plugin for our needs internally to get nicer output in a html table. But the basic logic is still the original one by cas.
The notifications are set in a cron-job on your webserver and sends the emails to your developers/managers or reporters.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5828 [mantisbt] security minor always 2005-06-22 05:52 2020-04-15 12:17
Reporter: amartinez Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: It is not possible to hide "private" bugs from "developers" who are not assigned to the bug
Description:

It is not possible to hide "private" bugs from "developers" who are not assigned to the bug

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010603)
thraxisp   
2005-06-22 09:02   

Yes, This would be a more strict interpretation of private. If "view_private_bug_threshold" were set to MANAGER, the handler wouldn't be able to see the bug. It would have to be asigned to them by a manager before they could see it.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15593 [mantisbt] email feature always 2013-03-12 10:54 2020-04-14 11:19
Reporter: HeikoSL Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 1.2.14  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add a globalwatcher email config option, all emails are copied to
Description:

My employer eCola GmbH wanted to get all emails mantis has send as a copy in a specified email account.

I added a config option $g_globalwatcher_email to config_defaults_inc.php that can hold the email address or switched OFF.

Depending on the config option every email that will be stored in the queue is added a second time to the queue but with the $g_globalwatcher_email-address. (functionality added to email_api.php, function email_store)

Tags:

patch

Steps To Reproduce:
Additional Information:

patch file in attach

Attached Files: Glob_watch.patch (1,780 bytes) 2013-03-13 00:01
https://mantisbt.org/bugs/file_download.php?file_id=4375&amp;type=bug
Notes
(0035441)
atrol   
2013-03-12 15:40   

Thank you for this contribution.
Would be fine if you could attach a patch which contains just the needed changes but not additional files like config_defaults_inc.php~ and email_api.php~

(0035445)
cas   
2013-03-13 00:01   

Nice addon.
Cleaned the patch file so it only contains what is actually needed

(0035450)
HeikoSL   
2013-03-13 05:03   

Thank you cas. Next time I hopefully will clean it on my own...



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26856 [mantisbt] plug-ins feature always 2020-04-10 04:31 2020-04-10 04:31
Reporter: fman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: EVENT_REPORT_BUG_FORM - add parameter f_master_id - useful when cloning to get plugin data
Description:

Hi
I've developer a plugin impactMatrix that we use to request to reporters 3 elements to calculate ITIL Urgency.
these values are stored in a plugin table.

I've developed another plugin cloneToOtherVersion, that we use to force several values when cloning.
I'm not able to populate the fields regarding impactMatrix, with the values present in the ticket I'm cloning, because
the f_master_id is not passed to EVENT_REPORT_BUG_FORM, that is used when cloning.

IMHO it will be great if this parameter will be added to the standard EVENTS that can be used to populate the form while cloning.

regards

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6523 [mantisbt] filters feature always 2005-12-21 05:23 2020-04-05 14:16
Reporter: dapozzom Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 1.2.17  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Search field criteria
Description:

How can I have the standard attribute (ie Reproducibility), as a filter criteria

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0041451)
grangeway   
2014-10-07 19:30   

We are resolving this issue as "no change required", because it was reported against an old version of MantisBT which is no longer supported.

We recommend that you upgrade to the latest stable version [1]; if after doing so the problem still exists, do not hesitate to reopen the issue.

[1] http://www.mantisbt.org/download.php

(0041454)
atrol   
2014-10-08 01:49   

Reopened.
We can't filter by reproducibility in current version.

(0041470)
grangeway   
2014-10-08 15:43   

Guessing I read 'resolution' as reproducibility as I checked this last night :)

(0041471)
grangeway   
2014-10-08 15:43   

Setting product version to 1.2.17



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26809 [mantisbt] ldap feature always 2020-03-24 04:24 2020-04-03 04:40
Reporter: maturbet Platform:  
Assigned To: community OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Personalize LDAP fields cached
Description:

To customize the list of ldap account fields to be cached for a user.

Adding global variable :
$g_ldap_cache_fields = array();
And include it in search attributes :
$t_search_attrs = array_merge(
array(
'mail',
config_get( 'ldap_realname_field' )
),
config_get( 'ldap_cache_fields' )
);

Tags:
Steps To Reproduce:
Additional Information:

PR https://github.com/mantisbt/mantisbt/pull/1637

Attached Files: personal_fields.png (60,174 bytes) 2020-04-03 03:36
https://mantisbt.org/bugs/file_download.php?file_id=9051&amp;type=bug
showing_field.png (65,398 bytes) 2020-04-03 03:36
https://mantisbt.org/bugs/file_download.php?file_id=9050&amp;type=bug
exemple_ldap.txt (1,878 bytes) 2020-04-03 03:36
https://mantisbt.org/bugs/file_download.php?file_id=9052&amp;type=bug
Notes
(0063821)
maturbet   
2020-04-03 03:36   

Som usage exemples
*1 : actualy in use in our company

(0063822)
maturbet   
2020-04-03 03:37   

*2 : (not implemented yet in internal plugin) :
Associated with EVENT_MENU_ACCOUNT we will be able to add to the user's menu, specific links composed with data from LDAP.

(0063823)
maturbet   
2020-04-03 03:37   

*3 : https://www.mantisbt.org/bugs/view.php?id=23392



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
23392 [mantisbt] plug-ins minor have not tried 2017-09-22 08:24 2020-04-03 04:40
Reporter: rct Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mantis LDAP Avatar plugin
Description:

Hello,

Would you like to host this Mantis plugin into mantisbt-plugins?

Github URL : https://github.com/romaincabassot/MantisLdapAvatar

Name : LdapAvatar

Description : This plugin connects to the Mantis globally configured LDAP and cache the avatars retrieved from a configured LDAP attribute to a local storage path.
When the user's LDAP last modified attribute is modified, the avatar is retrieved again from LDAP.
If the avatar exceeds the configured maximum width or height, the avatar is resized.

Romain

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0057793)
dregad   
2017-09-22 09:02   

I would suggest you rename the plugin to remove the Mantis prefix - it's redundant.

Other than that, no problem with hosting it in the mantisbt-plugins org.

Did you consider the possibility of retrieving the photo directly from LDAP instead of having a link to a local file ?

(0057795)
rct   
2017-09-22 10:13   

Ok for the name: https://github.com/romaincabassot/LdapAvatar

"Did you consider the possibility of retrieving the photo directly from LDAP instead of having a link to a local file ?"
I could be done but I think that retrieving photos locally can help caching images and serve site fastly. Could you give me examples of when retrieving photos directly can be an advantage?

(0057796)
dregad   
2017-09-22 12:47   

I don't have a specific example. At my previous company the LDAP (active directory actually) contained small jpeg photos of all employees, so I just thought it could be useful in such scenario. Just an idea...



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4320 [mantisbt] email feature always 2004-08-13 03:26 2020-04-03 04:26
Reporter: OliverBee Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Email filtering
Description:

1)
At present the user can only filter the emails based on the severity, but maybe it's more senseful to filter emails based on a user role (like the email filtering of Bugzilla). My colleagues are annoyed about so much email traffic of mantis and just move their emails to the trash directory. It would be nice that I only get mails for issues I am related to (reporter, assignee, monitorer). I don't want to get informed when another developer assignes an issues or resolves one (expect if I reported that issue).

2)
It would also be comfortable to configure if I will get emails about new issues which are not assigned to anybody.

3)
The third feature request I would like to have is the email filtering possibility for custom status and relationship changes. I added a custom status 'tested' between resolved and closed and it's not possible to disable the email notification for that status. Neither is it possible to reject relationship changes notifications.

Sorry, if it is configurable and I have overseen it.
Mantis is a great product :)

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006977)
thraxisp   
2004-08-13 07:02   

The first two are already possible at an installation level using the $g_notify_flags and $g_default_notify_flags. See the manual page at <http://manual.mantisbt.org/manual.configuration.email.php>.

(0006978)
OliverBee   
2004-08-13 07:46   

Are you sure that I can configure 1) and 2) ? I read the documentation (by the way your link doesn't work it is http://manual.mantisbt.org/manual.configuration.email.php) but I don't want to configure this for everybody but user independent.

For example I want to get all mails (after bugnote added, status change, etc.) for issues I am the handler of and for all issues I have reported, but I doesn'
t want to get mails I'm not related on.

My flags are set to following at the moment and this should be sufficient or not? How is the notifyFlag settings read, is it read the way that if one of the conditions in the array is true, I will get the mail?
$g_default_notify_flags = array('reporter' => ON,
'handler' => ON,
'monitor' => ON,
'bugnotes' => ON,
'threshold_min' => DEVELOPER,
'threshold_max' => NOBODY);

(0006980)
OliverBee   
2004-08-13 08:00   

Will I get all the Mails defined in default_notify_flags even if I put alle the flags off in my user settings?

(0006983)
thraxisp   
2004-08-13 15:50   

The $g*notify_flags are global for the installation. (There is a feature request to extens all configuration to a per project or maybe per bug basis).

If you wan people to only see bugs they are involved in, you could set
<pre>$g_default_notify_flags = array('reporter' => ON,
'handler' => ON,
'monitor' => ON,
'bugnotes' => ON,
'threshold_min' => NOBODY,
'threshold_max' => NOBODY);
</pre>

This would only send mails to people whe originated, were handling the bug, specifically requested monitoring, or added a bugnote.

This is overridden by the user's preferences (for example, where you don't want to see specific status changes).

(0006997)
thraxisp   
2004-08-15 18:17   

The individual settings should be part of the per project settings contemplated for 0.20.

(0008190)
naib   
2004-10-27 21:15   
(Last edited: 2004-10-27 21:17)

I agree with this request - many users want to either turn off email for certain projects or turn off certain types of email - particularly with respect to the large increase in mail traffic since the Relationships feature was put in. If I add a relationship to a bug, users now get 2 more emails than they used to, per bug!

I consider this a high priority because I'm in danger of losing the very people who are interested in how our project is moving along.

edited on: 10-27-04 21:17

(0008208)
harpreet_singh   
2004-10-29 13:26   

Hi,

I am not able to open the given urls.

With Regards

Harpreet Singh

(0008212)
DGtlRift   
2004-10-30 08:33   

Remove the ) or > at the end of the URL

(0010381)
OliverBee   
2005-06-07 04:44   

I think this bug is resolved now, plz close.

(0010390)
thraxisp   
2005-06-07 10:02   

I'm leaving it open to capture the request for user based filtering on a per project basis.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26839 [mantisbt] printing minor always 2020-04-01 14:15 2020-04-03 01:49
Reporter: bmason Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.22.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Viewer does not get Selection column in View Issues or Print Reports lists
Description:

Users with Viewer access cannot see the Selection column in the View Issues list or the Print Reports screen, even though that column is included in their Manage Columns.

This seems to happen regardless of the project selected.

Tags:
Steps To Reproduce:

Log in as a user with global access level of Viewer.
In My Account, open Manage Columns.
Verify that selection is the first column listed for View Issues Columns and for Print Issues Columns.
Now click View Issues and adjust filter so that some issues are listed.
Notice there are no selection boxes in the selection column.
Click Print Reports.
Notice there are no selection boxes in the selection column.

Additional Information:
Attached Files:
Notes
(0063814)
atrol   
2020-04-01 16:43   
(Last edited: 2020-04-01 16:46)

Now click View Issues and adjust filter so that some issues are listed.
Notice there are no selection boxes in the selection column.

I assume there is also no drop down at the bottom to select an action. Right?
If so, this is the reason that no checkboxes are displayed, as they are not needed in this case.

Click Print Reports.
Notice there are no selection boxes in the selection column.

This is a bug, as the checkboxes are needed for the Display selected only button.

(0063815)
bmason   
2020-04-01 16:56   

Yes, you are right. The fact that the selection boxes are missing in the View Issues list is okay because a Viewer can't do anything on that screen anyway.

But the fact that they are missing from the Print Reports screen is definitely a problem because the Viewer will not be able to print or export the exact bugs they want.

(0063816)
atrol   
2020-04-01 17:07   
(Last edited: 2020-04-01 17:08)

PR https://github.com/mantisbt/mantisbt/pull/1644

@bmason, would be fine if you could confirm that the changes in the PR fix the issue.
For the changes see https://github.com/mantisbt/mantisbt/pull/1644/files

(0063817)
bmason   
2020-04-01 17:16   

Wow, that was fast!

I noticed the new line of code seems to be coming before a comment line that relates to the deleted line. You may wish to remove the comment if it is no longer valid.

My test system is not available at this moment because we are validating version 2.22.2 for our intended use. Will try to test the fix in the next couple of days.

(0063818)
atrol   
2020-04-01 17:28   

You may wish to remove the comment if it is no longer valid.

The comment is still valid, it's a comment for the next line 1084

# check report_bug_threshold for the actions &quot;copy&quot; or &quot;move&quot; into any other project
access_has_any_project_level( 'report_bug_threshold' ) 


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26101 [mantisbt] ui minor have not tried 2019-08-29 17:45 2020-04-02 17:34
Reporter: syncguru Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Upgrade to font-awesome free 5.0
Description:

Version 5.0 out. It also introduced a paid version called Pro.
We should upgrade but stick with the free version.

https://fontawesome.com/
License: https://fontawesome.com/license/free

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063800)
syncguru   
2020-03-28 17:27   

Look into this and reached a conclusion that upgrading to V5.0 adds very little value to mantisbt.
In addition to the opinion listed here: https://www.enableds.com/font-awesome-5-worth-upgrading/ - getting Ace theme to work with the new version of fontawesome is non-trivial undertaken.

To keep mantisbt at the most recent version prior to v5.0 - I upgraded to version 4.7.0

(0063820)
dregad   
2020-04-02 17:34   

So this should be closed as won't fix then ?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26837 [mantisbt] db mssql minor N/A 2020-04-01 03:22 2020-04-02 17:01
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Update ADOdb to 5.20.17
Description:

Bug fixes https://github.com/ADOdb/ADOdb/blob/v5.20.17/docs/changelog.md

Not expecting any regression to MantisBT codebase with this release.

Tags:
Steps To Reproduce:
Additional Information:

https://github.com/mantisbt/mantisbt/pull/1642

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26841 [mantisbt] ldap major always 2020-04-02 06:23 2020-04-02 06:35
Reporter: bboulares Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Very bad performance with $g_use_ldap_email = ON
Description:

Hi

when activating g_use_ldap_email = ON, i have very bad performance to manage projects due to manage_proj_edit_page.php slowness (takes 50 secondes).

How to solve this knowing that i use both ldap and DB ?
Can I use multiple $g_ldap_root_dn = 'dc=company,dc=grp'; to reduce time to fetch users in AD ? list like:
#$g_ldap_root_dn_list = array('ou=A1;dc=company,dc=grp','ou=A2;dc=company,dc=grp');

Thanks

Tags:
Steps To Reproduce:
Additional Information:

#Authentification LDAP
$g_login_method = LDAP;
$g_reauthentication = ON;
$g_reauthentication_expiry = 600;
$g_ldap_server = 'ldap://ldapserver:389';
$g_ldap_root_dn = 'dc=company,dc=grp';
$g_ldap_organization = '';
$g_ldap_protocol_version = 3;
$g_ldap_follow_referrals = OFF;
$g_ldap_bind_dn = 'cn=svc-ldap,ou=Comptes_SVC,ou=Administration,dc=company,dc=grp';
$g_ldap_bind_passwd = '***';
$g_use_ldap_realname = ON;
$g_use_ldap_email = ON;
$g_allow_blank_email = OFF;
$g_send_reset_password = ON;
$g_ldap_uid_field ='employeeID';
$g_ldap_realname_field='cn';
#$g_log_level = LOG_WEBSERVICE;
$g_log_level = LOG_ALL;
$g_log_destination = 'file:/APPLI/logs/mantisbt.log';

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26821 [mantisbt] code cleanup minor N/A 2020-03-28 11:58 2020-04-01 03:13
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Standardize access of option database_version
Description:

Option $g_database_version should always be written/read for ALL_USERS and ALL_PROJECTS.

Instead of relying of internal logic of config_get and config_set if user and project parameter are not set, provide them always as parameters.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063798)
atrol   
2020-03-28 12:01   

PR https://github.com/mantisbt/mantisbt/pull/1638



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26822 [mantisbt] ldap minor always 2020-03-28 12:24 2020-04-01 03:13
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: LDAP configuration options can be set in database
Description:

LDAP configuration options can be set in database by the MantisBT administrator and can be set per project and/or user.

Such kind of options should

  • only be set by the server administrator
  • apply for the whole MantisBT instance, but not for specific projects or users
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063799)
atrol   
2020-03-28 12:32   

PR https://github.com/mantisbt/mantisbt/pull/1639



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24191 [mantisbt] integration feature have not tried 2018-03-30 15:27 2020-03-28 20:02
Reporter: sandyj Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.11.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Some Fontawesome icon not showing.
Description:

Some fontawesome icons are not showing when configuring banners. Might need an update to the latest version of fontawesome e.g. tried these two fa-newspaper, fa-accessible-icon

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0059369)
atrol   
2018-03-30 15:44   

We deliver Font Awesome 4.6.3 at the moment.

fa-newspaper should work, as it should be included since 4.2 https://fontawesome.com/icons/newspaper

fa-accessible can't work, as it's included in 5.0 https://fontawesome.com/icons/accessible-icon



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26617 [mantisbt] documentation minor have not tried 2020-01-21 14:05 2020-03-28 13:10
Reporter: rogueresearch Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Admin Guide has various broken links, obsolete info, etc.
Description:

Patch here: https://github.com/mantisbt/mantisbt/pull/1613

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26798 [mantisbt] administration minor always 2020-03-19 12:26 2020-03-28 12:57
Reporter: atrol Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: PHP warning in config_get_global
Description:

In some cases config_get_global gives ERROR_CONFIG_OPT_NOT_FOUND warning

PHP Warning:  100 in .../core/config_api.php on line 192

This is WAD at the moment and happens for any string configuration option where function config_eval is not able to reference a variable.

/**
 * check for recursion in defining configuration variables
 * If there is a %text% in the returned value, re-evaluate the &quot;text&quot; part and replace the string
 *
 * @param string  $p_value  Configuration variable to evaluate.
 * @param boolean $p_global If true, gets %text% as a global configuration, defaults to false.
 * @return string
 */
function config_eval( $p_value, $p_global = false ) {

In typical use cases there is no problem, but the approach itself is not clean and can lead to real life issues, e.g this post in forum

Most of the time there is just the warning without any visible side effect, e.g. set

$g_crypto_master_salt     = '%1%C*&^$#Gand$%^$#%@UOOMm60hvxe8AngM=';

but there are also strange restrictions because of this, e.g. you can't set something like

$g_db_password            = '%1%myPasswordThatCantainsTwoDollars'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063778)
atrol   
2020-03-19 12:28   
(Last edited: 2020-03-19 12:29)

Options to fix

  • Remove config_eval, see discussion in 0021604 and my former try
  • Introduce new parameter $p_eval = true in functions config_get and config_get_global and set it to false for some options
  • Introduce new functions config_get_no_eval and config_get_global_no_eval and use it for some options
  • Introduce new functions config_get_no_eval and access the global variable instead of calling config_get_global for some options
    ...

Comments welcome

(0063782)
dregad   
2020-03-21 10:37   

Not sure if you are aware that since 1.2.0rc1, as a workaround \ can be used to escape the % in configs, so it does not get interpreted by config_eval(), e.g.

php > $g_db_password            = '\%1\%myPasswordThatCantainsTwoDollars'
php > echo config_eval($g_db_password,true);
%1%myPasswordThatCantainsTwoDollars
(0063783)
dregad   
2020-03-21 11:21   
(Last edited: 2020-03-21 11:28)

While it is true that there are a few config options such as db_password and crypto_master_salt that should probably never be eval'ed, I'm wondering whether it's worth the effort to implement new, specific API functions.

A simple check in config_eval(), making sure that the matched value is an existing global variable would probably do the trick (except for an improbable scenario where $g_db_password = 'Password%some_existing_config%';, in that case user should escape the % as explained in 0026798:0063782).

An alternative would be to define a global variable, whitelisting all the configs that should never be eval'ed, similar to $g_public_config_names, e.g.

$g_no_eval_config_names = array( 'db_password', 'crypto_master_salt', ... ); 

Then a simple in_array() lookup in config_eval() could skip the preg_match and replacement loop for those configs.

Of course we could also consider reversing the logic, i.e. implement this array as a list of configs where eval is allowed; I guess this would be closer to your intention of removing config_eval() (0021604), which I'm not convinced is something we should do.

EDIT: submitted the note by mistake, before I was done typing...

(0063784)
dregad   
2020-03-21 13:09   

PR https://github.com/mantisbt/mantisbt/pull/1635 implements the simple sanity check I mentioned in 0026798:0063783, which resolves the issue described here.

@atrol let me know if you feel it's worth pursuing the whitelist config option alternative, in that case it should probably be tracked separately.

(0063785)
atrol   
2020-03-21 20:30   
(Last edited: 2020-03-26 09:19)

Not sure if you are aware that since 1.2.0rc1, as a workaround \ can be used to escape the % in configs

Thanks for the hint, I wasn't aware of that

A simple check in config_eval(), making sure that the matched value is an existing global variable would probably do the trick ...

Sounds good as it fixes > 99,99% of real use cases, but complicates the rule when you have to use the escape workaround and when it works without escaping.
In a very improbable case an option might work in version x, but will no longer work in version x+1 as a new global variable has been introduced.
I am aware that I am a nitpicker, but I like clean and simple code ;-)

let me know if you feel it's worth pursuing the whitelist config option alternative

Not as an alternative, but an additional functionality.
After your changes this would just be needed for very improbable cases, so there is no priority for that.

removing config_eval() (0021604), which I'm not convinced is something we should do.

I still think that removing wouldn't be that bad.
Independent from the current issue and 0021604 there are other reasons,
e.g. our users are hardly aware that they change $g_update_bug_assign_threshold if they change $g_handle_bug_threshold in config_inc.php.
It's even more complicated if there is a combination of this setting in config_inc.php with changes via manage_config_work_threshold_page



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20273 [mantisbt] webpage minor sometimes 2015-11-15 21:23 2020-03-27 06:09
Reporter: longnd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: APPLICATION WARNING 0002702: Your session has become invalidated.
Description:

I have same problem as issue 0015502. The warning message appear and page redirect to my_page.php page.
I pass it by click reload button on my browser when warning page is still.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063792)
Starbuck   
2020-03-25 20:03   
(Last edited: 2020-03-25 20:04)

Ref 0019820 and forum post: https://www.mantisbt.org/forums/viewtopic.php?p=69845#p69845



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26811 [mantisbt] authentication minor always 2020-03-24 09:49 2020-03-25 06:12
Reporter: realitix Platform:  
Assigned To: community OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 2.24.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2.25.0  
    Target Version: 2.25.0  
Summary: Username regex is too strict by default
Description:

The regex used to validate username limits the extension dns name to 4 chars.
However, lot of domains exceed this rule.
The following python code give the longest dns suffix:

import urllib2

def is_ascii(s):
return all(ord(c) < 128 for c in s)

data = urllib2.urlopen("https://publicsuffix.org/list/public_suffix_list.dat&quot;)
nb_char = 0
longest_domain = None
for line in data:
if not line.startswith('//') and '.' not in line and is_ascii(line):
d = line.strip()
if len(d) > nb_char:
nb_char = len(d)
longest_domain = d

print("Longest domain {} with {} chars".format(longest_domain, nb_char))
The longest dns name is 18 chars

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063789)
realitix   
2020-03-24 09:49   

Here the pull request: https://github.com/mantisbt/mantisbt/pull/1634



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5583 [mantisbt] feature minor always 2005-05-09 10:54 2020-03-19 13:01
Reporter: hsoj Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ability to return user to their originating page after updating a bug
Description:

I need a way to go from updating the bug, back to the page I was on.

So say, I'm on the My View page, I click the pencil graphic by the bug I wanted to update, then when I'm done updating, I click on the submit button, I want to be taken back to the My View page.

Currently, I will be taken by default to the View Bug page.

Tags:
Steps To Reproduce:
Additional Information:

Perhaps this could work alongside the current submit button at the bottom of the update bug form? (i.e. in addition to the submit button, there is a submit button that says "Update bug and return to <pagename>."

Attached Files:
Notes
(0010052)
thraxisp   
2005-05-09 14:43   

We could probably take a similar approach to "set_project" and cache the referrer for the update.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21604 [mantisbt] performance feature have not tried 2016-08-14 08:48 2020-03-19 12:28
Reporter: atrol Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Discuss recursive configuration options
Description:

The discussion started as a side note to PR https://github.com/mantisbt/mantisbt/pull/840

atrol
A bit off topic.
I don't like to introduce one more of this '%var%' stuff.
I would like to discuss removal of recursion in defining configuration variables.
I don't see that much value in it and would expect a better performance if config_eval would be removed and
config_get_global and config_get would be simplified.

dregad

I don't see that much value in it

It makes configuration easier for admins, by avoiding the need to duplicate declaration of several related options. Consider the case of paths, or $g_cookie_prefix for example. Without the '%%' feature, the admin would have to manually set each of the cookies names in their config_inc.php.

You will probably and rightly argue that we do not need to make the cookies names configurable. Of course by refactoring the code (in the above case, getting rid of these config options), we can implement alternative that works without the recursion.

The questions are, whether this is worth the effort and what kind of performance improvement we can obtain by removing this feature.

expect a better performance if config_eval would be removed and config_get_global and config_get would be simplified.

If this is important to you, I would suggest to open an issue in the tracker, and evaluate how much we'd gain with your proposed approach.

evaluate how much we'd gain with your proposed approach.

atrol
Quick and dirty removal of config_eval
https://github.com/atrol/mantisbt/tree/config_eval_remove

There is a bit less memory usage (removed the caching of the evaled options) and there is about 7% better performance in 2nd benchmark, see results below.
Not outstanding, but not that bad for such a small part of the code.

Do you think it's worth to think more about it (obsolete cookie seetings, ...) and target it for a version > 2.0?

My View 2nd call

Original master-1.3.x
Page execution time: 0.3540 seconds
Memory usage: 10,411 KiB

Removed config_eval
Page execution time: 0.3499 seconds
Memory usage: 10,388 KiB

View Issues 2nd call

Original master-1.3.x
Page execution time: 0.2916 seconds
Memory usage: 10,514 KiB

Removed config_eval
Page execution time: 0.2705 seconds
Memory usage: 10,441 KiB

dregad

about 7% better performance in 2nd benchmark

7% is not bad indeed, I did not expect that much actually. But keep in mind that in absolute terms, it's still less than 0.02 s gain.

I'm still concerned about the loss of "just in time" evaluation of configs however, especially for paths that are quite likely to have been changed by admins - we need to be very careful not to cause regressions. Consider this example:

_config_defaultsinc.php

$g_path = (dynamically built from $_SERVER) // e.g. http://internal-hostname.example.com/mantisbt/
$g_icon_path = $g_path . 'images/';

_configinc.php

$g_path = 'http://example.com/mantisbt/'; # required e.g. due to use of reverse proxy

In this case, $g_icon_path == 'http://internal-hostname.example.com/mantisbt/images/, which is invalid in the reverse-proxy scenario; this would force the admin to manually define all variables referencing $g_path (formerly %path% in their config_inc.php (and knowing that they have to do so). Not very user-friendly, and likely to cause support issues when upgrading.

Do you think it's worth to think more about it (obsolete cookie seetings, ...)

Yes definitely. And get others' opinions too.

target it for a version > 2.0?

For sure a 2.x target, if we decide to move forward.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0053790)
atrol   
2016-08-14 09:06   

7% is not bad indeed, I did not expect that much actually. But keep in mind that in absolute terms, it's still less than 0.02 s gain.

0.02 s is not that much, but In best case it means 7% less payment when using CPU based cloud services, or being able to serve 7% more users on the same hardware, or about 2% less power consumption, ...

(0053793)
cproensa   
2016-08-14 11:06   

I have never needed to use recursive configurations, didn't meet the use cases, so i cant provide a precise opinion.

However, it has been talked about changing the configuration system in some ways: json based, in-database, hierarchical properties, etc.
Maybe it's worth to consider all these proposals as one common milestone.

(0053797)
atrol   
2016-08-14 16:00   

Maybe it's worth to consider all these proposals as one common milestone.

It is, but we are not that good in dealing with bigger conceptual changes.
It's better to complete small changes instead of having bigger changes nearly completed.

(0053798)
cproensa   
2016-08-14 17:57   

It's better to complete small changes instead of having bigger changes nearly completed.

true!
i'm only refreshing related ideas.

anyway, i would not hurry this proposal, if the only benefit is very small
Let's be wary with that measured 7% gain. Is it O(1), or O(n) related to bug count?
Simplfying code is harder to measure, but, there also exists already enough ugly code, ahem, filter api, or convoluted: Reflection

If going by the numbers, for my view page: see 0021044 for my measure of 75% gain, or 0020138 for 68% gain in view all page (in my specific instance)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26797 [mantisbt] administration feature N/A 2020-03-17 15:56 2020-03-17 16:01
Reporter: atrol Platform:  
Assigned To: atrol OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Add failed_login_count to user information
Description:

Add failed_login_count to user information on pages manage_user_page and view_user_page

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063774)
atrol   
2020-03-17 16:01   

PR https://github.com/mantisbt/mantisbt/pull/1632



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25956 [mantisbt] installation minor N/A 2019-08-03 08:29 2020-03-16 12:24
Reporter: dregad Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Increase minimum PHP requirement to 7.0
Description:

Since MantisBT 2.0.0 we officially support PHP 5.5.9 and later, aligned with Ubuntu14.04 LTS "Trusty Tahr" release (as per discussion in 0021841).

PHP 5.5 is EOL since 21 Jul 2016, and PHP 5.6 support ended 31 Dec 2018 so I think it's finally time to put 5.x behind us.

Continuing our strategy to align requirements with Ubuntu LTS releases, the oldest one as of this writing is 16.04 Xenial Xerus, which comes bundled with PHP 7.0 by default. Note: 7.0 is also EOL since 31 Dec 2018.

Tags:
Steps To Reproduce:
Additional Information:

Maintaining compatibility with PHP 5.x is becoming increasingly difficult, as more and more libraries and tools are dropping support for it (e.g. PHPUnit, and many others).

Travis CI is defaulting to Xenial for builds since May 2019 [1], and PHP 5.5 is not available at all under this distribution (see #25955). We can force use of Trusty for now to keep things working, but we need to make the switch at some point.

Attached Files:
Notes
(0062498)
cproensa   
2019-08-03 09:45   

I'm ok with this.

(0062499)
atrol   
2019-08-03 10:14   

I am also ok with this when speaking about my own installations.

But keep in mind that I introduced a hard check for minimum PHP version in version 2.13.0 to fix 0024128.
So upgrading from 2.x 2.20.0 would stop some (maybe even quite a lot) of installations.

The general problem is, that we don't offer some kind of LTS version.

(0062500)
dregad   
2019-08-03 11:05   

keep in mind that I introduced a hard check for minimum PHP version

Well if we require a minimum version, then I think it's normal that the software should fail with a message when the requirement is not met.

Even if technically, MantisBT would still work with older PHP versions, we can always instruct users who get stuck because they can't upgrade PHP on their server for whatever reason, to try - at their own risk of course - to change value of PHP_MIN_VERSION in their config.

(0062501)
atrol   
2019-08-03 11:43   

to change value of PHP_MIN_VERSION in their config

Not possible at the moment. The check is done before config_inc.php is included. There was a good reason to check it in a very early state.
See also discussion on the PR https://github.com/mantisbt/mantisbt/pull/1318

(0062655)
vboctor   
2019-08-25 16:42   

I always assumed that 2.0.0 we had PHP 7 as the target version, and support for PHP 5.x was best effort. Given that all 5.x are out of support, I think we should make PHP 7 a hard requirement and move on.

(0063758)
Kyle_Katarn   
2020-03-13 17:35   

Please do not underestimate the impact on users... and make this change very explicit.
I've found this ticket "by chance"... and i'm currently preparing my whole site to be PHP7 capable in order to upgrade to PHP7 before it gets released.... which takes me a lot of code rewritting, in particular to move from mysql to mysqli extension...

(0063766)
Kyle_Katarn   
2020-03-16 10:48   

https://www.mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.install.requirements

to be updated

(0063767)
atrol   
2020-03-16 10:57   

@Kyle_Katarn what has to be updated?

(0063768)
Kyle_Katarn   
2020-03-16 12:24   

The above mentionned web page, once PHP 7 becomes required.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26782 [mantisbt] db oracle major always 2020-03-16 02:46 2020-03-16 06:17
Reporter: amrodmbt Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Checking failed when "Attempting to connect to database as admin"
Description:

Checking failed when "Attempting to connect to database as admin" using Oracle Database type with correct login credentials.

Tags:
Steps To Reproduce:
Additional Information:

Bug fixed after correcting Line 413 of /admin/install.php from:

$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password );

to

$t_result = @$g_db->Connect( $f_hostname, $f_admin_username, $f_admin_password, $f_database_name );

Attached Files:
Notes
(0063765)
atrol   
2020-03-16 06:17   

Similar to 0026604:0063499



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26785 [mantisbt] db oracle minor always 2020-03-16 04:39 2020-03-16 04:39
Reporter: amrodmbt Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Database query failed when loading "Configuration Report" under "Manage Configuration"
Description:

The following error occurs when trying to open "Configuration Report" under "Manage Configuration":

APPLICATION ERROR 0000401

Database query failed. Error received from database was #932: ORA-00932: inconsistent datatypes: expected NUMBER got CHAR for the query: SELECT config_id, user_id, project_id, type, access_reqd, CASE type WHEN :0 THEN null ELSE value END value FROM m_config WHERE 1=1 AND user_id = :1 AND project_id=:2 ORDER BY user_id, project_id, config_id .

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Tags:
Steps To Reproduce:
Additional Information:

It seems the issue is related to data type conversion issue of parameter 0.
I have successfully solved this issue in Oracle DB by changing line 213 of adm_config_report.php from
"CASE type WHEN :complex THEN null ELSE value END"
to
"CASE WHEN type = :complex THEN null ELSE value END",
but I am not sure if this change will cause any problem in other types of database server.

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26783 [mantisbt] db oracle major always 2020-03-16 03:12 2020-03-16 03:12
Reporter: amrodmbt Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Schema generated does not include preset Special handling for Oracle during installation
Description:

When Oracle Database type is selected, special handling for Oracle in schema.php is not called correctly during installing database.

Tags:
Steps To Reproduce:
Additional Information:

It seems that install.php tries to fake out database access routines used by config_set_global( 'db_type', $f_db_type ), but global variable$g_db_functional_type, which is used by db_is_oracle() function in schema.php, is not reloaded according to this new db_type value.
The bug is fixed after adding the below line after Line 859 in install.php:

$g_db_functional_type = db_get_type( config_get_global( 'db_type' ) );

Moreover, due to stricter checking on declared variable after PHP 7.4, a isset() checking should be added on Line 1005 and 1007.
Otherwise, a SYSTEM NOTICE: 'Trying to access array offset on value of type null' in 'C:\inetpub\wwwroot\mantisbt\admin\install.php' will occur.

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
19964 [mantisbt] authentication minor always 2015-07-23 07:53 2020-03-15 15:27
Reporter: badfiles Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Wrong anonymous rights application
Description:

Anonymous users have different rights depending on the way they 'login'

Tags:
Steps To Reproduce:

Setup Mantis for anonymous login.
Allow reporting for anonymous user access level.
Delete all cookies.
Login as anonymous with /login_anon.php
You are detected as anonymous.
You can report an issue.
Delete all cookies.
Go to, say, /my_view_page.php
You are detected as anonymous.
You cannot submit an issue.

Additional Information:

This also affects on page contents: anonymous that has not truly logged in has no access to the bugs he should not have access to but he sees them in lists.

Attached Files:
Notes
(0051119)
atrol   
2015-07-23 08:53   
(Last edited: 2015-07-23 08:56)

I don't understand the problem at the moment.
Is there a reason (e.g. security) that you set Severity to major?

There is a difference between anonymous visiting the bugtracker (web crawlers, users just viewing, ...) and beeing logged in as anonymous user.
e.g. you will also notice that the current selected project is stored if you are logged in.

We would not need the "Login Anonymously" link if there is no difference.

As a side note: We don't recommend to use another access level than VIEWER for the anonymous account.
http://www.mantisbt.org/docs/master/en-US/Admin_Guide/html-single/#admin.config.misc

(0051134)
badfiles   
2015-07-25 05:16   

We would not need the "Login Anonymously" link if there is no difference.

In this case user should not be detected as 'anonymous' if he did not login as 'anonymous'

(0051176)
dregad   
2015-08-02 17:36   
(Last edited: 2015-08-03 02:14)

I believe the root cause for this is that when a page is browsed anonymously without prior login, the anonymous user's cookies are not actually set. This causes MantisBT API functions such as config_get() to return a generic value.

In this case, it returns whatever value is defined for $g_report_bug_threshold in config file instead of what might be defined in the database (global or project-specific).

PR https://github.com/mantisbt/mantisbt/pull/623

EDIT: for the record, removed the "git trunk" product version as the issue likely exists since a very long time.

(0051337)
vboctor   
2015-09-01 01:48   

Reducing severity to minor since this is a corner case and we likely had this bug for a long time.

(0051395)
dregad   
2015-09-07 18:51   
(Last edited: 2015-09-08 04:34)

EDIT: please ignore me - I posted this note in the wrong issue...



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
17577 [mantisbt] performance minor always 2014-08-07 19:46 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.2.17  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Improve print_user_option_list() performance
Description:

On instances with large number of users, the function has very poor
performance (e.g. > 20 seconds to load 28K users on this tracker).

This is an issue e.g. when filtering issues by reporter or when using adm_config_report.php, especially when the current project is 'All Projects'.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0041032)
dregad   
2014-08-07 19:49   

PR https://github.com/mantisbt/mantisbt/pull/238

The proposed fix is for master, I plan to backport it to 1.2.x if accepted.

(0051427)
atrol   
2015-09-09 09:50   
Reminder sent to: dregad

Should we target to 1.3.x or maybe even 2.0.x?

(0051429)
dregad   
2015-09-09 18:51   

The reason for targeting 1.2 was that our tracker was heavily affected by this issue. Now that we have upgraded it, a 1.3.x target is probably best (assuming I ever find the time to get to it :/).

The impact is still major IMO, although not blocking for release since not so many instances are likely to be affected by this.

(0051728)
cproensa   
2015-10-26 20:51   

for solving half of the problem: why not rewrite the user selector in filter section to fetch all users that appear in existing bugs?

This would be a query (fine tuned to some degree by filter parameters), but surely less work on the server.
The real problem here is that for "all projects", its fetching and combining a list of all users, repeating for every project.

And, for an improved resolution, change the select into an autocomplete widget (when available by js), with progressive remote search

(0051732)
dregad   
2015-10-27 04:20   

change the select into an autocomplete widget (when available by js), with progressive remote search

This is exactly where I want to go. I'm pretty sure I have a feature branch with initial research on this somehere, but I can't find it ATM.

(0051734)
atrol   
2015-10-27 04:39   

I'm pretty sure I have a feature branch

Maybe this one?
https://github.com/dregad/mantisbt/commits/dynamic-reporter-select

Independet from AJAX some other optimizations that did not make their way into the product but might be worth to review them again.

https://github.com/mantisbt/mantisbt/pull/238
https://github.com/mantisbt/mantisbt/pull/271

(0051735)
cproensa   
2015-10-27 06:48   

^^^ regarding that:
please have a look at 0020225, its somewhat related to the affected core functions

(0051753)
cproensa   
2015-10-29 08:04   

i have this branch with a rewrite of the affected functions
https://github.com/cproensa/mantisbt/tree/project_user_list

this shows great improvement, as testing with 20k users, 0000054:0000100 projects
still it can get faster, but i have some questions before it can be done
should i open a PR to comment there?

(0051780)
cproensa   
2015-10-31 21:41   

PR: https://github.com/mantisbt/mantisbt/pull/668

(0052164)
vboctor   
2015-12-22 03:38   
(Last edited: 2016-05-09 12:03)

Changing status to minor based on @dregad's 0017577:0051429 and offline discussion with @atrol since we are trying to identify blocking issues for v1.3. Though this may make it before the release, it is not blocking.

(0053204)
dregad   
2016-05-21 04:31   

cproensa's PR https://github.com/mantisbt/mantisbt/pull/769 (see related changeset below) greatly improves this performance issue.

(0053370)
atrol   
2016-06-14 02:17   

Independent from the AJAX approach and other optimizations, but will also enhance performance at least for some of the user lists, e.g. "Reporter" on "View Issues" page:

Wouldn't it be better to list just the users that reported an issue for the current project (distinct reporter_id from bug table)?

This will reduce the number of listed users and solve also the issue that we are not able to search for issues that have been reported by deactivated or deleted users, see 0010141.

(0053374)
cproensa   
2016-06-14 03:37   

distinct xxx from bug table

yes, that would be the simplest solution. For several filter fields this should be a valid approach.

able to search for issues that have been reported by deactivated or deleted users

but, irrc, then someone can complain that a reporter gets a hint of the existence of the deactivated users (i dont think this is an issue, just saying)

Now that theres some will to change things it filter api, this is a thing that should be done

(0053412)
atrol   
2016-06-18 13:17   

someone can complain that a reporter gets a hint of the existence of the deactivated users

We could add a new option for it, something like $g_show_deactivated_users_threshold = MANAGER;
But this will not prevent a user from using "View Issues" page to list all issues and look for users which are displayed strike out.
So adding this option would just let some people think that users with access level < $g_show_deactivated_users_threshold can't find deactivated users.

(0055289)
dregad   
2017-01-24 08:46   

Unless someone objects, I'd like to mark this one as resolved, considering cproensa's commit MantisBT master b433e7e6 - on this tracker it takes about 3-5 seconds to load the reporters' list (about 35K users), which I think is acceptable.

Other ideas for improvement should be tracked separately.

(0055298)
atrol   
2017-01-24 15:49   

or when using adm_config_report.php, especially when the current project is 'All Projects'

This is still quite slow.
Didn't have a deeper look, might be caused by missing indices on mantis_config_table.

(0061796)
dregad   
2019-03-29 09:40   

@cproensa wrote in 0017577:0051728

And, for an improved resolution, change the select into an autocomplete widget (when available by js), with progressive remote search

Opened 0025666 to track this



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26142 [mantisbt] plug-ins feature N/A 2019-09-15 14:42 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Improve handling of invalid / incorrectly installed plugins
Description:

When installing plugins in a MantisBT instance, or when moving / upgrading MantisBT there are several things that can go wrong

  • The case of the directory in which the plugin is installed does not exactly match the plugin's name
  • A registered plugin is no longer present on disk
  • The plugin code could be invalid
  • etc.

Currently, some of these scenarios are not detected by Core, making it difficult for the administrator to figure out what is wrong (or that something is wrong to begin with).

If there are any invalid plugins, the Manage Plugins page should detect them and present the administrator with a list, allowing them to fix the problem.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: invalid_plugins_not_detected.png (60,489 bytes) 2019-09-15 15:07
https://mantisbt.org/bugs/file_download.php?file_id=8714&amp;type=bug
new_missing_or_invalid_plugins_section.png (81,287 bytes) 2019-09-15 15:38
https://mantisbt.org/bugs/file_download.php?file_id=8715&amp;type=bug
new_admin_checks.png (39,421 bytes) 2019-09-15 15:38
https://mantisbt.org/bugs/file_download.php?file_id=8716&amp;type=bug
TestInvalidPlugins.tar.gz (333 bytes) 2019-09-15 15:42
https://mantisbt.org/bugs/file_download.php?file_id=8717&amp;type=bug
Notes
(0062808)
dregad   
2019-09-15 15:07   
(Last edited: 2019-09-15 15:10)

Consider the following scenario: a MantisBT instance with a successfully installed 3rd party plugin (e.g. Announce).

  • Migrate MantisBT to a new location (fresh install, copying the database -> the plugin was not migrated)
  • Install a new plugin (e.g. Snippets), but create the directory with wrong case (snippets)
  • For the sake of testing, throw in a couple of invalid plugins (with undefined name / version properties in the plugin's base class)

Contents of plugin directory:

$ ls -1 plugins
Gravatar
MantisCoreFormatting
MantisGraph
snippets
TestInvalidNoName
TestInvalidNoVersion
Web.config
XmlImportExport

Contents of _mantis_plugintable:

mysql> select * from mantis_plugin_table;
+----------------------+---------+-----------+----------+
| basename             | enabled | protected | priority |
+----------------------+---------+-----------+----------+
| MantisCoreFormatting |       1 |         0 |        3 |
| Gravatar             |       1 |         0 |        3 |
| Announce             |       1 |         0 |        3 |
+----------------------+---------+-----------+----------+
3 rows in set (0.00 sec)

None of these errors are visible on the GUI (except for possibly missing menu items, etc. as the plugins are not registered) as shown on the screenshot below.

(0062809)
dregad   
2019-09-15 15:38   
(Last edited: 2019-09-15 15:44)

PR https://github.com/mantisbt/mantisbt/pull/1565

See attached screenshots showing how the test scenario looks like with the new code, in

  • Manage Plugins Page
  • Admin Checks

Note that if there are no invalid or missing plugins, the section is not displayed.

(0062810)
dregad   
2019-09-15 15:42   

For the record, here are the 2 dummy invalid plugins I used for testing.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25764 [mantisbt] email feature N/A 2019-05-15 19:44 2020-03-15 15:27
Reporter: TomekAP Platform:  
Assigned To: community OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Enable S/MIME signed e-mail notifications
Description:

Now emails can not be signed, nevertheless, there is such option in phpmailer. I suggest adding in email_api.php at the end of section "case PHPMAILER_METHOD_SMTP:"

$t_mail->sign(config_get_global('cert_filename'), config_get_global('key_filename'), config_get_global('key_pass'), config_get_global('extracerts_filename '));

And add some variables in config_defaults_inc.php:

And in config_defaults_inc.php
/**

  • Path to mail certification file
  • @global string $g_cert_filename
    */
    $g_cert_filename = '';

/**

  • Path to mail private key file
  • @global string $g_key_filename
    */
    $g_key_filename = '';

/**

  • mail private key pass
  • @global string $g_key_pass
    */
    $g_key_pass = '';

/**

  • Path to mail extra certification file
  • @global string $g_sign_extracerts_file
    */
    $g_sign_extracerts_file = '';
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0062073)
dregad   
2019-05-16 04:19   

Feel free to submit a pull request on Github with a proposed implementation for review.

(0062085)
TomekAP   
2019-05-17 08:03   

I created branch, but can not push it:
Username for 'https://github.com': TomekAP
Password for 'https://TomekAP@github.com':
remote: Permission to mantisbt/mantisbt.git denied to TomekAp.
fatal: unable to access 'https://github.com/mantisbt/mantisbt.git/': The requested URL returned error: 403

(0062086)
dregad   
2019-05-17 09:34   

You need to push to your own fork repository, i.e. https://github.com/TomekAP/mantisbt.git then on the GitHub UI, submit a pull request.

(0062088)
TomekAP   
2019-05-17 10:44   

now I hpe it is OK:
https://github.com/mantisbt/mantisbt/compare/master...TomekAp:master

(0062092)
dregad   
2019-05-18 09:15   

@TomekAP almost there... you just need to actually click the Create pull request button to submit it for review.

(0062094)
TomekAP   
2019-05-18 09:29   

Now is it OK?
https://github.com/mantisbt/mantisbt/pull/1512

(0062095)
dregad   
2019-05-19 06:42   

That's it. Will review as time allows

(0063202)
dregad   
2019-12-09 06:46   

New PR https://github.com/mantisbt/mantisbt/pull/1591



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24689 [mantisbt] administration feature N/A 2018-08-22 09:04 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Remove clickable alphanumeric index in manage_user_page.php
Description:

This follows discussion with @atrol in PR 1381.

The new search functionality for the manage user page (see 0012677) is much better and more flexible than the existing functionality, which only allows filtering on username beginning with A-Z, 0-9.

As a follow-up work item, we should

  • remove the alphanumeric index buttons at the top of manage_user_page.php
  • make sure it is still possible to filter Unused and New accounts (currently they can only be excluded via Hide Inactive)
  • obsolete config option $g_default_manage_user_prefix

print_manage_user_sort_link() API function can probably be removed after that, as well asnever_logged_in_titleand1_week_titlelanguage strings.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0060478)
atrol   
2018-08-23 05:57   

obsolete config option $g_default_manage_user_prefix

Implemented as part of PR1381



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24628 [mantisbt] markdown minor have not tried 2018-07-24 05:39 2020-03-15 15:27
Reporter: zringele Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.12.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Double quotes " and lesser than sign < are shown as HTML entity within Markdown code blocks
Description:

When Markdown option is enabled in MantisCoreFormatting plugin, HTML special chars within backticks are displayed as the corresponding entities.

  • double quote " &quot;
  • lesser than < &lt;

Same issue with code blocks

&quot; &lt;
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0060309)
zringele   
2018-07-24 05:42   

& quot ; I mean

(0060311)
atrol   
2018-07-24 05:59   

zringele,

I was not able to reproduce your problem with a fresh install of the latest stable MantisBT release (2.15.0 at the moment).

If you are running an older version, I recommend that you upgrade to the latest (download from [1]). If after doing so the problem persists, do not hesitate to reopen the issue and provide detailed step-by-step instructions to reproduce the issue; the following additional information may also be useful:

  • Exact version of MantisBT, PHP, Database, Web server, Browser and Operating System
  • Relevant customizations (e.g. changes in config_inc.php, etc)
  • Installed plugins or custom functions ?
  • Was the MantisBT source code modified in any way ?

[1] http://mantisbt.org/download.php

(0060312)
zringele   
2018-07-24 08:14   
(Last edited: 2018-07-24 08:15)

&quot;
Looks like the problem is only when using " inside a code tag like this &quot;

(0060313)
atrol   
2018-07-24 15:06   

The PR that fixes 0024241 fixes also this issue.

(0062147)
dregad   
2019-05-28 04:21   

Work-in-progress fix https://github.com/mantisbt/mantisbt/pull/1332



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24241 [mantisbt] markdown minor always 2018-04-09 17:28 2020-03-15 15:27
Reporter: atrol Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.12.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: $g_html_valid_tags are not rendered if Markdown is enabled
Description:

This is a try to use one of the default $g_html_valid_tags (strong).

<strong>Some strong words</strong>

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0059565)
dregad   
2018-04-13 09:55   

Work-in-progress attempt to fix this issue can be found in PR https://github.com/mantisbt/mantisbt/pull/1332.

Testing and feedback would be welcome.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24188 [mantisbt] ui minor always 2018-03-29 18:40 2020-03-15 15:27
Reporter: vboctor Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.12.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Update issue history code to display user names via standard APIs
Description:

When preparing a username for display, use prepare_user_name(). Feel free to add an argument to express if you want it in text vs. html, but the business logic for formatting a user name should be captured in one place. We should also consider having history_get_event_from_row() take an argument for html vs. text and pass it to prepare_user_name(), so the right format happens for html with tooltip, class name, etc vs. text email.

This is follow up change to the following PR:
https://github.com/mantisbt/mantisbt/pull/1321

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063046)
atrol   
2019-11-01 08:00   

Unassigned as I will hardly be able to invest time for it in short/mid term.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22841 [mantisbt] authentication minor have not tried 2017-05-06 17:50 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Don't truncate password when it exceeds db field size
Description:

Following up on discussion in PR 1048.

auth_process_plain_password() silently truncates the processed password to the size of the underlying database field.

This can cause problems when the password field's size is increased, as it will cause users to no longer be able to login, forcing them to reset their password.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0056786)
dregad   
2017-05-06 18:14   

PR https://github.com/mantisbt/mantisbt/pull/1048

(0062010)
thE_iNviNciblE   
2019-04-28 09:22   

FYI:

"New lengths vary depending on the database management system:

MariaDB version 10.0 and higher - 80 characters
PostgreSQL version 7.3 and higher - 61 characters
PostgreSQL versions lower than 7.3 - 31 characters
Microsoft SQL (all versions) - 128 characters
MySQL version 5.7.8 and higher - 32 characters
Percona version 5.7 and higher - 32 characters
Other database management systems - 16 characters"

(0062011)
dregad   
2019-04-28 11:27   

@thE_iNviNciblE Your post is confusing. Where do you get this information from ? The size of password field is set to 64 chars by MantisBT at installation time, and that does not depend on RDBMS.

Or maybe you meant something else, in that case please clarify...

(0062254)
thE_iNviNciblE   
2019-06-14 02:44   

@dregad:

i've seen information here: https://docs.plesk.com/release-notes/onyx/change-log/#179-preview13

(0062257)
dregad   
2019-06-14 03:44   

That's the changelog for Plesk, I don't see how it is related to MantisBT.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22840 [mantisbt] authentication minor sometimes 2017-05-06 17:43 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Don't expire user sessions when updating password hash after login method change
Description:

As per @vboctor's suggestion

user_set_password() assumes that it is being called by a user, so it updates the cookie to expire browser sessions.

The same function is used by authentication API's auth_does_password_match() when updating the password hashes after a change of login method, only in this case there is no need to expire the sessions since the password itself is not changing - only the way it is stored in the database.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0056787)
dregad   
2017-05-06 18:14   

PR https://github.com/mantisbt/mantisbt/pull/1048



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22464 [mantisbt] custom fields minor always 2017-03-04 04:53 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Loose type comparison can prevent custom field update
Description:

The current use of loose comparison to determine whether a custom field needs to be updated can cause an update not to occur even though it should, e.g. when the old value is '01' and the new value is '1.0'.

Tags:
Steps To Reproduce:
Additional Information:

Initially reported by @syncguru and @atrol in https://github.com/mantisbt/mantisbt/pull/1035#discussion_r104065620

Attached Files:
Notes
(0055902)
dregad   
2017-03-04 05:00   

https://github.com/mantisbt/mantisbt/pull/1035



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21908 [mantisbt] security minor always 2016-11-13 06:45 2020-03-15 15:27
Reporter: atrol Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Weakened security headers in 2.0.x
Description:

2.0.x comes with http_csp_add( 'style-src', "'unsafe-inline'" ); in http_api.php.
We don't allow unsafe-inline styles in 1.3.x.

Tags:

csp

Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0058143)
yanual   
2017-11-06 05:56   

Why you don't allow unsafe-inline styles in 1.3.x. ?

(0058144)
atrol   
2017-11-06 06:03   

Why you don't allow unsafe-inline styles in 1.3.x. ?

Wrong question, it should be: Why you allow unsafe-inline styles in 2.x?

Allowing unsafe-inline styles decreases security.
That's why I reported the issue.

(0058147)
dregad   
2017-11-06 06:40   

@yanual I suggested you read https://stackoverflow.com/a/31759553/1045774 for a brief explanation of the potential risks to your site when unsafe-inline styles are allowed.

(0058148)
yanual   
2017-11-06 09:11   

@atrol your formulation is indeed better.
Ok, I will wait patiently for postponement of the treatment of the issue.
@degrad i know these risks.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
21694 [mantisbt] ui minor have not tried 2016-09-16 18:01 2020-03-15 15:27
Reporter: cproensa Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.0.0-beta.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: inconsistent presentation of required fields
Description:

The mark for required fields is styled inconsistently on several forms
Attached is example of two where the presentation differs.

"my account" form, the "" is separated from text
"report page", the "
" has no separation

The underlying issue is that now the "required" symbol has to be written explicitly in the HTML. In version 1.3 this was inserted by css :before

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Selección_046.png (8,253 bytes) 2016-09-16 18:01
https://mantisbt.org/bugs/file_download.php?file_id=6877&amp;type=bug
Selección_047.png (13,670 bytes) 2016-09-16 18:01
https://mantisbt.org/bugs/file_download.php?file_id=6878&amp;type=bug
2016-10-19 10_52_54-Report Issue - MantisBT.png (8,415 bytes) 2016-10-19 04:53
https://mantisbt.org/bugs/file_download.php?file_id=6928&amp;type=bug
Notes
(0054268)
mcmo   
2016-10-19 04:53   

this is also the case in v2.0.0-beta.3

(0057602)
cproensa   
2017-09-03 19:05   

This is the css that was used in v1.3

div.form-container fieldset label.required:before,
th label.required:before,
td label.required:before {
    font-size: 8pt;
    content: '* ';
    color: red;
}

should we apply something like that, instead of explicitly printing the *?

(0057606)
dregad   
2017-09-04 07:12   
(Last edited: 2017-09-04 07:14)

should we apply something like that, instead of explicitly printing the *?

IMO, yes, that would be much better

EDIT: maybe consider using a margin-right for the spacing instead of hardcoded space (and we should make sure it works with RTL as well)

(0057609)
atrol   
2017-09-04 10:38   
(Last edited: 2017-09-04 12:06)

@dregad @cproensa
Are you aware of css/common_config.php which deals with required class?

div.form-container fieldset.required:after {
    position: absolute;
    margin: -1.75em 0em 0em .5em;
    font-size: 8pt;
    content: '* &lt;?php echo lang_get( 'required' ); ?>';
    color: red;
}

This approach allows to implement also language dependant display (Assuming that * is not the best characater e.g, for Chinese).
But I thought also about removing this generated CSS as it's not cached in browser and generated / delivered again and again.
Maybe delivering static content and having something like lang/css/english.css lang/css/german.css ...

Another thing to consider would be Translatewiki.

[Edit 1] And while we are on it, we should also consider HTML5 client side validation, https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_required

https://github.com/mantisbt/mantisbt/pull/1026

[Edit 2] The HTML5 required attribute could also be used for styling https://css-tricks.com/almanac/selectors/r/required/

(0057611)
dregad   
2017-09-05 05:25   

@atrol This CSS was used to display the "legend" for the asterisk marking mandatory fields, at the form's bottom in Mantis 1.3. As far as I can tell, it is no longer used in 2.0 (git grep 'fieldset.*class' yields no results in php files), so the style could probably be removed.

Note: an alternative to the dynamic stylesheet could be to use a jQuery AJAX to get the language string, which would probably be easier than maintaining many language-specific static CSS files.

Re: client side validation, required only checks that the field is effectively not empty; a single space bypasses that. But anyway using this attribute makes perfect sense.

(0057612)
cproensa   
2017-09-05 07:38   

Ideally, with PR 1026, required inputs would be identified by it's "required" property.

If we still want to add a "*" to labels, we could base the display of that on the related input's property.
Afaik, this can't be done directly in css, when having
&lt;label for=&quot;xxx&quot;>&lt;/label> &lt;input id=&quot;xxx&quot;>

However, if having a label.required style, this class can be added with js to those labels linked to required inputs.
(Or simply use it staticly on the label)

(0057614)
atrol   
2017-09-05 08:05   

As far as I can tell, it is no longer used in 2.0

Right, didn't find any usage, opened 0023310 to remove it.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20874 [mantisbt] ui minor always 2016-05-04 21:45 2020-03-15 15:27
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.0-beta.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Content Security Policy blocked embedded images added by Chrome Extension
Description:

The content security policy that we have in place blocks images embedded in the html whether they are embedded by a plugin or by a Chrome extension. The case where I hit this issue where the a chrome extension that added an integration button but the image (which was embedded as background image in css) was blocked.

The fix for this specific case is to whitelist "data:" as per the stackoverflow thread below?

http://stackoverflow.com/questions/18447970/content-security-policy-data-not-working-for-base64-images-in-chrome-28

We can do the following:

  1. Ask administrator to update code to add their CSP.
  2. Add a config option that enables admin to whitelist sources.
  3. Add an event to enable plugins to whitelist their own sources. Gravatar's plugin approach overrides previous header as per my understanding rather than complements it.

I personally think 2 and 3 should be implemented. What are the thoughts of also enabling "data:" by default?

@dregad and @atrol what are your thoughts?

Tags:

mantishub

Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0053072)
atrol   
2016-05-05 05:17   
(Last edited: 2017-03-02 05:03)
  1. Add a config option that enables admin to whitelist sources.

Didn't try, but the existing option custom_headers might be enough for it

What are the thoughts of also enabling "data:" by default?

Don't have time to check all details for that. Might mean less security out of the box, thus should be a decision of the administrator.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20577 [mantisbt] plug-ins feature have not tried 2016-02-07 18:45 2020-03-15 15:27
Reporter: cproensa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Consistent use of EVENT_UPDATE_BUG_DATA
Description:

Currently the event EVENT_UPDATE_BUG_DATA (chain) is only triggered from the bug_update page.
Seems like the expected behaviour is for it to be triggered on any modification applied to bug data, and not only from the bug_update page.
Actions that modify data performed from action group page, soap, and other places, bypass this event.

A proposal:
1) move this event triggering into BugData->update
2) restrict the use of "bug_set_field" outside core api. Use BugData instead.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0052480)
dregad   
2016-02-08 04:28   

Proposal sounds OK to me, but how do you propose to restrict use of bug_set_field(), more to the point, how to enforce such a restriction ?

(0052483)
cproensa   
2016-02-08 04:49   

I mean "restriction" as reviewing current use and change into BugData higher level operations whenever its appropiate. Enforcing is not possible, nor recommended...
bug_set_field() may have its place outside core, but caller must be aware that this bypasses some side functionality.

So one point of discussion here is to delimit which changes should be treated "silently", and which one should trigger side events and notifications

(0052517)
cproensa   
2016-02-14 11:07   
(Last edited: 2016-07-31 19:29)

PR: https://github.com/mantisbt/mantisbt/pull/834

(0054878)
dregad   
2016-12-30 11:25   

Updated PR https://github.com/mantisbt/mantisbt/pull/966

See related issue in Source integration plugin https://github.com/mantisbt-plugins/source-integration/issues/189

(0054884)
cproensa   
2017-01-01 11:44   

I copy and answer here @vboctor comments on the PR966
https://github.com/mantisbt/mantisbt/pull/966#pullrequestreview-14807058

Good change @cproensa - I've added some inline comments. But here are my high level comments:

It would be great to start the new extensibility model for these events where we have an object
per event. For the event objects it is tempting to re-use BugData as a field on these >events, but
I would rather have the raw properties or event objects that we want to expose (normal or calculated).
This will give have the following benefits:

I understand your proposal as having a dedicated class for each event
This object would be only used for passing the data to and back from the event callback?
From previous conversations, i guessed the idea to be passing a parameter as, for example, array defined as:
array( 'new_bug_data' => <new BugData object>, 'old_bug' => <old BugData object> )
instead of having dedicated parameters in the callback function.
The aim is to have the ability to add new parameter, or optional ones that may appear in some cases,
inside this array, and not break the callback definition for small changes like those.

If a property x (e.g. id) on BugData makes sense for Event 1 (create-post) but not Event 2 (create-pre), then it will only show up on Event 1.
If a property x is read-write on Event 1 but read-only on Event 2, then this can be achieved.
We can incorporate logic via property setters or methods on such event objects.

This expands the idea of a dedicated class, which would be populated with some/all of the Bugdata properties, in this example.
This would add a lot of overhead, to copy those fields, and to manage if they are updated by the plugin.
Further, in this example, the approach should be to actually send the raw BugData, which encapsulates the data being modified.

In a future where more object-mapping is used to manage all application entities, this may make sens, to have
a readonly instance, and an editable one, for each type of object (eg, BugData). But this may be managed at the entity classes,
not in the event. For simplicity, in that scenario, i'd go with embedding a read-only entity object in the event data object.

A change in internal BugData structure doesn't break plugins.

If we are worried about potential changes in BugData class, then the right move is to clean up that class. This class
was introduced some time ago, but has been left half-cooked. It's good as a starting point but if it's going to be used
to allocate all bug-related logic, maybe it needs a restructuration.
In your suggestion of keeping a stable interface, this could be rethought to separate a clean stable base class/interface,
façade, etc, and a lower level logic layer.

An internal property on BugData doesn't show up to plugins.

This may be out of scope. Currently plugins currently have access to all core functions, without restrictions.

I would rather if plugins don't register callbacks, but depend on PRE vs. POST events to do the logic without side-effects
in PRE and do the necessary action in POST.

If i understand correctly, that's how it's supposed to work. Maybe it has not been made clear enough in the documentation.
PRE-processing eventa can modify any data inside the current BugData object. They should not make changes outside of this class
for example, add a note, because the update action is not guaranteed to be finished.
POST-processing events should do all the external changes, becasue here is when the BugData changes has been already commited.
Furthermore, they should not stop the execution.

Ideally, and i have it planned for a later change, is to move some validation/changes into this workflow inside BugData.
For example, the change of status when a bug is assigned, should be made at the PRE-processing stage.

All the stuff about managing callbacks inside the BugData class is to adapt the current core actions to this requeriment,
where side effects are performed after preprocessing, after BugData changes are saved, and before notifying a post-processing
event.

We could also consider having an event type where if a plugin fail, we would stop the execution of the rest (for PRE events),
and another where we would continue with other plugins (for POST events).

Currently, the non-obviusly-documented method to stop a update execution is to throw an error. This is an all-or-nothing approach
but currently it's the only one availabe.
Ideally if a plugin, when hooked to a pre-processing event, must stop the modification, it can be flagged by raising an exception
instead of an error.
The exception can be catched from the outside code, for example: at bug action group page.

Your suggestion would mean that a true or false must be explicitly returned by each plugin, and the event manager then stops the
execution chain. This is a clean solution, however, think that a pugin would usually want to return a reason on why the execution
was stopped, very much like the error code, or exception payload, would express an invalid operation.

It would be great for the update method to know the before/after state. This enables better email notifications and other
changes that depend on the delta rather than just the final state. Currently the code disables email notification from within
update method and triggers it by the caller. Some ORM models would have such functionality built-in.

The update methods provide parameters for both the modified BugData object, and the previous unchanged object. This was existing
functionality in these events.
The email notifications, with this PR has been kept the same as they were before.
BugData update already has some checks to compare old and new values and issue email notifiacionts based on this.
Old code that did changes directly (by updating bug table), has hardcoded notification logic. This must be reviewed
more coarefully, becasue some of them bypasses notifications on purpose, or trigger a different notification
than the one a raw change in BugData properties does.

I suggest targeting this to master branch to go into a future 2.x minor release.

In a totally personal note: i really need this functionality as soos as posible. This has been in work since 1.3.0.
I have some complex plugins that has some broken functionality because of this, and migrating to a 2.x version is not
feasible in the short term.

Answering some of the inlined comments:

Did you consider having "create_callbacks"? At least as it appears externally to the calls via add_create_callbacks()?

Yes, i did. However, at the moment i've tried to keep it simple.
As i told prevously, the callbacks implementation is to fill the void of not having object oriented entities, where
changes can be staged, validated, and comitted in a managed way.
Ideally, this situation should be transitional until in some future, the same strategy is used for all entities.

Should we use PHP anonymous functions here to define an anonymous function that calls file_move_bug_attachments
and pass in the required parameter, rather than getting a separate function name and array of parameters?
This applies to callback registration and all calls to it.

It's done somehow with other callbacks. For example:
$add_bugnote_func = function( array $p_bugnote_params ) { ... }
$t_updated_bug->add_update_callback( $add_bugnote_func, array( $t_bugnote_params ) );

Your proposal is more oriented at the typical javascript programming style, where callbacks are defined ad-hoc
as anonymous functions. Im't not sure if that is feasible here. At the time of execution of that code, the data
that is neede (for example, the bugnote text, etc) must be stored somewhere within the code scope.
I found the way to have it done is by storing it as the "parameters" which will be passed to the callback function.
Originally, the bugnote data would have been fetched from POST inputs, but i'd rather extract it from bug_update page
main body, and keep it reserved for later use, than accesing POST within the BugData update callbacks later.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20540 [mantisbt] attachments major always 2016-01-25 12:28 2020-03-15 15:27
Reporter: vboctor Platform:  
Assigned To: dregad OS:  
Priority: high OS Version:  
Status: assigned Product Version: 1.2.16  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Implement upgrade step to cleanup corrupt disk attachments after db->disk conversion
Description:
  1. Set [ $g_file_upload_method = DISK; ] and configure [ $g_absolute_path_default_upload_folder ] in config_inc.php
  2. Report an issue with attachment.
  3. Check the attachment in mantis_bug_file_table, the content is not null. However, the disk file is also existed in the folder.

3a. If access /admin/move_attachments_page.php, the attachment count is not 0.
3b. If administrator do 'move to disk', the 'diskfile' will be mapping to a new place which file size is 2 bytes. Thus no one can download correct file content.

query result the attachment:
<pre>
+----+--------+-------+-------------+----------------------------------+--------------+---------------------------------------+----------+-----------+---------+------------+---------+
| id | bug_id | title | description | diskfile | filename | folder | filesize | file_type | content | date_added | user_id |
+----+--------+-------+-------------+----------------------------------+--------------+---------------------------------------+----------+-----------+---------+------------+---------+
| 5 | 4 | | | b66c36fbdc246d15ca50cb51073b0aca | tempfile.PNG | /volume1/web/wnbu/mantis-attachments/ | 17893 | image/png | '' | 1449109357 | 2 |
+----+--------+-------+-------------+----------------------------------+--------------+---------------------------------------+----------+-----------+---------+------------+---------+
</pre>

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0053266)
vboctor   
2016-06-04 19:45   

This is not a blocking issue for 1.3.x, since the issue is fixed and we just need a cleanup task in check.php that can be done at any point in time. It can also be done in 1.2.x or 1.3.x or 1.4.x, etc.

Let's use 0020340 to track the future work to do cleanup. Delaying 1.3.x for this is just creating more bad db blobs for customers using 1.2.x.

(0053806)
dregad   
2016-08-15 04:40   

Reopening to track the implementation of the schema upgrade cleanup step, as mentioned in 0020340:0053805.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20431 [mantisbt] db schema minor N/A 2015-12-28 05:22 2020-03-15 15:27
Reporter: dregad Platform:  
Assigned To: dregad OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Use utf8mb4 charset for new MySQL installations
Description:

We currently create the database with 'utf8' charset and 'general_ci' collation.

In MySQL, utf8 charset uses up to 3 bytes, which means some characters can't be stored properly. Since MySQL 5.5.3 the 'utf8mb4' charset is available, and does not have this limitation.

We should use utf8mb4 for new installation.

In addition, we default to 'general' collation which sometimes yield incorrect sort order for special (multibyte) characters. See MySQL documentation [1] for examples and more explanation.

[1] http://dev.mysql.com/doc/refman/5.7/en/charset-unicode-sets.html

Tags:

schema

Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0052209)
dregad   
2015-12-30 18:21   

Switching to utf8mb4 charset may not be as simple as I thought initially...

MySQL limits the maximum index key size depending on the engine used:

  • MyISAM: 1000 bytes [1]
  • InnoDB: 767 bytes [2] in MySQL < 5.7.7 (unless 'innodb_large_prefix' option is enabled), 3072 bytes in 5.7.7 and above (or when innodb_large_prefix == ON)

Considering 4 bytes per characters, the maximum length of a character field used as index key is:

  • MyISAM: 1000 / 4 = 250 chars
  • InnoDB: 767 / 4 = 191 chars

Schema update step 196 updated the user table's username field to 255 chars in length (see 0008017). Converting the table to utf8mb4 or trying to create it from scratch with that charset triggers the following error

1071: Specified key was too long; max key length is 767 bytes

We have the following options:

  1. forget about utf8mb4, keep using 3-byte utf8 (eventually, someone will face issues as they try to store 4-byte unicode chars, e.g. emoji or some CJK characters)
  2. reduce size of username column from 255 to 191 chars
  3. change the idx_user_username index to become a 'prefix' index, i.e. to only cover the first 191 chars of the username field

Option 3 is probably acceptable, since it seems highly unlikely that we would have email addresses longer than 191 chars to begin with, and even less to have 2 of them differ only on or after the 192nd char. Nevertheless there is still the technical possiblity that this situation will occur.

I would recommend number 2 as the safest option, and assuming we don't really need 255 chars for the username. I don't think we do; the original requirement from 0008017 was to allow storing email addresses as user identifier; 255 was set arbitrarily.

[1] http://dev.mysql.com/doc/refman/5.7/en/myisam-storage-engine.html
[2] http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html

(0052210)
dregad   
2015-12-30 18:23   
Reminder sent to: atrol, vboctor

Your opinion on 0020431:0052209 would be appreciated.

(0052211)
vboctor   
2015-12-31 05:25   

Looking at the code under admin/check/ it seems that our current minimum requirement for MySQL is 5.0.8 and hence if we are planning to use utf8mb4, then we need to up such requirement to 5.5.3. Not sure how common is 5.5.3. Though if we end up waiting, then we could make the move directly to 5.7.7 where it wouldn't be necessary to reduce the field size.

I don't have a problem with reducing the max size for username. I assume based on the above, this is the only offending field.

(0052214)
atrol   
2015-12-31 12:25   

To wait for 5.7.7 is no option.
Even the next version of LTS Ubuntu comes with an older version.

Ubuntu LTS versions that come with 5 years of security updates [1]
12.04 5.5.22
14.04 5.5.35
16.04 5.6.27

Red Hat Enterprise Linux is quite another story [2]
RHEL-5.1 5.0.95
RHEL-6.7 5.1.73
RHEL-7.2 no longer MySQL but MariaDB 5.5.44

So requiring 5.5.3 would rule out Red Hat.

It seems we should stay with utf8 at the moment.

[1] http://distrowatch.com/table.php?distribution=ubuntu
[2] http://distrowatch.com/table.php?distribution=redhat

(0052215)
dregad   
2015-12-31 18:21   

Thanks to both of you for your comments.

Actually my intention was not to enforce utf8mb4 across the board, but rather to detect the mysql version at install time, and define the charset accordingly (utf8 if < 5.5.3, utf8mb4 otherwise), allowing instances running recent software to benefit from better unicode support..

We can keep MySQL 5.0.8 as minimal support, even though that's effectively end-of-life since 2013.

With regards to MariaDB, at least until version 5.5 it's supposed to be a "drop-in replacement" for MySQL, so (in theory) RHEL 7.2 should be just fine and use utf8mb4.

Not sure how things will evolve with MariaDB 10.x / MySQL 5.7 though, but that's another topic.

(0052230)
dregad   
2016-01-01 19:25   

Pull request https://github.com/mantisbt/mantisbt/pull/699

(0052239)
vboctor   
2016-01-03 20:43   
(Last edited: 2016-01-03 20:46)

@dregad How about the option is using a prefix index and updating the API(s) that looks up by username to potentially handle more than one match? That is assuming the DBMS won't filter these independent of the index anyway. Which I think it should.

(0052240)
dregad   
2016-01-04 10:39   

The problem is not with filtering, it is about ensuring the key's uniqueness, which can't be guaranteed with a prefix index.

Updating the API would not resolve this issue, and sounds like overengineering for an issue that is anyway quite unlikely to occur (have you ever heard of a 191-char long e-mail address ?)

(0053358)
dregad   
2016-06-13 06:17   

Interesting note on Drupal's approach to handle index size limitation on utf8mb4 fields https://www.drupal.org/node/1314214

(0053413)
dregad   
2016-06-18 16:32   

In order to (greatly) simplify the implementation of utf8mb4 charset support, including upgrade steps and future maintenance, I would like to propose that we increase the minimum version requirement for MySQL to 5.5.3 in 2.0.x.

5.5.3 was released in March 2010. It was actually a milestone release, the General availability is 5.5.8 (released 2010-12-03), but I don't see the need to require a higher version than we actually need.

As pointed out by atrol, this will prevent some distros from running our software, but I think that's an acceptable trade-off.

For the record, Drupal followed a similar approach, as documented in the link I referenced in my previous post.

(0053416)
atrol   
2016-06-18 17:12   

we increase the minimum version requirement for MySQL to 5.5.3 in 2.0.x.

I would prefer this instead of implementing workarounds to fix 0021101.
Maybe target for 2.1.x if someone think it's to early to enforce 5.5.3.

(0053418)
dregad   
2016-06-18 17:35   

I would prefer this instead of implementing workarounds to fix 0021101.

I agree, but I also believe that we do need a solution for 1.x as well, since depending on MySQL settings, use of any 4-byte char will either result in

  • the offending char and everything after it to be silently truncated
  • a DB error to occur, preventing data from being saved to the DB

The workaround I propose in 0021101 / PR https://github.com/mantisbt/mantisbt/pull/797 is fairly simple, and prevents an error which is more and more likely to occur as people using Mantis on smartphones are used to inserting emojis.

Of course will need to be reverted once utf8mb4 support has been implemented.

(0054374)
j_schultz   
2016-11-02 10:37   

This blog post suggests a different and interesting workaround compared to the pull requests referred to in the previous post: https://roartindon.blogspot.de/2015/04/hacking-utf16-to-work-around-mysqls.html
Rather than replacing everything with <?>, surrogate pairs are used. It requires some unicode decoding code so maybe it's not worth the effort, but still an interesting idea.

(0054574)
dregad   
2016-11-24 09:01   

Changing target version since we'll have MySQL 5.5.3 as minimum requirement there.

(0054577)
atrol   
2016-11-24 09:47   

since we'll have MySQL 5.5.3 as minimum requirement there

Did you consider 0020431:0052214 ?
Added also note to 0021841:0054575

(0056429)
travm1   
2017-04-07 00:09   

There is some generic info about UTF8mb4 here: https://www.everipedia.com/UTF8/

(0056430)
dregad   
2017-04-07 03:21   

There is some generic info about UTF8mb4 here: https://www.everipedia.com/UTF8/

@travm1 what is your point ?

(0061894)
thE_iNviNciblE   
2019-04-11 16:37   

cool that mantis will to that out of the box utf8mb4, without manuell database stuff with this quite cool mysql, mssql, postgre tool https://www.heidisql.com/ :-)

now mantis is able to process unicode... stuff like this is possible https://unicode.org/emoji/charts/full-emoji-list.html
would be more nice to work with smileys while typing reports, better workplace, not so conservativ.
you don't need grafics anymore.

(0061895)
thE_iNviNciblE   
2019-04-11 16:41   

stuff like http://www.sonderzeichen.de/Emoticons-Alphabet.html this html charakter also works with 😁 for example ... � ���

i'll do a ticket, for supporting input with smileys...

(0061896)
thE_iNviNciblE   
2019-04-11 16:43   

is the bugstracker mysql database really under UTF8mb4 correctly ?

in my previous ticket are the correct unicode smileys, normaly they are working... we all see not the smiley but �



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
20307 [mantisbt] printing minor have not tried 2015-11-23 22:55 2020-03-15 15:27
Reporter: vboctor Platform:  
Assigned To: vboctor OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.0-beta.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.25.0  
Summary: Print issue page needs to adjust formatting for tags and relationship handler
Description:

See 0019540 for an example that highlights these issues.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Selección_091.png (15,569 bytes) 2016-01-11 18:35
https://mantisbt.org/bugs/file_download.php?file_id=6560&amp;type=bug
Notes
(0051931)
cproensa   
2015-11-24 05:00   

See 0019540 for an example...

are you sure? I cant see relation to that id...

(0051943)
atrol   
2015-11-24 09:33   

There is no relation in the way you mean.
But it's an example that there is a need to adjust formatting of tags and relationships.
https://www.mantisbt.org/bugs/print_bug_page.php?bug_id=19540

(0051944)
cproensa   
2015-11-24 10:48   

Thanks atrol, got it.
The problem is that some elements are showed as links, while the page should be text only for a print situation?

Notice that also a link to other issues is also hyperlinked

(0052295)
cproensa   
2016-01-11 18:35   

Also, the substitution of # numbers (and comments) in summary texts for bug links is broken on print page
Example image attached

(0052328)
vboctor   
2016-01-18 15:35   
(Last edited: 2016-01-18 15:36)

Here is my attempt to summarize what needs to be fixed:

  • We don't need hyperlinks to issues or usernames.
  • We don't need the X delete icon for tags.
  • We should ideally still strikethrough resolve issue #.
  • We should still format bug ids and note ids to do the proper prepending with 0s.
  • In @cproensa screenshot, we should not expand # and ~ tags in text form. We should just normalize them as pre the previous point.

Does that make sense?

(0061946)
stevecharon   
2019-04-17 09:34   

There is no print_bug_page.php anymore since 2.x
But it would be nice to re-introduce this because printing a page without this means I have to go through reports and click my issue and then print.
That is a hassle of 3 to 5 clicks instead of the 1 click we used to have in 1.3



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14841 [mantisbt] customization minor always 2012-10-18 05:41 2020-03-14 18:00
Reporter: mctuft Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 1.2.11  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to customise fields shown on "change status" pages
Description:

There is no way to customise which fields appear on the "Change Status" pages.

Customising $g_bug_change_status_page_fields in config_inc.php has no effect.

It would be nice to have customisable field lists for each status level:

$g_bug_change_status_unresolved_page_fields
$g_bug_change_status_resolved_page_fields
$g_bug_change_status_closed_page_fields

Tags:
Steps To Reproduce:

Customise $g_bug_change_status_page_fields in config_inc.php, removing 'view_state' from the list.

View a bug and hit the "Change status to" button.

The "View status" field still appears on the "change status" page.

Additional Information:
Attached Files:
Notes
(0034505)
dregad   
2012-12-07 09:20   

Instead of defining several global vairables, it would probably be a better design to have this as an array specifying fields that should be displayed for each status (it would also provide additional flexibility).

(0040098)
kelson   
2014-04-14 11:45   

Hi,

In MantisBT 1.2.17, in bug_change_status_page.php, I found at line 44 :
$tpl_fields_config_option = 'bug_change_status_page_fields';
However, $tpl_fields_config_option is not used anywhere.

What about of this configuration option ?

Cheers

(0041931)
TomR   
2014-11-27 12:43   

Is this still an issue.

It seems so, because we want to remove 'resolution' field evertwhere.

However it stills shows up on bug_change_status_page.php

Anyone with q quick fix?

(0048874)
alexandre.boc-ho   
2015-02-19 05:47   

Hi,
News about this bug?

Cheers

(0057380)
windrienk   
2017-08-03 05:38   

I had the same problem, I fixed it by removing/commenting the code in bug_change_status_page.php. Each field has his own piece of html and php code in there so you can comment/remove it.

(0057774)
tvdmaas   
2017-09-21 06:06   

It would make the handling process more intuitive if this would work because not all fields are always mandatory ....



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26771 [mantisbt] markdown minor N/A 2020-03-12 07:16 2020-03-12 07:16
Reporter: nenadalm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Configurable safe list of markdown links
Description:

MantisCoreFormatting plugin is using Parsedown to convert markdown to html.

Parsedown has list of allowed links: https://github.com/erusev/parsedown/blob/1610e4747c88a53676f94f752b447f4eff03c28d/Parsedown.php#L104 and if link doesn't start with string in the list, it is broken.

It would be nice to have this list configurable to e.g. allow email messages open in thunderbird usink thunderlink addon: https://addons.thunderbird.net/en-US/thunderbird/addon/thunderlink/

$g_plugin_MantisCoreFormatting_safe_links[] = 'thunderlink://';
Tags:
Steps To Reproduce:
Additional Information:

pr: https://github.com/mantisbt/mantisbt/pull/1629

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9193 [mantisbt] other feature always 2008-05-22 13:48 2020-03-12 05:19
Reporter: timj Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Selected project" state should be client-side not server-side
Description:

The fact that Mantis keeps state server-side for the selected project is really limiting. Lots of people these days use tabs/multiple windows and I often want to be able to have one tab with one project open and another with another project open yet with Mantis as I move around in one window, as soon as I perform an action in the other window, it will jump to the most recently-selected project in the old.

Keeping state server-side like this and the way it causes cross-window interactions is very confusing and user-unfriendly. It is the frequent cause of mis-filed bugs etc. in a multi-project system.

Mantis should really pass the project ID around client-side (i.e. in GET/POST fields) to avoid this problem.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017929)
Blue Ninja   
2008-05-28 14:23   

I agree. This will also simplify features talked about in the forums such as being able to report to a sub-project directly.

(0059539)
npeifer   
2018-04-12 07:10   

Yes, this would be great. Related to: 0023741, 0005790 and other.

HTML5 introduced the local storage[1] which could be used for this purpose. You can even store JSON objects with a tiny hack[2].

[1] https://www.w3schools.com/html/html5_webstorage.asp
[2] https://stackoverflow.com/a/3146971/3204042

(0059541)
atrol   
2018-04-12 07:28   

@npeifer contributions are welcome.

Send us a Pull Request on our Github repository https://github.com/mantisbt/mantisbt

(0063745)
nenadalm   
2020-03-12 05:19   

Another possible way of solving it would be using some query parameter - project_id? That would store id of currently selected project. Mantis would then set on each request current project by setting $g_project_override variable to project_id query. On project selection, redirect url would have to change project_id to newly selected project. Cookie version could stay for a while to make project selection working as badly as now for urls that wouldn't have project_id specified.

url generating functions like project_page would have to be updated to append project_id and manually written urls would have to be updated too. Non updated urls would still use the cookie version.

contribution welcome?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
23991 [mantisbt] relationships minor always 2018-02-16 06:48 2020-03-10 06:52
Reporter: mchendl Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clone closed ticket doesn't work for reporter
Description:

As discussed in 0011290, it should be possible for a reporter to clone a closed ticket. Closed tickets are set read-only in my configuration.
In my 2.1.0 version the clone button for reporters is visible only when the variable update_bug_threshold is set to 25 (reporter).

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0058902)
atrol   
2018-02-16 07:11   

Just a note in case someone starts to implement it.

It would mean that Relationship with the parent issue must not be offered to users without update_bug_threshold access rights.

(0060726)
mchendl   
2018-10-02 11:12   

Thanks @atrol for the clarification! Is there any chance to get this feature implemented? Now we use 2.12.0 and as I can see in the recent release notes it isn't implemented until 2.16.1.

(0060730)
atrol   
2018-10-03 06:07   

@mchendl, patches are welcome. It all depends on priority and a developer or community member deciding to spend their time on a specific issue.

All contributions are welcome and greatly appreciated.

Patch submissions can be made in several ways. In the order of preference:

  1. Send us a Pull Request on our Github repository [1]
  2. Attach a GIT patch to the issue
  3. Attach a Unified Diff, clearly specifying the patch's base release

Kindly avoid to upload entire modified PHP files.

Please make sure that your submissions adhere to our Coding Guidelines [2], if they don't your patch might be rejected.

[1] https://github.com/mantisbt/mantisbt
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4218 [mantisbt] relationships feature always 2004-07-29 09:03 2020-03-04 03:57
Reporter: DGtlRift Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 0.19.0a2  
Product Build: a2 Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Issue found/fixed & version/build relationships with Changelog
Description:

When we go to a new version, we split the code (let's say version 3.0 (patch 14) to 4.0 (patch 0)) so that we can start including new core features in the 4.0 version. The issue arrises when a few months later an issue is found in version 3.0p15, and testers have found that it goes back to before the code split so it is also in version 4.0p2.

So it is possible to have the same bug in multiple versions, and fixed at diffrent patch levels for those versions.

If version and fixed_in_version were dependancy keys on another table for a join, that could give the versions the issue was confirmed/fixed in for multiple major versions.

In addition, the build (what we use to indicate patch-level) could also be used for this information if instead of being in the mantis_bug_table it
was in a mantis_project_version_build_table that would be tied to mantis_project_version_table so that builds could be enumerated against versions.

This would also allow for (thanks to Wanderer for the suggestion) the possibility for multi-level ChangeLog where the ChangeLog could show:
First level - Fixed in version
Nested - Fixed in build

Tags:
Steps To Reproduce:
Additional Information:
+------------------------------+
| mantis_project_version_table |
+---+-------------+------------+
| K | id          | 1:M >>-------\
|   | project_id  |               \
|   | version     |                \
|   | date_order  |                 \
|   | description |                  \
+---+-------------+                   \
                                       \
+------------------------------------+  |
| mantis_project_version_build_table |  |
+---+----------+---------------------+  /
|   | versioID | M:1 &lt;-----------------/
| K | id       | 1:1 &lt;----------\
|   | buildStr |                 \
+---+----------+                  \
                                  |
+---------------------------+     |
| mantis_bug_versions_table |     |
+---+--------------+--------+     /
| K | verbuild_ID  | 1:1 >>------/
| K | bug_ID       | M:1 &lt;-----\
|   | foundORfixed |            \
+---+--------------+             \
                                  \
+------------------+              |
| mantis_bug_table |              |
+---+--------------+----+         |
| K | id                | 1:M >>--/
|   | ...               |
+---+-------------------+

This could be the relationships between the tables. I think this would work, but I'm not sure how much code change would be involved. The foundORfixed entry would just be a boolean type to indicate if it was ... well, fixed or found. I didn't think it should be a key since I don't think it is possible to find and fix a bug in the same version (unless it is not a bug, or wont be fixed.)

Attached Files:
Notes
(0006438)
DGtlRift   
2004-07-29 09:07   
(Last edited: 2004-07-29 11:47)

Ack... My relationship diagram fell apart in the additional comments... but I think you should be able to cut and paste it to view the fixed type font... OR are there tags to include into submission that would force text to be fixed type?

This is related to issue 3638

<pre>
+------------------------------+
mantis_project_version_table +---+-------------+------------+ K id 1:M >>-------\ project_id \ version \ date_order \ description \
+---+-------------+ \
\
+------------------------------------+
mantis_project_version_build_table +---+----------+---------------------+ / versioID M:1 <-----------------/ K id 1:1 <----------\ buildStr \
+---+----------+ \
+---------------------------+
mantis_bug_versions_table

+---+--------------+--------+ /
| K | verbuild_ID | 1:1 >>------/
| K | bug_ID | M:1 <-----\
| | foundORfixed | \
+---+--------------+ \
\
+------------------+ |
| mantis_bug_table | |
+---+--------------+----+ |
| K | id | 1:M >>--/
| | ... |
+---+-------------------+
</PRE>

Thnx thraxisp

edited on: 07-29-04 11:47

(0006439)
thraxisp   
2004-07-29 10:10   
(Last edited: 2004-07-29 10:11)

(Note: Text fields do support the HTML {pre}{/pre} construct.)

edited on: 07-29-04 10:11

(0022129)
siebrand   
2009-06-13 04:10   

Unassigned after having been assigned for multiple years without progress.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4285 [mantisbt] feature minor N/A 2004-08-06 09:33 2020-03-03 13:08
Reporter: chrisbond Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: the ability to define a roadmap for a product and version it.
Description:

the ability to define a roadmap for a product and version it.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006695)
jlatour   
2004-08-06 09:40   

You can currently create one 'master issue' for a version, and have all the bugs that need to be fixed for that version and features that need to be added for that version as children (see 0003987 here). Is that sufficient, or is there any other functionality you need?

(0006700)
chrisbond   
2004-08-06 10:03   

Sorry I probably didnt explain.

When developing a product we often define a roadmap. For example, http://www.mantisbt.org/roadmap.php. Where we define what is in each release for the major versions.

Its that functionality with the type of view on roadmap.php.

One way to archive it would be with a parent and children but it would be nice to have an overview like on roadmap.php for printing and giving to clients.

(0006702)
DGtlRift   
2004-08-06 10:36   

Seems like this can be done with something very much like the ChangeLog, but it can't use the fixed_in_version column (since it is not fixed/done)... it would have to be something like a hope_to_be_fixed_in_version column...

Although, come to think of it.. if there were release dates associated with the versions, then it could use the fixed_in_version, and a version with a future release date would be used for a roadmap and the changelog could ignore it.

(0006703)
chrisbond   
2004-08-06 10:38   

Sounds good to me =)

(0006727)
jlatour   
2004-08-06 12:11   

Agreed. DGtlRift, do you want to implement this? ;-)

(0009028)
gtomlin   
2005-01-15 10:20   

This could tie in well with 0004218 and 0004904.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
19540 [mantisbt] filters minor always 2015-03-23 09:08 2020-03-03 04:15
Reporter: Chewits Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 1.2.17  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Filter "Assigned To:" doesn't show all usernames when "All Projects" is selected
Description:

This is a duplicate of 0010130 - I cannot reopen it.

The problem is still there for me in 1.2.17. See "Steps To Reproduce".

Tags:

mantishub

Steps To Reproduce:
  1. Create a Project and its SubProject
  2. Assign some user to the SubProject as a developer
  3. Create new issue in SubProject and edit it for that user to be a Reporter, Handler ("Assigned To:" field) and let him monitor the issue.
  4. Go to View Issues page when "All Projects" is selected.
  5. None of the filters "Reported", "Monitored by" or "Assigned to" shows that user.
  6. The same behavior when you select "Project" in the Projects List.

In my opinion, the correct behavior is to display the user in filters for both cases above.

Additional Information:
Attached Files:
Notes
(0049285)
dregad   
2015-03-23 12:29   

I did not go into details, but on this tracker (running 1.3.0b2 as of this writing), when 'all projects' is selected I see a full list of developers in the 'assigned to' field. Maybe the problem is only with subprojects.

(0050620)
gd71   
2015-04-24 05:41   

Hello,
in 1.2.x, my feeling is that this problem occurs when the reporter or handler lists of users are different depending the project. Meaning also the default role is viewer for "all project".
I can understand that the problem could be considered as 'normal' in simple filter, but in advanced filter, the selected project in the upper right corner should not affect the contain of list of values

(0051756)
cproensa   
2015-10-29 16:14   

The problem is that when user is in "All projects",
the filters only account for first level of projects

Subprojects, on level 2 and on, dont show any issues in the filter, eg My View: assigned to me

this is still an issue in 1.3

(0051838)
vboctor   
2015-11-13 12:25   

I've seen a similar issue with Reporters when sub-projects are used. The Reporters list in Simple Filters doesn't include some reporters with default access level REPORTER that has access to multiple sub-projects, but no top level projects. I'll try to reproduce on a test instance and see if I can locate the exact repro steps.

(0051839)
cproensa   
2015-11-13 12:51   

@vboctor

re-reading my comment, i think i have mixed two issues here, and also its mixed on the related issues.

1) In my-view page, when current project is ALL_PROJECTS, the filtered boxes only show info from 1 level of subprojects.

2) user option lists, in filter fields (on view-all-bug page): assigned to, reported by, note by... are built only with the current project scope.

2b) Some filter related code, uses 'current project' to retrieve info, but sometimes the filtered project may be explicitly different from the 'current' one.

In my PR (668) for fixing the print-user-option-list i extended functionality to process multiple projects. This allows a natural solution to (2). With the hard work already done, there are included the fixes for the filter-by-user issues, and actual project scope.

(0053495)
wind-hja   
2016-07-01 08:49   

I have the same problem. I am missing some users in the filter list for all projects. With 300+ projects it is a bit of challange to find the one with wrong permissions. Does anyone have an easy solution for this issue?

(0054168)
mboutell   
2016-10-07 02:21   

When we have sub projects I have the same problem when "All projects" is selected in v 1.3.1. IS there a solution ??? Thx

(0063725)
dregad   
2020-03-03 04:15   

Community-proposed fix, see PR https://github.com/mantisbt/mantisbt/pull/1627

@cproensa, would you mind reviewing ?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26740 [mantisbt] plug-ins feature always 2020-02-25 14:41 2020-03-03 03:13
Reporter: val-kulkov Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: plugin_require_api() does not seem to serve any practical purpose
Description:

The official PHP documentation for function include, which also applies to the function require, states the following (emphasis added):

If the include occurs inside a function within the calling file, then all of the code contained in the called file will behave as though it had been defined inside that function. So, it will follow the variable scope of that function. An exception to this rule are magic constants which are evaluated by the parser before the include occurs.

Therefore, require_once() on line 826 in plugin_api serves no practical purpose. Remote PHP debugging shows that this require_once() properly imports variables and functions from $p_file, but then all imported variables and functions are lost as soon as the scope of function plugin_require_api() is lost.

I am not suggesting a fix just yet, because the purpose of plugin_require_api() is not clear to me. I would appreciate a clarification. If this function is supposed to import variables and functions from $p_file into the plugin's namespace, then this function should either return the imported variables and functions or provide a constructed filename so that the caller can execute require_once() directly. If, on the other hand, plugin_require_api() is supposed to use some magic constants, then it is entirely unclear how this process should work.

I am writing a Mantis plugin which would use lang_api to import plugin error messages in a language chosen by the user. At present, plugin_api.php provides a stub function errors() to import error messages, allowing the plugin implementation to override it. Unfortunately, there is no easy mechanism at present to import error messages in a language chosen by the user: see lines 1002-1007. Importing error messages via plugin_require_api() does not work because, as described above, the variables are lost as soon as the scope of plugin_require_api() is lost.

For now, I am using the following code in the plugin's register() function:

# Plugin error messages
$t_current = plugin_get_current();
$t_path = config_get_global( 'plugin_path' ) . $t_current . '/';
$t_plugin_errors_file = $t_path . 'lang/errors_' . lang_get_current() . '.php';
require_once( $t_plugin_errors_file );
$this->error_text = $plugin_errors;

and then I define errors() like this:

function errors() {
    return $this->error_text;
}

but then again, I wonder what the purpose of plugin_require_api() is.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063692)
cproensa   
2020-02-25 15:21   

Here you can see an example of using the plugin errors() function:
https://github.com/mantisbt-plugins/timetracking/blob/6535f2d8ee70ea80990d532d679b8b45fd96a9d8/TimeTracking/TimeTracking.php#L82-L87
where error codes are defined as constants in the plugin namespace, and error strings are retrieved from the plugin translation files.

the purpose of plugin_require_api() is not clear to me

plugin_require_api()has the benefit of inferring the plugin path, so you can specify a file relative to the plugin root. For example:
plugin_require_api( 'core/constants.php' ); for a file within a directory "core" under the plugin directory structure.

One thing that plugin_require_api does different from require_api is that it does not register the global variables, but that can be replicated with the similar code to:
https://github.com/mantisbt/mantisbt/blob/a1f45450accd9ccd7d93dffbed085d388fe37d75/core.php#L120-L123

I'm not sure if that should be changed, or adding globals to all the scope is a risk of overwritting other globals defined in the core includes.
So far, it hasn't been a problem for me, as i don't use globals across includes when writting plugincode.

I am using the following code in the plugin's register() function:

I suggest not to include other files like that in register(). Because register is always called as part of plugin discovery, even if the plugin is not enabled.
A better place is init() that is only called for a plugin that is enabled.
An exception would be the linked code above, where a constants file is needed to be used also within register().

For some more involved plugins, my current approach is to use namespaced classes, and an autoloader, so the whole plugin_require_api is not needed.

(0063697)
dregad   
2020-02-26 05:00   

To my knowledge, plugin_require_api() is used to include a plugin-specific API (i.e. a series of functions) without having to worry about the actual plugin path. I have only seen it used in MantisGraph core plugin, and I don't think it was intended to register variables in the global namespace and like @cproensa I'm not sure it should.

Note that the scoping issue only affects variables declaration - PHP functions are always global [1]

All functions and classes in PHP have the global scope - they can be called outside a function even if they were defined inside and vice versa.

As for registering error messages, another example can be found in Source Integration plugin (https://github.com/mantisbt-plugins/source-integration/blob/v2.3.1/Source/Source.php#L125)

(0063720)
val-kulkov   
2020-03-02 14:48   

Thank you @cproensa and @dregad for your valuable comments. I changed my approach with plugin_require_api() and I am now trying to use namespaces as much as I can to keep plugin names away from the Mantis namespace. It is indeed a safer approach.

Since I started using namespaces, I found that apparently I cannot use plugin_event_hook to register namespaced functions. For example:

plugin_event_hook( 'EVENT_LAYOUT_RESOURCES', 'add_resources_v_list' );

works, but

plugin_event_hook( 'EVENT_LAYOUT_RESOURCES', 'MyPlugin\add_resources_v_list' );

does not.

Interestingly, if I define a function and then call plugin_event_hook() with this function in a plugin's page, the function never gets called. The result is the same regardless of whether I use a separate namespace or not: the function never gets called. It appears that in order for plugin_event_hook() to work with a function, the function must be defined inside the plugin's class definition.

Since the second argument of plugin_event_hook() is a string, clearly the function with the name matching this string must be accessed dynamically in the PHP code. Why such dynamic access fails to work with namespaced functions or functions defined within a plugin's page code is somewhat a mystery to me. At this point, I am not ready to dig deeply into the gory details of the Mantis code to understand why this happens, so my comments are simply an observation of this behaviour which seems odd and potentially misleading to me.

If this behaviour is the intended behaviour, should there be some comments in the plugin_event_hook() code to guide developers to use only functions defined in the plugin's class definition to avoid problems similar to mine?

(0063721)
dregad   
2020-03-03 03:13   

It appears that in order for plugin_event_hook() to work with a function, the function must be defined inside the plugin's class definition.

@val-kulkov it may be poorly documented, but plugin hooks are indeed expected to be methods of the plugin's base class.

Technically, event_hook() API function allows you to hook a regular function to an event (with $p_plugin paramer to 0) but I don't think this is actually used anywhere.

I am not ready to dig deeply into the gory details of the Mantis code to understand why this happens

Look at event_callback() function.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5940 [mantisbt] customization minor N/A 2005-07-14 10:22 2020-02-29 07:26
Reporter: Darkwinde Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 1.0.0a3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Web UI to customize access levels
Description:

I think a great feature will be the editability of the acesslevels by name.

So there are still these levels:

$s_access_levels_enum_string = '10:viewer,25:reporter,40:updater,55:developer,70:manager,90:administrator';

so it would be a great deal, if ehre is a php-menue availble to set up new names, add new oder deleting...so you can clone or inherit with reduced accessebilities.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010790)
thraxisp   
2005-07-15 18:34   

Editting the levels is pretty straight forward. The string translations are more difficult.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8008 [mantisbt] webpage feature N/A 2007-05-24 04:31 2020-02-27 17:17
Reporter: brody Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.0.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: extending "my_view_page.php" with self defined filters (including custom filter fields)
Description:

I defined some custom fields, e.g. a data field named "recheck on" and on updating an item's status, I set this field to an future date. It would be very great, if an filter display on my_view_page could show them with an dynamic filter

"recheck on" = (today and before), to get items, that must be revied immediately

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4945 [mantisbt] feature feature always 2004-12-08 02:21 2020-02-27 13:19
Reporter: HeikoNorderstedt Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Customisation for My-View Page
Description:

It would be very usefull if every user could customize his my-view-page with individual filters.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063712)
HUISCO   
2020-02-27 13:19   

Hello guys,
How soon can we expect to implement this ticket?
Maybe there is a corresponding plugin?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26738 [mantisbt] attachments minor always 2020-02-25 05:09 2020-02-25 05:09
Reporter: webaware Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: WebP attachments are not forced to display inline
Description:

file_download.php builds a local array of mime types that will be forced to display inline: $t_mime_force_inline

This array does not include 'image/webp', and cannot be overridden, so WebP images are forced to download. It would be better to allow them to display inline as per other image formats. Of the popular web browsers, only IE11 and Safari browsers cannot display WebP images, so I reckon it's no risk to allow WebP images to display inline always.

https://caniuse.com/#search=webp

If it is considered a risk, then perhaps $t_mime_force_inline can be made a configuration item that can be overridden in local configs for people who don't care about IE11 and Safari.

Tags:
Steps To Reproduce:
  • attach a WebP image to a bug
  • view the bug, seeing the image expanded inline
  • click on the image and note that you are forced to download it
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26590 [mantisbt] installation minor always 2020-01-10 13:44 2020-02-24 16:45
Reporter: rogueresearch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.21.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wording of admin/check/index.php results could be clarified with a prefix
Description:

When I run admin/check/index.php I get the attached results.

mysql.allow_local_infile php.ini directive is set to 0
mysql.allow_local_infile should be disabled to prevent remote attachers to access local files (see issue 0023173).

Database default collation is UTF-8
Database is using latin1_swedish_ci collation where UTF-8 collation is required.

Maybe it's just me, but in both cases, the wording of the first line does not make it clear if it's:

  • stating the problem found, or
  • stating the expectation

I think this would be much clearer with a little prefix, like:

Checking if: mysql.allow_local_infile php.ini directive is set to 0
mysql.allow_local_infile should be disabled to prevent remote attachers to access local files (see issue 0023173).

Checking if: Database default collation is UTF-8
Database is using latin1_swedish_ci collation where UTF-8 collation is required.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: MantisChecks.png (77,494 bytes) 2020-01-10 13:44
https://mantisbt.org/bugs/file_download.php?file_id=8955&amp;type=bug
Notes
(0063421)
dregad   
2020-01-10 18:06   

The check's description is always stating the expectation (or at least it should be, I did not go back and check every single test).

I hear your argument, but I'm not sure I is really worth the effort to update the all the individual checks' descriptions... And I'm not sure that updating the function printing the test row would be the correct approach, as there are probably a few cases where Checking if or whatever prefix we pick, would not be applicable.

(0063422)
rogueresearch   
2020-01-10 18:37   

Thanks for the confirmation that it's stating the expectation.

I did come to that conclusion eventually, but for quite a while I thought this was showing me a list of errors, not a list of (failed) expectations. i.e. I thought it was telling me that mysql.allow_local_infile is set to 0 and that I should therefore change it to 1.

I don't know the codebase, but perhaps there is a way to add the prefix without changing every individual check's description...?

(0063426)
dregad   
2020-01-11 17:09   

I don't know the codebase, but perhaps there is a way to add the prefix without changing every individual check's description...?

That's basically what I meant with _I'm not sure that updating the function printing the test row would be the correct approach, as there are probably a few cases where Checking if or whatever prefix we pick, would not be applicable._

In clear, there are functions that perform the check and print the results, check_print_test_row() and check_print_test_warn_row() so changing those would only work if ALL checks are written the same way.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
13979 [mantisbt] feature minor have not tried 2012-02-28 18:31 2020-02-23 20:59
Reporter: tchalvakspam Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Top nav search functionality, e.g. top "Jump" bar could accept search terms for quicker search navigation.
Description:

I came to report this issue because I found a convenience issue with the need to click through to "view issues" before you can search for a term. It would be much more convenient to have direct access to a keyword search in the top header at all times than to have to click through a certain link to get access to it.

Tags:
Steps To Reproduce:

Try to search for an issue by keyword.

If you have a keyword, say "Particle", and you want to find an issue with that keyword, you will generally have to A: be familiar enough with the interface that you know that searching is available only within the "View Issues" link, and B: click through the "view issues" link, load that new page, and then find the search box part way down that page and then do the search before you get your results.

Additional Information:

Now, there's already a "search" type box in the header that currently only accepts integers and just gives an error on anything else.

With a if((int) $term = $term) type check and branching, it could act as a search box, using any integers as a check for issue numbers and everything else as a keyword search by passing the term through to the filter search results page here:
http://www.mantisbt.org/bugs/view_all_bug_page.php

Obviously there are a variety of other ways to implement this as well.

Attached Files:
Notes
(0031351)
dregad   
2012-02-29 03:45   

Maybe this plugin http://git.mantisforge.org/w/MantisCmd.git can do what you need

(0031354)
tchalvakspam   
2012-02-29 10:54   

....a command line interface? ...does it also add to the web ui or something?

(0031356)
dregad   
2012-03-01 03:26   

It's just a text field that is displayed on MantisBT header, allowing you to enter some commands including "s" for search.

(0059543)
Starbuck   
2018-04-12 13:53   

2018: similar request in forum.
Can we bump this to acknowledged status and maybe identify dupe requests?

(0060005)
IchSelbst   
2018-06-01 15:53   

Could you replace the the field "entry #" on dashboard page by a full text search, please?

(0061717)
rogueresearch   
2019-03-19 16:17   

+1 from me. If the 'jump' field could do a keyword search if the string did not match an exact issue number, that'd be nice.

(0063050)
Neustradamus   
2019-11-02 09:36   

I would like to search tickets, but I can not enter a word or words in search, only numbers are accepted.
It is a big problem.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7840 [mantisbt] customization feature N/A 2007-03-19 08:02 2020-02-21 11:08
Reporter: stefanvandenoord Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Customizable 'my view' page
Description:

I think it would be great if the 'my view' page was customizable. For example, the user preferences could include a checkbox for each standard 'my view' block, as well as each filter available to the user. The user could then also have the results of certain filters available on the 'my view' page, and could hide standard blocks that she doesn't need.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: customMyView.diff (70,617 bytes) 2007-10-23 13:55
https://mantisbt.org/bugs/file_download.php?file_id=1512&amp;type=bug
customMyView.tar.gz (19,887 bytes) 2007-10-23 13:57
https://mantisbt.org/bugs/file_download.php?file_id=1513&amp;type=bug
customMyView_v2.tar.gz (10,282 bytes) 2007-10-23 15:41
https://mantisbt.org/bugs/file_download.php?file_id=1514&amp;type=bug
customMyView_v2.diff (33,697 bytes) 2007-10-23 15:41
https://mantisbt.org/bugs/file_download.php?file_id=1515&amp;type=bug
mantis1.GIF (10,669 bytes) 2008-03-05 08:19
https://mantisbt.org/bugs/file_download.php?file_id=1723&amp;type=bug
configurable_my_view.patch (34,142 bytes) 2008-05-31 16:13
https://mantisbt.org/bugs/file_download.php?file_id=1818&amp;type=bug
Notes
(0015284)
vboctor   
2007-07-29 22:14   

I think it would be a good idea for users to add My View boxes based on filters that they have access to. Also to remove such boxes using some configuration page or using AJAX to close the windows. We may consider support for minimizing such windows.

(0015958)
Nycto   
2007-10-23 13:56   

While implementing Mantis for my company I set-up this feature. I have attached an archive to this note with a diff file, 4 new files and a readme that describes installation and use.

(0015959)
jreese   
2007-10-23 14:43   

Can you resubmit a diff that does not contain useless add/remove blocks? Perhaps your file editor needs to be set to use Unix-style line feed like the rest of the Mantis codebase, rather than windows style carriage returns.

(0015960)
Nycto   
2007-10-23 15:42   

re-uploaded

(0015969)
giallu   
2007-10-24 05:10   

I am interested in this feature, so If no one beats me on that, I will happily review/commit your code.

(0017258)
ghohm   
2008-03-05 06:20   

Do you think this customization work with the last version 1.1.1?

If, yes, why didn't you add this very useful feature in the last Mantis' version?

Gôm

(0017260)
mauro   
2008-03-05 08:22   
(Last edited: 2008-03-05 08:23)

I install this improve but account_my_view_page.php and my_view_page.php are empty.I don't know how I can complete data, any idea?
I attach image example.

thanks

(0017261)
ghohm   
2008-03-05 11:22   

Someone know how can I execute this command (see "readme")?

3) Apply the diff file with the following command:
patch -p0 < customMyView.diff

Yes ... My Mantis is working on Windows!

(0017286)
mkornatzki   
2008-03-07 17:30   

this feature is great.
thanks for the development.

there is only one error. If a user wants to add a custom filter add by another one the page refreshes but the filter didn't append.

you can fix this if you edit the function filter_add_to_my_view in filter api as follows:

change if ( !filter_exists( $c_filter_id, $c_user_id ) )
to if ( !filter_exists( $c_filter_id, null ) )

(0017304)
mauro   
2008-03-10 05:18   

I change
if ( !filter_exists( $c_filter_id, $c_user_id ) )to
if ( !filter_exists( $c_filter_id, null ) )

but in "My View" the custom filters don't appear.
The process that i follow is:
1 - Go to "View Issues" and create a new filter and save it.
2 - Go to "My Account" and Custom Filters are empty.

Another idea.....
Thanks

(0017973)
mkornatzki   
2008-05-31 16:19   

i really like this feature. i made a patch (configurable_my_view.patch) against the actual trunk.

You have to download the archive customMyView_v2.tar.gz and follow the readme. instead of using the diff-file of the archive use the new patch.

(0019252)
AMonsef   
2008-08-27 02:26   

hi all,

i am running Mantis in our company 6 months ago over iSeries using Mysql, i am trying now to apply this patch but i had this error:

Hmm... I can't seem to find a patch in there anywhere.

could you please advice?

thanks

(0020602)
mnoznica   
2009-01-13 07:23   

I have fixed the problem about filters of another user replacing the line:
else if (!is_null($p_user_id) && $p_user_id != $filter['user_id'])
to
else if (!is_null($p_user_id) && $p_user_id != $filter['user_id'] && $filter['is_public'] == 0 )

in the filter_exists function off filter_api.php

This allow the public filters be added by all users

(0023168)
cmfitch1   
2009-10-13 15:31   

This seems like an important thing to do in order to really make the my view page useful. Was there a problem with the submitted change that the development team didn't like? I applied it to 1.2.0 and with a little bit of playing around had it working. I need to do a full code review and more testing, and I'm not sure if something needs to be done to automate the addition of a database table, but I'll attach a git patch shortly if that's all this is waiting on.

(0026481)
squarebox   
2010-08-26 22:57   

@cmfitch1: do you by chance have a patch that works with 1.2.2 or were you ever abel to get around to making one for 1.2.0?

As an addition to this feature, it'd be great if one could also change the display order of the view boxes view user preference would be great as well.

(0026898)
daryn   
2010-09-28 20:50   

See http://github.com/daryn/mantisbt/tree/save-filter for a similar feature branch against current trunk. This feature is nearly ready to commit and could use some additional testers.

(0028438)
Bozz   
2011-03-18 04:48   
(Last edited: 2011-03-18 04:49)

Souldn't it be integrated as a plugin instead of a patch ?

(0029867)
dregad   
2011-09-26 15:27   

daryn, I had a quick look at your branch, but unfortunately it does not apply cleanly on the latest trunk... Some conflicts are trivial, but others I'm not sure what to do. Any chance you can merge it ?

both modified: css/default.css
both modified: javascript/bugFilter.js
deleted by them: javascript/dev/bugFilter.js
deleted by them: javascript/dev/common.js
both modified: my_view_inc.php
both modified: my_view_page.php

(0033250)
dregad   
2012-10-17 06:35   

A possible custom workaround for allowing access level based customization of the my view page was described in 0006480:0033235

(0037881)
atrol   
2013-08-16 12:40   

Removed assignment. giallu will not contribute to this issue in near future.

(0062006)
ochattlesworth   
2019-04-27 05:05   

This would be a welcomed feature. In addition, I would add that the boxes on the My View page should be in a drag and droppable grid layout so users can easily reposition them.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25692 [mantisbt] administration crash always 2019-04-13 00:56 2020-02-19 12:19
Reporter: thE_iNviNciblE Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.20.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: How to set Session Timeout higher - my session expire if i stay in the same ticket for timetracking
Description:

i've setup like this:

php_value session.gc_maxlifetime 2160000
php_value session.cache_expire 2160000
php_value session.cookie_lifetime 2160000

after ~ 30 - 60 minuten timetracking i receive a "security token" error, can't safe, data is lost.

how could i change this?

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0061912)
thE_iNviNciblE   
2019-04-13 00:59   

why mantis is not out of the box combatible with a higher timeout, its only needed when you use the timetracking feature?

(0061926)
thE_iNviNciblE   
2019-04-13 18:14   

APPLICATION ERROR #2800

Ungültiges Sicherheitstoken zum Formular. Dies kann durch einen Sitzungsablauf oder durch versehentliches doppeltes Speichern des Formulars verursacht worden sein.
Bitte benutzen Sie die „Zurück“-Taste Ihres Browsers, um auf die vorhergehende Seite zurückzukehren. Dort können Sie den hier angezeigten Eintrag korrigieren oder eine andere Aktion ausführen. Über das Menü können Sie auch direkt zu einer anderen Aktion wechseln.

(0062056)
thE_iNviNciblE   
2019-05-10 23:01   

is it reproduceable ?

(0062125)
thE_iNviNciblE   
2019-05-23 19:00   

....

(0063543)
bos4711   
2020-01-31 09:23   
(Last edited: 2020-01-31 09:23)

@thE_iNviNciblE have a look at these:

0026608:0063541

http://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.troubleshooting.errors.2800



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24055 [mantisbt] plug-ins feature N/A 2018-02-28 16:34 2020-02-17 14:54
Reporter: simonegirlanda Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add events in in bug view
Description:

Add missed calls to hook for events as described in Plugin event reference (https://www.mantisbt.org/wiki/doku.php/mantisbt:plugins_events).

Can I implement changes directly?
May I have access to repository?

View Events
These events allow plugins to add new content to individual view pages in various locations.

EVENT_VIEW_BUG_AFTER_DETAILS ( Output )
EVENT_VIEW_BUG_AFTER_RELATIONSHIP ( Output )
EVENT_VIEW_BUG_AFTER_UPLOAD ( Output )
EVENT_VIEW_BUG_AFTER_USERS ( Output )
EVENT_VIEW_BUG_AFTER_NOTES ( Output )

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0059074)
atrol   
2018-03-03 04:49   

Submitting a patch is always a good idea, as it increases the chances of improvement eventually making it into MantisBT core. All contributions are welcome and greatly appreciated.

Patch submissions can be made in several ways. In the order of preference:

  1. Send us a Pull Request on our Github repository [1]
  2. Attach a GIT patch to the issue
  3. Attach a Unified Diff, clearly specifying the patch's base release

Kindly avoid to upload entire modified PHP files.

Please make sure that your submissions adhere to our Coding Guidelines [2], if they don't your patch might be rejected.

[1] https://github.com/mantisbt/mantisbt
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

(0059080)
simonegirlanda   
2018-03-05 03:34   

Thank you @atrol, I'll study guidelines and I'll send a pull request on git.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5744 [mantisbt] custom fields feature N/A 2005-06-08 11:24 2020-02-15 23:14
Reporter: malaussena Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Managing custom fileds in the workflow
Description:

When creating a custom field, I can say it is necessary reporting, updating, solving or closing an issue.

I would like, in manage_config_workflow_page.php, having a table like workflow.
One row for each custom field, one column by status. A checkbox saying : custom field necessary at this status

Would it be possible ?

Best, having "level access" by cutsom field saying by status the min threshold level allowed for updating the custom field...

Am I crazy ? ;-)

Tags:

patch

Steps To Reproduce:
Additional Information:
Attached Files: mantis.patch (26,005 bytes) 2007-07-26 20:08
https://mantisbt.org/bugs/file_download.php?file_id=1396&amp;type=bug
mantisbt.patch (41,332 bytes) 2007-07-27 01:46
https://mantisbt.org/bugs/file_download.php?file_id=1397&amp;type=bug
mantisbt_2.patch (27,515 bytes) 2007-07-27 11:52
https://mantisbt.org/bugs/file_download.php?file_id=1399&amp;type=bug
mantisbt_3.patch (23,541 bytes) 2007-07-27 18:31
https://mantisbt.org/bugs/file_download.php?file_id=1400&amp;type=bug
mantisbt_4.patch (25,132 bytes) 2007-07-27 20:53
https://mantisbt.org/bugs/file_download.php?file_id=1401&amp;type=bug
mantisbt_5.patch (37,460 bytes) 2007-07-29 01:10
https://mantisbt.org/bugs/file_download.php?file_id=1402&amp;type=bug
patch_custom_field_display.zip (66,792 bytes) 2009-05-28 12:27
https://mantisbt.org/bugs/file_download.php?file_id=2329&amp;type=bug
patch_custom_field_display_v2.zip (84,568 bytes) 2009-05-29 04:59
https://mantisbt.org/bugs/file_download.php?file_id=2330&amp;type=bug
Status_Custom_Fields.zip (137,010 bytes) 2020-02-15 23:14
https://mantisbt.org/bugs/file_download.php?file_id=8994&amp;type=bug
Notes
(0010424)
thraxisp   
2005-06-08 11:42   

It was in my plans...

(0012722)
illes   
2006-04-25 11:27   

Nice feature, I'm waiting for this one too.

(0015232)
roleary   
2007-07-26 20:08   
(Last edited: 2007-07-26 20:22)

I'm pretty much finished with a patch to implement this behavior. I need some guidance from the devs on how to handle upgrading from an older version to a version that supports this.

I've attached the current version of the patch. This patch allows you to specify, for each Custom Field, whether you would like that field Not Shown, Displayed, or Required for each Status. PATCH IS FOR 1.0.8

I believe I've covered all the bases here, but there are still some issues that need to be resolved. Mainly, I have not yet stripped the old "require_update", "display_update"... etc. and I have not implemented any sort of upgrade code.

If any of the devs could contact me, I would happy to work through my remaining issues and formally submit this, however that's done. I can update the code to patch to the latest version also.

(0015233)
roleary   
2007-07-27 01:47   
(Last edited: 2007-07-27 11:52)

Just uploaded new patch that will work on the current CVS repository.

Please use the latest patch above for 1.0.4a (mantisbt_2.patch). If someone can delete the other files, that would be great.

(0015247)
roleary   
2007-07-27 18:32   

mantisbt_3.patch

This patch contains the same functionality as "_2", but with the data stored in a list in a new column on the custom_field table instead of in a whole new table.

(0015249)
roleary   
2007-07-27 20:55   
(Last edited: 2007-07-28 02:57)

mantisbt_4.patch

Contains additional fixes as discussed in IRC:

<pre>
<roleary> Issue 0000001 - The viewing of the issue. The custom fields always show in that read-only view on top of the bug if they're assigned to the project. A couple ways to change that: either:
<roleary> a) leave as is
<roleary> b) only show when the field is "display" or "require" for the current status
<roleary> c) show when the field is "display" or "require" for any status <= the current status
<roleary> d) other ways?
<thraxisp> roleary: for 0000001, I like b. Display also needs to meet the read/write access levels.
</pre>

(0015264)
grangeway   
2007-07-28 15:10   

fwiw, assigned to myself as i'm trying to merge this with another patch.

(0015267)
roleary   
2007-07-29 01:23   

mantisbt_5.patch

This patch includes removal of all references to the old "display" and "require" values for custom fields.

Also, this patch includes a new function in admin/install.php that will migrate the existing custom field data. This new function (migrateCustomFieldDisplay()) must be called AFTER the patch has been applied to PHP files and AFTER the new field has been added to the custom_field table, but BEFORE the old fields in the custom_field table have been removed. This function is currently not called anywhere (waiting on help from thraxisp here), but I have tested it to make sure it works.

Additionally, there are some outstanding issues I am waiting for guidance on:
1) I only updated lang/string_english.txt, not any other language. Should I make the change to all files and leave the values blank?
2) I updated the API code accordingly, but currently it will return the serialized array as a string for the new field in custom_field. Not sure if that's the correct way to handle serialized data. Does the serialized array need to be unserialized and returned value-by-value? Or just as a string?
3) Do I need to do anything with admin/upgrades files? I'm not quite sure what their purpose is or how to go about creating an upgrade file for the changed schema.

(0015270)
vboctor   
2007-07-29 03:18   

A quick answer to your localization question. You only need to update strings_english.txt. Any string that is not in the current language will be defaulted to the English string.

It would be great if we can create a requirements wiki page that explains what this feature achieves and possible includes screen captures. This will make it easier to review the feature on high level. This will also be a good starting point for the feature documentation.

Browse through the requirements section in the Wiki to get an idea of what I mean:
http://www.mantisbt.org/wiki/doku.php/mantisbt:requirements

(0015279)
roleary   
2007-07-29 17:17   

Create a requirements page on the wiki per vboctor's request:
http://www.mantisbt.org/wiki/doku.php/mantisbt:custom_field_display_requirements

(0015285)
illes   
2007-07-30 03:49   

Nice documentation, thanks, I can only agree with that.

(0015296)
emathieu   
2007-07-30 09:27   

Could be a good idea to expand it to default fields.

In the requirements page, can you explain what is exactly the meaning of "None" and "Display"

(0015659)
malaussena   
2007-09-18 12:26   

I have only one thing to say (as the reporter)… very good work !

I hope to see leaving version 1.2.0 very quickly!

(0021959)
cbasset   
2009-05-28 12:32   

I've upload a new patch for the following reasons:

  • it fixes an issue in the view bug page
  • it adds possible workarounds for update as displaying fields depending on current status might be an issue if the update includes a status change.
  • it is more convenient to apply to current release

See readme.txt file included in the zip for more informations.

(0021966)
cbasset   
2009-05-29 05:00   

Upload v2 version of patch, lang file was missing in first upload.

(0022190)
Jheredero   
2009-06-18 04:46   
(Last edited: 2009-06-18 04:50)

Hello,

I have installed the pacth, it is very interesting, but I have a grant problem, when I reported a issue (status NEW), the values of the custom fields don´t record (are defined how required), In the other status and when it is recorded and updated work perfectly. do you know which can to be the reason?.
The only thing that no work of steps of the path documentation is the drop the constraints, these dont work but i undertand that isn´t the reason because in the other status work good.

Thank you and sorry for my english.

(0023047)
costinnila   
2009-10-01 08:27   

There is a problem in bug_update.php at line 129.
No $ sign in front of t_field_value. Because of this the required fields are not checked properly.

(0026015)
serom   
2010-07-02 04:15   

I'm having problems with this patch in Mantis 1.2.1. Is there a new patch for the latest version of mantis?

(0028207)
irineus   
2011-02-11 10:28   

It seems this patch doesn't work anymore with newer version (1.2.0 and up). There's any directions to do this in these new versions?

(0031178)
illes   
2012-02-07 05:12   

Any update on the status of this issue?

(0039117)
atrol   
2014-01-21 16:03   

Unassigned after having been assigned for a long time without progress.

(0063640)
cristobal.manrique   
2020-02-15 23:14   

I've just developed a plugin for this.
I guess it is very simple, and of course it can be improved, but for the moment it is a very useful tool, taking into account that it does not require any patch to mantis core files.

Unzip this to your plugins folder, go to manage/manage plugins and check the /doc folder for instructions.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25619 [mantisbt] email minor always 2019-03-18 11:40 2020-02-15 21:45
Reporter: rogueresearch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.19.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: $g_limit_email_domains impacts custom e-mail fields, which is unexpected from its documentation
Description:

The Admin Guide here:
http://www.mantisbt.org/docs/master/en-US/Admin_Guide/Admin_Guide.pdf

says:

"$g_limit_email_domains - Only allow and send email to addresses in the given domain(s). This is useful as a security feature and it is also useful in cases like Sourceforge where its servers are only limited to send emails to SourceForge email addresses in order to avoid spam. $g_limit_e- mail_domains = array( 'users.sourceforge.net', 'sourceforge.net' );"

After setting this to:

$g_limit_email_domains = array( 'rogue-research.com' );

I am no longer able to edit issues that use a 'custom field' of 'e-mail' type, mantis will report:

APPLICATION ERROR 0001303
Invalid value for field "Customer Email"

My customers of course don't have emails in my own domain. :)

From its documentation, I wouldn't have expected that $g_limit_email_domains limit what can go into database fields, but only to limit emails that mantis actually sends out.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0063423)
rogueresearch   
2020-01-10 19:16   

Hmmm, I just tried in Mantis 2.23.0 on a test server, and don't seem to reproduce it anymore...

Did someone fix this?

I'll try again on my production server once I update it too...

(0063424)
dregad   
2020-01-10 19:37   

I don't think this has been touched. Maybe it was caused by your setup. Please let us know after checking, whether the problem is indeed fixed, so we can resolve this issue.

(0063639)
rogueresearch   
2020-02-15 21:45   

I've finally tried on my production server (now 2.23.0), and this bug does reproduce.

What logs or steps would be helpful to debug this?

Thanks.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22098 [mantisbt] customization minor always 2017-01-01 12:53 2020-02-14 11:16
Reporter: atrol Platform:  
Assigned To: syncguru OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Setting bottom_include_page does not include specified file
Description:

Regression

Option bottom_include_page to include a file at the bottom of each page is still available but does not work any longer.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: place_for_top_include_page_1512889281130.jpg (267,270 bytes) 2017-12-10 02:07
https://mantisbt.org/bugs/file_download.php?file_id=7723&amp;type=bug
Notes
(0054897)
vboctor   
2017-01-02 23:05   

We had a discussion on this. We may end up deprecating such configuration option depending on the final solution that results from the discussion. Assigning to @syncguru since he will coordinate this discussion and the necessary work out of it.

(0054899)
atrol   
2017-01-03 02:54   

The request has been triggered by a user in forum.

Keep also in mind that we use it on https://www.mantisbt.org/bugs
$g_bottom_include_page = 'config/custom_footer.php';

(0054947)
SteveA   
2017-01-05 13:35   

Losing this functionality is causing me problems. I use $g_top_include_page and $g_bottom_include_page to basically wrap a MantisBT installation into an existing website . Removing the $g_bottom_include_page means I can't do this any more (we have some javascript that loads in the footer of the site which is needed to support some of the site menu functionality).

(0055326)
mahindra   
2017-01-25 14:32   

I am using $g_bottom_include_page to get our Name and Logo on the logon page
Now I am using $g_logo_image and have put the text in it - but it is not as nice as include page

(0055352)
mahindra   
2017-01-26 17:52   

It is possible to get the logo in $g_window_title = 'TESTUMGEBUNG - <img src="/mantis_TEST/images/EBVLOGO_60.gif" height="35" " />';

That's all what we need - thank you for this great system! :)

(0055353)
mahindra   
2017-01-26 18:22   

but this is not beautifull ;)

(0055359)
vboctor   
2017-01-26 21:50   

@mahindra the ability add html in the window title as in 0022098:0055352 is a bug that we should fix. It also won't work because window title is also used in other scenarios like some of the email notifications.

(0055629)
JWPlatt   
2017-02-10 00:52   

Like SteveA, we use $g_top_include_page and $g_bottom_include_page to wrap a MantisBT installation into our website with a consistent banner, menu, and game server statuses across all pages and subdomains for navigation. We manage open source development of the Cyan Worlds' Myst Online (Uru) MMO. Without the custom header and footer, I cannot upgrade from 1.3 to 2.x+ and maintain visual integration. I don't understand how there can be any question about web products like this playing friendly with website integration.

This is our implementation of 1.3:
http://bugs.openuru.org

(0055715)
vendeeglobe   
2017-02-17 03:41   

We used $g_top_include_page = '%absolute_path%/header.inc.php'; as project meta-navigation. Now what out of the box solution do we have for this purpose?

(0055722)
JWPlatt   
2017-02-19 17:46   

I see this task is assigned, but will restoring $g_top_include_page and $g_bottom_include_page definitely be on the roadmap? An existing feature for many years has been removed, so I'm naturally curious about why.

(0055723)
JWPlatt   
2017-02-19 18:08   

I guess a question after looking at your pull request from syncguru:
https://github.com/mantisbt/mantisbt/pull/860/commits
https://github.com/mantisbt/mantisbt/pull/860/commits/89e66ff60cfd2ebebb52ef6587c1eed55911c9ce

What happens if I apply it? Or in other words - why not?

(0056557)
Xenos   
2017-04-15 05:54   

That's easy: if these no longer work in Mantis, and we have no simple straight-through way to do so, then I'll stay on the old-that-will-be-vulnerable-but-still-since-it-works version

<code>
$g_top_include_page = '%absolute_path%/config/header.php';
$g_bottom_include_page = '%absolute_path%/config/bottom.php';
$g_meta_include_file = '%absolute_path%/config/meta.php';
</code>

I need these to set up custom conditionnal CSS sheets, custom metas (like charset), custom JS to load, and brand headers.
For now, this bug (and also, the fact that the whole styling changed so I'll have to retrain people on how to use this tracker, which is also very annoying btw) is a blocker to me.

(0056562)
JWPlatt   
2017-04-15 10:21   

@vbdoctor @syncguru How does this project defend eliminating support for a critical website integration feature that existed for years and the subsequent deafening silence about its restoration? There can be no question about web products like this playing friendly with website integration.

(0056564)
JWPlatt   
2017-04-15 10:23   

@vboctor See imperative note above. Adding this because I got your username wrong.

(0056566)
SteveA   
2017-04-15 11:02   

The continual pushing out to the next version for this fix is worrying - it suggests that this is not actually going to be fixed.

As others have noted it seems that this key bit of functionality (which is even used by the Mantis Team themselves) was dropped without any consideration of how Mantis is being used (I assume because it just didn't fit into how the new UI was designed ) . If the team are not going to re-implement this code (or another way of integrating mantis into other sites) then we're either left relying on the 1.3 code base or moving away from Mantis totally.

(0056602)
Xenos   
2017-04-17 15:36   
(Last edited: 2017-04-17 15:49)

I think I'll do Mantis' team job here, but that's the way I "fixed" that issue. I used someone else's plugin as a base, and built up something without reading any doc (because nope, I didn't want to spend time reading docs while it was instant to do this before) [I'll rename the plugin btw... I'll let you guess the original name]:

1) Create a "MyKingCustomPlugin" directory in the "plugins" directory
2) Create a README.md in there containing a short description like:

MyKingCustomPlugin

Because they changed everything when it comes to custom CSS/JS/meta tags
3) In that same folder, create a "MyKingCustomPLugin" file, containing your plugin code:

&lt;?php
// Funny: the class name is not the same as the file name... but who cares about PSR0 anyway?!
class MyKingCustomPluginPlugin extends MantisPlugin {

    public function register() {
        $this->name = 'My King Custom Plugin';
        $this->description = 'Custom stylings and such for this ... new Mantis version';

        $this->version = '0.1.0';
        $this->requires = array(
        'MantisCore' => '2.0.0'
        );

        $this->author = 'Xenos';
        $this->contact = 'xenos@reinom.oom';
        $this->url = 'https://toile.reinom.com';
    }

    public function hooks() {
        return array(
            'EVENT_LAYOUT_RESOURCES' => 'meta',
            'EVENT_LAYOUT_PAGE_FOOTER' => 'bottom',
            'EVENT_LAYOUT_PAGE_HEADER' => 'header'
// Funny thing: the EVENT_LAYOUT_PAGE_HEADER is never fired because of another bug
        );
    }

    public function bottom($p_event) {
        ?>
&lt;!-- Bottom HTML/PHP code goes here -->
        &lt;a href=&quot;https://reinom.com&quot; class=&quot;my-brand&quot;>
            &lt;img class=&quot;logo reinom&quot;
                 src=&quot;/custom/blog-icon.png?t=20170415A&quot; alt=&quot;Liste des projets Reinom&quot; title=&quot;Projets&quot;/>
        &lt;/a>
        &lt;?php
    }

    public function meta($p_event) {
        ?>
&lt;!-- Custom HTML meta code and PHP goes here -->
        &lt;meta charset=&quot;utf-8&quot;/>
        &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1.0&quot;/>

        &lt;link rel=&quot;stylesheet&quot; type=&quot;text/css&quot; href=&quot;/custom/custom.css?t=20170415A&quot;/>
        &lt;script class=&quot;my-stuff&quot;
                data-login-status=&quot;&lt;?php echo auth_is_user_authenticated() ? 'is-not-anonymous' : 'is-anonymous'; ?>&quot;
                src=&quot;/custom/custom.js?t=20170415A&quot;>/* report bogue */&lt;/script>
        &lt;?php
    }
    public function header($p_event) {
        ?>
&lt;!-- Header code should go here, but, meh, bugged -->
        &lt;?php
    }
}

4) Put your custom CSS and JS in dedicated files (because Content Security Policies may break your inline stuff), and NOT inside the plugins directiory (would have sound logical to put CSS/JS of a plugin inside that plugin's directory, but since it doesn't work out of the box like before, I've put it all in a "custom" directory inside the root folder of the server).
5) Have fun making your CSS/JS work again, because like ALL classes and such have been changed too... note that a LOT of "widgets" have no specific class, which is another painful thing.

Maybe it will help some people.
(btw since we still have no preview thing, which was IMO way more important than breaking all codes for this new structure and styling, then I have no idea how this note will render; hope it will look fine still).

(0057025)
SteveA   
2017-06-04 16:37   

So does another push out mean that we're actually no closer to knowing if this core functionality is going to be re-instated?

(0057026)
JWPlatt   
2017-06-04 17:22   

@SteveA You're putting negligence more politely than I would. I'm sure it's appreciated. I would never so cavalierly drop such an important feature in a project.

(0057209)
Emmanuel   
2017-07-12 12:02   

Hi Mantis Team,
We need to add a logo and add a link to documentation PDF.
$g_top_include_page is not working on 2.5.1.
Have you schedule to fix this feature ? Thank you.

(0057213)
JWPlatt   
2017-07-12 21:32   

@Emmanuel No. They're using the Microsoft approach to Window 8 with all the silence, but without the contrition and apologies to follow.

(0057286)
SteveA   
2017-07-21 17:27   

I assume that nothing from the Mantis team means that they've actually done nothing and are just hoping this will go away and they can concentrate on the "new shiny"

It would be good if you could at least confirm if you are ever going to re-instate this functionality. If you're not then that means people can look at working round it or moving to another product.

(0057287)
mahindra   
2017-07-21 17:35   

To change the loge has done this in our mantis.
Ok it's different and not so adaptable - but it also brings back a bit of corporate identity.

(0057288)
mahindra   
2017-07-21 17:35   

Logo ;)

(0057293)
atrol   
2017-07-23 08:08   

No excuse, but keep in mind that Mantis is developed by just a few people, working in their free time without getting paid for it.
At the moment, hardly anyone of us is able to invest time for Mantis.
This might change in some weeks, you never know.
I have hardly any time at the moment to contibute to this issue, I don't need it myself.

The solution is not that simple like some of you might think, at least if you don't want a quick and dirty solution.
https://github.com/mantisbt/mantisbt/pull/860 might give you an impression.
Any input is welcome. Notes like 0022098:0057213 and similar don't help to get any progress.

Finally we might end in a complete other and better solution than what we had in version 1.3.
E.g. we could offer a page where you can upload your logo and enter some additional HTML code.
Until there is a final decision, 0022098:0056602 is a good way to get what you want. Thanks @Xenos for it.

@JWPlatt I had a look at your Mantis installation, but also your Jira installation.
There is no top banner or menu in Jira, so I assume it is no high priority for you to have it in Mantis.

There are two options at the moment

  • stay with 1.3.x, which is still supported and gets security fixes.
  • use 2.x by using a plugin like the one proposed at 0022098:0056602.
(0057295)
SteveA   
2017-07-23 09:24   

Thanks for giving some update on this matter - its been a long time since anyone from the core Mantis team made any comment and all we've seen is the milestone being pushed out and out.

Staying with 1.3.x is what I suspect most people are planning to do.. it might be worth considering making it easier to find the 1.3.x security updates from the website - the download page only gives access to the current 2.x release....

(0057296)
JWPlatt   
2017-07-23 11:21   

@atrol Don't assume. The feature in Mantis is above a top priority. We will NEVER move to version 2 of Mantis until site integration is reimplemented. If it does not come soon enough such that security is compromised due to lack of maintenance on version 1, we will DELETE the Mantis installation entirely and forever in favor of using Atlassian tools such as JIRA. There is no comparison between JIRA and Mantis. JIRA is an enterprise tool from a large commercial company where we have no hope of influence over their support of any significant site integration. Whereas Mantis is really just a small tool we installed for people who like it, or don't like JIRA, but is entirely disposable. It's do or die for your small team, at least with us.

Candidly, as a professional software developer myself, dropping a long-existing and important feature like this was a bad decision. We wouldn't be having this discussion about finding time to reimplement it if you didn't drop the ball in the first place.

JW

(0057297)
syncguru   
2017-07-23 11:54   

@JWPlatt: Why the threatening hostile tone? Last I checked, Mantis is a free software that is developed and maintained by volunteers ...

The modern UI is much more complex. Supporting a configuration that allows random JS files to be loaded at different points during page load is very fragile and slows down or totally hinders future UI/UX enhancements. I don't think core mantis code should be concerned with that and take the hit to maintain it.
The solution that was proposed earlier in this issue is using a plugin to do the inclusion of JS files. I think that is a workable solution and should be taken seriously. I'd expect professional software developers to arrive at such conclusion, however.

(0057298)
SteveA   
2017-07-23 12:03   

But the header and footer allowed you to wrap Mantis into another website, basically integrating it. It does seem that the Modern UI was designed without considering that functionality, and I do find it rather ironic that back in January it was pointed out that the mantis site itself uses this now discarded functionality.

(0057299)
JWPlatt   
2017-07-23 12:11   

@syncguru Just giving you the candid reality of our decision process. Mantis has been on our trigger for a long time. I'm the site owner and the one who has kept it alive and integrated through upgrades because I don't believe in dropping important features for our past and future users. Get it?

If the plugin is a viable immediate solution, refine and integrate THAT into your distribution. I spend my volunteer time on our site. I'm not handing yours too.

JW

(0057300)
SteveA   
2017-07-23 12:20   

And that plugin would possibly be OK apart from the fact that EVENT_LAYOUT_PAGE_HEADER isn't fired at any time due to an unfixed bug...

(0057302)
vboctor   
2017-07-23 13:46   

For the scenario of using the EVENT_LAYOUT_PAGE_HEADER for adding a message to the users (which is what we were using this event for in this tracker), the proper way of doing this now is via the Announce plugin.

https://github.com/mantisbt-plugins/announce

As I said in 0022098:0054897, you should expect that this functionality is likely deprecated as far as MantisBT 2.x core is concerned. A plugin may surface that would enable such functionality in the future by some community member.

To reflect that, I have removed the target version from this issue.

Any product change is likely to not fit 100% of our user base, but our goal is that our product development benefits the majority of our users.

(0057303)
SteveA   
2017-07-23 13:55   

OK so something that was used by quite a lot of people, and which is still in your documentation for 2.5 has basically been removed and is not going to be re-introduced, and there is now no way of wrapping Mantis into another site because there is no easy way to inject wrapping code (such as divs) round the mantis pages

(0057309)
JWPlatt   
2017-07-23 16:35   

@vboctor It would be interesting to see your poll numbers from the research you did on behalf of your userbase to so well understand where the majority lies prior to dropping a major feature to help them with this beneficial action.

(0057310)
SteveA   
2017-07-23 16:49   

As you merged 0022117 and 0022494 into this - both of of which are concerned with general usage of the features rather than Mantis's own specific use - you can't really say that the announce plugin is the resolution.

Two features were removed from 2.5 (but not removed from the documentation, nor fully removed from the code base) - apparently after an internal discussion by the Mantis team.

Don't you feel that maybe asking end users about removing this functionality might have been wise?

(0057314)
Xenos   
2017-07-24 08:19   

@JWPlatt IMO, even if it's interesting to know your decision process, the way you worded it was indeed agressive (like Mantis team would be afraid of you dropping out the free tool they made...?!)
@SteveA I'm unsure about how you make your wrapping, but if you're using iframe then you may just put your stylings and such outside that iframe. If "wrapping" actually means "be on the the website domain and graphically look like the rest of the website", then I would suggest you to add CSS and script tags in the meta part (which works) and use the script to alter your content as you wish. That way, you won't be relying on Mantis' internal "event" thing, and just put your styling as a dedicated layer over the Mantis website. As it's styling, you don't have to worry about non-JS executing users nor search engines (which does seem to execute JS nowadays). If you still want to do it server-side, then you can always use a ob_start in your meta and alter to full content of the result (a bit heavy, but a way that works too).

But I agree with you that, from user point of view, it also seems late to me to be aware of dropped features after the release (or after the decision of removal is taken). I would too appreciate some place to be informed about that (ie: a RSS or, better, a mailing list).

(0057798)
SteveA   
2017-09-23 06:35   

@Xenos - iframes don't work very well -: one because of the Content-Security-Policy headers but also because of the changing URLs that Mantis uses.

The problem with just editing the meta is that on our site there is a left hand menu and a header which wraps round Mantis - basically Mantis is presented within the main DIV we have set where we render the active part of the site. The last line in the header include we use is <div id="main-content">

(0057800)
JWPlatt   
2017-09-23 11:53   

@vboctor @atrol @syncguru Is such site integration really impossible or beyond reasonable technical abilities to support?

I notice vboctor has not yet released the poll data actually showing what "the majority of our users" actually wants. Until then, I'll take it as a convenient and baseless rationalization for the laziness of dropping a long-time integration feature instead of supporting compatibility with prior work.

(0058020)
SteveA   
2017-10-22 09:38   

Is there any update on this? Is it ever going to be re-implemented or not?

(0058043)
samtuke   
2017-10-24 11:34   

We are also hoping to see this fixed

(0058268)
Starbuck   
2017-11-29 23:40   

I also found the feature not working and found this ticket quickly. I rarely post something like this but I found the whining in these notes very disturbing. As a user I completely relate to the situation, don't get me wrong - it's upsetting when existing functionality is deprecated.

But you people are completely missing the spirit of FOSS, and I have seen this a lot over the last 20 years. The pattern is that people feel entitled to get free/no-cost software and then complain violently when something doesn't work. But almost no one is willing to contribute to a resolution. The Free in FOSS isn't just about free beer, it's about freedom to make changes. The Open part means it's completely transparent, unlike binary commercial software. These qualities mean YOU have the right and ability to contribute to the project, and when it comes to something like this that starts to bend toward an obligation and responsibility. You're bragging about how you've relied on this software for years. But have you lifted a single finger to help in any way?

Let's turn this into a positive experience. You don't need to contribute code or write docs. And I don't think offering money to the primary maintenance people here is going to help them to free up any time. I do suggest that now is the time to find a young programmer who is looking for a little fame and a few bucks to provide you with what you want. It doesn't need to be money - offer some pizza, or if you run websites offer someone some free services in return for free services that they can provide to you. A real FOSS developer would appreciate it if you would "pay forward", not just "pay back" by just giving something to anyone in return for someone doing a favor for you. This is the spirit of FOSS and you guys are NOT getting it.

What we really need for MantisBT is more plugins. What we have for this software pales compared to plugins available for other platforms like WordPress or Drupal. Help to find people who want to write plugins, motivate them to create what you want by giving them something that they want.

By getting someone else interested in this project we all benefit. But FOSS consumers Must stop abusing the FOSS providers. Look at the thousands of dead freeware projects out there - many of them because the authors have been abused like we see here. It's just not worth it to deal with that kind of grief no matter how much people like @vboctor and @atrol enjoy working on this.

So get off their backs and off your asses and try to help with this rather than sitting back another year, doing nothing but whining. CONTRIBUTE! Ahem. Thanks for your time.

(0058269)
mahindra   
2017-11-30 01:13   

+1
A simple image did this for us.

(0058270)
JWPlatt   
2017-11-30 02:35   

@Starbuck

I like and appreciate your attitude and it certainly belongs and is valued in the open source community, to which I contribute elsewhere. Sadly, it's misplaced here.

The team that made the bone-headed, or simply cavalier, decision to drop an such an important feature like visual site integration, without providing a plugin, could very well make more bone-headed decisions. They control the merges, and I'm not going to fork or write a plugin for something that could suffer from more poor decisions. They know the code. It would be inefficient for me when they are infinitely more intimate with the code and could very well, perhaps even easily, produce a finished plugin for which Xenos started with a template in a post above. I wouldn't stand by and watch someone struggle and sink their precious time into something I know I could do faster and more easily.

(0058273)
atrol   
2017-11-30 04:39   
(Last edited: 2017-11-30 04:40)

Thanks @Starbuck for the note.

@JWPlatt, what's your goal?
Do you want us writing: JWPlatt is right, the Mantis team is bone-headed?

You wrote on your own forum that your goal is to shutdown your Mantis installation as it's not used since years.
Are those 23 issues in your tracker worth all this discussion?
Is it really your goal to get the issue fixed?

If so, take part on the technical discussion in the PR and/or try if the plugin is a solution for you and/or create your own branch with changes in your fork.
All those options are possible thanks to Open Source.

Really strange to read 0022098:0057296.

JIRA is an enterprise tool from a large commercial company where we have no hope of influence over their support of any significant site integration.

So you prefer to pay for a Closed Source product and to have no influence on development over not to pay and to be able to influence?
It's your decision, do whatever you want, but please stop writing unproductive comments.
They don't help to get any progress, but are just a waste of time.

(0058274)
mahindra   
2017-11-30 04:55   

It will be easy to render the include page in the black frame on top of the site.
There where you See MantisBT ;)

(0058284)
Starbuck   
2017-11-30 11:13   

While I'm familiar with the visual differences between v1 and v2, I'm not familiar with what looks like a higher-level decision about about how UI customizations have been changed and complicated. I recommend a forum discussion about what's changed, why it's created this complication, and then what we might be able to do to modify and then work With this new paradigm, via plugins or manual tweaks.

(0058286)
JWPlatt   
2017-11-30 16:02   

@atrol

Interesting questions. And thanks for taking the time to understand where I'm coming from.

what's your goal?

To retain use of Mantis under full site integration (a logo doesn't suffice) for possible future use where contributors might prefer it to our Atlassian tools. Choice is better. If no one uses Mantis, so be it, but I will support it for as long as Mantis supports sites with an upgrade path and no loss of function, such as critical site integration. Without site integration, Mantis will not be supported and upgraded and must eventually be removed. If it is removed, there is no choice for the users.

...try if the plugin is a solution for you and/or create your own branch with changes in your fork.

I partially address that, saying it would not happen because I would need to start from the ground up, having no knowledge of the Mantis codebase, while those in the project could do it far more quickly, easily, and probably much better because of their (your) experience. Site integration should not have been dropped anyway to force me into a choice of developing a solution or dropping Mantis. I really don't want to pay for others' mistakes when I can be more productive to the people who depend on me to be responsible and support them in my own projects. As you are for Mantis. Further, a look at the Xenos code led me to believe it is a more specific use and not fully fleshed out to be flexible enough to work for all sites as a general plugin. Specifically, Xenos comments 4 and 5 were particularly frightful.

So you prefer to pay for a Closed Source product ...

JIRA and the other Atlassian tools are free to open source projects. We get it for free.

(0058372)
mahindra   
2017-12-10 02:53   

There is so much space...

(0058377)
Emmanuel   
2017-12-11 08:43   

Hi all,
I solve my proble : add a logo and a doc link in the header of mantisbt2.

Thanks to Xenos and is MyKingCustomPlugin, I use it and add the logo and link in the footer. Then ask to js to move it.


jQuery( document ).ready(function() {
    jQuery(&quot;.smaller-75&quot;).contents().remove(); 
    jQuery(&quot;.logo&quot;).appendTo(&quot;.smaller-75&quot;); 
    jQuery(&quot;.doc&quot;).appendTo(&quot;.smaller-75&quot;);
});

Emmanuel
(0060488)
Darkseal   
2018-08-24 09:52   
(Last edited: 2018-08-24 09:55)

I developed a dedicated plugin to fix such issue for good, together with a bunch of similar scenarios when dealing with external JS, CSS and HTML content.

Here are the links:

https://www.ryadel.com/en/mantis-mantisbt-plugin-custom-content-php-html-css-js-files/
https://github.com/Darkseal/CustomContent/

The plugin has been released under GNU license 3.0, so it's fully usable by everyone.
A big thanks to Xenos and to his MyKingCustomPlugin for the inspiration (I've mentioned you in the "Acknowledgments" section, together with this whole issue).

(0060492)
JWPlatt   
2018-08-25 21:39   

Thanks, @Darkseal! I will test this as soon as I can. I'm hoping it looks just like it did when we used $g_top_include_page and $g_bottom_include_page. If it does, you've done what the Mantis team would not, and maybe they will consider incorporating it it into future releases.

(0060493)
SteveA   
2018-08-26 04:33   
(Last edited: 2018-08-26 04:35)

I tried to use it but had problems - I will try to remember what they were and put the issues on Github (I know I had problems with the names for the globals being wrong) and I couldn't get it to wrap the page correctly.

I think the problem is that it doesn't fully reproduce the three original insert points.

(0060494)
Darkseal   
2018-08-26 07:02   
(Last edited: 2018-08-26 07:27)

@SteveA , thanks for your GitHub feedback! I fixed a couple issues there and added the missing include file.

Notice that the CustomContent plugin insert points are currently FIVE, and only FOUR of them are currently working because of a bug in the current Mantis 2.16.0 source code, which doesn't trigger the corresponding EVENT_LAYOUT_PAGE_HEADER hook anymore.

If you really need to also enable that fifth one I can show you how to modify the mantis source code to manually trigger it and make it work with the pugin, but I wouldn't want to do that as the Mantis team will most likely fix that in a future release (thus fixing the plugin as well).

Notice, though, that with the HEADER insert point (which is currently working) you can do almost everything using JavaScript/JQuery, including HTML injection in the header part of the page (which is a much cleaner approach until they fix the source code). I added some useful examples in the CustomContent plugin's README.md file, I hope you'll find them useful enough.

(0060956)
Starbuck   
2018-11-13 14:28   

Since there is a new solution for this, I recommend discussion of the plugin get moved to the new forum for General Plugin Discussion . Thanks Ryan!

And since it looks like this will not be fixed, I recommend the status of this ticket get changed accordingly. If closed, perhaps the summary should recommend "consideration of" the CustomContent plugin ... until another built-in solution is available.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26701 [mantisbt] preferences minor have not tried 2020-02-13 04:05 2020-02-13 04:05
Reporter: cproensa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.24.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Notification of a note added is not received when the issue is updated
Description:

When having my user preferences, for example:

  • E-mail on Status Change: disabled
  • E-mail on Note Added: enabled

When an issue is updated that matches those rules: by changing status and having a note added in the same "change status page", there is no notification sent.
I would expect a "note added" notification.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26693 [mantisbt] api rest major always 2020-02-11 05:28 2020-02-11 05:28
Reporter: fman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Avoid to create invalid JSON response when locatization issues happen
Description:

I've missed some label translations when adding new relationships types.
When using the getIssue method Mantis returns the json with issue data + warning messages that seem to be triggered by code in lang_api.php

IMHO if is not a crash, some error triggered needed to be different when error happens when a 'human being' is watching the screen, and when a API call is done, to avoid in the case of API call that other system break.
In my case json_decode() on content got from mantis fails
I've refactoring my code to provide a better error message in this situation

please let me know if you need more details.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26691 [mantisbt] api rest feature N/A 2020-02-10 13:15 2020-02-10 13:15
Reporter: fman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add Logic to select what issue attributes have to be returned
Description:

IMHO it will be great if the getIssue call will have an additional parameter to select the amount of information to retrieve
For some use cases, you do not want to retrieve the issue history or the notes.

I've inspected the code and it seems all the magic happens in file mc_issue_api.php -> mci_issue_data_as_array()
The needed change means to add (brute force solution) code like this

if ( isset($p_attr['steps_to_reproduce'])) {
the original code.
}

where p_attr will be a new function argument.

Another solution is to have a config variable at the project level that will allow a more static and less flexible configuration to select what attributes to retrieve.

Probably a new REST API route to get ONLY the issue history can be useful

regards

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25698 [mantisbt] mentions minor have not tried 2019-04-17 11:14 2020-02-10 08:11
Reporter: Maurycy Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 2.19.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mentions does not work when user login is an email
Description:

In our organization all logins are oganizational email accounts. Also in Mantis we use emails as logins (usernames). Unfortunately that causes that mentioning does not work, because it does not include char @ as possible element of user name.

Tags:
Steps To Reproduce:
Additional Information:

Currently the pattern matching for mentions looks like that:

        $s_pattern = '/(?:'
            # Negative lookbehind to ensure we have whitespace or start of
            # string before the tag - ensures we don't match a tag in the
            # middle of a word (e.g. e-mail address)
            . '(?&lt;=^|[^\w])'
            # Negative lookbehind  to ensure we don't match multiple tags
            . '(?&lt;!' . $t_quoted_tag . ')' . $t_quoted_tag
            . ')'
            # any word char, dash or period, must end with word char
            . '([\w\-.]*[\w])'
            # Lookforward to ensure next char is not a valid mention char or
            # the end of the string, or the mention tag
            . '(?=[^\w@]|$)'
            . '(?!$t_quoted_tag)'
            . '/';

My proposition is to extend it like this:

        $s_pattern = '/(?:'
            # Negative lookbehind to ensure we have whitespace or start of
            # string before the tag - ensures we don't match a tag in the
            # middle of a word (e.g. e-mail address)
            . '(?&lt;=^|[^\w])'
            # Negative lookbehind  to ensure we don't match multiple tags
            . '(?&lt;!' . $t_quoted_tag . ')' . $t_quoted_tag
            . ')'
            # any word char, dash, period or at sign, must end with word char
            . '([\w\-.@]*[\w])'
            # Lookforward to ensure next char is not a valid mention char or
            # the end of the string, or the mention tag
            . '(?=[^\w@]|$)'
            . '(?!$t_quoted_tag)'
            . '/';

I've tested this pattern and it seems to work, see: https://regex101.com/r/gkitVn/1

Attached Files: mention_api.php.patch (771 bytes) 2019-04-19 06:21
https://mantisbt.org/bugs/file_download.php?file_id=8522&amp;type=bug
Notes
(0061962)
dregad   
2019-04-18 03:45   

The updated regex allows any number of @ signs in the string, which would not be a valid username identifier, but considering that we only create the link if the pattern match corresponds to an existing user, it probably would not be a problem.

(0061963)
Maurycy   
2019-04-18 03:53   

True... we could change it from ([\w\-.@]*[\w]) to ([\w\-.]*@?[\w\-.]*[\w])

(0061982)
Maurycy   
2019-04-19 06:21   

Attached patch file that allows for single @ sign inside user name.

(0063597)
phanek   
2020-02-10 08:04   
(Last edited: 2020-02-10 08:08)

@stevecharon
test

(0063598)
phanek   
2020-02-10 08:04   
(Last edited: 2020-02-10 08:11)

test 2
@stevecharon



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26680 [mantisbt] api rest feature N/A 2020-02-07 04:10 2020-02-07 04:10
Reporter: fman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add extra field in JSON input for issue add/update to interact with plugins
Description:

Use case
I have and planning application that needs to create a MANTIS BUG when a PLANNING ASK is created, and we need to have in the MANTIS TICKET a reference to the PLANNING TASK UUID, on a specific plugin table.
I do not want to use CUSTOM FIELDS

Right now if you add one or more additional attributes in the JSON used to call the Mantis REST API, no error is thrown but these attributes dos are not added to the issue object in IssueAddCommand.php code

=> $this->issue = new BugData; (line 240)

IMHO il will be useful is ONE additional attribute 'extra' will be added AS IS, in order to be managed in the plugin method related to bug add/update

hope the request is clear

regards

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5278 [mantisbt] custom fields feature always 2005-02-24 11:30 2020-02-07 04:03
Reporter: HeikoNorderstedt Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: custom field for user accounts
Description:

We made several changes to use the custom fields for the user accounts as well. To use the fields they have to be added in the "Manage Users" section. The value of the custom field from the user account (from every single user) will be copied into the custom field in the report page. We use this for example to fill out the telephone number from our costumers.

To store the values of the user custom fields we need two new database tables:
mantis_custom_field_user_table, mantis_custom_field_user_string_table

To use the extension you have to execute the upgrade script in the admin directory of mantis.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: AccountPage.png (15,270 bytes) 2005-02-24 11:31
https://mantisbt.org/bugs/file_download.php?file_id=629&amp;type=bug
Mantis_0192_UserCustomFields.zip (38,344 bytes) 2005-02-24 11:31
https://mantisbt.org/bugs/file_download.php?file_id=630&amp;type=bug
upgrade_patch.zip (5,029 bytes) 2007-06-11 04:07
https://mantisbt.org/bugs/file_download.php?file_id=1343&amp;type=bug
Add_User_Custom_Fields.png (3,589 bytes) 2007-06-11 04:07
https://mantisbt.org/bugs/file_download.php?file_id=1344&amp;type=bug
0_19_user_custom_fields.php (1,483 bytes) 2007-06-13 03:31
https://mantisbt.org/bugs/file_download.php?file_id=1346&amp;type=bug
Mantis105CustomUsterFields.zip (38,258 bytes) 2007-06-13 10:55
https://mantisbt.org/bugs/file_download.php?file_id=1347&amp;type=bug
AccountCustomFields.zip (16,447 bytes) 2015-06-10 08:35
https://mantisbt.org/bugs/file_download.php?file_id=6350&amp;type=bug
strings_arabic.txt (1,837 bytes) 2015-06-26 21:25
https://mantisbt.org/bugs/file_download.php?file_id=6373&amp;type=bug
user profiles mod themadmaxboy.rar (6,938 bytes) 2015-07-01 21:28
https://mantisbt.org/bugs/file_download.php?file_id=6375&amp;type=bug
Notes
(0009729)
grangeway   
2005-04-05 13:54   

Do you have that zip handy in form of a diff at all?

Paul

(0009740)
HeikoNorderstedt   
2005-04-06 02:48   

Sorry, I only have the zip file with the changed and new sources. I am not so familar with cvs to produce diff files, but the changes all base on the 0.19.2 Release Version of mantis.

Heiko

(0014686)
daryn   
2007-06-06 10:23   

Is this being worked? I see the last comment was two years ago. I'm very interested in this feature and would be willing to work on it if needed. The attachments are missing and I'm wondering if there are any design specs for the feature.

(0014687)
HeikoNorderstedt   
2007-06-06 11:29   

Yes it's working. We added the changes on the 1.0.5 release of mantis. If you are interested, i can upload the changed sources in the next days.

What do you mean with "design specs"?

The features of the modification are:

  • You can add costum fields to the user account, the same way as you can
    add them to the bug.
  • If you add the same custom fields to the account and the bug, the values
    from the user account custom fields will be copied to the bug custom fields.
(0014689)
daryn   
2007-06-06 12:08   

Great. I'm keeping my code synced with cvs but I don't see anything related to this. Is it in CVS yet or just patched to a release? If it's already in there how do I configure it? I don't seem to be able to find it. If it isn't there, yes I would certainly be interested in the source changes.

In regard to design specs, I was just wondering if there was any documentation specifying how this should be implemented. Your explanation below is helpful.

Thanks for the speedy response!

Daryn

(0014704)
HeikoNorderstedt   
2007-06-07 09:13   
(Last edited: 2007-06-07 09:14)

@daryn
I uploaded the changed PHP-Filed based on Version 1.0.5. I did not test, if the changes are complete and working. Please response if something ist missing. To use the modification you have to execute the upgrade scipt in the admin directory of mantis. This will create the new two tables for the user-custom field entries.

(0014717)
daryn   
2007-06-08 13:29   

I'm having trouble with the db update. I tried to run the admin/update script and several things were updated but the user custom fields were not. I don't see them in the update scripts either...

(0014742)
HeikoNorderstedt   
2007-06-11 04:11   

@daryn
Don't ask me why, but I had to patch the upgrade.php to see the upgrade-scripts. I also made a change in the upgrade_inc.php. When you click at advanced-upgrades now you should see the Add_User_Custom_Field_xxx upgrades.

(0014745)
daryn   
2007-06-12 12:39   

@Heiko I must be doing something wrong because I still am unable to get this to work. I appear to be missing the file upgrades/0_19_user_custom_fields.php. Is there a better way to discuss this? IRC?, Skype? Other?

(0014754)
HeikoNorderstedt   
2007-06-13 03:35   
(Last edited: 2007-06-14 03:08)

@daryn
Sorry I forgot to upload the Upgrade scripz 0_19_user_custom_fields.php :-O
You have to copy the script into the admin\upgrades directory.

(0014758)
HeikoNorderstedt   
2007-06-13 10:59   

@grangeway
Could you please delete the file mantis_usercustomfields.zip

(0014759)
vboctor   
2007-06-13 12:43   

I deleted mantis_usercustomfields.zip.

(0025594)
djcarr   
2010-05-23 21:02   

I think the ability to have a custom field of type User still has strong value, as you can then create fields such as Tester etc.

With current Mantis the testing team try to assign issues to themselves which breaks the developer-based statistics. It'd be ideal to provide a custom field that they can incorporate into their workflow.

(0026906)
rtartas   
2010-09-29 05:23   

Hi,

I use Mantis 1.2.2. Can anybody advice (step by step) how to install the User Custom fields functionality?

(0029687)
rtartas   
2011-09-12 05:37   

Hi,

I upgraded Mantis to version 1.2.5. Can anybody advice (step by step) how to install the User Custom fields functionality?

(0029688)
HeikoNorderstedt   
2011-09-12 07:42   

Hi rtartas,

the modified Mantis source code is based on version 1.05. It will not work on version 1.25. We also plan to upgrade our mantis installation in the near future. If there is still interest in our modifications, we can upload a new version then.

(0029689)
rtartas   
2011-09-12 07:53   

Hi Heiko,

Yes, I'm still interested in this modification. So if you could upgrade this and upload this here - I'll be very happy!

Thank you!

(0039670)
mach825   
2014-03-15 17:48   

Hello,

This seems like a really nice feature to have. Will this customization be upgraded to work with the 1.2.x code?

Thank you,
Shannon

(0039677)
HeikoNorderstedt   
2014-03-17 06:06   

Hello mach825,

currently we are running version 1.2.11 of mantis. I handed over then development of our mantis installation to our working student. We made several changes to the original code. We have to seperate these changes before we can upload the necessary code for the custom fields. This will take a while. :-)

(0039681)
cas   
2014-03-17 06:54   

This should be a plugin, would make life much easier

(0040999)
Jo   
2014-07-28 11:44   

Hi,
I use Mantis 1.2.17. How can I upgrade this modification? I really need to add a column to sync user's more info from LDAP.

(0041001)
HeikoNorderstedt   
2014-07-29 03:17   

@Jo
We are currently working to make the custom user fields to a plugin. After testing the plugin we will make it available. But this will take some time.

(0041002)
Jo   
2014-07-29 08:35   

@HeikoNorderstedt
Thanks a lot.
Sincerely hope that we can use this plugin soon as possible.

(0041823)
HeikoNorderstedt   
2014-11-10 03:12   

@Jo
The develpment is almost complete. We are testing at the moment.

(0050680)
mohamedh   
2015-04-30 17:47   

sorry but I still don't understand how to add this "custom user fields" feature to mantis

can someone explain to me please?

(0050846)
mohamedh   
2015-05-31 09:58   

@HeikoNorderstedt

I would like to ask about the plugin you were talking about, is it ready? can you kindly share it with us?

(0050880)
HeikoNorderstedt   
2015-06-08 03:53   

@mohamedh
Sorry, we are still testing the plugin.
Our Mantis Version is 1.2.11. We will try upgrade the version for Mantis 1.2.19 and upload an "untested" diff-file. Please refrain from further questions.

(0050881)
mohamedh   
2015-06-08 12:24   

@HeikoNorderstedt

Thanks a lot for taking time to reply, I can wait a little longer, no problem.
Also, I don't have any problems with using an Untested version and I would really appreciate it if you share it, because I need that plugin badly.

I didn't mean to bother you by asking, by I was just curious to know more about the current state of the plugin.
Anyway, I'm not gonna ask you again, I will wait for you to post it here, but please share it ASAP once it's usable
And thanks a lot

(0050885)
HeikoNorderstedt   
2015-06-10 08:37   

@mohamedh
I have uploaded the Plugin for the Mantis Version 1.2.19.
The Plugin ist not tested yet!
Feel free to report bugs but do not expect to get them fixed :-)

(0050919)
mohamedh   
2015-06-15 16:43   

@HeikoNorderstedt

THx alot
It works like a charm, you're awesome, the plugin is awesome, and the entire world is awesome XD

thanks again for the plugin, it's working very good, btw if you're planning to release it for public I can offer to translate it to Arabic, French and maybe Spanish and Turkish(my Turkish and Spanish aren't good enough though)

(0050920)
HeikoNorderstedt   
2015-06-16 03:29   

@mohamedh
After some more testing we could publish the plugin in the official git-hub repository. I am not sure if it is allowed for 'official' plugins to make changes to the original source code of mantis.

If you like you can upload your translations here. We could add a polish language file.

Thanks for your responds.

(0050921)
dregad   
2015-06-16 09:13   

We generally don't recommend altering MantisBT core, but I don't think there's an official policy against hosting a plugin that does in the mantisbt-plugins organization on github.

That being said, I would at least ask you to make this source code change explicit in the readme file, and also draw your attention to the fact that it is your responsibility to support such changes.

Please refer to https://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins for the process to publish a plugin.

(0050937)
mohamedh   
2015-06-18 14:31   

@HeikoNorderstedt

I have a question,is it possible to make the new custuom field visible in the "view_user_page.php"

(0050957)
HeikoNorderstedt   
2015-06-22 03:54   

@mohamedh
Yes it is possible, but it is not impelemented. We do not use the "view_user_page.php".

(0050983)
mohamedh   
2015-06-26 21:25   

Attached is the Arabic translation for your plugin, feel free to use it and insert in your next release

"Yes it is possible, but it is not impelemented"
Yeah, we have done it modifying "view_user_page.php"(core file) and it worked fine, however it will show a
"APPLICATION WARNING #100: Configuration option "plugin__auto_load_threshold" not found"

so In order to remove this warning (optional) we needed to hack this file "acf_api.php"(plugin file, located at AccountCustomFields/pages/acf_api.php)

If someone is interested I can upload the modified files.

MantisBT is very awesome and easy to customize , however it still lacks a lot of feature, specially basic ones that should exist, for example custom user fields, I think it's something that Must be available by default, with the plugin/codes being provided now thanks to HeikoNorderstedt I would like to ask if you can implement it in your future releases, also adding some nice features like private messages, ability to customize the summary page..etc would be awesome...
And thanks for all your efforts

(0050993)
HeikoNorderstedt   
2015-06-29 05:06   

@mohamedh
Please upload your modifications, so we can take a look.

(0051002)
mohamedh   
2015-07-01 21:28   

I have attached it, credits goes to themadmaxboy

(0058538)
fman   
2018-01-13 07:06   

Just started minor changes to @HeikoNorderstedt work => it rocks!!!
Just sent mail to plugin author requesting access to repository to fork.
I'm doing the silly changes needed to use plugin with MantisBT 2.x
Also minor changes to access Custom Fields on user create/update pages.
Going to provide feedback when finished (no more than a couple of weeks from now)

(0058611)
fman   
2018-01-25 10:57   
(Last edited: 2018-01-25 11:09)

Here Answer I've got:

Good Morning,
unfortunately there is no repository where you can fork from. The published version of the plugin is the only one available. Internally, we use a personalized version. You can start a new repository with the published version though, because there are no more changes to this version.
If you have questions regarding the functionality of the plugin, feel free to ask, but don’t expect an immediate answer, since I’m not responsible for our mantis version anymore. For questions regarding the mantisbt-plugins github you should probably ask the mantis developers. J

Best regards,
Sebastian

Then I'm going to start working on a repo

(0058612)
dregad   
2018-01-25 11:18   

Then I'm going to start working on a repo

@fman, as mentioned earlier, please refer to https://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins for the process to publish a plugin.

(0062935)
Spexy   
2019-10-01 10:19   

Good morning, is there a version of this plugin suitable for the current version of Mantis?

(0063445)
e_kesaf   
2020-01-16 01:44   

I also need same thing. Is there new versiyon?

MantisBT Version 2.20.0
Schema Version 209
PHP Version 7.3.7
Database Driver mysqli
Database Version, Description 10.3.16, 10.3.16-MariaDB

(0063446)
dregad   
2020-01-16 05:29   

Then I'm going to start working on a repo

Looks like @fman never got very far with creating the plugin - as I write this https://github.com/fmancardi/AccountCustomFields has only one initial commit with a readme file. Or maybe he never pushed his changes to GitHub.

(0063490)
fman   
2020-01-22 10:11   

@dregad: I'm sorry for never finishing the work. My experience is that is much better if you have minimum PHP development knowledge to develop a plugin. I've followed this path to create a RACIMatrix Plugin.

regards

(0063496)
dregad   
2020-01-23 04:16   

I'm sorry for never finishing the work

No worries, my comment was not meant to put pressure or anything, I was just stating the fact that there was no actual code in the repo, and maybe you had forgotten to push it.

The rest of your answer is somewhat confusing, I'm not sure I get your point... What does your experience, PHP knowledge or the RACIMatrix plugin have to do with this (assuming you mean https://github.com/fmancardi/RACIMatrixAssignment)

(0063592)
fman   
2020-02-07 04:03   

@dregad
I will try to explain better: if you have a medium PHP experience, IMHO it's always better to create a simple plugin to add the specific attributes that you need for the entity (in this case users).
My first approach to add attributes regarding RACI Matrix was using the USER Custom Fields plugin, but I found it not as comfortable as you can think.
Because I've some experience with the development plugin, my choice was a specific one, and I think this is the best approach if you have PHP and Mantis knowledge



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
25908 [mantisbt] security tweak N/A 2019-07-08 14:48 2020-02-06 17:59
Reporter: RealityRipple Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Block URLs in Public Notes from Anonymous Accounts
Description:

If an anonymous account is required, for, say, automated reporting by software, or just because you'd rather not prompt your users to create an (or another) account, there should probably be some extra spam prevention methods added in. My suggestion is simple: block the anonymous account from sending Notes with URLs in them.

Private notes probably aren't a big deal, since spammers are unlikely to target a single person. If this changes in the future, it can easily be changed, however. But for now, it makes for a good alternate way for legitimate anonymous users to post URLs in notes if necessary.

I've created a quick and dirty test implementation based on a dead-simple algorithm I've been using on my own website for years. Changes are very welcome.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0062367)
RealityRipple   
2019-07-08 14:52   

Pull Request of Test Implementation at https://github.com/mantisbt/mantisbt/pull/1525

(0062374)
vboctor   
2019-07-10 01:49   

Thanks @RealityRipple for your contribution.

I'm generally not convinced that allowing anonymous user to contribute content is a good setup. There is obviously the spam risk, but there are also the fact that it is not a setup that allows for collaboration with the user who submitted the issue or even have some pseudo identity for them to know who said what.

The antispam work was mainly don't for providing some very basic protection for users that signup and then contribute content.

Given the above and that that the suggested anti-spam work in this PR is content based, I was wondering if it would be better to implement this as a plugin that can hook into EVENT_BUGNOTE_DATA event, and do one of the following:

  1. block the submission with appropriate error message if it has undesired content (i.e. urls as per your current implementation).
  2. create the note with a temporary message and queue up the real message for approval by someone with appropriate access, once approach update the note with the real text or text updated by the moderator.

Anyways, implementing 1 above should be simple as a plugin.

(0062632)
RealityRipple   
2019-08-22 15:17   
(Last edited: 2019-08-22 16:54)

EVENT_BUGNOTE_DATA does not currently pass along $p_private - any chance that can be added as a parameter?

Edit: I put together a plugin that can, but doesn't have to, support $p_private: <https://github.com/RealityRipple/SafeAnon>
However I'd like to wait until the parameter is either decided to be included or not before adding it to the official Plugin list.

(0062635)
dregad   
2019-08-23 05:28   

I have no objections with adding the view status to the EVENT_BUGNOTE_DATA event, but I'm wondering if we should not send the whole BugnoteData structure to the event, instead of just the text, the bug_id and now the view_status... what would come next ?

This would be consistent with what we do in EVENT_BUG_DATA. Of course such change would break backwards compatibility for existing plugins relying on this event.

(0062636)
RealityRipple   
2019-08-23 05:33   

Attached files are probably the only other thing that would potentially be included in notes. This is sort of getting off-topic for this report, though, and should probably be started as an additional issue.

(0062638)
dregad   
2019-08-23 06:45   

Attached files are probably the only other thing that would potentially be included in notes

Not sure if you're aware that attachments are currently not directly linked to bugnotes, but to the parent bug instead. The relationship to the note is inferred based on timestamp. This should be fixed in the near future (see 0021733), so at this time this is probably not feasible. I have not looked in detailed at the proposed implementation

This is sort of getting off-topic for this report

Indeed. Follow-up in 0026071.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26151 [mantisbt] custom fields minor have not tried 2019-09-17 08:04 2020-02-05 02:56
Reporter: cproensa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Custom fields required but not displayed should be filled with the default value
Description:

As a follow up to 0026140:

In the scenario where a custom field:

  • is configured as required
  • is configured as not displayed
  • has a default value
  • the custom field still has no value for an issue.

When submitting the changes for the issue, the custom field should be created with the default value.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0062852)
dregad   
2019-09-17 08:30   

I agree that this should be the system's behavior.

(0062934)
keessonnema   
2019-10-01 07:54   

When is this feature planned to be implemented? Just for clarification.

(0062945)
cproensa   
2019-10-04 10:39   

@vboctor @atrol any objection to this?
I plan to work on this as soon as i have some time (and by dependency: 0026140)

(0062960)
atrol   
2019-10-07 16:44   

No objection from my side.

(0063583)
zeroion   
2020-02-04 15:35   

Any idea when this bug will be fixed? It's been a few months since this was reported, and this really affects usability, as we use the default text to provide guidance to our users.

(0063585)
keessonnema   
2020-02-05 02:56   

I would like to know aswell. It would still be a great change.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26673 [mantisbt] custom fields major random 2020-02-05 01:36 2020-02-05 01:36
Reporter: amphetamine Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.23.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add new item in custom fields (Enumeration type), then edit the issue the original selected item was changed
Description:

custom field type "Enumeration":
for example, there are hundred of list items, (a01, xx | a02, xx | ....| a100, xx | )
the original issue case select a0X, xx,
then add an new items in the list, says a49,xx,
afterward, edit original issue, the item of custom field was changed to a01, xx (not a0X, xx),

i also checked all the submitted issues with related to that custom filed, unfortunately, all have the same problem when click the edit button, the custom fields value is always revert to first item a01, xx

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22203 [mantisbt] feature feature N/A 2017-01-15 15:56 2020-02-04 15:05
Reporter: GunSmoker Platform:  
Assigned To: community OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 2.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Public / external access to tickets by unique URL
Description:

Mantis should have a feature of allowing people to view tickets by known URL without having to log in. Currently, Mantis has anonymous access option, which does allow viewing without logging in. However, it does not allow you to control this behaviour per ticket.

The usage case is simple:

  1. You application posts a new bug to Mantis.
  2. You report an unique URL to user.
  3. User can open this URL and track progress of the bug (see its status, may be dev. comments, etc.).
  4. User should not be able to view other tickets (bugs) in this project or any other project.

This can be implemented by adding some random secret value ("token") to each ticket. If this value is present in URL - allow limited read access, otherwise - use normal access rules (cookies, anonymous access, etc.).

For example:
https://bugs.domain.com/view.php?id=631
https://bugs.domain.com/view.php?id=631&amp;token=ya86EXROftHDXfAYG1eq

The first URL should block user unless he is logged in and has access to the project. The second URL should allow limited read access regardless of user being logged in or not.

A simplified front-end page may be added to implement this limited view. Also, a secret token (or full URL) must be passed back to caller when creating/updating bug via API.

Tags:
Steps To Reproduce:
Additional Information:

https://help.fogcreek.com/7564/public-access-to-cases - "Public Access to Cases"; a similar feature in FogBugz tracker.

Attached Files: Безымянный.png (170,563 bytes) 2017-01-15 16:15
https://mantisbt.org/bugs/file_download.php?file_id=7071&amp;type=bug
view.png (23,971 bytes) 2017-01-18 08:00
https://mantisbt.org/bugs/file_download.php?file_id=7084&amp;type=bug
view2.png (36,023 bytes) 2017-01-18 08:00
https://mantisbt.org/bugs/file_download.php?file_id=7085&amp;type=bug
Notes
(0055134)
GunSmoker   
2017-01-15 16:15   

An example of this feature in FogBugz.

On the left: case is accessed by unique URL. Only limited view is available.
On the right: case is accessed by logged in user. Full view is available.

(0055198)
GunSmoker   
2017-01-18 08:00   

This is how it is implemented on our server.

(0055235)
GunSmoker   
2017-01-19 07:34   

https://github.com/mantisbt/mantisbt/pull/1001

(0055350)
GunSmoker   
2017-01-26 15:45   

This can also be integrated with 0022263

(0063582)
GunSmoker   
2020-02-04 15:05   

https://github.com/exceptionless/exceptionless/wiki/Reference-Ids - a similar feature in Exceptionless bug tracker.

Posting new ticket allows you to specify pre-made "reference id" (a custom ID to report back to users, view bug report via web, use in search, etc.)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
22263 [mantisbt] api soap feature N/A 2017-01-26 13:35 2020-02-04 14:44
Reporter: GunSmoker Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mantis lacks features for automated crash reporting / "exception driven development"
Description:

Software developers usually build exception and error reporting facility for their applications. Application should be able to automatically send bug reports for each crash. There must be a central place where all bug reports are collected (e.g. like Mantis), which may be used as TO-DO list for developers to fix bugs.

The idea here is to merge reports about the same crash (from different users) into one bug on Mantis. The more crashes bug receives - the greater priority it will have. So you can fix, say, top 3 bugs in your list - and solve the majority of problems that your users are having.

The problem is that Mantis is not suited for this kind of work. The problems are (*):

  1. There is no way to identify crashes.
  2. There is no way to sort crashes on occurrences.
  3. There is no simple "send bug report" API.

The suggestions are:

  1. Add new property for the bug: "occurrences" / "count". This should be an integer property, which should be 1 on bug's creation and can not be modified by editing bug manually via UI. It should act as normal column in other aspects, be shown in bug's view, "view issues", allow sorting, etc.

  2. Add new property for the bug: "alias" / "bug-id" / "bug-hash". It should be a string, similar to summary, which can be used to identify bugs instead of integer id, with the following properties: a). it must be unique per project; b). attempt to create new bug with existing "alias" should return old bug and increase "occurrences" by 1; c). attempts to enter bugs with alias set must be concurrency-safe; d). exact format of "alias" should not be fixed and left to application. For example, it can be CRC-32 / SHA1 of exception type, address and call stack, or it can be something like "bug_project.exe_module.dll_0x00004567_EAccessViolation".

  3. Add a simplified API to submit bug and attachments in one simple request and get bug description back.

Tags:
Steps To Reproduce:

(*)

Obviosly, you can workaround Mantis problems by:

  1. Using SOAP API;
  2. Introduce custom field to identify crashes;
  3. Introduce custom field to count crashes.

However, there are major problems with this workaround:

  1. Most imprortantly - sorting by integer custom fields is still not working properly in Mantis. That means that you can not identify crashes with most occurrences with just Mantis only. You have to use your own custom SQL.

  2. Second, your submit workflow should be like this: a). find bug by custom field; b). if bug is not found - create new one; c). if bug is found - read it, then edit by adding +1 to occurrences. This obviosly introduces sync issues. If two instances of app from different users will try to submit the same crash simultaneously - you may end up with two bug reports for same crash, or lost occurrences.

  3. Next, your credentials for Mantis will be stored in your application, which means they can be extracted and used. This means that one can potentially do much more than just send a crash report (like read other reports and dev's comments). A new single "send report" API would eliminate this issue.

  4. In older versions of Mantis you could not even search by custom fields - which forced you to use summary as technical non-human readable "alias".

Additional Information:

https://blog.codinghorror.com/exception-driven-development/ - more about the described crash reporting idea

http://help.fogcreek.com/the-fogbugz-api/bugzscout - a similar feature in Fogbugz bug tracker. Cases (bugs) about crashes are called "BugzScout cases". "Alias" is called "sScoutDescription", "count" is called "Occurrences". Scout cases can be send via usual fully-featured Fogbugz API or via dedicated "send-report-only" BugzScout API.

http://help.fogcreek.com/7566/bugzscout-for-automatic-crash-reporting - description of BugzScount simplified API.

Bugzilla also have "alias" / "bug-id" / "bug-hash" field (which is called - "alias"). JIRA has "votes" (e.g. "occurrences") and ability to search by most voted issues.

Attached Files: s1.png (90,451 bytes) 2017-01-26 15:30
https://mantisbt.org/bugs/file_download.php?file_id=7116&amp;type=bug
s2.png (74,384 bytes) 2017-01-26 15:30
https://mantisbt.org/bugs/file_download.php?file_id=7117&amp;type=bug
s3.png (11,658 bytes) 2017-01-26 15:30
https://mantisbt.org/bugs/file_download.php?file_id=7118&amp;type=bug
Notes
(0055343)
rombert   
2017-01-26 14:06   

It seems to be that you've described ABRT :-)

https://github.com/abrt/abrt

Incidentally, ABRT has MantisBT integration so this should suit your needs.

(0055344)
GunSmoker   
2017-01-26 14:14   

Honestly, Fogbuz suits my needs :)

However, we historically use Mantis.

(0055346)
GunSmoker   
2017-01-26 15:04   

Even if you look at ABRT: https://github.com/abrt/libreport/wiki/MantisBT - you will see that docs says it has problems, because Mantis lacks the mentioned features (unlike Bugzilla), so they have to use workarounds.

(0055347)
GunSmoker   
2017-01-26 15:30   

Screenshots of working feature.

(0055348)
GunSmoker   
2017-01-26 15:41   

https://github.com/mantisbt/mantisbt/pull/1008

(0055349)
GunSmoker   
2017-01-26 15:45   

This can also be integrated with 0022203

(0063581)
GunSmoker   
2020-02-04 14:44   

https://exceptionless.com/exceptionless-api-usage-and-overview/ - a similar feature in Exceptionless bug tracker.

A scoped token allows access only for "post event" API.

Additionally, posting event allows you to specify pre-made "reference id" (a custom ID to view bug report via web), as well as "ManualStackingKey" - for automatic merging same bug reports into one ticket with automatic increase of "Count" (e.g. same as above-discussed "alias", "bug-id", "sScoutDescription"), so you can view unique bug reports only.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26672 [mantisbt] api soap crash always 2020-02-04 14:04 2020-02-04 14:16
Reporter: GunSmoker Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 2.22.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [SOAP API regression 2.22.x]: mc_issue_add fails with "Object of class SoapFault could not be converted to int"
Description:

It seems that latest versions of Mantis have a regression issue. Issue confirmed on 2.22.1 (see 0026492 ), 2.22.2 (www.mantishub.com / mantishub.io), 2.23.0 (local Apache). Unfortunately, I don't know what previous version of Mantis does not have this issue.

Code that worked on previous versions of Mantis now fails. Specifically, mc_issue_add fails with "Object of class SoapFault could not be converted to int".

Even if there is a bug in client code, and it sends invalid request - the server MUST respond with a clear failure reason (like "invalid credentials", "required field is not specified", "category not found", etc.), but not with internal crash.

The sample XML request for mc_issue_add is specified in "Additional info" below.

Tags:
Steps To Reproduce:

From Apache logs:

Stack Trace:
IssueAddCommand.php L252 __set(<string>'category_id', <Object><SoapFault> ( [faultstring] => 'Category \'""\' not found.', [faultcode] => 'Client', [faultcodens] => 'http://schemas.xmlsoap.org/soap/envelope/' ))
Command.php L136 validate()
mc_issue_api.php L938 execute()
UnknownFile L? mc_issue_add(<string>'root', <string>'123456', <Object><stdClass> ( [view_state] => <Object><stdClass> ( [id] => 10 ), [project] => <Object><stdClass> ( [id] => 1, [name] => 'Test' ), [category] => '', [priority] => <Object><stdClass> ( [id] => 30 ), [severity] => <Object><stdClass> ( [id] => 50 ), [status] => <Object><stdClass> ( [id] => 10 ), [summary] => 'EEurekaConnectionTestException (Bug 0000C12D; v1.0.0.0)', [version] => '1.0.0.0', [build] => '1.0.0.0', [platform] => 'Windows x86-64', [os] => 'Microsoft Windows 10 (64 bit)', [os_build] => '1909 (10.0.18363.592)', [reproducibility] => <Object><stdClass> ( [id] => 70 ), [projection] => <Object><stdClass> ( [id] => 10 ), [eta] => <Object><stdClass> ( [id] => 10 ), [resolution] => <Object><stdClass> ( [id] => 10 ), [description] => '(Error Message) This is a demo bug report from EurekaLog connection testing.', [steps_to_reproduce] => '(Steps to reproduce) I\'ve clicked on "Test" button on "Sending" tab', [custom_fields] => <array> { [0] => <Object><stdClass> ( [field] => <Object><stdClass> ( [id] => 2 ), [value] => '00000000' ), [1] => <Object><stdClass> ( [field] => <Object><stdClass> ( [id] => 1 ), [value] => '1' ) } ))
mantisconnect.php L89 handle()

Additional Information:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;>
<SOAP-ENV:Body xmlns:NS1="http://futureware.biz/mantisconnect&quot; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/&quot;>
<NS1:mc_issue_add>
<username xsi:type="xsd:string">alex@eurekalog.com</username>
<password xsi:type="xsd:string">my-Password-Here</password>
<issue xsi:type="tns:IssueData">
<view_state xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">10</id>
</view_state>
<project xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">1</id>
<name xsi:type="xsd:string">MyProject</name>
</project>
<category xsi:type="xsd:string" />
<priority xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">30</id>
</priority>
<severity xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">50</id>
</severity>
<status xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">10</id>
</status>
<summary xsi:type="xsd:string">EEurekaConnectionTestException (Bug 0000A56A; v1.0.0.0)</summary>
<version xsi:type="xsd:string" />
<build xsi:type="xsd:string">1.0.0.0</build>
<platform xsi:type="xsd:string">Windows x86-64</platform>
<os xsi:type="xsd:string">Microsoft Windows 10 (64 bit)</os>
<os_build xsi:type="xsd:string">1909 (10.0.18363.592)</os_build>
<reproducibility xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">70</id>
</reproducibility>
<projection xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">10</id>
</projection>
<eta xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">10</id>
</eta>
<resolution xsi:type="tns:ObjectRef">
<id xsi:type="xsd:long">10</id>
</resolution>
<description xsi:type="xsd:string">(Error Message) This is a demo bug report from EurekaLog connection testing.</description>
<steps_to_reproduce xsi:type="xsd:string">(Steps to reproduce) I've clicked on "Test" button on "Sending" tab</steps_to_reproduce>
</issue>
</NS1:mc_issue_add>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Attached Files:
Notes
(0063579)
GunSmoker   
2020-02-04 14:05   

Apache logs are for 2.23.0

(0063580)
GunSmoker   
2020-02-04 14:16   

Just to clarify - this is a server-side problem, it is not about client side.

Apache logs:
[:error] [pid 8132:tid 1292] [client 192.168.1.80:50475] [mantisconnect.php] Error Type: SYSTEM NOTICE,
Error Description: Object of class SoapFault could not be converted to int



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
26477 [mantisbt] ui major always 2019-12-17 17:15 2020-02-04 11:18
Reporter: polzin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.22.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Removing the caching of pages with validation gives returns the "empty form on back" bug 0003728
Description:

For v2.22, 0025969 the forced caching of certain pages (bug_change_status_page.php, bug_report_page.php, bug_update_page.php) was removed. This returns the "empty form on back" bug 0003728.

The best ui would be to have some javascript that does a check first when pressing the submit button.
If this is not possible, I would suggest to revert 0025969, as it breaks a common functionality for some rather uncommon feature.

In general, I have the feeling that "$g_allow_browser_cache" should not be an option in config_defaults_inc, because with this setting ON, a lot of weired things are happening. But for the mentioned pages it is valuable, as long as a pre-submit-javascript check is not possible.

Tags:
Steps To Reproduce:

What I have done:

  • Enter "Report issue" form (but did not fill in category)
  • Submit
  • System shows error message
  • I press browser "back"
    What I expect:
  • Form filled
    What I see:
  • Form empty
Additional Information:
Attached Files:
Notes
(0063293)
cproensa   
2019-12-17 18:05   

i think that the main problem of caching those pages is that it caused a greater bad than good.
I don't have the time right now but the summary of the issue was:

  • The caching headers was not being effectively applied since many years ago.
  • Once the caching headers were rewritten, and were effectively applied, bad thing happened, like: changing project, or going to report page after changing projects, would not refresh the correct report page (with coherent fields for the project, as the cached copy is presented)
  • that's why the caching of those form pages was disabled.

I'm not sure on what conditions, (previously to that point in time of those changes), the back navigation would have worked in presenting the previous form values. May be because of some combination of the headers, or some specific behaviour of browsers when presented with the incosistent headers?

FYI: currently, some browsers do effectively cache the form inputs. IIRC Chrome in my experience does this. Firefox in the other hand, don't. This is a internal behaviour of the browser, that is caching the form inputs, not the whole page.
Reverting to force the page cache is not viable, becasue of the prolems that were experimented.

The best ui would be to have some javascript that does a check first when pressing the submit button.
But for the mentioned pages it is valuable, as long as a pre-submit-javascript check is not possible.

What is the point in pre-submit processing regarding the back navigation and losing the input fields?

(0063299)
polzin   
2019-12-17 20:46   

@cproensa The reason for using "back" is that some form validation issued an error, e.g. mandatory field not set. This is something that happens frequently and should not make you loose all your input.

(0063575)
polzin   
2020-02-04 11:18   

Any suggestion how to proceed on that?



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
24572 [mantisbt] db mssql major always 2018-06-28 08:57 2020-02-04 06:54
Reporter: ghirschy Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.14.