View Issue Details

IDProjectCategoryView StatusLast Update
0024549mantisbtfilterspublic2018-11-30 11:49
ReportermahindraAssigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version2.15.0 
Target VersionFixed in Version 
Summary0024549: Permalink - Filter lose information after click on view issues
Description

1.create a permalink - for example

https://www.mantisbt.org/bugs/search.php?project_id=1&status=80&handler_id=11111&sticky=on&sort=last_updated&dir=DESC&hide_status=-2&match_type=0
2.The result is correct

=>Error: Click on View issues - the filter is gone

As a result, the permalink always has to be retrieved from another application (eg Mail).

Steps To Reproduce

Login before testing
If it does not work right now, please reset the filter before test the URL above

TagsNo tags attached.

Relationships

related to 0024775 assignedcproensa Improve presentation of temporary filters 

Activities

mahindra

mahindra

2018-06-18 13:42

reporter   ~0060099

related to 0024437 ?

atrol

atrol

2018-06-18 14:03

developer   ~0060100

related to 0024437 ?

no

@cproensa wad or bug?

cproensa

cproensa

2018-06-18 16:46

developer   ~0060104

The link is open as a temporary filter, in the same way than those from "my view".
I'm not sure if this behaviour has been changed from older versions, but it's quite reasonable in my opinion.

mahindra

mahindra

2018-06-18 17:06

reporter   ~0060105

Last edited: 2018-06-18 17:12

View 3 revisions

From the Permalink beginning until 2.11.1 - we have been waiting forward 2.15 (because the improvings with the realname-view from atrol) the filter setting would be hold from view target til logout/login and change project, too.

So you can manage more than one exercise in more Browser tabs like all Internet user

I hope, we are not allone with many IDs, and time/order-organization for a realize-team ?

skottke

skottke

2018-06-19 07:39

reporter   ~0060113

The filter has been a permanent filter so far. As I use a filter, I can manipulate a ticket and then I could return to the ticket list of the filter. Now the filter is only temporary and I after each ticket it is always necessary to click on filter link again. This makes filter in fact unusable. It is very important to reimplement the original function.

atrol

atrol

2018-06-19 08:19

developer   ~0060114

The link is open as a temporary filter, in the same way than those from "my view".

Confirmed, and also the same when using links from changelog and roadmap

I'm not sure if this behaviour has been changed from older versions

The behaviour of permalinks has been changed

but it's quite reasonable in my opinion.

I agree, that all those links should behave the same way.
I am not sure at the moment, if something should be changed.

As I use a filter, I can manipulate a ticket and then I could return to the ticket list of the filter.

You could

  • manipulate the ticket in a new tab, thus keeping the list, or
  • use the back button of your browser to return to the list instead of using the View Issues button
cproensa

cproensa

2018-06-19 08:44

developer   ~0060115

We can consider adding the tracking for the temporary filter in the menu for "view issues", redirect, etc. This has a path of improvement for cleaning up the temporary filter tracking, globally.

What we also lack at the moment is a clear control of what filter is "pinned" as permanent for the current project, and an easy way to set or change that, based for example in the current filter in use (which in this case is temporary)

I now better understand with the explanation from the later post:

As I use a filter, I can manipulate a ticket and then I could return to the ticket list of the filter.

as expecting to return to previous state of the issue listing.

Now the filter is only temporary and I after each ticket it is always necessary to click on filter link again. This makes filter in fact unusable.

this would be fixed, as described, if returning would keep track of the temp filter id.

The filter has been a permanent filter so far

What i don't like about persisting filters as default, is that it breaks the experience when using multiple tabs, for the same project

mahindra

mahindra

2018-06-19 10:48

reporter   ~0060118

At login I prefer to reset the filter settings - 90% I always reset this first after logging in

I have nothing against the same filters in several tabs for the same project, as it used to be before

skottke

skottke

2018-06-21 00:17

reporter   ~0060125

@cproensa: It's true that if I used different filters in several tabs in previous version, only the current filter was applied by all filters. But we knew this restriction and it was ok for us.

But now filters are not useful any more. I use 10 filters, one for each developer. I check the developer tickets and adapt priorities and enter some changes. After the first ticket and click on ticket list the filter is cancelled.

So I am forced to enter all specific attributes manually in order to work as before, This is a fundamental drawback in usability.

