[brainstorming] Mass-editing of Items

[florian-h05]

I‘ve read the wish for mass-editing of Items in the UI several times on the forum (I currently cannot find the posts, I will probably add the links later) and I see the lack of such features in MainUI, so I started asking myself how we can improve the UI here.

Closely linked to mass-editing of Items is IMO the possibility to search over several UI-based entities like scripts, rules, scenes, Items, Things using a single search field: the developer sidebar. I have opened a PR to improve it‘s capabilities, see #1732.

This discussion here should be a brainstorming of what features you think are useful for mass-editing of Items inside the UI. Please create a new comment for each idea and discuss this idea by answering to that comment.

[florian-h05]

I came up with the following idea(s):

• duplicate Item functionality: Add a button to existing Items to create a new Item from them. This would open the Item creation sheet, but with the configuration of the existing Item already filled in. You would need to change the name and that‘s it — you have duplicated a Item.

[rkoshak]

This would be useful for all entities, not just Items.

[ghys]

"Add from YAML" would be even more useful - you would go straight to a YAML editor where you'd be able to potentially paste what you took from the Code tab of the entity you want to duplicate, adjust what you need to adjust and either go to the details page for the entity you created, or go straight to creating another one.

[rkoshak]

I don't think these two ideas are mutually exclusive. It can be quite useful to "save a copy" of something to run some experiment or develop a rule or the like. In the case of a rule, you can disable the original, experiment with the copy, than disable/reenable to swap back if your changes aren't ready to deploy.

The need to

1. open the entity
2. click the code tab
3. copy the YAML
4. navigate away
5. click +/add
6. open the code tab
7. paste and edit
8. go back to the design page and don't forget to change the UID, name and description
9. save

An "Add from YAML" would only address some of this workflow from 5 to 9 but not really significantly change the number of steps and clicking about. But if we had "Save a Copy" or "Duplicate" button on every entity page (except maybe discovered Thing?) we would have:

1. open the entity
2. click duplicate
3. edit
4. maybe go back to the design page and change UID, name and description
5. save

Ultimately, what makes this whole process awkward is we have to take the YAML from the Code tab in the first place.

Again, I'm not saying anything against an "Add from YAML", but I don't think it's the same thing as a duplicate option.

[ghys]

I don't think these two ideas are mutually exclusive.

Absolutely, we can have both.

[florian-h05]

@d51x As you have already created a PR to add a duplicate functionality for rules and Thing channels, you should probably know about this discussion here.
I want to implement a duplicate functionality for almost all UI entities, however I'm glad if someone else provides PRs and implements those capabilities, so in case you want to contribute more, feel free to do so. I will definitely not reject copy/duplicate features for UI entities.

[rkoshak]

A table view of all Items or all Items that match a given criteria showing the various properties of the Items. Except for the name, each field can be edited in place in the table. I'm not sure how that would work with metadata but even if we support everything but metadata it'd be an improvement.

If not a table, populate the "create items from text" page with the .items file syntax of the Items where they can be edited in place (changing the name would cause a new Item to be created).

[rkoshak]

Complete the "Code" tabs by adding one to the Item's page. I think we now have everything in the REST API we need to actually do this, finally. I'm not sure if it will help as much with bulk editing but it sure would help a ton in providing support on the forum.

[florian-h05]

I have started working on this and I am pretty close to finishing it, here's a first impression:

(Note that the configuration of this Item is non-sense as I am just playing around with it a bit.)

Would fix #728.

[ghys]

Great! I also had the idea that it was a perfect place to edit all metadata at once (it would require some shenanigans when saving though).

[florian-h05]

Yeah, saving this requires some extra code since metadata editing takes places at its own endpoint. I haven’t implemented that yet.
UPDATE: I just read your comment on #1715, your idea with extending the Items REST endpoint for metadata would solve the need for additional requests, so I will wait a bit if there is any development at core for this.

[florian-h05]

I finally had the time to clean-up my code and open a PR: #1818.

[rkoshak]

We have a way to create a bunch of Items from a Thing with "create equipment from thing" and "create points from thing".

What if we could do that from a custom UI Widget or Rule Template too at instantiation time. Have a way for a developer to list all the Items their doodad needs to operate and the end admin user can select a preexisting Item or check a box to create the Item right there as they are filling out the properties for the doodad.

