Problem description: found two identical functions in tools>customization>keyboard>functions>format> rename sheet <and> rename sheet Either the two functions are exactly identical, or they are slightly different, in which case, the function name should be more specific. Steps to reproduce: 1. go to tools>customization>keyboard 2. you will find under the functions thingie, format category and under that, two exactly identical functions, both named rename sheet Current behavior: two identical functions Expected behavior: need to be more specific/appropriate Operating System: Fedora Version: 3.5.7.2 release
Confirmed - seems like the second one isn't even usable. I'll take this bug. Thanks for reporting!
Unfortunately I just haven't had the time to solve this bug - if I make any progress I will report back but until then setting back to default and NEW
Unassigning myself - after digging and talking to two calc experts - this one is trickier than you'd think - both functions are linked to a bunch of things so I can't just delete the label
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Reproduced. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64) Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50 Locale: fi_FI OpenOffice.org 3.3.0 OOO330m20 (Build:9567)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Dear Kranthi Katikala, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #7) > Dear Kranthi Katikala, > > To make sure we're focusing on the bugs that affect our users today, > LibreOffice QA is asking bug reporters and confirmers to retest open, > confirmed bugs which have not been touched for over a year. dear QA Administrators, i still see two entries 'Rename Sheet' in version: Version: 7.1.0.0.alpha0+ Build ID: 7b00fbddfb1cd55a68ed7481ebd4a5d5f60c6128 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: de-DE (en_US.utf8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2020-06-30_22:29:48 Calc: threaded
Dear Kranthi Katikala, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still happens in master. Proposed patch: https://gerrit.libreoffice.org/c/core/+/147222/1
I'd like to point out that there are several items that have the same "name" (i.e. "rename sheet" is not the only one). So, instead of "solving" just one item, perhaps there should be some kind of re-thinking about how to present the info so users can differentiate the items that have equivalent names. ATM, each tool-tip in each item might give some clue, but it is probably not meaningful for final common users. IMHO, such re-thinking needs some discussion from UX. The alternative would be to have patches for each individual "repeated" item names, which doesn't seem the right thing to do.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b7e54ce8fb57203068f1c2e610758523687ef9a tdf#63965 Hide one extra Rename Sheet command from Customize dialog It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just to leave an explicit trace about this: 1. Label: Rename Sheet Command: .uno:Name Tooltip: Rename Sheet 2. Label: Rename Sheet Command: .uno:RenameTable Tooltip: Rename Sheet
(In reply to ady from comment #11) > I'd like to point out that there are several items that have the same "name" > (i.e. "rename sheet" is not the only one). > > So, instead of "solving" just one item, perhaps there should be some kind of > re-thinking about how to present the info so users can differentiate the > items that have equivalent names. ATM, each tool-tip in each item might give > some clue, but it is probably not meaningful for final common users. > > IMHO, such re-thinking needs some discussion from UX. > Sure, such thinking would belong to: Bug 115527 - Redesign of the keyboard tab of the Customization dialog The current GroupId based categorization is independent of the menu / context menu / tabbed toolbars structure, unmaintained and rather obsolete in its current form.
(In reply to Gabor Kelemen (allotropia) from comment #14) > (In reply to ady from comment #11) > > I'd like to point out that there are several items that have the same "name" > > (i.e. "rename sheet" is not the only one). > > > > So, instead of "solving" just one item, perhaps there should be some kind of > > re-thinking about how to present the info so users can differentiate the > > items that have equivalent names. ATM, each tool-tip in each item might give > > some clue, but it is probably not meaningful for final common users. > > > > IMHO, such re-thinking needs some discussion from UX. > > > > Sure, such thinking would belong to: > Bug 115527 - Redesign of the keyboard tab of the Customization dialog > > The current GroupId based categorization is independent of the menu / > context menu / tabbed toolbars structure, unmaintained and rather obsolete > in its current form. Actually, we've been down this route for bug 108458 and is why in addition to the Name of the command we now *also* see the specific UNO .uno: command in a pop-out tooltip.
(In reply to V Stuart Foote from comment #15) > Actually, we've been down this route for bug 108458 and is why in addition > to the Name of the command we now *also* see the specific UNO .uno: command > in a pop-out tooltip. As mentioned in comment 13, these are 2 different .uno commands. So, is comment 12 still relevant / in place / valid? Or, should this be reverted?
Gabor Kelemen committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/90b5817217bea5d789ca727a881e2ad458837a55 tdf#63965 Hide one extra Rename Sheet command from Customize dialog It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.