Open njohner opened 6 years ago
I've started working on this issue. I've added support for identifiers of the type orgunit:userid
in the ActorLookup
class, and storing the orgunit
in UserActor
s:
https://github.com/4teamwork/opengever.core/compare/nj_actor
If we want to have all the logic handled by the ActorLookup
and the different Actor
classes, we would need to have a unified interface for the different Actor
classes. As it seems we mainly use these classes to generate vocabularies of possible values, so I think that with the label
attribute and representatives
method we should be able to cover most cases.
I think that for a case like this one here, it should be not too hard to have all the logic in the actor classes: https://github.com/4teamwork/opengever.core/blob/master/opengever/task/util.py#L203
But for this one here: https://github.com/4teamwork/opengever.core/blob/master/opengever/ogds/base/sources.py#L191
I'm not sure whether the implemented representatives
would retrieve the same users as the sql query.
m.E. wäre es sinnvoll, wenn wir hier zuerst die API Support Arbeiten im Aufgabenmodul abschliessen ( #4786). Deshalb --> 2019.2
For sure no point in doing both in parallel...
Conditionals to correctly treat users with a orgunit specification are spread throughout the
Task
code. This should be managed by theActor
class instead.See for example: https://github.com/4teamwork/opengever.core/pull/4483 https://github.com/4teamwork/opengever.core/blob/master/opengever/task/util.py#L203 https://github.com/4teamwork/opengever.core/blob/master/opengever/ogds/base/sources.py#L191