copy+adapt container model

[christianschaeffer]

Containers are objects that can be assigned to events and the structure of whose content is described by a checklist.

[christianschaeffer]

Before starting with this (and #7), we should discuss how to link resources and containers.

Basically, I see the following two options:

1. Do not use a separate Container model, only the existing Resources. Each Resource must have an (optional) Checklist and a list of Checks. The way I understand ephios, this would requires the Resource model to be moved to core.
2. Containers live in this plugin and Resources somewhere else (core or their own plugin). Both are independent. There is an optional one-to-one relationship and if so, the checklist status of a container-resource (+some links) can be shown whenever such a resource is assigned to or referenced in an event.

@jeriox @felixrindt What do you think?

[jeriox]

@jeriox @felixrindt What do you think?

I remember that we had a discussion about this, but unfortunately not the outcome. IIRC we modeled your option 1 as an interface similar to AbstractParticipant, where plugins can signal a set of Resources and their properties (readiness etc.) that are then displayed by core in a similar way that all participations are rendered in the same way. This would then be only a dataclass to pass around and not a model. I think I prefer this approach, as it does not entail two different models for the same entity. But maybe @felixrindt remembers more about the discussion?

[christianschaeffer]

I think I also remember a signal-based solution, with the caveat that this requires Resource to be moved to core first.

[felixrindt]

I think I also remember a signal-based solution, with the caveat that this requires Resource to be moved to core first.

No such Resource implementation exists currently. What we have is a Resource as some generic model in the SimpleResource Plugin, but that serves a different focus.

an interface similar to AbstractParticipant, where plugins can signal a set of Resources and their properties (readiness etc.) that are then displayed by core in a similar way that all participations are rendered in the same way. This would then be only a dataclass to pass around and not a model.

That's what we discussed yet. I'm unsure whether we really should buy into that complexity. For participants, we used a dataclass because there was no value in duplicating participant info in a model next to the UserProfile model, but we needed an abstraction for placeholders and guests etc. With Resources, there is no existing model holding that information. We could just decide to do an ABC for implementing a Resource (like wagtail Pages/AbstractParticipation) that would define an interface and some ID to reference from shifts.

[jeriox]

that would define an interface and some ID to reference from shifts.

that's a fair point, I didn't think about the reference from a shift to a resource that is allocated for that shift. I guess in the other version every plugin would need to have its own model with a relation between shift and resource and return the corresponding objects as dataclasses for the signal. the common base table is probably the simpler approach then