atrol

atrol

2018-06-21 02:07

developer   ~0060126

@skottke, maybe you did not read 0024549:0060114 where I described two ways how you could work with the current implementation

I use 10 filters, one for each developer

I would use stored filters for this scenario.
It's better to have the list with filters in Mantis itself instead of maintaining a list of links outside the system.

skottke

skottke

2018-06-21 06:33

reporter   ~0060127

@atrol: Thanks for this hint. It's much more comfortable to use links outside Mantis. All essential filter are stored in favorite bar in IE browser. What's more, I am used to start all applications by Win-R and an individual ShortCut, and every start of process / application / website can be managed by keyboard. I need 2 seconds to get the right filter, and it does not matter in which application I am currently working.

So internal filter are not an alternative to the flexibility of external filters, because there is no possibility to run them without using mouse.

What we want is not more than to reestablish the functionality which we have been using for 12 years now.

mahindra

mahindra

2018-06-22 00:21

reporter   ~0060129

Is it possible to make this switchable in the config.php to support keyboard input (without using mouse) better?

skottke

skottke

2018-07-25 08:35

reporter   ~0060320

@cproensa: You wrote in #60115: "What i don't like about persisting filters as default, is that it breaks the experience when using multiple tabs, for the same Project". I understand that when you use filters only as different lists of tickets for an overview. If you try to work with ticket lists in each filter (change of tickets), the filter is lost (unless you click once again on the link for the external filter).

Because all my ca. 25 external filters are now unusable for me (after 12 years working with Mantis), I was forced to change to internal filters. Drawback: I cannot manage them by keyboard and it's slower to select them from combobox as on my favourite bar in the browser.

It is possible to implement a filter parameter in configuration in next mantis version in order to configure if external filters work temporarily (as now and as default) or persistent as before? That would be a fine solution of this problem. Please let me know. Thanks.

mahindra

mahindra

2018-08-08 22:41

reporter   ~0060385

It is better to save the attribute for external links in the profile for managers, because testers after clicking on external links often forget to reset the filters and do not see their tickets.
Especially if they have the filters collapsed.

mahindra

mahindra

2018-08-08 23:26

reporter   ~0060386

Alternatively, it makes sense to return to the old logic and reset the filters on the project switch so that "new" users see their tickets and are not trapped in the permalink.
What do you all mean?

skottke

skottke

2018-08-09 00:21

reporter   ~0060387

0024549:0060386: Yes, it makes sense to reset the filter after switching / changing the project. Each project has its own properties and sometimes it's bewildering to keep the filter on project switch. I'd by pleased, if we could return to the old logic in this case.
0024549:0060385: Our testers know the function to reset filters, they know how to work with external and internal filters. So there was not any problem. I still think it's quite confusing if I get an external link by e-mail, click on it, get a ticket list, click on one ticket of this list, and then this list is lost (because the old filter is active again), and I cannot check other tickets of the list unless I click on the external filter of the e-mail again.

skottke

skottke

2018-08-29 15:01

reporter   ~0060532

@cproensa
@atrol

The discussed problem is still a severe issue for daily use of mantis. So I would like you to tell me, how much does it cost to order the change as described in 0024549:0060387. It's acceptable for me to pay for it.

Thanks.

cproensa

cproensa

2018-08-29 17:47

developer   ~0060533

Last edited: 2018-08-29 17:49

View 3 revisions

The discussed problem is still a severe issue for daily use of mantis. So I would like you to tell me, how much does it cost to order the change as described in 0024549:0060387. It's acceptable for me to pay for it.

I think it's just a matter of reverting this commit.
https://github.com/mantisbt/mantisbt/commit/5a258e9fe00d0699e7b195fe7824fc45c055b13a

You can do it on your own to fix your instance.

However i'm not sure if that's the right solution (for the main project):

  • In my opinion, permalinks are in the same functional category as temporary filters. The fact that historically they have not behaved in the same way is not an excuse.
  • The same issue happens with temporary filters. When going to "view list" from "view issue" the filter is lost. If a solution should be implemented, it must be here, and then it would fix both temporary and permalinks.
  • Other user workflows may get degraded if external links messes with the current views of the user, even when the link is open in other tab/browser/machine

