To add the salient points from the other post, the unsatisfying short-term solution to this problem for me is to add my own createdBy field to my model using a relation on user-permissions (users), and then update my controller functions to use that field for filtering.
async create(ctx) {
let newCampaign = ctx.request.body;
newCampaign.createdBy = ctx.state.user.id; //not using strapi built-in
newCampaign.created_by = ctx.state.user.id // strapi will ignore this, strip it out and throw it away
let entity = await strapi.services.campaign.create(newCampaign);
return sanitizeEntity(entity, { model: strapi.models.campaign });
},
Here is how you would take advantage of that in the find:
async find (ctx){
let entities;
if(ctx.query.createdBy) delete ctx.query.createdBy;
ctx.query.createdBy = ctx.state.user.id.toString();
if (ctx.query._q) entities = await strapi.services.campaign.search(ctx.query);
else entities = await strapi.services.campaign.find(ctx.query);
const campaigns = entities.map((entity) => {
//TODO: Find better way to provide this data
entity.participantCount = entity.participants.length;
return sanitizeEntity(entity, { model: strapi.models.campaign });
});
return campaigns;
},
Because the user / API session isn’t available in the lifecycle model functions… you are forced to then override the default & create your own model.create() function(s)… which in my opinion defeats the entire purpose of using Strapi to take advantage of its auto-generated CRUD etc.
I really wish I could use the awesome strapi permissions system related to admins on the end-users… in fact I was explicitly planning on doing this for my current project and now I’m seriously stuck not sure what to do.
While I write this post I’m considering writing my own middleware / authentication that looks at the strapi-administrator table instead of users. If that works I’ll update here.
I really can’t stress enough the negative impact of this “feature” (separate admin & users). I like Strapi a lot and I want the project to succeed. I wish someone on the project leadership would consider that this feature is not a positive, and in fact is a huge negative for many organizations considering Strapi. I think it will negatively impact adoption of the platform when someone get 2 months into building something and realizes a seemingly available feature has been made functionally useless.
To provide some context, we are building an MVP API system, and we have a functional demo we have been doing for investors. We are at a point where we would like to set up a few different accounts we can demo with for different market segments. The “easy” feature request of "only let API users see stuff they have created" has led me down this seemingly bottomless rabbit hole.
The problem is API users can create stuff, but you can’t assign ownership to them. The reasons for this are unclear. One of the solutions to this would be letting Admin users authenticate via the API… since the built in mechanisms for ownership DO function for admin panel users. This would let more granular access control for API users be accomplished via the built in Admin panel permissions.
I know Strapi is capable of all this, it’s just a matter of figuring out how. I’m sorry for the frustrated tone in my post, I hope the information within is constructive and can help other orgs who want to build SaaS products w/Strapi.