Developer forum

Do not create permissions per user. It will break when you have 1000 users or something...

Create user groups that has the correct permissions, and then assign users to those groups.

Hi Nicolai,

Thank you for the reply.

I have considered this potential danger. In my case, I will have a few hundred users but it will still be close to breaking.

I would normally assign all of them the same permissions (on a group) but I need to be able to restrict what each of them see. That's why I am considering a 1:1 relation with a Warehouse. The Warehouse can have specific categories (and fields) and each warehouse will contain only the products that the user can/should see and edit.

If I assign all of them to the same warehouse, I need a way to handle what they see. Hence my last question about saving some UserID information on a product. In theory (have not tested it) if I have a userID on the product, I can probably add generic filtering on the PIM repository to always display only the products marked with the identifier of the user (using a User macro). But that would still leave me with displaying all categories that the user does not have Products into.

Of course, this is all theoretical at this point. I am trying to figure out the best way to handle this.

The broad scope is to allow external vendors to edit their products in a centralized PIM.

And I am investigating 2 approaches:

1. Allowing them inside the PIM backend

2. Create/duplicate the functionality in the front-end

I probably have more control with option #2 but it will require constant maintenance as the PIM will evolve and the functionality will be pretty limited (view, filter, import, export)

Option #1 is ideal but even if I can make it work for 100 vendors, there is no guarantee that my customer will not try to add 1000 more one year from now.

Jesper can probably tell you more about this project :)

Thank you,
Adrian

Get them in the backend. Use group permissions. One warehouse = one vendor = one group. More users from the same vendor - put them in the vendors group.

Group structure something like this:

• Other group
• PIM administrators
• Extranet users or whatever
• Vendors
  • Vendor 1
  • Vendor 2

Keep it simple, keep it explicit and you can get it to work.

Hi Nicolai,

This sounds Ideal.

In my case, it means that I will have 100+ Groups for vendors, 100+ Warehouses, 100+ users.

The users and the groups don't scare me, we have solutions with a whole lot more.

I have not tested any scenario with more than 30 shops, but I guess that will be handled nicely if the permissions are set correctly.
What about the permissions? Do you see any potential issue there if there will be a couple hundreds definitions? Can I set them programmatically? Say, and onboarding logic in a custom section in Admin that will create the User, Warehouse and set the permissions?

Thank you,

Adrian

Hi Adrian,

Do you need a "Warehouse" per Vendor ?

Why not make a "Warehouse", eg. called "Vendor", and then create a TopGroup for each Vendor and named with the "Vendor-Name"

Just my sugestion 

/Søren

Hi Soren,

Thank you for the suggestion. I thought of that approach as well and there are a few reasons, outlines in my previous messages.

The first reason is access to products. Each vendor should see only his products and should be able to enrich only his products.

The second reason is the Categories that the Vendor should assign products to. This part can probably be handled by a generic Channel publication on a Vendor channel instead of creating categories for each Vendor warehouse. The problem though will be related to the properties that can be enriched.

Imagine a PIM where you have 100+ categories and subcategories with probably a similar number of ProductCategories. Each Vendor should document the fields relevant for the categories the products are assigned to. Hence the need to have some categorization.

The ideal setup would be to use a single warehouse, as you suggested, and filter products (and maybe categories) per vendor. Much like how an Assortment would work.

Yeah. Now I said it. We need to add the concept of Assortments (or some new concept of assortments) to PIM warehouses  :) It sounds like a nice feature request for PIM, although I am not sure how many projects will actually need/use it.

Thank you,

Adrian

This looks like other cases we have had.

Problem is that the warehouse structure should reflect how the data should be structured in terms of types of products, their fields and natural inheritance.

To structure the products after vendors to handle permissions, is not good for the PIM discipline - we have seen similar implementations in other projects and the result is not outstanding....

A product do have a manufacturer on them. In your case maybe the vendor?

A feature where permissions are handled on manufacturer or something similar - a new field on the product "Owner" which is a group/organisation or something similar. It has to be relatively simple and be able to live on the index so we can handle it all over...

A user can then be member of one or more "owners" and then that would control what products are available.

@Søren. Let's discuss.

Hi Nicolai,

I agree with all your comments.

Ideally, the separation should be done in the same warehouse in order to preserve Product Schema.

I would rather have some dedicated logic (Owner) than repurposing an existing one (like Manufacturer).

The owner can be based on a CustomerNumber or a GroupID. Or even better, a VendorID.

If the entire content visible in PIM is controlled by the PIM query. maybe an Extranet User Macro based on the Admin user can solve this rather elegant.

It will not filter the Categories, but at least we can be sure they will see only what they are entitled to see.

Thank you for considering looking into this use case.

Adrian