Bug Hunting Session
Bug 57895 - UI: Conditional Formatting for cells shown incorrectly and and incompletely in CF dialog
Summary: UI: Conditional Formatting for cells shown incorrectly and and incompletely ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha1
Hardware: Other All
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: target:4.1.0 target:4.0.0.0.beta2
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-12-04 20:16 UTC by andis.lazdins
Modified: 2013-01-11 13:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Conditional formatting settings are lost on file open (53.70 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-12-04 20:17 UTC, andis.lazdins
Details
Screenshot comparison (429.47 KB, application/pdf)
2012-12-05 12:41 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andis.lazdins 2012-12-04 20:16:20 UTC
In Version 4.0.0.0.alpha1+ (Build ID: e14b5f33ceae3280b46eb97a88b949d00263956) on Ubuntu 12.04 opening of file with conditional formatting elements original conditional formatting setting (in sample file if cell value is > 0, than cell style = Number) is changed to empty value (if cell value is equal = (empty box), then Default style).
When the same file is opened in previous versions of libeoffice, conditional formatting settings survive on file open.

This problem arised from testing of peoblems with conditional formatting here https://bugs.freedesktop.org/show_bug.cgi?id=57176
Comment 1 andis.lazdins 2012-12-04 20:17:51 UTC
Created attachment 71012 [details]
Conditional formatting settings are lost on file open
Comment 2 andis.lazdins 2012-12-04 20:21:00 UTC
(In reply to comment #1)
> Created attachment 71012 [details]
> Conditional formatting settings are lost on file open

Conditional formatting settings mentioned in the first comment are in cells J12:AN26
Comment 3 Rainer Bielefeld Retired 2012-12-05 12:28:24 UTC
[Reproducible] with reporter#s sample and with parallel installation of  "LOdev  4.0.0.0.alpha1+   -  ENGLISH UI / German Locale  [Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3)]"  {tinderbox: Win-x86@6, pull time 2012-11-26 00:29:34} on German WIN7 Home Premium (64bit) with own separate User Profile:

In janv.N12 with menu 'Format -> Conditional Formatting ->  Condition' only the "Cell Value is" is shon correctly, "Bigger Than" is shoen as "equal to", and in the condition field nothing is shown instead of the number "0".

Might be a UI problem, CF works correctly for that cell, and when I save an edited document with LibO 4.0 the conditions for N12 are shown correctly in LibO 3.6.4

With "LibreOffice 3.6.4.3 rc" German UI/ German Locale [Build-ID: 2ef5aff] {pull date 2012-11-28} on German WIN7 Home Premium (64bit) I see the conditions shown correctly in the dialog.

Has nothing to do with "old document", when I correct the CF settings for N12 wiht LibO 4, close CF dialog and reopen dialog my correct settings are "lost" again. And even worse: My changes will not be applied. I tried to change the existing ">0" condition to ">0,5", but my changes were not applied.

@Spreadsheet Team:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Please tell me if it would be useful to try to narrow down version where bug appeared.
Comment 4 Julien Nabet 2012-12-05 12:36:27 UTC
Comment on attachment 71012 [details]
Conditional formatting settings are lost on file open

fix mimetype of attachment
Comment 5 Rainer Bielefeld Retired 2012-12-05 12:41:24 UTC
Created attachment 71027 [details]
Screenshot comparison

Screenshot shows different contents in CF dialog with 3.6.4 and 4.0

My conclusion that effect has nothing to do with "from old version" might have been too rush, I can't reproduce the problem with a simple document newly created with LibO 4.0. But I see document exchange problems related to CF between 3.4 and 3.6.4.3, I still need to do some further research to understand all that.
Comment 6 Markus Mohrhard 2012-12-05 13:14:43 UTC
Obviously one for me.
Comment 7 Markus Mohrhard 2012-12-06 00:49:27 UTC
(In reply to comment #6)
> Obviously one for me.

And actually not a bug. The behavior changed a bit and as you can see in the Manage conditional formats dialog the conditions are still correct.

Begiining with 4.0 we allow overlapping conditional formats. That means that you have a conditional formatting in A1:C4 and define a new one in B1. Then they will be applied in the order of the definition.

I have to talk to the UX guys how to make this new behavior more transparent to the user.

This step was the last step that I wanted to archive with range based conditional formats. Please always check with Formats->Conditional Formatting->Manage... the conditional formats.
Comment 8 Markus Mohrhard 2012-12-06 01:05:00 UTC
Removing the blocker attribute.
Comment 9 andis.lazdins 2012-12-06 06:39:10 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Obviously one for me.
> 
> And actually not a bug. The behavior changed a bit and as you can see in the
> Manage conditional formats dialog the conditions are still correct.
> 
> Begiining with 4.0 we allow overlapping conditional formats. That means that
> you have a conditional formatting in A1:C4 and define a new one in B1. Then
> they will be applied in the order of the definition.
> 
> I have to talk to the UX guys how to make this new behavior more transparent
> to the user.
> 
> This step was the last step that I wanted to archive with range based
> conditional formats. Please always check with Formats->Conditional
> Formatting->Manage... the conditional formats.

I'm not sure if I understood clear this comment. I'm sure this is a problem. If there is a dialogue on conditional formatting conditions, those settings should appear in right place and in right way. With manage option I can only remove conditional formatting areas, there is nothing to do with settings.
Comment 10 Rainer Bielefeld Retired 2012-12-06 06:58:10 UTC
@andis.lazdins@gmail.com 
Please do not use your e-mail client for comments, please do not cite!

@all:
A major problem is that there still does not exist any description for the new CF design (at least  I do not know any).

Concerning severity of the problem I currently am not sure. It sould be possible to exclude CF definition of a cell from the CF range to what the cell belong without chin ups, and UI should contribute useful information, if the operation "change CF definition for single change in range" is impossible, that should be mentioned somewhere and may be dialog should not accept that change. But it's a bad solution that UI pretends to accept a change without any warning.

I agree with Markus' decision to remove the "blocker" importance (I should have done that with my comment 5). It's not a general problem making impossible any edit of CF as I thought after my first tests. But nevertheless this one might cause serious problems for many users.
Comment 11 Markus Mohrhard 2012-12-06 18:52:59 UTC
(In reply to comment #10)
> @andis.lazdins@gmail.com 
> Please do not use your e-mail client for comments, please do not cite!
> 
> @all:
> A major problem is that there still does not exist any description for the
> new CF design (at least  I do not know any).

A blog post is already in work to explain it. However I still need to get input from the UX team how to deal with the overlapping conditional formats in the dialog.

> 
> Concerning severity of the problem I currently am not sure. It sould be
> possible to exclude CF definition of a cell from the CF range to what the
> cell belong without chin ups, and UI should contribute useful information,
> if the operation "change CF definition for single change in range" is
> impossible, that should be mentioned somewhere and may be dialog should not
> accept that change. But it's a bad solution that UI pretends to accept a
> change without any warning.

It accepts the change. Imagine you define a conditional format value is equal 1 in the range A1:C4 and now you also need a conditional format value is equal 2 for A1. Then you can now define the conditional format first for A1:A4 and then select A1 and define a new one.

It might not make much sense for formulas like equal to but for some of the new conditional formats that depend on the range of the format it is quite important. Imagine you define top 3 elements(new format in 4.0) that highlights the cells with the 3 highest values and you want to highlight also only one specific cell if it is greater than zero.

> 
> I agree with Markus' decision to remove the "blocker" importance (I should
> have done that with my comment 5). It's not a general problem making
> impossible any edit of CF as I thought after my first tests. But
> nevertheless this one might cause serious problems for many users.

It is right now only a UX problem. The conditional formats are all there.
Comment 12 Not Assigned 2012-12-15 06:52:07 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7073310431becb1a69af0c7187b9844ce7901cd5

make editing conditional formats more obvious, related fdo#57895



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Not Assigned 2012-12-15 14:14:33 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98f1295fe749100f3564c4b4ca66f106d25739c0&g=libreoffice-4-0

make editing conditional formats more obvious, related fdo#57895


It will be available in LibreOffice 4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Markus Mohrhard 2012-12-15 14:25:44 UTC
Please check in beta2 if you can live with this solution.
Comment 15 andis.lazdins 2013-01-11 13:21:57 UTC
The problem is gone in Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)

Thank you!