View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0024549 | mantisbt | filters | public | 2018-06-18 13:40 | 2019-03-16 20:20 |
Reporter | mahindra | Assigned To | cproensa | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 2.15.0 | ||||
Target Version | 2.20.0 | Fixed in Version | 2.20.0 | ||
Summary | 0024549: 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 =>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 | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to 0024437 ? |
|
no @cproensa wad or bug? |
|
The link is open as a temporary filter, in the same way than those from "my view". |
|
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 ? |
|
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. |
|
Confirmed, and also the same when using links from changelog and roadmap
The behaviour of permalinks has been changed
I agree, that all those links should behave the same way.
You could
|
|
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 expecting to return to previous state of the issue listing.
this would be fixed, as described, if returning would keep track of the temp filter id.
What i don't like about persisting filters as default, is that it breaks the experience when using multiple tabs, for the same project |
|
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 |
|
@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. |
|
@skottke, maybe you did not read 0024549:0060114 where I described two ways how you could work with the current implementation
I would use stored filters for this scenario. |
|
@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. |
|
Is it possible to make this switchable in the config.php to support keyboard input (without using mouse) better? |
|
@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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
I think it's just a matter of reverting this commit. 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 your workflow, as a user, i would opt to open issues in separate tabs. I'm not against reverting, if the team agrees on it, but i dont encourage it either. |
|
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. |
|
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. In German - Why should the admin "rumfrickeln im code?" We have a sponsor After discussion above, it will be the most targeted solution to save that in the profile. I think we should ask the head of mantisbt, should we? |
|
@atrol, and others, Create some indication that the current displayed filter is temporary, some text or icon around the filter dialog box. This should solve the request to easily persist the temp filters, whether they come from permalinks or my_view. |
|
Sounds good to me |
|
Good solution for me, because new users will not overlook the resetting of their filters after looking around. |
|
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 |
|
Is it possible to accelerate the implementation? |
|
@mahindra |
|
@cproensa many many thanks! |
|
@cproensa: The ticket for implementation 0024775 is scheduled to version 2.18. What are your plans to publish this version? Thanks. |
|
@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. |
|
@skottke how is your opinion about https://github.com/mantisbt/mantisbt/pull/1390#issuecomment-431171139 ? |
|
@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 |
|
@cproensa: I mixed up your name and mahindra, upper information is turned to you. |
|
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. 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.
Those buttons can also be integrated in the collapsed widget |
|
I like this design - stunningly great https://mantisbt.org/bugs/file_download.php?file_id=8203&type=bug |
|
Thanks, this is an excellent proposal, it is quite easy to unterstand and the location is adequate. |
|
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? |
|
@cproensa Thanks again - how is that with the topic, which @skottke had addressed in 0024549:0060870 ? |
|
Good catch 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. |
|
@cproensa: We might consider both alternatives, but more easier to understand for common user is a complete reset of the filter. |
|
It looks good to me, but having both the pushpin and the floppy disk is somewhat confusing.
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). |
|
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.
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 |
|
Yes I realized that, but my initial reaction was to wonder why there are 2 buttons hence my remark about it being confusing.
Yes, that was my idea.
Absolutely. It makes sense to get rid of it. |
|
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. |
|
@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 please have a look at https://github.com/mantisbt/mantisbt/pull/1390 |
|
@mahindra and your point is ? There is nothing new in the PR or in this issue since I posted my last note 0024549:0060893. |
|
@dregad I agree with skottke in 0024549:0060932 after your last note 0024549:0060893 |
|
And ? I still don't understand what you expect from me. |
|
@dregad in https://github.com/mantisbt/mantisbt/pull/1390 cproensa is asking you "cproensa commented 29 days ago I think it is ready for realization @cproensa ? |
|
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. |
|
@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. |
|
ok, i'll work on it |
|
Thank you for supporting this Ticket |
|
@mahindra @skottke it would be fine if you could invest some time in testing latest state of PR 1390 |
|
@atrol @cproensa @dregad @vboctor Einen guten Rutsch ins neue Jahr 2019! |
|
@mahindra https://github.com/cproensa/mantisbt/archive/0024775_improve_presentation_temporary_filter.zip |
|
Many Thanks! Following seen
We will keep watching this in the next few days. Happy new year! |
|
I think, from UI standards, the usual is that bottom area has the form submit. |
|
Result of testing: Solution is fine, and it might be obvious for everyone what is meant by the new buttons. Button "Persist" disappears after usage of reset filter, that's correct. As #mahindra mentioned, names of buttons have to be adapted in dependency of general language. Thanks for excellent collaboration! |
|
@mahindra @skottke These steps have to take place before you will see translated messages in an official build
|
|
@atrol Thank you very much for your feedback At the moment we are short of time for translations. Together with the positive feedback from @skottke - these IDs can be closed for the function to come in the next release. |
|
@atrol until then german translation |
|
Persisting filters is not only used for permalink functionality but also for other filters, e.g. those ones linked on Concerning the messages in general: |
|
You are free to use something better Alternatively, a 2nd word may better describe the process as it is the first entry on the page. |
|
Setting to resolved. |
|
Cool |
|
@mahindra I hope you like my German translations. |
|
@atrol they are beautiful |
|
I don't need, maybe you and others https://de.wikipedia.org/wiki/Liste_von_Austriazismen |
|
I'm not able to find https://de.wiktionary.org/wiki/Oachkatzlschwoaf ;) |
|