Alternative to dictionary item field

[bjarnef]

Although creating a dictionary value for some properties might work and is great, I am not sure if it is ideal for some properties, e.g. to specify a path or selecting a template/view or for setting a url (in payment providers).

I think it also could end up with many dictionary items, where some editors have access to manage dictionary items, but we don't want editors to modify configuration of e.g. template view in email templates or return urls in payment providers.

For e.g. template view it could use file picker (it is possible to configurate is to e.g. have /views as start node and also filter which file types are allowed to select).

This could be used for email template views, order editor config, etc.

If these need to support multiple languages (which it probably should), then these should maybe open an overlay with the option to configurate it per language (or invariant?) - maybe it dictionary collection, where key is the culture code and value the template, url, etc.

[mattbrailsford]

Yea, the difficulty here is that it would then need a bespoke culture-variants facility building in. TC does it, but it’s not very good imo with the culture tabs. The aim of the dictionary input is to try and reuse core functionality. I know it’s not a perfect solution but it avoids a lot of wheel reinvention.

[mattbrailsford]

Maybe the question here is should the core dictionary service be improved for more structured data?

[bjarnef]

Yes my concern about this is that editors sometimes have access to dictionary items in translations section - especially now where it isn't required, it to be located under settings section.

The benefits with dictionary items are also that they can be re-used, but not sure how much it these will we re-used.

For example for email templates it does make sense to use dictionary items for subject and sender name, but it doesn't seems right the add a dictionary items for sender address (email) where the dictionary item doesn't have validation for this should be a valid email address.

Not sure if it would be possible to add a editor, which has culture as key and an value (editor view - this could maybe re-use core property editors like email address, textbox, textarea, decimal, numeric).
This might be a bit more complex, but I think it would improve the editor experience.

[mattbrailsford]

Yea, it could be possible to use custom editors to manage the values, but like I say, that could do with some core support as if I implement it in the dialog you could bypass it via the actual dictionary section.

If everyone agrees the dictionary is the wrong place to store this stuff though then I guess it’s irrelevant as it would all need an entirely custom solution.

Could be done but it isn’t a small task.

Ultimately the question is, is it good enough? Or is it just not fit for purpose? (Remember, in TC all payment provider settings are all string inputs).

[bjarnef]

The main concerns I have for using dictionary items for storing these settings, are that they are accessible for editors who have access to Translation section, so they could potential break stuff if they make a typo or by accident edit one of these dictionary items for configuration.

Furthermore as dictionary items works in Umbraco core at the moment, it doesn't validate the value to the expected format, e.g. an email address.

Not sure if Tea Commerce allowed to use dictionary items in these settings.

I know it probably is a large task to change and the current setup with dictionary items might work. I just wanted to bring this up to consider if there is a better way to handle this and avoid editors to break stuff (not on purpose, but by mistake).

[bjarnef]

Maybe the dictionary icon should also open a overlay to select an existing dictionary item or create a new one (not sure if you always want to create a new?).

[mattbrailsford]

@bjarnef I think that's probably best discussed in another issue and this one is kept focused on whether to actually use the dictionary input or not, unless you are saying that those changes would make it a more acceptable solution, which I don't think is the case here.

[bjarnef]

@mattbrailsford I have created another issue for that https://github.com/vendrhub/vendr/issues/19

[bjarnef]

Another challenge with the dictionary items in these settings is that we can't have e.g. email regex validation on e.g. Sender Address field in email templates, because it is allowed to use a dictionary item and in when creating/saving the dictionary item value for each culture, it hasn't validation for the expected format.

The dictionary item is great for e.g. Subject Line and Sender Name, but I guess not ideal for settings which need to be in a very specific format/type, while it works well for translations of labels.

It probably requires some large changes, but maybe a custom property editor to edit the value per culture and where it could re-use core datatypes (property editor). Probably a limited list of core property editor to re-use:

• Umbraco.Label
• Umbraco.Integer
• Umbraco.Decimal
• Umbraco.EmailAddress
• Umbraco.DateTime
• Umbraco.TextBox
• Umbraco.TextArea

Maybe more if it makes sense, but probably not complex property editors like Umbraco.Grid and Umbraco.ImageCropper.

I think this would improve the editor (developer) experience in backoffice, ensure correct input and prevent editors who have access to dictionary items to change these important settings (where the not have access to settings section.

[mattbrailsford]

I do understand all the concerns and the restrictions that the dictionary field imparts, but I'd really like to start hearing ideas though on what an ideal solution would look like. When I was thinking through this I had 3 options.

1. For any entity that has translatable settings, create a "content app" tab that lists all the languages and for each one you can go in and prove the values appropriate to that language. This was the approach I started down, but it also started to feel cumbersome, and not really consistent with Umbraco.

2. Something kind of Vorto like, providing inline language switching abilities. Being the dev behind Vorto though, I know the difficulties this solution has and it's not ideal, and again the UI would be consistent with Umbraco.

3. Try and implement something that acts the same as content language variants where the languages are listed in the title bar and you can switch between them, updating the editor UI to be for a specific language with non variant properties becoming grayed out if not on the primary language. This one feels the most Umbraco, but it's also potentially the most work and probably likely to hit conflicts in trying to make the Umbraco angular directives work in a way they weren't meant to work.

Option 1 is probably somewhat the simplest, but option 3 would probably be the best fit. None of these are a small amount of work however and it's a question of whether any of these are achievable by the March launch deadline.

I'm open to other suggestions.

[bjarnef]

@mattbrailsford yes, the suggestion I outlined is probably a bit similar to Vorto and something like this format for each of these settings properties. Not sure if we need the "editor" property in the json - this is just an example :)

[
  {
    "language": "da",
    "value": "test@mail.dk",
    "editor": "Umbraco.EmailAddress"
  },
  {
    "language": "en",
    "value": "test@mail.com",
    "editor": "Umbraco.EmailAddress"
  }
]

The issue I see with dictionary items is that some editors have access to these, so they can potentially break functionality in the store. Furthermore we don't get the nice validation and property editor fitting the expected value for the specific setting.

[bjarnef]

@mattbrailsford I wonder if we have other options now the something similar to the block editor structure. Also segments are available via API in Umbraco v8.7, but I guess it is only available with content (not sure if it possible to use with custom data).
Mayve HQ have some further insights how we can improve this? I would really like the settings for Vendr core, payment providers, etc. which are crucial to the functionality not are handled via dictionary items.