Description of problem: oVirt/RHEV project is on translate.zanata.org, as the engineering team would like to maintain the translation project for both upstream/downstream in a single, external location. This allows anyone who has an account, and is a member of a specific language team to edit translations and could possibly have some negative impact on our translation work (e.g. our translations may be changed without us being aware of). I am wondering if Zanata can have a feature to control the user permission to edit per project basis. Version-Release number of selected component (if applicable): 3.6.2 How reproducible: 100% Steps to Reproduce: 1. Log in to translate.zanata.org 2. Make sure that you are the member of the language team 3. Pick a random project and try to edit Actual results: It allows editing by any member Expected results: It is preferred to have an option to restrict members Additional info: Spoke to Carlos about this about a year or two ago, and he is aware of our requirements.
By the way, is there a filter in zanata to search the strings modified by users other than a specific user? I know one filter which is "last modified by" but to use that we need to know the specific user names which is not always possible.
Yuko, Thanks for bringing this up. Just to understand your requirements : - First comment This is related to organisation request in https://bugzilla.redhat.com/show_bug.cgi?id=1200250 which allow to have restriction on access for translation, either by organisation, or by project. We are still trying to work out the details for this feature at the moment but it is one of our high priority. - Second comment, We don't have that filter yet. As you said, Zanata can search by specific user, but not a group of users. Can you please describe how are you using it?
Hi Alex, Thank you very much for your prompt reply. Good to hear that your team has already been working on it as high priority. As with your question on my second comment, the possible use case would be for a translator who is working on a particular project to check if other translators have edited his/her project, without specifying the names (as we do not always know who that can be). It can be something like google search with a minus (-) to exclude own username. (Last modified by translators other than <user>)
Hi Yuko, As Alex replied, user access control per project is something we are trying to implement in next quarter as a top priority. It is good to get your insight and feedback for this feature. We will keep you informed when we have more details. For the filtering, do you think we should create another RFE since it seems it is not related to the title of current issue. For filtering, you are requesting to find out the list of translators who have worked on the same project other than yourself, am I correct? Cheers, Michelle
(In reply to Michelle Kim from comment #4) > Hi Yuko, > > As Alex replied, user access control per project is something we are trying > to implement in next quarter as a top priority. It is good to get your > insight and feedback for this feature. We will keep you informed when we > have more details. > > For the filtering, do you think we should create another RFE since it seems > it is not related to the title of current issue. For filtering, you are > requesting to find out the list of translators who have worked on the same > project other than yourself, am I correct? > > Cheers, > Michelle Hi Michelle, Thanks for your reply and prioritizing this request. Greatly appreciated. I will be happy to provide you my feedback when you need it. With the filtering, yes, that's what I wanted. I will log a separate RFE for that. Cheers, Yuko
Michelle, should we incorporate this into the Organizations feature?
Carlos, Yes I believe this is related to Organization Feature. I just wanted to make sure that our new feature includes this RFE in its implementation. Thanks for the suggestion and let's make this as part of the org story. We will need to make sure to break down the organization feature into multiple sub stories starting from bare minimum feature to additional nice to features.
correcting a type on my previous comments s/nice to features/nice to have features
I would like to use this RFE to create the following new feature: 1. Ability to create a project/version that is private (only visible/editable to certain group of translators) - Private Project with dedicated team (translators) 2. Ability to create a project/version that is public to view but editable by certain translators 3. Ability to create a translation team and assign/approve/remove translator from the team list. For example, a user creates a project called "A" and make the project "viewable" by all but "editable" by A team(x, y, z translators). So other translators able to view the project in the project list but won't be able to edit. The user will have to apply to become part of A team to be able to edit the file. Carlos, Can you please let me know if this is something we can start estimatining as an initial feature before Organization RFE gets finalized? Thanks, Michelle
Just removing "Version" from my previous requirements. I would say just "Project" level Access Control would be sufficient. Project Setting View - Private (Hidden from the view) / Public Edit - By Team / By All
(In reply to Michelle Kim from comment #10) I'm adding Luke to the cc list as he has been looking at the Organizations implementation and this is a real requirement that could potentially be related to that. Here is my take on these: > I would like to use this RFE to create the following new feature: > > 1. Ability to create a project/version that is private (only > visible/editable to certain group of translators) - Private Project with > dedicated team (translators) > > 2. Ability to create a project/version that is public to view but editable > by certain translators This implies the concept of a 'Team' of translators for a project. > > 3. Ability to create a translation team and assign/approve/remove translator > from the team list. Could this be a separate step? I mean, we can initially implement a project team, and then further down the line we can implement custom teams that may be assigned to projects as a maintainer sees fit. > > For example, a user creates a project called "A" and make the project > "viewable" by all but "editable" by A team(x, y, z translators). So other > translators able to view the project in the project list but won't be able > to edit. The user will have to apply to become part of A team to be able to > edit the file. > > Carlos, > Can you please let me know if this is something we can start estimatining as > an initial feature before Organization RFE gets finalized? > > Thanks, > Michelle
(In reply to Carlos Munoz from comment #12) > (In reply to Michelle Kim from comment #10) > > I'm adding Luke to the cc list as he has been looking at the Organizations > implementation and this is a real requirement that could potentially be > related to that. > > Here is my take on these: > > > I would like to use this RFE to create the following new feature: > > > > 1. Ability to create a project/version that is private (only > > visible/editable to certain group of translators) - Private Project with > > dedicated team (translators) > > > > 2. Ability to create a project/version that is public to view but editable > > by certain translators > > This implies the concept of a 'Team' of translators for a project. Yes, so if project maintainer creates a project, they can decide if the project will be private or public. Once they decided to make the project private, they should be able to decide: The project is still viewable or hidden from the public view And create a project team who can translate the project. This would be the scope of this RFE. Do you think we need to seperate the feature adding a team ? > > > > > 3. Ability to create a translation team and assign/approve/remove translator > > from the team list. > > Could this be a separate step? I mean, we can initially implement a project > team, and then further down the line we can implement custom teams that may > be assigned to projects as a maintainer sees fit. Agreed. Let's focus on project team creation and create new RFE for custom teams. > > > > > For example, a user creates a project called "A" and make the project > > "viewable" by all but "editable" by A team(x, y, z translators). So other > > translators able to view the project in the project list but won't be able > > to edit. The user will have to apply to become part of A team to be able to > > edit the file. > > > > Carlos, > > Can you please let me know if this is something we can start estimatining as > > an initial feature before Organization RFE gets finalized? > > > > Thanks, > > Michelle
I created new RFE to create "customer teams" to be able to link the team to projects. I believe having a feature to create team is a pre-requisite before being able to implement "Private" project story. https://bugzilla.redhat.com/show_bug.cgi?id=1234706
Notes from Dev meeting: Project teams. Teams have roles: - Project Maintainer - Translation Manager - Translator (for language) - Reviewer (for language) If a project defines translation permissions, only those permissions apply. Otherwise, global permissions apply. The API should respect the same permissions.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-524