In your workflow, as a user, i would opt to open issues in separate tabs.
Reverting the permalink behaviour wont fix the fact that opening two different permalinks for the same project will replace each other.

I'm not against reverting, if the team agrees on it, but i dont encourage it either.

skottke

skottke

2018-08-30 00:25

reporter   ~0060534

@cproensa:

Thanks for commenting.

Well, you have another point of view concerning external filters and obviously another use. If you just want to have a look to a list of certain tickets and you do not want to do anything with them, it makes sense to open several tabs and it's an advantage that filters can by used without an impact on active current filter.

But for us it's not, i. e. my team uses extern filters to deploy certain tickets. Finishing a ticket they have to change a status of the ticket. Then they cannot continue, but they have to call the filter again after each ticket.

I use about 20 external filters (by keyboard short cuts). The internal filters are usable only inside mantis und only by mouse. So the external filters were a very useful enhancement with the same functionality as internal filters up to last upgrade.

In your opinion are "permalinks in the same functional category as temporary filters". But for 12 years they were not. So it is contentious. It's a question of use. I am convinced that external filters that only have the function of internal filters lose a lot of their functionality.

You write: "In your workflow, as a user, i would opt to open issues in separate tabs." I spoke to many colleagues about it. No one uses mantis in this way. We rarely need several filters at the same time. The only use is to control the status of progress without the need to do anything with the tickets. But this is an exceptional case.

What's wrong with the idea to keep the current functionality as a default and to establish an alternative behavior as discussed here by configuration setting?

As I wrote, I can pay your development costs for that change.

mahindra

mahindra

2018-08-30 13:39

reporter   ~0060563

Dear @cproensa ,

thanks for the hint in https://www.mantisbt.org/bugs/view.php?id=24549#c60533 that we can push the realization to the admin by upgrading mantis every time.
I consider that it is a security risk, with each upgrade to patch codes and what shall we do, if there is a major change?!

In German - Why should the admin "rumfrickeln im code?"

We have a sponsor
skottke wrote in 0024549:0060532 " It's acceptable for me to pay for it."

After discussion above, it will be the most targeted solution to save that in the profile.
So every user can decide for themselves.

I think we should ask the head of mantisbt, should we?

cproensa

cproensa

2018-08-31 09:03

developer   ~0060570

@atrol, and others,
What do you think of this approach:

Create some indication that the current displayed filter is temporary, some text or icon around the filter dialog box.
Add an action (icon, filter menu option, etc) that makes a current (temporary) filter as the persistent default filter for the project.

This should solve the request to easily persist the temp filters, whether they come from permalinks or my_view.

dregad

dregad

2018-09-01 20:21

developer   ~0060586

Sounds good to me

mahindra

mahindra

2018-09-03 08:39

reporter   ~0060591

Good solution for me, because new users will not overlook the resetting of their filters after looking around.

skottke

skottke

2018-09-05 04:32

reporter   ~0060601

0024549:0060570: proposal is ok for me. By this way the user is free to choose which kind of filter he needs in a special situation

mahindra

mahindra

2018-09-11 12:46

reporter   ~0060637

Is it possible to accelerate the implementation?

cproensa

cproensa

2018-09-13 19:51

developer   ~0060658

@mahindra
I have opened 0024775 as a more generic issue for filter presentation. There it is a preliminary implementation.
Feedback is welcomed. However, i alone can't make a strong decision over more drastic UI changes

mahindra

mahindra

2018-09-14 07:37

reporter   ~0060661

@cproensa many many thanks!
=> if an advanced option is set - is it possible to colorize the menu icon?
I will ask that in 0024775 too
Because if the filter options are collapsed, you are not able to see, that there is an option locked...



filter locked.png (14,858 bytes)
filter locked.png (14,858 bytes)
skottke

skottke

2018-10-04 06:38

reporter   ~0060735

@cproensa: The ticket for implementation 0024775 is scheduled to version 2.18. What are your plans to publish this version? Thanks.

dregad

dregad

2018-10-04 08:45

developer   ~0060736

@skottke, as you can see in PR https://github.com/mantisbt/mantisbt/pull/1390, there are some comments pending feedback from cproensa. When this has been addressed, we can consider merging.

mahindra

mahindra

2018-10-24 18:33

reporter   ~0060845

Last edited: 2018-10-24 18:34

