Bug 130198 - Make possibly use a current value from "Input list" field as variable value
Summary: Make possibly use a current value from "Input list" field as variable value
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields-Variable
  Show dependency treegraph
 
Reported: 2020-01-25 20:17 UTC by Roman Kuznetsov
Modified: 2022-03-07 08:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2020-01-25 20:17:23 UTC
Description:
Make possibly use a current value from "Input list" field as variable value.
There are many cases for variable using.
And would be very cool to have a simple opportunity to set a variable value  from list in document using "Input list" field.

Steps to Reproduce:
-

Actual Results:
-

Expected Results:
-


Reproducible: Always


User Profile Reset: No



Additional Info:
-
Comment 1 Regina Henschel 2020-01-25 21:23:11 UTC
What do you want to do with the variable? Please say a little bit more about the use case.

You can mark the input list in the text and set a reference on it. Later you can insert a reference to it with type "Reference". That will show the current value of the input field at other places in the document.
Comment 2 Roman Kuznetsov 2020-01-26 17:14:51 UTC
(In reply to Regina Henschel from comment #1)
> What do you want to do with the variable? Please say a little bit more about
> the use case.
> 
> You can mark the input list in the text and set a reference on it. Later you
> can insert a reference to it with type "Reference". That will show the
> current value of the input field at other places in the document.

I want use current value from "Input list" field as variable when I use a variable for hide sections. For example, I want hide/shows two sections by one variable:
a="pay" and it shows a first section but second is hidden.
a="don't pay" and first section is hidden but it shows second shows.
I should change that variable manually. But...
I don'w want remember these variables (and my users too!). I want just select needed variant from list inside text body and that variant should be a variable.
Comment 3 Regina Henschel 2020-01-26 18:53:56 UTC
Thank you for the explanation. Currently it is not possible to reference a drop-down list in a condition.

Currently LibreOffice uses for the condition its own namespace "ooow". So I see no problem from an ODF point of view, to extend the condition so, that a reference to a drop-down list can be used. Details need to be clarified, e.g. the case that a variable and a drop-down list have the same name.

I think, it is a useful extension.
Comment 4 Regina Henschel 2020-01-26 18:58:48 UTC
To be clear, my proposal it not to allow a reference as value of a variable. That would be complicated in regard to file format. My proposal it to allow a reference to a drop-down field in a condition.
Roman: Would that be OK?
Comment 5 Mike Kaganski 2020-01-27 08:58:50 UTC
(In reply to Regina Henschel from comment #4)
> To be clear, my proposal it not to allow a reference as value of a variable.
> That would be complicated in regard to file format. My proposal it to allow
> a reference to a drop-down field in a condition.

I suppose that doing that way would be not really good: it would introduce yet other special case to the complexity, without giving full flexibility. Could adding some "extension" attribute to the drop-down list markup, which would optionally bind it to a variable, be possible? Which could get to a following revision of the standard. That could allow other uses of the drop-down, like in following "show variable", e.g. in header/footer area.

Or maybe adding another field type would be better, like current two similar "Input Field"s, one on Variables tab, the other on Functions tab, and the former being bound to Variable - this would be more consistent with regard to status quo IMO, because making a field on Functions bound to Variable is not correct... and binding it to variables unconditionally would break compatibility.
Comment 6 Roman Kuznetsov 2020-01-27 09:54:45 UTC
(In reply to Mike Kaganski from comment #5)

> Or maybe adding another field type would be better, like current two similar
> "Input Field"s, one on Variables tab, the other on Functions tab, and the
> former being bound to Variable - this would be more consistent with regard
> to status quo IMO, because making a field on Functions bound to Variable is
> not correct... and binding it to variables unconditionally would break
> compatibility.

yeah, adding a new type of variable field like "Variable Input list" would be more general solution for my enhancement
Comment 7 ibelin123 2021-02-06 03:32:01 UTC
+1 for this Enhancement. 

Adding a variable input list may also solve my feature request in Bug 122654 (https://bugs.documentfoundation.org/show_bug.cgi?id=122654)
Comment 8 Gabriele Ponzo 2021-09-23 14:06:36 UTC
Definitely +1
I've just held a speech about this in LibOcon 2021