I talked to Warren Buckley about how to approach filtering languages in the backoffice, based on user permission or user types.
What I'm trying to accomplish is:
Everyone should be able to see the values in the default language (English)
Editors and Admins can see and edit values in every language
Translator A can edit ZH, KO & JA
Translator B can edit ES, FR, DE & IT
Translator C can edit AR
My thought was a relation between users and languages - Since this is not possible with Umbracos RelationType, I created a custom table for storing these.
On Vorto's FilterLanguage event, i check the usertype and look in the DB for the users languages
Vorto.FilterLanguages += (sender, args) => {
if (UmbracoContext.Current.Security.CurrentUser.UserType.Alias == "translator")
{
var languageList = applicationContext.DatabaseContext.Database.Fetch<string>("SELECT umbracoLanguage.languageISOCode FROM User2Language INNER JOIN umbracoLanguage ON User2Language.languageId = umbracoLanguage.id WHERE (User2Language.userId = " + UmbracoContext.Current.Security.CurrentUser.Id + ")");
args.Languages.RemoveAll(x => !languageList.Contains(x.IsoCode));
}
};
It does work, but the downside is theres no configuration UI for relating users to languages.
This is exactly the kind of thing that the FilterLanguages event is there for, so you are definitely going the right way. What is the reason for not using Relations? Are umbraco languages and umbraco users not both nodes? (I thought that was the only requirement, that they had to be nodes).
I guess for the UI, you have a few options. Simplest might be to create a dashboard control so you can manage the mapping of the translators to their languages, or you could create a custom tree in the users section which might be nicer. Or maybe even a new context menu item in the users section, similar to the hostnames dialog on content, you could right click on users and assign languages to them in a custom dialog (I'd probably do this one myself).
The last option could be to extend Vorto and do it in the prevalue editor, but that doesn't sound very discoverable for setting them up, it seems like it should be something that happens in the users section to me.
I don't think they are, i can't choose them when creating Relation types
I didn't consider context menu items, but it sounds like a good idea
Regarding read-only languages, i think it should be possible to do something similar to how i did RTL ( https://github.com/mattbrailsford/Vorto/pull/15/commits ) by setting an attribute or class in the Vorto view, and reading that in my custom property editors
Different languages for backoffice users
(Continued from Slackchat)
I talked to Warren Buckley about how to approach filtering languages in the backoffice, based on user permission or user types.
What I'm trying to accomplish is:
Editors and Admins can see and edit values in every language
Translator A can edit ZH, KO & JA
My thought was a relation between users and languages - Since this is not possible with Umbracos RelationType, I created a custom table for storing these. On Vorto's FilterLanguage event, i check the usertype and look in the DB for the users languages
It does work, but the downside is theres no configuration UI for relating users to languages.
This is exactly the kind of thing that the FilterLanguages event is there for, so you are definitely going the right way. What is the reason for not using Relations? Are umbraco languages and umbraco users not both nodes? (I thought that was the only requirement, that they had to be nodes).
I guess for the UI, you have a few options. Simplest might be to create a dashboard control so you can manage the mapping of the translators to their languages, or you could create a custom tree in the users section which might be nicer. Or maybe even a new context menu item in the users section, similar to the hostnames dialog on content, you could right click on users and assign languages to them in a custom dialog (I'd probably do this one myself).
The last option could be to extend Vorto and do it in the prevalue editor, but that doesn't sound very discoverable for setting them up, it seems like it should be something that happens in the users section to me.
Matt
I don't think they are, i can't choose them when creating Relation types
I didn't consider context menu items, but it sounds like a good idea
Regarding read-only languages, i think it should be possible to do something similar to how i did RTL ( https://github.com/mattbrailsford/Vorto/pull/15/commits ) by setting an attribute or class in the Vorto view, and reading that in my custom property editors
is working on a reply...