View 2 revisions

@skottke how is your opinion about https://github.com/mantisbt/mantisbt/pull/1390#issuecomment-431171139 ?

skottke

skottke

2018-10-25 02:51

reporter   ~0060846

@mahindra: Thanks for implementing an appropriate solution of this issue. I read the discussion on github. I am not sure what is meant by "clock icon" / "filter with clock"; I could not find such an icon. But generally: The implemented solution with a new choice "set as persistent filter" is okay, but it's hidden in the filter menu, and I agree that it's difficult to find and to unterstand.

I prefer your proposal "placing a pushpin [...] button in the widget bar". This pushpin button could be placed on the left side next to the filter button und it should be enabled, if the current filter is temporary, and disabled, if the current filter is persistent.

By this way the user knows the current filter state without any click. If the user wants to persist the filter, he/she has to click the new button. Then it's disabled.

That is my contribution to this discussion... I am looking forward to a solution. M. Skottke

skottke

skottke

2018-10-25 02:54

reporter   ~0060847

@cproensa: I mixed up your name and mahindra, upper information is turned to you.

cproensa

cproensa

2018-10-25 18:08

developer   ~0060856

Last edited: 2018-10-25 18:09

View 2 revisions

I prefer your proposal "placing a pushpin [...] button in the widget bar". This pushpin button could be placed on the left side next to the filter button und it should be enabled, if the current filter is temporary, and disabled, if the current filter is persistent.

I have two objections for that. First, i don't want to alter the widget styles by placing additional icons, at least not as a need for this functionality request.
And second, our current behaviour is that filters are persistent by default, and the temporary filter is a special case of a filter. That's why i don't like placing any control that is not useful in the standard state of a filter (persistent), and i prefer showing something only when the filter is temporary (in support of this, think about the inverse action: turn a filter into temporary state, is not currently an existing feature)

For context: in older versions, using the "apply filter" button would update a temporary filter AND make it persistent. This was changed in one of the recent filter internals redesign, so now it updates the filter BUT keeps it temporariness (thus, losing that side effect, which is the feature we are now trying to reintroduce, in a clearer way i hope)

So, regarding this issue, i still feel there should be a more visible option for the action of "fixing" the temp filter.
A suitable place would be at the bottom of the filter form, next to the save button. Here i feel we could make more changes, as opposed to the widget frames, without impacting the general style.
Here is a proposal where:

  • buttons are only icons, reducing the clutter caused by long text labels (good for adaptative layouts)
  • the pushpin button fixes a temporary filter
  • the cross button resets the filter (instead of having it as a faux stored filter in the dropdown)

Those buttons can also be integrated in the collapsed widget



filter_buttons.png (35,560 bytes)
filter_buttons.png (35,560 bytes)
mahindra

mahindra

2018-10-28 12:55

reporter   ~0060866

I like this design - stunningly great

https://mantisbt.org/bugs/file_download.php?file_id=8203&type=bug

skottke

skottke

2018-10-29 08:18

reporter   ~0060869

Thanks, this is an excellent proposal, it is quite easy to unterstand and the location is adequate.

skottke

skottke

2018-10-29 08:42

reporter   ~0060870

One more question: "the cross button resets the filter" => after reset of the filter is the previous filter active again or no filter any more?

mahindra

mahindra

2018-10-29 09:30

reporter   ~0060871

Last edited: 2018-10-29 09:30

View 2 revisions

@cproensa Thanks again - how is that with the topic, which @skottke had addressed in 0024549:0060870 ?

cproensa

cproensa

2018-10-29 11:38

developer   ~0060872

One more question: "the cross button resets the filter" => after reset of the filter is the previous filter active again or no filter any more?

Good catch
Without further modification, it resets the filter in the same way the current "reset filter" that is shown in the dropdows for stored filters (or the button for users without that access)
This means, sets a blank filter.

If this proposal is finally implemented, we could consider that this option removes only the temporary filter, so the previous filter "in use" is restored, instead of a full reset to empty filter.

skottke

skottke

2018-10-30 01:09

reporter   ~0060874

@cproensa: We might consider both alternatives, but more easier to understand for common user is a complete reset of the filter.

dregad

dregad

2018-10-31 12:26

developer   ~0060883

It looks good to me, but having both the pushpin and the floppy disk is somewhat confusing.

