Assign multiple roles to same person

[stefan....@gmail.com]

Is it possible to assign multiple roles to the same person (e.g. product owner and back)?

[Alejandro Alonso]

Hello Stefan,

Actually it's not possible, roles are only related to permissions in Taiga so as a workaround you could create a new role including the permissions from both roles.

Regards,

2015-04-15 16:16 GMT+02:00 <stefan....@gmail.com>:

Is it possible to assign multiple roles to the same person (e.g. product owner and back)?

--
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To post to this group, send email to tai...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/6cdc9ae2-c1a2-4341-9838-e6826b43399d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alejandro Alonso Fernández   CIO & Co-founder alejandr...@kaleidos.net  | Tel: (+34) 627263808 | (+34) 913562995 www.kaleidos.net/FC8EAC/

[p...@joinoutset.com]

Actually it's not possible, roles are only related to permissions in Taiga so as a workaround you could create a new role including the permissions from both roles.

That's a bummer :( ... but completely reasonable explanation. At my last job we had a similar problem and ended up implementing a system that would take the simple union of all permissions from each of the user's "security groups". So if a user has roles "A" and "B", and has permission to do "X" in role "A", and does not have permission to do "X" in role "B", the end result would be the the user DOES HAVE permission to do "X"

I don't see too much of a need for this in the current state of the product, but down the line, I could foresee a need to have tasks categorized by role, with associated filtering, and the like. Since not all teams have a strict separation of roles, a single developer may be both UI/UX and Frontend, and would like to see and do things relevant to each role.

I love the role system you've put in place, but worry that it could be over limiting down the line

[Alejandro Alonso]

Thank you very much Pat, I agree with you, the actual system could be over limiting in the future and probably we will have to improve it soon.

I don't see too much of a need for this in the current state of the product, but down the line, I could foresee a need to have tasks categorized by role, with associated filtering, and the like. Since not all teams have a strict separation of roles, a single developer may be both UI/UX and Frontend, and would like to see and do things relevant to each role.

I think this sound more like tagging tasks than filtering by role, did you try using tags?

Regards!,

[Patrick Fowler]

I think this sound more like tagging tasks than filtering by role, did you try using tags?

Tags are great and I have been using them extensively - but in the realm of roles, I could see the need for a more restricted/integrated setup. I could imagine a mechanism similar to the role-based story points : When creating a task, you could create a task for a specific role. For example a Story about displaying to-do items could have a "Back" tasks to create a CRUD api, a "UI/UX" to design and mockup the interface, a "Front" task to build the HTML and necessary controllers. That would open up to a "role based view" where the front-end developer would login, and see all the front-end tasks that are ready for dev : i.e.: a view of the "most relevant" tasks for that developer. But that is down the line a bit.

A simpler setup that would be helpful is having additional restricted Custom Field types: "Scoped" tags (would limit tag auto-fill to only that field) , or Enum ( eg: Having a "Persona" field, with a pre-defined list of options ). But that's a whole other discussion :)

Loving the product, and so is my small distributed team. Looking forward to contributing more to the discussion, and hopefully the code down the line.

[Alejandro Alonso]

Hello Patrick,

Tags are great and I have been using them extensively - but in the realm of roles, I could see the need for a more restricted/integrated setup. I could imagine a mechanism similar to the role-based story points : When creating a task, you could create a task for a specific role. For example a Story about displaying to-do items could have a "Back" tasks to create a CRUD api, a "UI/UX" to design and mockup the interface, a "Front" task to build the HTML and necessary controllers. That would open up to a "role based view" where the front-end developer would login, and see all the front-end tasks that are ready for dev : i.e.: a view of the "most relevant" tasks for that developer. But that is down the line a bit.

I'm adding your idea a possible enhancement for Taiga so we can track the feedback we receive about it and study if it can be included in Taiga core -> https://tree.taiga.io/project/taiga/issue/3072

 

A simpler setup that would be helpful is having additional restricted Custom Field types: "Scoped" tags (would limit tag auto-fill to only that field) , or Enum ( eg: Having a "Persona" field, with a pre-defined list of options ). But that's a whole other discussion :)

The actual implementation of the custom fields was the MVP we could imagine about them, we wanted to wait for feedback from our users to check how they are using it. We plan to add different type of fields (date, list, number), validators, required...

 

Loving the product, and so is my small distributed team. Looking forward to contributing more to the discussion, and hopefully the code down the line.

Thank you very much, all your feedback, comments, ideas or code are welcome! :)

Regards, 

[Adam Spiers]

Hi all,

I realise this thread is 6.5 years old, but I'd love to know the latest status on support for assigning multiple roles to the same person!

I'm currently evaluating Taiga for our dev team as a much-needed escape route from Asana, and this is one of the aspects of Taiga's model which on the surface seems like a limitation we would probably suffer from.  Many members of our team wear multiple hats, in different combinations - therefore the workaround of creating roles which encapsulate combinations of roles could result in a miniature combinatorial explosion of roles.  For example, even with three "base" roles, we'd need all of these to cover the combinations:

- UI

- API

- smart contracts

- UI + API

- UI + smart contracts

- API + smart contracts

- UI + API + smart contracts

But we have several more roles, so clearly this could get ugly very quickly.

Furthermore, if we used this workaround, then when doing estimation for a given story, if we assign (say) 2 story points for UI and 3 for API, then presumably Taiga will not understand the link between those two base roles and someone with the combined "UI + API" role.  So it seems to me, as a Taiga novice, that this is somewhat of a non-starter.  But if so I would have expected many people to feel the pain of this limitation, so maybe by now either there's a good solution, or I'm missing some fundamental piece of info which explains why this isn't actually a big problem?

One more question:

On Monday, 20 July 2015 at 08:19:57 UTC+1 Alejandro Alonso wrote:

Hello Patrick,

Tags are great and I have been using them extensively - but in the realm of roles, I could see the need for a more restricted/integrated setup. I could imagine a mechanism similar to the role-based story points : When creating a task, you could create a task for a specific role. For example a Story about displaying to-do items could have a "Back" tasks to create a CRUD api, a "UI/UX" to design and mockup the interface, a "Front" task to build the HTML and necessary controllers. That would open up to a "role based view" where the front-end developer would login, and see all the front-end tasks that are ready for dev : i.e.: a view of the "most relevant" tasks for that developer. But that is down the line a bit.

I'm adding your idea a possible enhancement for Taiga so we can track the feedback we receive about it and study if it can be included in Taiga core -> https://tree.taiga.io/project/taiga/issue/3072

This link no longer works, even though the prefix without the number still seems valid.  Is this still available somewhere?

Thanks a lot!