View Issue Details

IDProjectCategoryView StatusLast Update
0025680mantisbtbugtrackerpublic2019-04-25 18:42
Reporter123 Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionwon't fix 
Product Version 
Target VersionFixed in Version 
Summary0025680: Redirect after bug report process ending
Description

There is a g_default_home_page configuration parameter.
Why not redirect the user to g_default_home_page after creating the issue?

TagsNo tags attached.

Relationships

related to 0025695 closedcommunity Redirect to the new issue's page after reporting it 

Activities

123

123

2019-04-04 23:04

reporter   ~0061832

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

dregad

dregad

2019-04-05 06:07

developer   ~0061835

That makes sense and would be consistent with the concept of "default page".

cproensa

cproensa

2019-04-05 20:26

developer   ~0061839

That makes sense and would be consistent with the concept of "default page"

I'm not sure... currently, "default page" is the landing page after login.
Ideally, the return page after bug creation, should be the one in use before initiating the report action. But we don't have that information, as is.
The usual behaviour in most of the pages is to return to a page that lists the created/modified element. For example:

  • After creating a user, displays the user
  • After creating a project, displays the manage projects list.

...not consistent, but still it's a related page in that context.

I see that a common setting for "default page" can be "my view" page. I wouldn't like to go to "my view" after each issue creation. I'd expect it to go to view issues list, or the individual new issue.

123

123

2019-04-05 21:27

reporter   ~0061840

There is another option.
Redirect the user to the page where the bug_report process was initiated.
And if the initiation page is not my_view_page or view_all_bug_page, then redirect to default_home_page.

What do you think?

123

123

2019-04-09 05:36

reporter   ~0061869

I updated my PR.

Now you can take into account the wishes of @cproensa and redirect to the page from which the process started reporting the error.

To register the page of the parent, I used cookies.
Also, to control possible parent pages, I entered an additional parameter in the global configuration
$ g_bug_report_redirect_pages_allowed = array ('my_view_page.php', 'view_all_bug_page.php');
This will allow administrators to flexibly control this process. For example, it could be used to create plug-ins or custom pages with a list of issues.

Unfortunately, there is a small feature. We cannot control the cancellation of the creation issue, and therefore the cookie will not be cleared. That will lead to a one-time violation of logic in the redirection process. It seems to me that this will happen quite rarely.

What do you think?

dregad

dregad

2019-04-13 12:12

developer   ~0061923

I'm not really fond of this implementation with cookies. Do we really need to go back to wherever the new bug was submitted ?

The more I think about it, and considering my usage of the system, over 95% of the times after submitting a new issue, I want to see it afterwards. Sometimes I want to create another issue right after that (which is achieved by the Report Stay check box on the bug report page, and if I forget I just click on the Report Issue button on the sidebar again). Occasionally I want to see the issues list; this is currently the default behavior on bug_report.php after timeout, maybe we should change that ?

Anyway, I'm tempted to close this as "won't fix". Thoughts ?

123

123

2019-04-13 21:38

reporter   ~0061927

Well, there is another option.

What if we configure the global parameter 'default_home_page' for each user?
Any user will be able to change the page to the one that you like more in the settings of your even record.
Under this option, the question remains with a list of possible pages.
Either we have to offer them ourselves, or give freedom of choice and offer a field for input.

dregad

dregad

2019-04-14 12:46

developer   ~0061931

@123 I was more questioning the use case for allowing user to pick the target page after submitting a but, more than the proposed implementation itself.