If this proposal is finally implemented, we could consider that this option removes only the temporary filter, so the previous filter "in use" is restored, instead of a full reset to empty filter.

For me, it would be preferable to just clear the temp filter and revert to the previously active filter - completely resetting the filter would be unexpected behavior (skipping a step).
To make things more obvious, we could also add a dummy "Temp filter" option in the selection list, wdyt ?

cproensa

cproensa

2018-10-31 13:48

developer   ~0060884

having both the pushpin and the floppy disk is somewhat confusing.

The floppy icon is the "save filter" action. You can save the currently applied filter into a named filter, whether it's temporary or not.

we could also add a dummy "Temp filter" option in the selection list,

like, replace the current "blank" line with the "temp" string as an indication. may be.

also note that if we then always show a dedicated button for resetting filter, the dummy item in the dropdown would become redundant

dregad

dregad

2018-11-01 10:06

developer   ~0060893

Last edited: 2018-11-01 10:32

View 2 revisions

having both the pushpin and the floppy disk is somewhat confusing.

The floppy icon is the "save filter" action. You can save the currently applied filter into a named filter, whether it's temporary or not.

Yes I realized that, but my initial reaction was to wonder why there are 2 buttons hence my remark about it being confusing.

we could also add a dummy "Temp filter" option in the selection list,

like, replace the current "blank" line with the "temp" string as an indication. may be.

Yes, that was my idea.

the dummy item in the dropdown would become redundant

Absolutely. It makes sense to get rid of it.

skottke

skottke

2018-11-07 11:30

reporter   ~0060932

For me, the pushpin button is important in order to fix a temporary filter. An additional reset button is nice to have, but not essential.

mahindra

mahindra

2018-11-13 12:21

reporter   ~0060955

@cproensa I think that the reset filter entry is often not found because it is hidden in the combo. The reset button makes sense
@dregad what's your opinion ?

mahindra

mahindra

2018-11-27 07:03

reporter   ~0061013

@dregad please have a look at https://github.com/mantisbt/mantisbt/pull/1390
Thank you

dregad

dregad

2018-11-27 09:03

developer   ~0061015

@mahindra and your point is ? There is nothing new in the PR or in this issue since I posted my last note 0024549:0060893.

mahindra

mahindra

2018-11-27 10:08

reporter   ~0061016

Last edited: 2018-11-27 10:08

View 3 revisions

@dregad I agree with skottke in 0024549:0060932 after your last note 0024549:0060893
Thank you

dregad

dregad

2018-11-27 11:01

developer   ~0061017

And ? I still don't understand what you expect from me.

mahindra

mahindra

2018-11-27 11:09

reporter   ~0061018

Last edited: 2018-11-27 11:10

View 2 revisions

@dregad in https://github.com/mantisbt/mantisbt/pull/1390 cproensa is asking you

"cproensa commented 29 days ago
there has been some discussion on https://mantisbt.org/bugs/view.php?id=24549
about presentation.
Can you have a look to see if it's viable?"

I think it is ready for realization @cproensa ?

cproensa

cproensa

2018-11-29 10:36

developer   ~0061026

PR 1390 is good to go as is.

The secondary task of rearranging the visual options (as proposed in 0024549:0060856) can be included there, or treated as a later change.
By any mean, in order to do real work on the UI side i'd like to get the approval, comments, suggestions, etc from more members of the development team, especially from @vboctor, @syncguru...

dregad

dregad

2018-11-30 10:04

developer   ~0061029

The secondary task of rearranging the visual options (as proposed in 0024549:0060856) can be included there, or treated as a later change

@cproensa, if you don't mind, I would prefer the revised UI (as discussed in here earlier) to be included in PR 1390. I suggest you add commits, post a note in the PR to request feedback and if nothing comes within a week then I'll merge it.

cproensa

cproensa

2018-11-30 11:31

developer   ~0061030

if you don't mind, I would prefer the revised UI (as discussed in here earlier) to be included in PR 1390

ok, i'll work on it

mahindra

mahindra

2018-11-30 11:49

reporter   ~0061031

Thank you for supporting this Ticket

Issue History

