Search the FirstSpirit Knowledge Base
Hello All,
Certain users have been assigned to editors group and have been assigned the permissions to edit content. But when they go into the content creator to modify the pages and try to edit the permissions. They get the 'Berechtigungen nicht gesetzt' error .
But, when the administrators try to edit the permissions. They seem to be set.
The permissions seem to be set for the group.
It would be helpful, if you could provide any hints or the reason as to what the issue might be?
Thanks and Regards,
Shreyas
Hi Shreyas,
I think there is a misunderstanding here. Your screenshot of the SA shows the editorial permissions, meaning “which user is allowed to edit (delete, release etc.) which element in FirstSpirit“.
The screenshot of the CC shows just the metadata form of the page (or pagefolder or page reference or sitestore folder - that depends on the CC configuration). Inside the metadata form, the input component „CMS_INPUT_PERMISSION“ is shown. This does NOT define editorial permissions but is just an input component used to render it’s content into the output channel. It is usually used (and optimized) for JSP (or PHP) output channels to output information used to evaluate permissions on the published site by the JSP/PHP code in the output channel. The output of the input component itself does not create PHP or JSP but just the selected users/groups in the input component which is then used by the „surrounding“ JSP code of the template. Those users/groups have nothing to do with the FirstSpirit users.
Some background: In the CC configuration part of the ServerManager you can define for which element types (page, page folder, page reference, sitestore folder, media elements) the metadata form can be shown in the CC and give each of those cases „meaningful names“. For example, the metadata form for media elements often contains copyright information so you can configure the metadata form to be named as „Copyright“ for media objects. In the end, it‘s a feature to show the editor better what he is editing: Instead of menu options like „edit page reference metadata“ (most editors don’t know what FirstSpirit metadata or a page reference is and usually they don’t have to) they see something like „edit keywords“ if the pageref metadata form contains a field to enter keywords.
The rest (no xxx set, xxx inherited from...) is the normal metadata form mechanism.
In your case it seems that editors are intended to define live site permissions...
I hope that helps 😉
Regards,
Michael
Hi Shreyas,
I think there is a misunderstanding here. Your screenshot of the SA shows the editorial permissions, meaning “which user is allowed to edit (delete, release etc.) which element in FirstSpirit“.
The screenshot of the CC shows just the metadata form of the page (or pagefolder or page reference or sitestore folder - that depends on the CC configuration). Inside the metadata form, the input component „CMS_INPUT_PERMISSION“ is shown. This does NOT define editorial permissions but is just an input component used to render it’s content into the output channel. It is usually used (and optimized) for JSP (or PHP) output channels to output information used to evaluate permissions on the published site by the JSP/PHP code in the output channel. The output of the input component itself does not create PHP or JSP but just the selected users/groups in the input component which is then used by the „surrounding“ JSP code of the template. Those users/groups have nothing to do with the FirstSpirit users.
Some background: In the CC configuration part of the ServerManager you can define for which element types (page, page folder, page reference, sitestore folder, media elements) the metadata form can be shown in the CC and give each of those cases „meaningful names“. For example, the metadata form for media elements often contains copyright information so you can configure the metadata form to be named as „Copyright“ for media objects. In the end, it‘s a feature to show the editor better what he is editing: Instead of menu options like „edit page reference metadata“ (most editors don’t know what FirstSpirit metadata or a page reference is and usually they don’t have to) they see something like „edit keywords“ if the pageref metadata form contains a field to enter keywords.
The rest (no xxx set, xxx inherited from...) is the normal metadata form mechanism.
In your case it seems that editors are intended to define live site permissions...
I hope that helps 😉
Regards,
Michael
Hi Shreyas,
Ok, after having read your question again it seems the misunderstanding was on my side - might be because that’s a question asked quite often 😉
So your problem is that different groups of editors see a different metadata form for the same element, correct?
In your screenshot for the admin, it shows that the metadata ist not set on the element but inherited from another element. Do the editors have permission to „see metadata“ of that other element that actually has the metadata set (not just inherited)? If not, that should be the explanation because otherwise, you could circumvent the fact that you are not allowed to see an elements metadata...
Regards,
Michael
Hello Michael,
Yes, it seems that most user groups are able to see the metafata for that particular page except for some users who get the above message in CC.
Are these the configurations for setting the permissions to see metadata in Server Manager?
Thanks and Regards,
Shreyas
Hi Shreyas,
kind of 😉
It's the place where you define for which kind of objects metadata should be editable via the CC's default functionality. It's not really about "permissions" here - you can IIRC always open the metadata form of any element using an editorId() like editorId(element:...,meta:true). The "real" permissions (if editors are allowed to see/edit that data) is configured in the SA's permission dialog (see metadata / edit metadata).
But if you add element types, FirstSpirit offers OOTB functionality, e.g. offer the metadata form of the current PageRef's parent folder via the "Contents" menu. That's in the end the reason why you can configure "names" for each element type's metadata depending on their "meaning" for a project.
Example:
Result:
You can find the documentation here:
Documentation for Administrators - ContentCreator settings
And as I understand, your "problem" is not that setting but the fact that some editors do not have the permission (defined in SA) to see the metadata of the element where they are defined. In the CC (and SA) when an element does not have metadata itself, the UI shows the "inherited" metadata - but of course you need the permission to see the metadata of the element from where they originate.
Regards,
Michael