When creating new, providing the ability to define Links and metadata would be really useful but even without it would be an improvement over what we have now.

Even if it's as basic as popping over the screen the "create items from text file" instead of a nice form it would be useful.

[J-N-K]

For me most important would be "duplicate" (not only for items, also for things and maybe rules), and also a sort of "persistent" filter for the list. The searchbar is nice if you want to do exactly one edit (or lookup), but unfortunately immediately after you chose an item/thing/rule and go back to the items/things/rules page you have to type in the searchbar again. An example use-case: I have the heating set point items for all my rooms named "Heizung_Setpoint_" and the labels are all "" because the I originally designed it, I had them all in a group "Setpoint" on a single page in BasicUI. Now I would like to rename all the labels to " Sollwert". I can easily find those Items by typing "Heizung_Setp", but I have to do that several times because after editing one item, the searchbar is reset.

[florian-h05]

The search filter is persisted for me. I can enter a search string, open a Item, navigate back to then Item list (both with the back button of MainUI and browser back), and the search string and filter are still applied.

Regarding duplication: I'll have a look into that feature, just want to wait for my many current PRs to get merged, otherwise I'd run into merge conflicts.

[rkoshak]

It only persists for me half the time. I think if you do certain operations on an Item (for example changing it's label) it signals to MainUI that a refresh is required and I lose the search term when I go back to the Items page. Without changing the Item the search is preserved.

[ghys]

There's a simple explanation, the UI framework keeps only the immediate previous page in the background, for the back transition to work. If you navigate 2 pages deep, like items list > item details > item edit, then the first page (items list) is eventually removed from the DOM (i.e. destroyed), and created again only when you go back to the items details - and so the initial state like the filter is lost. It could be kept for instance in sessionStorage and restored.

[florian-h05]

Thanks for the explanation, do you think you can provide a fix for that?

[digitaldan]

@florian-h05 thanks for opening up this as a discussion. I like all the ideas here. My personal request would be to have a text view of pages, rules, items, and things, similar to editing those when using file based configuration. Being able to mass edit, copy, search, etc.. would be huge, and would lessen the need to stick with file based configurations. While we could mimic the legacy item and things file format, i would also be open to json, yaml or other formats that might be easier to parse and format.

i could almost imagine a VSCode style editor, where on the left side you have a file like explorer with virtual files or directories for "pages", "items", "things", "rules", etc.... and then a similar editor on the right, maybe we stick with yaml since that is used else where.

Of course i'm a command line / text file junkie , so i realize i may be in the minority. And this is probably a HUGE scope creep request ;-)

[ghys]

i could almost imagine a VSCode style editor, where on the left side you have a file like explorer with virtual files or directories for "pages", "items", "things", "rules", etc.... and then a similar editor on the right, maybe we stick with yaml since that is used else where.

That was an idea I had for a long time but finally decided what I needed was something like my "ohadm" script:
https://community.openhab.org/t/ohadm-a-simple-script-to-manipulate-openhab-objects-and-sync-them-to-yaml-files/129824

That way you have the YAML files (one by entity, organized in folders) on your actual filesystem and can use a "real" editor that would have features an IDE-like in the UI could not match, as well as the option to source control them.

One other route I explored was a virtual file system for VS Code itself:
openhab/openhab-vscode#257

which is pretty much what you describe but in VS Code itself (for instance, "saving" the file would call the API to save it on the server).

I believe the UI is nice for light editing and the occasional mass addition, but not everything has to be crammed into it.

[digitaldan]

One other route I explored was a virtual file system for VS Code itself:
openhab/openhab-vscode#257
which is pretty much what you describe but in VS Code itself (for instance, "saving" the file would call the API to save it on the server).

Wow, thats exactly what i was imagining, but you beat me to it by many years ;-)

That was an idea I had for a long time but finally decided what I needed was something like my "ohadm" script:

Huh, i had not seen that before, super interesting.

[florian-h05]

One other route I explored was a virtual file system for VS Code itself:
openhab/openhab-vscode#257
which is pretty much what you describe but in VS Code itself (for instance, "saving" the file would call the API to save it on the server).

Looking at the PR, that‘s sounds really great. Would be a huge help for mass-editing, and we wouldn‘t have to reinvent the wheel by using VS Code (instead of putting something like this inside the UI).