Date Modified Username Field Change
2018-06-18 13:40 mahindra New Issue
2018-06-18 13:42 mahindra Note Added: 0060099
2018-06-18 14:03 atrol Note Added: 0060100
2018-06-18 16:46 cproensa Note Added: 0060104
2018-06-18 17:06 mahindra Note Added: 0060105
2018-06-18 17:11 mahindra Note Edited: 0060105 View Revisions
2018-06-18 17:12 mahindra Note Edited: 0060105 View Revisions
2018-06-19 07:39 skottke Note Added: 0060113
2018-06-19 08:19 atrol Note Added: 0060114
2018-06-19 08:44 cproensa Note Added: 0060115
2018-06-19 10:48 mahindra Note Added: 0060118
2018-06-21 00:17 skottke Note Added: 0060125
2018-06-21 02:07 atrol Note Added: 0060126
2018-06-21 06:33 skottke Note Added: 0060127
2018-06-22 00:21 mahindra Note Added: 0060129
2018-07-25 08:35 skottke Note Added: 0060320
2018-08-08 22:41 mahindra Note Added: 0060385
2018-08-08 23:26 mahindra Note Added: 0060386
2018-08-09 00:21 skottke Note Added: 0060387
2018-08-29 15:01 skottke Note Added: 0060532
2018-08-29 17:47 cproensa Note Added: 0060533
2018-08-29 17:48 cproensa Note Edited: 0060533 View Revisions
2018-08-29 17:49 cproensa Note Edited: 0060533 View Revisions
2018-08-30 00:25 skottke Note Added: 0060534
2018-08-30 13:39 mahindra Note Added: 0060563
2018-08-31 09:03 cproensa Note Added: 0060570
2018-09-01 20:21 dregad Note Added: 0060586
2018-09-03 08:39 mahindra Note Added: 0060591
2018-09-05 04:32 skottke Note Added: 0060601
2018-09-11 12:46 mahindra Note Added: 0060637
2018-09-13 18:51 cproensa Relationship added related to 0024775
2018-09-13 19:51 cproensa Note Added: 0060658
2018-09-14 07:37 mahindra File Added: filter locked.png
2018-09-14 07:37 mahindra Note Added: 0060661
2018-10-04 06:38 skottke Note Added: 0060735
2018-10-04 08:45 dregad Note Added: 0060736
2018-10-24 18:33 mahindra Note Added: 0060845
2018-10-24 18:34 mahindra Note Edited: 0060845 View Revisions
2018-10-25 02:51 skottke Note Added: 0060846
2018-10-25 02:54 skottke Note Added: 0060847
2018-10-25 18:08 cproensa File Added: filter_buttons.png
2018-10-25 18:08 cproensa Note Added: 0060856
2018-10-25 18:09 cproensa Note Edited: 0060856 View Revisions
2018-10-28 12:55 mahindra Note Added: 0060866
2018-10-29 08:18 skottke Note Added: 0060869
2018-10-29 08:42 skottke Note Added: 0060870
2018-10-29 09:30 mahindra Note Added: 0060871
2018-10-29 09:30 mahindra Note Edited: 0060871 View Revisions
2018-10-29 11:38 cproensa Note Added: 0060872
2018-10-30 01:09 skottke Note Added: 0060874
2018-10-31 12:26 dregad Note Added: 0060883
2018-10-31 13:48 cproensa Note Added: 0060884
2018-11-01 10:06 dregad Note Added: 0060893
2018-11-01 10:32 dregad Note Edited: 0060893 View Revisions
2018-11-07 11:30 skottke Note Added: 0060932
2018-11-13 12:21 mahindra Note Added: 0060955
2018-11-27 07:03 mahindra Note Added: 0061013
2018-11-27 09:03 dregad Note Added: 0061015
2018-11-27 10:08 mahindra Note Added: 0061016
2018-11-27 10:08 mahindra Note Edited: 0061016 View Revisions
2018-11-27 10:08 mahindra Note Edited: 0061016 View Revisions
2018-11-27 11:01 dregad Note Added: 0061017
2018-11-27 11:09 mahindra Note Added: 0061018
2018-11-27 11:10 mahindra Note Edited: 0061018 View Revisions
2018-11-29 10:36 cproensa Note Added: 0061026
2018-11-30 10:04 dregad Note Added: 0061029
2018-11-30 11:31 cproensa Note Added: 0061030
2018-11-30 11:49 mahindra Note Added: 0061031