Bug 147233 - Treat table formulas like fields
Summary: Treat table formulas like fields
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.5.2 release
Hardware: x86-64 (AMD64) All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Writer-Tables-Formulas
  Show dependency treegraph
 
Reported: 2022-02-06 14:00 UTC by Markus Elfring
Modified: 2022-03-03 11:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example for the software functionality “Calculating in text documents” (10.67 KB, application/vnd.oasis.opendocument.text)
2022-02-27 19:56 UTC, Markus Elfring
Details
Screenshot for a questionable software behaviour with calculation results (51.91 KB, image/png)
2022-02-27 20:26 UTC, Markus Elfring
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Elfring 2022-02-06 14:00:53 UTC
Description:
I have tried the software “LibreOffice Writer 7.2.5.1-2.1” out again.
Calculated values are also supported to some degree.
https://help.libreoffice.org/7.2/en-GB/text/swriter/guide/calculate.html

Steps to Reproduce:
Tooltips indicate the usage of formula specifications.

Actual Results:
I observed then that the computed display elements could be still edited.

Expected Results:
I imagine that such a text modification should be prevented because the display should be automatically updated according to changed input data.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
* How will the chances evolve to stress the usage of calculated values (including customised number formats)?

* Would you like to switch to the adjustment of formula code in more convenient ways?
Comment 1 Timur 2022-02-07 13:55:48 UTC
Not really clear what this is about. Please try to give an example.
Comment 2 Markus Elfring 2022-02-07 18:07:26 UTC
(In reply to Timur from comment #1)
Do you find display consequences (and modification possibilities) reasonable according to the referenced software documentation for the functionality “Calculating in text documents”?
Comment 3 Markus Elfring 2022-02-08 13:56:33 UTC
Which descriptions would other users find more pleasing and helpful for the observed software behaviour?
Comment 4 Dieter 2022-02-23 07:13:30 UTC
As Timur said, please give an example and some steps to reproduce.
=> NEEDINFO
Comment 5 Markus Elfring 2022-02-27 19:56:02 UTC
Created attachment 178569 [details]
Example for the software functionality “Calculating in text documents”

(In reply to Dieter from comment #4)
> As Timur said, please give an example and some steps to reproduce.

Do you understand the attached test document better than the available software documentation?
https://help.libreoffice.org/7.3/en-GB/text/swriter/guide/calculate.html
Comment 6 Markus Elfring 2022-02-27 20:26:34 UTC
Created attachment 178570 [details]
Screenshot for a questionable software behaviour with calculation results

Would you find editing effects occasionally questionable for desired automatic display updates at the shown place?
Comment 7 Dieter 2022-02-28 07:53:10 UTC
Thank you for the sample document. But I can't eee the problem: 2,34 € + 1,26 € = 3,60 € is correct. And everything is in line with documentation. So what is your expected result?
=> NEEDINFO
Comment 8 Markus Elfring 2022-03-01 19:43:49 UTC
(In reply to Dieter from comment #7)
> … But I can't eee the problem: …

* Did you notice that parts of the computation result display can be marked and modified?

* Should the number format representation be kept consistent for such a test case?

* May I expect that the original formula can become write-protected?


By the way:
I suggest to compare the software behaviour with functionality from fields.
https://help.libreoffice.org/7.3/en-GB/text/swriter/guide/fields.html
Comment 9 Dieter 2022-03-02 18:00:20 UTC
(In reply to Markus Elfring from comment #8)
> (In reply to Dieter from comment #7)
> > … But I can't eee the problem: …
> 
> * Did you notice that parts of the computation result display can be marked
> and modified?

It wasn't clear to me, that you refer to that behaviour. Please write proper bug reorts:
- Actual result (formula can be modified without formula editor)
- Expected result (Formula should only be modified in formula editor)
Is this correct?

Not sure, if this is a bug or enhancement request. I add esign-team for double-check.
Comment 10 Markus Elfring 2022-03-02 20:27:38 UTC
(In reply to Dieter from comment #9)
> - Actual result (formula can be modified without formula editor)
> - Expected result (Formula should only be modified in formula editor)

I find that this wording expresses an other software variant than my expectation.

I propose to increase the distinction between the construction of a formula and the corresponding computed value display.

* I imagine that a formula can be edited by some means (besides the widget which is supported at the moment).

* Would a setting be helpful for switching between source modification and another (visual) representation (similar to the existing configuration option for fields)?
Comment 11 Heiko Tietze 2022-03-03 08:40:31 UTC
It is possible to insert a formula in plain text, for example F2 > =1+1. The result is a field with the type "inserted formula" and editing is possible only via the fields dialog.

I suggest to do the same for table formulas, as requested in this ticket. That means F2 goes into the formula edit mode as today but the calculated result would be a field (with proper shading). Double click on the field probably requires to go into the formula edit mode as the fields dialog has no knowledge of table cells. Consequently we cannot use the field dialog to define the the number format but have to keep it per table cell.