Rethink the usage of the SingularActionMixin

[ostcar]

The backend has the feature, that one action can be called multiple times in the same request with different data-sets. The Mixin SingularActionMixin deactivates this feature.

I run into this in the speaker.create action, when trying to create a list of speakers with a lot of entries.

I deactivated the Mixin for the SpeakerCreateAction and it works fine.

I don't know why this Mixin is used in the SpeakerCreateAction or any other action. It deactivates a useful feature of the backend.

Could you remove the Mixin in all possible places and document in all other places, why it is necessary?

[luisa-beerboom]

The idea is that the client is not supposed be able to create multiple speakers at once, because a user creating multiple speakers at once is not an intended use-case.
Therefore the backend forbids it.

I can imagine there are probably also a few singular actions that would need some additional code to take care of possible model interactions between the payloads and are written as singular actions to remove the need to write that code. No concrete examples coming to mind right now though -> would need investigation.

There is a possible workaround of sending it as separate actions with single payloads in one request. Perhaps you may need the handle_separately flag in that case, you'll probably have to test that. This'll all decrease performance a bit, of course, but if it's only for a few tests that might be fine, right?

[ostcar]

I don't understand it. A user, that has only the permission to put himself on a list of speaker can only call the action with himself (one user). But a user, that can set other users to the list of speakers, could do this in bulk. I don't understand, why this is not an intended use-case. Maybe the client does not support this feature currently. But why is this a problem for the server?

[luisa-beerboom]

Putting it as concisely as I can:

It's technically possible to remove the mixin.
It's also a lot of work.
It'd bring no benefits in production that I know of.
It'd likely make the process in production less efficient.
It's possible to bulk create speakers in other repositories tests already, quite easily actually.
Therefore I don't see a point in going through the hassle.

Here's the long explanation in the speaker context:

There's a bunch of stuff that needs to potentially be unique in context, not only in relation to pre-existing models, but also in relation to other models that would be created with the same action.
The generated weight is an example. There's also the speech_state which sometimes needs to be unique per user per list.
Because there's a guarantee that there's only ever going to be one payload per action, all these checks and calculations are currently somewhat simpler and faster than they would otherwise need to be. If we took that restriction out, we'd have to rewrite our highly specific (and somewhat complex) weight and speech_state code to ensure it takes previous payloads from the same action into account.

This would probably take quite a bit of time, definitely require a lot of testing and add a bunch of complexity to this already complex action.
All for a feature that would only be useful for tests of other services, since the client workflow (the client being the only place where the stuff is set in production) doesn't allow for it anyway and does not have much potential for reworking it so that it becomes an option without a complete UI overhaul.
These tests could, just as easily, be set up using the workaround I described above, though.

[ostcar]

I don't get it. Without the singularActionMixin, the Action is called multiple times. For the class, it is the same, as if the action would be called multiple times.

But I understand, that you don't want to fix it.