For your first question, it depends on what you actually need to achieve with your access rights, but my guess is that is is indeed a good idea to have a group per company. Nothing prevents you from having members in different groups, so you can let all users in the "Supplier group", which would then be what you refer to as the "common denominator" between companies, and then differentiate the users per company by placing them in their corresponding company group.
This way you can set common security on the global Suppliers group and then put company specific rights on the Company group.
As far as your second question is concerned, I am not sure I understand what you mean.
I have never done it so I cannot help you much further, but I'm pretty sure it is possible, since you can do it from the backoffice manager. In the worst case, you can look at the code they use in the backoffice and re-use it in your logic.
Just for reference, when creating a document you can assign a member and public access level via the Access class. You will also need to associate a group to it so this takes me back to your suggestion were I will now have to create a group per company!
MemberType, MemberGroup structure
Hi there,
Ok so I'm in a bit of a pickle here….
I'm trying to build a website that will serve different companies and I think my structure is wrong.
Here is what I did:
I created a member type named "Supplier Member". I also created a group named "Supplier group".
Now, each dedicated company personnel I added to the supplier group so by that I created a big group which contains all the companies' personnel.
I just realized that this, as much as it might work, it's probably not the right way and I will really appreciate any kind of input before I continue.
Do I need to create a Group per company?
How can I create a common denominator between companies in order to group them under the "Supplier" title?
Also, at the moment I can get all the members of a group by using the following:
Member[] supplierMemberList = MemberGroup.GetByName("Supplier").GetMembers();
Is there such a thing for a Member Type where I can get all personnel's details?
Many thanks
mkariti
Pickle anyone?
Hi mkariti,
For your first question, it depends on what you actually need to achieve with your access rights, but my guess is that is is indeed a good idea to have a group per company. Nothing prevents you from having members in different groups, so you can let all users in the "Supplier group", which would then be what you refer to as the "common denominator" between companies, and then differentiate the users per company by placing them in their corresponding company group.
This way you can set common security on the global Suppliers group and then put company specific rights on the Company group.
As far as your second question is concerned, I am not sure I understand what you mean.
Also, you might want to have a look at this package which allow setting security on user types: http://our.umbraco.org/projects/backoffice-extensions/usergroup-permissions
Hope this helps.
Cheers,
Michael.
Hi Michael,
Many thanks for your reply!
I decided to continue with the same structure I started earlier as other problem arose with the new structure.
I just need to ask if it is possible to set a single user protection on a document when creating the document (programmatically)?
Many thanks
mkariti
Hi mkariti,
I have never done it so I cannot help you much further, but I'm pretty sure it is possible, since you can do it from the backoffice manager. In the worst case, you can look at the code they use in the backoffice and re-use it in your logic.
Cheers,
Michael.
Hi Michael,
After a few hours I managed to do this.
Just for reference, when creating a document you can assign a member and public access level via the Access class. You will also need to associate a group to it so this takes me back to your suggestion were I will now have to create a group per company!
I guess there is a right way,,,:D
Cheers
mkariti
Hi mkariti,
Thanks for the info.
It seems like your getting close to something working :-)
Cheers,
Michael.
is working on a reply...