My point is that this adds complexity for no or very little benefit, and we should stick to current behavior or even simplify it (i.e. always return to the newly created issue's page). Most key MantisBT pages are just one click away from that anyway.

Maybe you care to explain your reasons for needing this feature.

123

123

2019-04-14 23:18

reporter   ~0061932

Last edited: 2019-04-14 23:24

View 2 revisions

@dregad As I wrote below, I will be satisfied with the redirect to default_home_page.
I agree with you that adding unnecessary complexity is a bad idea. But since @cproensa stated that it is necessary to redirect to the page from which the issue creation procedure was initialized, I developed additional solutions to the problem.
I will also be satisfied with the option to redirect to the page with the newly created issue.

With my suggestion for improving this part of the code, I wanted to achieve the logical behavior of the mantisbt.
In my scenario, most of the users do not have deep knowledge in computer science, and it is sometimes difficult for them to navigate in an interface that behaves not logical.

Also in my use case mantisbt I would really like to be able to remove the link to view_all_bug_page from the side menu, since for most users it is not needed. This page is used only if it is necessary to sort the issues by a specific filter and only engineers use it, and in rare cases.

dregad

dregad

2019-04-15 02:39

developer   ~0061933

@cproensa stated that it is necessary to redirect to the page from which the issue creation procedure was initialized

While I don't necessarily disagree with this, I personally don't think it is useful as per my earlier comment.
It's also worth mentioning that on the next line he wrote:

The usual behaviour in most of the pages is to return to a page that lists the created/modified element

Which contradicts his previous statement.

Considering that you

will also be satisfied with the option to redirect to the page with the newly created issue.

then I think we are in agreement ?

remove the link to view_all_bug_page from the side menu

While I would agree that its usage could be considered complex and not so useful for some literate people, this page is quite central to MantisBT operations, and I would recommend against removing it, as this is the only way to access issues globally and to search / filter them.

123

123

2019-04-15 05:45

reporter   ~0061935

Last edited: 2019-04-15 06:01

View 2 revisions

While I would agree that its usage could be considered complex and not so useful for some literate people, this page is quite central to MantisBT operations, and I would recommend against removing it, as this is the only way to access issues globally and to search / filter them.

I'm sorry, I incorrectly formulated my answer.
I mean that this page should take into account the level of user access.
In any case, I think we will discuss this in another issue.

123

123

2019-04-15 05:50

reporter   ~0061936

then I think we are in agreement ?

Yes.

Last question. Do we change the behavior of buttons on bug_report.php or leave everything as it is?

dregad

dregad

2019-04-15 06:52

developer   ~0061937

@123 thanks for your feedback.

Do we change the behavior of buttons on bug_report.php or leave everything as it is?

I propose the following :

  1. Close this issue as won't fix
  2. leave buttons on bug_report.php as they are today

Optionally, change defaut redirect from view_all_bug_page.php to the newly opened bug's page, which IMO is more useful (a separate issue should be created for that).

Note that the "report stay" option will add a 3rd button to this page to report more issues, and change default redirect to bug_report_page.php

Alternatively, I would be also fine with not presenting any buttons to the user, and just automatically redirect to view.php or bug_report_page.php depending on status of "Report Stay" checkbox.

123

123

2019-04-16 01:09

reporter   ~0061940

Ok.
Please close this issue and I will open a new issue and prepare a new PR.

Issue History

Date Modified Username Field Change
2019-04-04 23:01 123 New Issue
2019-04-04 23:04 123 Note Added: 0061832
2019-04-05 06:07 dregad Note Added: 0061835
2019-04-05 20:26 cproensa Note Added: 0061839
2019-04-05 21:27 123 Note Added: 0061840
2019-04-09 05:36 123 Note Added: 0061869
2019-04-13 12:04 dregad Assigned To => community
2019-04-13 12:04 dregad Status new => assigned
2019-04-13 12:12 dregad Note Added: 0061923
2019-04-13 21:38 123 Note Added: 0061927
2019-04-14 12:46 dregad Note Added: 0061931
2019-04-14 23:18 123 Note Added: 0061932
2019-04-14 23:24 123 Note Edited: 0061932 View Revisions
2019-04-15 02:39 dregad Note Added: 0061933
2019-04-15 05:45 123 Note Added: 0061935
2019-04-15 05:50 123 Note Added: 0061936
2019-04-15 06:01 123 Note Edited: 0061935 View Revisions
2019-04-15 06:52 dregad Note Added: 0061937
2019-04-16 01:09 123 Note Added: 0061940
2019-04-16 01:31 123 Issue cloned: 0025695
2019-04-16 01:31 123 Relationship added related to 0025695
2019-04-16 05:25 dregad Assigned To community => dregad
2019-04-16 05:25 dregad Status assigned => resolved
2019-04-16 05:25 dregad Resolution open => won't fix
2019-04-25 18:42 atrol Status resolved => closed