4teamwork / opengever.core

OneGov GEVER core package
11 stars 5 forks source link

Handle ids of the form `orgunit:userid` in the Actor class #4484

Open njohner opened 6 years ago

njohner commented 6 years ago

Conditionals to correctly treat users with a orgunit specification are spread throughout the Taskcode. This should be managed by the Actor 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

njohner commented 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 UserActors: 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.

phgross commented 5 years ago

m.E. wäre es sinnvoll, wenn wir hier zuerst die API Support Arbeiten im Aufgabenmodul abschliessen ( #4786). Deshalb --> 2019.2

njohner commented 5 years ago

For sure no point in doing both in parallel...