Strapi admin: Change row owner, hide forbidden fields and displayed join key


Just started trying to setup Strapi for our organization and I’m a bit at a loss with three things. Hope it’s OK that I ask about all three in the same post:

  1. Change row owner
    We’re using the three roles, one which can only read its own data. However, we will want to transfer rows between our user, a task performed by an admin, is there a way to do that? IE data entry person 1 only have access to a section of the data, fills out that part. An admin checks and then assigns it to person 2 who have access to another set of data.

  2. Pick which key is displayed in the relation
    When having a relation, say for instance you have a question collection and an answer collection. A question can have an answer. When we pick the answer the drop down is populated with what I suspect is row IDs, strings like “5f7c9ac942b05a007f711e29”. It’s not the case for every relation but I haven’t figured out how to select a human readable for the drop down. Is it possible to pick which field populates that drop-down?

  3. Hide forbidden fields in the forms
    Definitely less important than the other two, but we have a couple of fields that aren’t interesting at all to the people doing the data entry, I’ve set the fields as forbidden to them but that shows them as forbidden in the form when creating a new entry. It would be nice if it’s possible to just not show the fields rather than having potentially confusing fields not applicable to the user. So is it possible to not show the forbidden fields rather than just disabling them?

Thanks in advance

1 Like

@alexandrebodin @Jab is something we can currently handle within the Admin?

For this one @jmo you can adjust what key is shown, while you are in the Edit View of one of the records on the right hand side there is an option to “Configure the view”, from there you can select the field and change “Entry Title”. Here is an example in which I have an Article type with a oneToMany relation with a Comment type:

Same here, within the “Configure the view” option you can remove fields from being shown to the user (We don’t currently support different views based on roles yet)

1 Like

Thanks @DMehaffy,

for the second, perfect that was exactly what I was looking for!

The third though seems like it’s not possible to hide the fields, since I want the people with a role having the rights to change the field to see it, and I can’t have role based views so it’s either going to say “forbidden” for authors and be visible for editors, or it’s going to be hidden for both?

Just an example to hopefully make it clearer as I’m not sure I’m explaining myself well:
A user with the role Author creates a post. The posts have subject, text, ready for publishing, tags and qa state. I want authors to fill out subject and text. Then when they are done they set ready for publishing.

Then an Editor picks it up, proof reads the text and the subject, adds tags which makes sense and set the qa state to validated and then publishes the article.

In this case I’d like tags and qa state hidden for the author, they are irrelevant for them and not allowed to edit them. But I do want the editor to see them, as far as I understand that means those two fields have to be visible and say “not allowed”? What I’d like is if a field is not allowed, then don’t show it because it’s just confusing clutter for the author.

Like I said, it’s not the end of the world but like with other hidden fields (created_by, …) it feels saner to just not show disallowed fields.

Adding @Aurelsicoko @maeva @Jab to this, as I agree it would be nice to have specific views based on the role.

Thanks to the Enterprise Edition, you can select which fields are available for a specific role. You can choose if the field should be in read-only mode or if the value should be hidden. We do not offer the ability to have a different layout (in other words having different fields displayed or not) based on the roles.

We already thought about it though. The EE partially solves the issue here.

Ok thanks, will see if I can convince them to go EE. That would solve the issue I was having.

Regarding my first issue, I worked out a workaround which is OK-ish at least:
In the post I added a field “AssignTo”, foreign relation to admin users. Then in the model I added this hook:

  async beforeUpdate(params, data) {
      if (data.assignTo) {
          if (data.assignTo !== data.created_by) {
              data.created_by = data.assignTo;
          delete data.assignTo;

That will make the row owned by the person selected in the assignTo drop-down. Slightly hacky since it’s changing created_by but that’s the only thing I found defines data ownership?

1 Like

I’m having a similar issue here.

is there a way to do this from the schema for a plugin? I have been looking at this documentation but modifying those attributes doesn’t seem to be doing anything.

setting visible to false worked for what I needed. This is not in the documentation.