It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,874
×4,713

question asked: Mar 15 '13, 7:32 a.m.
question was seen: 3,848 times
last updated: Mar 19 '13, 11:15 a.m.

Related questions

How can I set separate permissions for "Everyone" defined on the accesstab than for any ProjectArea Member

2
Guido Schneider (3.4k●14●91●115) | asked Mar 15 '13, 7:32 a.m.
edited Mar 17 '13, 5:15 p.m.

If a User gets access to a project are by definitions done in the access tab of the project area admin page, (either with the setting Everyone allowed or by explicitly add the user to the Access-Userlist), this user will become the builtin role "Everyone" and with this the permissions defined for "Everyone".

Users which are member of a teamarea in the projectarea itself, but are not member of the ownerteamarea which owns a particular workitem, will also get the role "Everyone" for this workitem.

Is it possible to differentiate between users which having access to a workitem because they are member of the projectarea somewhere and users which get access just over the Access tab?

BTW: The description on the access tab gives the impression, the Everyone right or the userslist gives only  Readonly access. But this is not true. This description should be explicitly tell that all this users will become the Everybody rpermissions and not only read only.

AddOn:

I try to explain:
- Person A, is Member of Teamarea T1 in Projectarea P1. He is NOT member of any other Teamareas.
- Person B has access to P1 defined in the userlist of the Access tab of P1 Adminpage, but he is NOT member of any teamarea of P1 nor the P1 itself.
- Workitem W1 is filed agains a category which is associated to another Teamarea T2.

If Person A access the Workitem W1, he get's the permissions defined for builtin role EVERYONE
If Person B access the Workitem W1, he get's also the permissions defined for builtin role EVERYONE.

Question, is it possible to define different permissions for a person, which is member somewhere in the projectarea where the workitem belongs to, than for a person who get's access to a workitem just because of the access tab of the project admin (e.g. userlist or everyone read etc.) 

Comments
Geoffrey Clemm commented Mar 16 '13, 2:47 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Can you expand on what you mean by "differentiate" ?
Permission is normally a binary thing ... either someone has permission to do something, or they don't.

Guido Schneider commented Mar 17 '13, 5:13 p.m.

That's clear.

I try to explain better in the question.

Erwin Kunz commented Mar 18 '13, 3:38 a.m.

In addition; or as clarification. On the PA Access Control tab you can add People to the Access List, which based on the text should get READ ONLY Access!
But actually they get the EVERYONE Role what is definitively not read only.
Did I miss something?

Access Control
Help
Configure which users have read access to the project area and its artifacts. If you grant access to members of the project area hierarchy, anyone who adds a member to any team will implicitly grant access to the entire project. For strict control, grant access to users in the access list only. Note that repository administrators will always have access.

Accepted answer

1
permanent link
Jared Burns (4.5k●2●9) | answered Mar 18 '13, 1:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The short answer is no. If permissions are granted to Everyone it really just means everyone.

In your case, it sounds like you're looking for an implicit "member" role on the project or team area that you can grant permissions to. We've seen this request before (e.g. workitem 88963), but we haven't implemented it for a couple reasons: 1) exactly how this would be interpreted is up for debate and we already have enough complexity with role inheritance and 2) there are a number of requests out there for implicit role (e.g. 'creator', 'owner', 'author', 'admin'...) and as we go down this path we see that the semantics for these roles isn't really consistent/clear. So we instead have just stuck with our simple model of explicitly assigned roles.

The recommendation is to create your own 'team member' role and always assign it to people who should have permission.

There's another point that's come up in this discussion - "read access" versus "read only". It sounds to me like the terminology is unclear. If I can try to clarify what we mean:
  • "read access" means "you have permission to read data". This is a statement about read permissions only. It makes no statement about write permissions.
  • "read-only" means "you only have permission to read data". This is a statement about both. You have read permissions and you don't have write permissions.
Guido Schneider selected this answer as the correct answer
Comments
Guido Schneider commented Mar 19 '13, 9:12 a.m.

Thank you Jared!

I think this discussion was very usefull to understand better how the permission is working and specialy to show what Everyone means. Many people think the users on the access list have Read-Only permission, but they have Everyone.

The explanation about read access and read-only is very helpfull for a non-native english speaker.

1
Ralph Schoon commented Mar 19 '13, 11:14 a.m. | edited Mar 19 '13, 11:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Hi Jared, thanks for stepping up and Guido for asking. I think however Guido is up to something that bugged me a lot in the past and I just right now see as being troublesome. I have seen that a couple of times. It is somehow interwoven with Guidos question. So here goes:

  • For planning I need users to be members in a team are
  • To be able to create work items everywhere I would need them to have a role in the project (or role everyone opened up)
  • Since permission goes up in the team area hierarchy this seems to be the only way.

So I end up to add the users at least at the project area level with a common role or opening up everyone. Which is exactly the role users without project or team membership at all have.

So I kind of would like to have an automatic role like Everyone (team member in the project) and a role Everyone (Everyone else). It is sort of similar to Guido's thought but more limited in scope. But it would allow to better control and distinguish project users and external users. And I wouldn't have to add users on different levels. Does that make sense?


Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.