The "Container Path: /mnt" line actually bears absolutely no relationship at all to either the container path (or the host path).

 

It's rather the description you've given it.  In absence of a description being given when adding a new path, it uses the container path.  But, when editing an existing path the description already does exist and the system keeps the description (But you can edit it all day long)

The description/label I've given is "Mnt". I did not change that. I'm not talking about that.

 

I'm talking about "Container Path" and "Host Path". I did change both. The modified  "Container Path" is not reflected on the Container page.

 

Please look again.

 

No.  You've given it a Name of Mnt  The description is what you're seeing that's not being updated.  If no description is present, then the system populates the description after saving with the container path.  If the description already exists, then the system does not update it.  You see this on many good templates where the author goes to the extra step and tells you what the path is actually for, not simply "Container Path: xxx"

OMG, I do see it now. It's the description field.

 

IMHO, this should be changed at least for "Config Type=Path" to reflect the correct labels and values. If I change a field labeled "Container Path" on the edit window, I do expect to read that value on the container page behind the label "Container path" and not the content of the field "description". This will lead to massive misinterpretation.

 

There are IMHO two possible options:

 

1.) On Container page write "Description: <value of description field>"

 

2.) On Container page repeat the correct value and label from the edit wiindow (e.g. "Container path: <value of container path field>" at least for "Config type=Path".

 

Just my 0.02 USD.

 

I know what you're saying, and I'll look at the coding on the weekend.  What the system should do is not by default populate the description ever unless the user / maintainer does it themselves, but on the edit template screen show the container path if there's no description present.

40 minutes ago, Squid said:

What the system should do is not by default populate the description ever

 

No the current behavior is correct. The description is automatically generated based on the given input and this description is displayed under the key value. It is always possible to update the auto-generated description afterwards.

 

The description itself has no influence on the field, it is not used by Docker, but serves purely as extra help.

57 minutes ago, bonienl said:

The description itself has no influence on the field

 

But the description content is not labeled "Description". It's called in some cases as another field. And that's terrible.

 

Please step a little bit back and see the system from the view of a novice. They are used to e.g. Windows. If there's a field you can change, than that field has the same label on many, if not all, windows. Here's "Container path". Both windows have a label "Container path". But on one windows it is an entryfield, and on another window it's a description somebody else entered. In that case it's a must to label that field Description on the Docker Window. Everything else leads to confusion.

 

Honestly, I disagree @bonienl  Not saying that having it auto generate isn't a bad thing.  Just saying that it should generate it on the Edit Template Screen if there's no description in the system and not update the actual Description entry until the user actually enters something in there.  Net result is the same, but it keeps it up to date with the Container Path if no description is present, but still allows a description to override everything.

When a description is (already) given then auto-generate isn't done, in other words an existing description is never overwritten unless the user makes changes.

 

What is the actual problem? The fact that the description isn't automatically updated or that it isn't clear that it is just a description?

 

In my opinion we are talking here about a feature request and not a bug.

 

3 hours ago, bonienl said:

In my opinion we are talking here about a feature request and not a bug.

 

 

Correct. It's a feature request to fix something that NEEDS to be implemented because the current implementation, at least in one configuration (here: Config types=path), may lead to terrible and confusing results.

 

Will add a detailed feature request tomorrow morning.

 

Never meant to imply to it was a bug, as I know it's not as per my first response.