1) You can create or modify any existing role to include termbase editing. If the users are in the root, they will be able to modify any TB in any org.  Usually  the translator role is able by default to edit, create and delete TB.  Therefore, they will be able to edit terms in MT desktop even if its not an active project published.

2) Power user can edit TB yes but it seems overkill.

3) This is what we do here. We removed the TB permissions (except view) of the translator role and created a new role called TB editor. We then added that role to selected users.

4) Power user will prevail.

Hi Vincent, 

Thank you for your reply.

Yet I'm stil puzzled a bit as I can't find more concrete info about setting the Termbase Editor right in the documentation.

Could you be so kind an tell me what other resources need to be selected in the Termbase section in for the new Multterm Editor role.

Currently my settings for translator are like this.

Thank you

Ours is basically this for MT editor: 

Hi Vincent

Thank you for the hint. I've set it as you suggested but still it's not working on some termbase.

I didn'nt figure it out what combination of GroupShare permissions and Multiterm Admin term base settings makes the Multiterm Desktop show: this status bar notice:
"Termbase not editable. Source Language is Not Writable. Target language is not writable."

It seem I need to take more time and read the complete two sections in the Multierm documentation: 

Manage user actions over a server-based termbase

https://docs.sdl.com/LiveContent/content/en-US/SDL%20MultiTerm%20Help-v4/GUID-D38E366D-03C2-4F36-A3C5-D336DD3032C3#addHistory=true&filename=GUID-CE3BE970-E3BF-4F27-96B0-32BDA50F1815.xml&docid=GUID-B06D0C7F-E6DF-4C4A-A545-51E68C254D81&inner_id=&tid=&query=&scope=&resource=&toc=false&eventType=lcContent.loadDocGUID-B06D0C7F-E6DF-4C4A-A545-51E68C254D81

and 

Manage MultiTerm restrictions

https://docs.sdl.com/LiveContent/content/en-US/SDL%20MultiTerm%20Help-v4/GUID-D38E366D-03C2-4F36-A3C5-D336DD3032C3#addHistory=true&filename=GUID-CE3BE970-E3BF-4F27-96B0-32BDA50F1815.xml&docid=GUID-51F82A8B-0E9C-4237-9066-97DC0F0E8D71&inner_id=&tid=&query=&scope=&resource=&toc=false&eventType=lcContent.loadDocGUID-51F82A8B-0E9C-4237-9066-97DC0F0E8D71

:-\

This is weird. Does it show this on the majority of the termbase? Usually no error message will show up if there are multiple permissions. 

Can you send a screenshot?

I'd say just create a new role for the people you want to edit TB and remove the old roles they were assigned.

The behavior is indeed wired. 

I have a training TB, for which just can't get rid this status bar notice:
"Termbase not editable. Source Language is Not Writable. Target language is not writable."

User is added to the termbase, the permissions are set through a GS2017 permission group Multiterm Editor and by creating a copy of Expert user restriction in Multiterm administrator.

I'll do some more test in next days to see if I can figure it out.

This post is just to add a bit of information if somebody else is struggling with permissions on Multiterm Server termbases. 

I believe the issues experienced are caused by a "bug" or "bad design" of GroupShare Permissions module where default setting is that user permissions  can be assigned only relative to organizations and are expected to be inherited to Libraries.

But this, at least for GS 2017 is not the case. 

The fact that there  is a "bug" or  "application design issue" is  quite easy to spot.

Resources > Termbases   

then in the Filter dropdown box select the suborganization you want to look in. 

In my example bellow, if I select Gamma I can see the termbases locate in the root of Gamma organization (there are none here) where I cannot see the termbases located in the Library named Terminology.

The workaround here is to go to the Users unit, select the Permission and then click the Suborganization Library (highlighted yellow) for which you want to set the permissions. 

Here you assign the required permissions to the user.  

Simon