[Libreoffice-qa] Some issues about password protection of OOXML and doc files
Hi, I just searched bugzilla ut couldn't find a bug report - but i remember the issue was talked - 1- OOXML files (docx, xlsx, pptx) can be saved as password protected both opening and editing. But as i see, saving them with editing password does not work. File opens with asking password but it is editable i/o read-only and asking dor editing password. Is there any bug report you know, otherwise i will submit a new one. 2- Another issue: With LO 4.4 we have a read-only mode status bar https://wiki.documentfoundation.org/ReleaseNotes/4.4#Edit_.2F_Read-only_mode But this bar does not seen on doc files Can you confirm this issue? Best regards Zeki ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Keywords
Hi, Also changing the discriptions if possible would be great. On 2015-02-01 19:47, Florian Reisinger wrote: Hi Joel, Add: Janitor Love I18n l10n - We have a category for that Notourbug (we have a status) Liebe Grüße / Yours, Florian Reisinger Am 01.02.2015 um 19:17 schrieb Joel Madero jmadero@gmail.com: Hi All, Getting ready to purge some of the keywords below. I suggest starting with removing CLEANUP0407, BISECT_PENDING, MOVETOXKC, NEEDINFO, X12. Unless I hear objections in the next few days I'm going to just move forward with deleting them. EDIT KEYWORD... DESCRIPTION BUGS bisected [1] The bug has been successfully connected to a code commit that introduced the bug (such as with git bisect). 272 [2] bisect_pending [3] The bug seems likely to benefit from bisecting, (such as easy to reproduce, etc.), but the bisect has not yet been performed. See also the bisected keyword. 0 [4] cleanup0407 [5] April 2007 bug cleanup. 2 [6] have-backtrace [7] bugs that have a useful backtrace 236 [8] i18n [9] Xorg Internationalisation issues (i18n) 26 [10] janitor [11] Cleanup bugs, usually trivial. 9 [12] l10n [13] Xorg/X11 Localisation issues 51 [14] licence [15] Files with licence problems (e.g. mixing incompatible licences, missing/non-permissive copyrights, et al) 2 [16] love [17] Marking a bug with this keyword means that you're willing to help someone fix the bug, or that it should be fixable by a beginner without any help. This should ONLY be set by a maintainer or people familiar with the code base, and ONLY when it looks like a project suitable for a new developer looking for a task. 8 [18] movetoxkc [19] Bugs that should be moved to xkeyboard-config, if still applicable. 0 [20] NEEDINFO [21] The bug does not have enough information in order to solve the problem. Please read the comments and add the relevant information required to aid in solving the problem. 51 [22] notourbug [23] It's not really our bug, but we might work around it anyway. 2 [24] patch [25] Bugs with a valid patch. 21 [26] regression [27] Xorg bug regressions (issues previously fixed but somehow broken again) 3406 [28] security [29] Security-sensitive bugs 6 [30] want-backtrace [31] Bugs whose triage could be greatly accelerated with the addition of a backtrace from the crash. 14 [32] x12 [33] Bugs that require a protocol version bump. 0 [34] ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa [35] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ [36] Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette [37] List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ [38] Links: -- [1] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=16 [2] https://bugs.documentfoundation.org/buglist.cgi?keywords=bisected [3] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=17 [4] https://bugs.documentfoundation.org/buglist.cgi?keywords=bisect_pending [5] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=12 [6] https://bugs.documentfoundation.org/buglist.cgi?keywords=cleanup0407 [7] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=5 [8] https://bugs.documentfoundation.org/buglist.cgi?keywords=have-backtrace [9] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=1 [10] https://bugs.documentfoundation.org/buglist.cgi?keywords=i18n [11] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=6 [12] https://bugs.documentfoundation.org/buglist.cgi?keywords=janitor [13] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=2 [14] https://bugs.documentfoundation.org/buglist.cgi?keywords=l10n [15] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=8 [16] https://bugs.documentfoundation.org/buglist.cgi?keywords=licence [17] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=15 [18] https://bugs.documentfoundation.org/buglist.cgi?keywords=love [19] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=10 [20] https://bugs.documentfoundation.org/buglist.cgi?keywords=movetoxkc [21] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=14 [22] https://bugs.documentfoundation.org/buglist.cgi?keywords=NEEDINFO [23] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=11 [24] https://bugs.documentfoundation.org/buglist.cgi?keywords=notourbug [25] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=9 [26] https://bugs.documentfoundation.org/buglist.cgi?keywords=patch [27] https://bugs.documentfoundation.org/editkeywords.cgi?action=editamp;id=3 [28] https://bugs.documentfoundation.org/buglist.cgi?keywords=regression [29]
Re: [Libreoffice-qa] Keywords
On 02/02/2015 02:50 AM, Rob Snelders wrote: Hi, Also changing the discriptions if possible would be great. Changing description of what? Best, Joel ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Keywords
Description of the keywords ;) Liebe Grüße / Yours, Florian Reisinger Am 02.02.2015 um 15:28 schrieb Joel Madero jmadero@gmail.com: On 02/02/2015 02:50 AM, Rob Snelders wrote: Hi, Also changing the discriptions if possible would be great. Changing description of what? Best, Joel ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-qa] On the topic of Backporting bugs fixed on master
[ moved to better forum from https://bugs.documentfoundation.org/show_bug.cgi?id=89039 ] --- Comment # 5 on bug 89039 from V Stuart Foote Regards resolving WFM, guess that is OK if that is the QA consensus. But the logic escapes me then of even retaining MABs (or tracking Metas). If a bug shows as resolved in the MAB listing (or any tracking Meta)--it does not get further reviewed--and then we have to drag BZ for the issues. --- Sure. That's us running into the limitations of Bugzilla, really. --- Which then requires an advanced query against Whiteboard field to match regular expression backportRequest or similar strings. --- Queries are here, for reference: https://wiki.documentfoundation.org/QA/Bugzilla/Useful_Queries#Backport_Requests --- With 4.4.0 just out of the gate, valid new MABs are going to bubble up against the branch--I just don't see a reason to close them so quickly and then to depend on someone doing a reverse bibisect and back-port requests. --- Regardless of what we mark the bugs in Bugzilla, our fastest tool for figuring out which commit fixed a bug is by a reverse-bibisect. And the backportRequest:X.y tag is a very specific way for us to communicate our intentions with the developers. We don't currently have a way to indicate a status for each branch that's active, but if we were to add that, then we could say NEW for 4.4 and RESOLVED for 4.5. I'm not sure of the best way to add that without making things more confusing... Bugzilla isn't quite that customizable. --- Which can't even be done for OS X or Windows issues. --- Well, we can do some limited bibisecting on both platforms. I really hope that in 2015 we can make bibisecting much more doable for both Win and OSX. Best, --R -- Robinson Tryon QA Engineer - The Document Foundation LibreOffice Community Outreach Herald qu...@libreoffice.org ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] On the topic of Backporting bugs fixed on master
Robinson Tryon wrote Sure. That's us running into the limitations of Bugzilla, really. [...] Bugzilla isn't quite that customizable. Hi! Disagree. It is only the way how this project use (or rather not use) Bugzilla features. To solve the issues mentioned I would propose using flags. Robinson Tryon wrote And the backportRequest:X.y tag is a very specific way for us to communicate our intentions with the developers. [...] We don't currently have a way to indicate a status for each branch that's active, but if we were to add that, then we could say NEW for 4.4 and RESOLVED for 4.5. I'm not sure of the best way to add that without making things more confusing... Bugzilla isn't quite that customizable. Branching. Lets imagine we have active flags for following current LO branches (it is an example, so do not validate the versions or naming please): - target4.5 - target4.4 - target4.3 A joedoe commits a patch to 4.5 and 4.4 branches. Gerritbot could set the flags automatically (instead of whiteboarding): - target4.5 + - target4.4 + - target4.3 _ (unset) We want the patch to be backported to 4.3, as this is serious bugfix and 4.3.7 slot is available. To request this we set flag target4.3 to ? requesting an action from a commiter (if he has the Bugzilla account - IMHO he should have one to Assign the bug to himself). He do not have time so he denies it by setting a flag to target4.3 -. The bug has the following flags set in the end: - target4.5 + - target4.4 + - target4.3 - Affected branches. To indicate which branch is affected one could set the following flags: - affected4.5 + - affected4.4 + - affected4.3 + All those flags give us information which branches got fixed and which not. If archive flags would be shown (for inactive branches), this could help the bibisecters: - affected4.5 + - affected4.4 + - affected4.3 + - affected4.2 - Why this is better than whiteboard? Flags are sortable, visible by product/component, you don't need to type long strings, we know who set the flag, developers see the requests in My request tab, we can search the flags (https://bugs.documentfoundation.org/page.cgi?id=quicksearch.html#advanced_examples) - just imagine that there could be a flag:target4.3? or flag:target4.3- saved search or whine to find people who can backport it. For me this would be far better workflow than abusing whiteboard, where you can type everything (and I see that more and more informations go there). With flags, those can be made inactive, so you cannot set them or deleted if you do not care about them anymore or just not visible in the UI. Not mentioning the security options to request and grant them... One could also decide that there should be full version history - target4.3.x scheme used to indicate the specific release. Hope it helps. Best regards. P.S. I can imagine that flags could be used for many other things like requesting: - a documentation update - moztrap test - relnotes update - bibisecting etc. P.S.2 There is a chance that Bugzilla will deal better with branches when Sightings feature is ready - see https://bugzilla.mozilla.org/show_bug.cgi?id=55970. Unfortunately this is very old bug... -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-On-the-topic-of-Backporting-bugs-fixed-on-master-tp4138618p4138627.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/