Closed GabrielInTheWorld closed 2 years ago
I have not checked this. But it sounds, that it is the same problem then in #343
@GabrielInTheWorld could you confirm this and then close this as duplicate?
This is not a duplicate of #343. I found the problem but I don't know how to solve it. I think the current behavior is correct.
The issue is, that a User can not see a motion but the motion is on the projector (which the user can see). The question is, can the user see projection/X/content_object_id.
To see a [generic-]relation-field, the user needs not only the permission for that field but also the permission for the related field. So in this case, the user has to have the permission for motion/X/projection_ids
. Since the user can not see the motion, also projection/X/content_object_id is restricted.
I think this behavior is important. If the user could see projection/X/content_object_id
but not the motion, then it would seem as if the relation / database was broken.
If it is important that every user that can see the projection can see projection/content_object_id
then we have to change the restriction of motion and all other objects, that can be on the projector, so the back-reference can be seen when the object is on the projection. It is a bit more complicated, because the id-field has also to be seen, if one field of a object can be seen (see the description in the overview).
For example, for motion, it would be look like this:
// Group A
id
// Group B
number
title
// Group C
projection_ids
The question is, if it is really necessary to see projection/content_object_id to show the projection. All requied fields should be contained in projection/content. If not, @r-peschke could add them.
Seems okay to me. Especially the projection/7/content can be shown at all without restrictions, including the motion data. What do you wanna show more?
Okay, the only thing I need to fix this, is the information about projection/X/content_object_id
. I need this, because the content_object_id
is a fqid and thus I get the collection from the content_object
.
As of projection restrictions every user, who can see a projector, can also see the content_object_id
and this is missing.
Wiki page projection restrictions allows the user with the right projector.can_see
to see the field projection.content_object_id
. But, see example above, this field was removed by the restrictor.
I documented in the wiki how the restrictor handles relation fields. If hope this is clearer know: https://github.com/OpenSlides/OpenSlides/wiki/Restrictions-Overview
@GabrielInTheWorld I don't understand why you need field content_object_id
in a situation, where the client can not see the related content_object.
In your first post, you have the case, that there in a motion on the projector, that the user is not allowed to see. But if the user can not see the motion, then content_object
has to be null. Why do you need the id of a motion, if the client should not see the motion?
@GabrielInTheWorld I don't understand why you need field
content_object_id
in a situation, where the client can not see the related content_object.In your first post, you have the case, that there in a motion on the projector, that the user is not allowed to see. But if the user can not see the motion, then
content_object
has to be null. Why do you need the id of a motion, if the client should not see the motion?
I do not need only the id of an object, I even need the fqid of the object. The reason is, that an fqid contains the information about the collection of an object. The content_object_id
is the fqid of an object, which is e.g. projected. In your projection overview is documented, that everyone, who can see a projector, is allowed to see the content_object_id
from a projection. So, please implement it.
Could you explain the concrete situation what you want to do with the fqid? In which situation is it needed. What bug/problem should be solved with it?
As I already wrote, the client get the collection of a content_object
from a projection by its content_object_id
. To determine which slide the client should show, it needs the collection.
Would it help to change the content of projection/content
to include the type of the content object?
For example:
{
"type": "assignment",
"title": "...",
...
}
Yeah, this would be helpful. But why do you not send just the content_object_id
as described in the wiki?
After relation fields have passed the first filter (descried in the wiki), that the user can see them, they have to pass another filter, that the user can also see the other end of the relation. This is a generic check that I can not change only for this case. See this wiki page.
The reason is to prevent invalid relations.
I add the change to the projection/content field as soon as possible. @r-peschke I hope it is ok for you that I do that. If you don't like this change or you want to do it, please ping me. I will add you for a review.
I add the change to the projection/content field as soon as possible. @r-peschke I hope it is ok for you that I do that. If you don't like this change or you want to do it, please ping me. I will add you for a review.
Surely this is okay for me.:-). You should realize it for all projections, it will be a problem not only for the motion. But I think it is meant this way. Another thing to mention is the name: I would prefer collection
instead of type
, because this part of an fqid is the collection.
I sent this request:
Hint: The underlying motion is in a state, in which only users can see the motion, who have the permission
motion.can_manageor if they are the submitters of the motion.
As a delegate, I get this update:
As a superadmin, I get this update:
As you can see, there are some fields missing, e.g. the
content_object_id
. This field - for example - is necessary to show the current projection correctly.