Created attachment 151761 [details] Absolute simplest case - empty .odt marked as Confidential test system Ubuntu 18.04.1 with Version: 6.3.0.0.alpha1+ Build ID: 40e2a0d7039eee9c5377996da3949680903e1016 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-22_13:55:35 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Steps to reproduce: 1 - Open the attached file in Writer. 2 - Select Tools->Redact Result: .odg file opened in Draw does not have the water mark 'confidential' in the background, though there is a bit of a 'C' there. Expected result: The .odg file would maintain the water mark appropriate for the TSCP classification.
I linked in the developer: To be honest I'm not sure if this is an issue or a feature. I can't remember how this was handled in "Orange Book Compliant" systems I worked on in the past, but I kind of think the watermarks stay.
Hmm. Having the C there is a symptom of a bug. We should either preserve the confidential background or not. No partial remnants. I wonder if it behaves the same way maybe before d5b59b8d9d798b884dbcf0c97f403d739b01e1cc
This seems to have begun at the below commit. f9801f37701bc53faec64c1fdb85da27a4d16e36 is the first bad commit commit f9801f37701bc53faec64c1fdb85da27a4d16e36 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon May 6 19:00:37 2019 +0200 source 2ff22c0bf4c23c4bed9ccfcfa79dff848086650d author Muhammet Kara <muhammet.kara@collabora.com> 2019-05-03 22:07:59 +0300 committer Muhammet Kara <muhammet.kara@collabora.com> 2019-05-06 16:49:16 +0200 commit 2ff22c0bf4c23c4bed9ccfcfa79dff848086650d (patch) tree 5b33fca87caa56c093b6dcca3575855aa73480ee parent e2c2136dccbf2f4800ca4adc04911b6258a179fe (diff) tdf#125135: Standardize content placement for redaction Correct the position & size by roundtrip conversion from/to wmf as a temporary solution.
(In reply to raal from comment #3) > This seems to have begun at the below commit. > > f9801f37701bc53faec64c1fdb85da27a4d16e36 is the first bad commit > commit f9801f37701bc53faec64c1fdb85da27a4d16e36 > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Mon May 6 19:00:37 2019 +0200 > > source 2ff22c0bf4c23c4bed9ccfcfa79dff848086650d > > author Muhammet Kara <muhammet.kara@collabora.com> 2019-05-03 22:07:59 +0300 > committer Muhammet Kara <muhammet.kara@collabora.com> 2019-05-06 16:49:16 > +0200 > commit 2ff22c0bf4c23c4bed9ccfcfa79dff848086650d (patch) > tree 5b33fca87caa56c093b6dcca3575855aa73480ee > parent e2c2136dccbf2f4800ca4adc04911b6258a179fe (diff) > tdf#125135: Standardize content placement for redaction > Correct the position & size by roundtrip conversion > from/to wmf as a temporary solution. That's what I was suspecting. Thank you for confirming!
Please note that it will take a while to fix this because it is result of a workaround for another (bigger) problem.
(In reply to Muhammet Kara from comment #5) > Please note that it will take a while to fix this because it is result of a > workaround for another (bigger) problem. Understood. Thinking about this further and using the tool a bit more, just to let you know there is a rfe in my mind regarding TSCP and Redaction Preview rendering. But that is something that would best be done I suppose by starting a conversation about it, as a future upgrade. An email on the dev ml about that first then, just to give you heads up.
*** Bug 126082 has been marked as a duplicate of this bug. ***
Has been in the assigned state for too long. I am busy with other parts of the redaction feature, so if anyone feels like taking a look at this, don't hesitate to assign it to yourself, but please keep in touch with me to avoid conflicts.
Dear Drew Jensen, 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