Community
Participate
Working Groups
This is a UI issue....The current Service property page (and the corresponding wizard page when creating a new connection) shows subsystem configuration IDs in the "Configuration" section. This is non-intuitive for the user.
RSE should show the "name" field for the subsystem configuration instead.
Do we agree that we want the "name" instead of the "id" ?
As it stands right now the names of subsystem configurations are not guaranteed to be unique. For example, the FTP "Files" subsystem configuration and the DStore "Files" subsystem configuration are named the same. It's also quite likely that they will be the same too since this is what we display in the tree for the subsystem.
Created attachment 104378 [details] proposed patch to display label instead of id Here's a patch I'm proposing where a new label field is required for a subsystem configuration. Any thoughts?
Created attachment 105830 [details] updated patch I updated a couple things in the patch.
Let me know what you think of the patch. The label attributes for subsystem configurations would need translation although "label" is an optional attribute, so the fallback would be to use the id as it does now.
Strictly speaking, your proposed patch is [api][breaking] because ISubSystemConfigurationProxy is not marked @noextend -- an extender could implement ISubSystemConfigurationProxy directly, and break by your addition of the #getLabel() method. The second problem is that you are adding pii, and while you're right that the plugin.xml's label field is optional with fallback to the ID, your patch adds a translatable label for "Local Files" for instance, so if the additional pii is not translated users would now see "%localFilesLabel" rather than "local.files" which they see now. This is a corner case though, and if you think you must have the fix in 3.0.1 then I'd guess it is possible to change the patch in a way that makes it "API compatible". But that's considerable effort. In my personal opinion, the issue is minor anyways so I'd prefer deferring it to 3.1 -- Ankit, you're the original submitter, what do you think? Is it OK for you to move severity to "minor" ? The current ID's that we have are not too bad, are they?
Ankit, could you respond to comment #7? Is this needed for 3.0.1 or can it wait til 3.1?
Please check whether this is still possible in 3.2 or needs to be deferred to the next release due to breaking API changes.
Moving deferred 3.3 api items to 3.4
We are post API freeze.
