View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
16553 | Feature requests | Label sets | public | 2020-07-31 16:54 | 2021-11-02 09:46 |
Reporter | Mazi | Assigned To | ollehar | ||
Priority | normal | Severity | @60@ | ||
Status | new | Resolution | open | ||
Summary | 16553: Relevance equation not copied when loading answer options from a label set | ||||
Description | When saving a label set e.g. the sub-questions of a multi choice question and there are relevance equations applied to certain items, those relevance equations disappear when loading the label set at a different question. | ||||
Steps To Reproduce | Create a label set with relevance equation for some items. | ||||
Tags | No tags attached. | ||||
Bug heat | 8 | ||||
Story point estimate | |||||
Users affected % | |||||
You're using an outdated version of LimeSurvey. Please update to the latest version and check if the bug can still be reproduced. Thank you. |
|
The instructions to reproduce this is 3 steps. It will take you a minute to test this yourself. Simply asking users to test again and again if this is still an issue will surely lead to users not reporting bugs anymore. I am not sure if this is intended. |
|
You want me to test 800 bugs manually, instead of distribute it to all different users? Nope. Not gonna happen. |
|
So what's the alternative? I have reported about a hundred bugs the last months and I will not re-test all the not yet fixed ones because of such a default message. I simply do not have time for that. |
|
Just answer "Yes, bug still there"? |
|
Sorry, but as a Limesurvey partner I need to earn some money so I can pay my fees. I can't spend my time with bug testing. |
|
You don't have to test it, just answer "Yes" if you think it's not fixed. |
|
Well, but what if my crystal ball won't tell me whether this is fixed?!? |
|
I trust you. ^^ |
|
Thanks for reporting, @Mazi! @Olle: I can confirm that behavior with 3.25.16 and with 4.4.10. However, I am not sure if copying relevance is a good idea for label sets. As the name suggests these sets are about labels and not about more advanced options. But perhaps I don't see the actual use case. And there is the risk that users involuntarily apply relevance equations. Perhaps we could look for arguments for and against including relevances in label sets? If you need the relevances, why don't you just copy the question? |
|
Overall, I am a bit undecided about asking users to re-confirm a bug. I think if users did not use the most recent LimeSurvey version when reporting the bug we should ask for testing with a current version. But if a recent version has been used and the problem is the long backlog, then I would refrain from asking reporters to re-test. We should be grateful for each bug report. On the other hand, if an issue is really important for the reporter, it would really help if the person tested again - especially when the reporter knows how much open tickets there are at the moment. #strongertogether Is that reply worthy of Solomon? |
|
Back to topic: |
|
@f_funke: Thanks for your feedback Salomon/Frederik. I have to admit that I have never thought about the desired behavior. You are rigth that there are reasons for not copying relevance equations like re-using them at other surveys. But in such cases I would simply not store it with the relevance and add the relevance afterwards. In a nutshell: When having relevance applied to items of my label set, I assume that will be copied along. |
|
I opened an internal forum thread where we can discuss the process of cleaning up Mantis: https://forums.limesurvey.org/forum/team-only/123953-cleaning-up-in-mantis#213236 |
|
This seems like a feature request and not a bug. I will change it to a feature request |
|
As @f_funke pointed out, this is not a bug since it is not the desired behavior. I will change the report to a feature request |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2020-07-31 16:54 | Mazi | New Issue | |
2021-03-10 17:12 | ollehar | Assigned To | => ollehar |
2021-03-10 17:12 | ollehar | Status | new => feedback |
2021-03-10 17:12 | ollehar | Note Added: 63057 | |
2021-03-10 17:39 | Mazi | Note Added: 63098 | |
2021-03-10 17:39 | Mazi | Status | feedback => assigned |
2021-03-10 17:49 | ollehar | Note Added: 63118 | |
2021-03-10 18:02 | Mazi | Note Added: 63123 | |
2021-03-10 20:45 | ollehar | Note Added: 63130 | |
2021-03-10 21:33 | Mazi | Note Added: 63154 | |
2021-03-10 21:35 | ollehar | Note Added: 63156 | |
2021-03-10 21:36 | ollehar | Status | assigned => new |
2021-03-10 21:37 | ollehar | Priority | none => normal |
2021-03-10 21:37 | Mazi | Note Added: 63157 | |
2021-03-10 21:38 | ollehar | Note Added: 63158 | |
2021-03-11 10:33 | f_funke | Note Added: 63287 | |
2021-03-11 10:34 | f_funke | Note Added: 63288 | |
2021-03-11 10:38 | f_funke | Note Added: 63289 | |
2021-03-11 10:48 | Mazi | Note Added: 63291 | |
2021-03-11 11:21 | ollehar | Note Added: 63293 | |
2021-11-01 11:34 | galads | Note Added: 67023 | |
2021-11-01 11:34 | galads | Bug heat | 6 => 8 |
2021-11-01 11:34 | galads | Project | Bug reports => Feature requests |
2021-11-02 09:46 | galads | Note Added: 67041 |