I will have two or 3 types of users on the front (Clients, Providers, and Manufacturers) and each user will have different set of features and data profile.
Which is the best strategy you imagine for creating the content types for each type of user?
In my head, I have in mind to create 3 content types related to Users and set a field for USERTYPE, and the front requests the rest of the profile on the other content type.
What do you think?
Also related to security, is it possible to set access to contents according to different user types?
Thank you.
It's depending of you want to do and depending of your application need.
You can also create roles, one for Clients, one for Providers and one for Manufacturers. You will be able to manage who can do what.
Related
In my application the users are split in 2 macro categories: Customer and Backoffice, every category has a subset of role, for example MANAGER and USER for Customer type and different ones for the Backoffice type.
So a user could be a Customer with a MANAGER role or a Backoffice with, for example, a SALES role.
Every Spring + Cognito guide on web uses cognito:groups to map the Spring ROLE, but for my case I would need to nest groups which is not possible on Cognito.
I've been thinking to use 2 custom attributes ( writable only by the admin) to set the category and role of the user respectively.
My question is, is there any disadvantage to using attributes instead of the groups?
One major concern is, those custom attributes won't be available as claims in the access token. But groups are available. So If you plan to use acces_token you may have to consider that.
There are some other minor considerations that I can think of, which may or may not be related your implementation:
Maximum number of custom attributes per user pool is 50.
Once created, you can not edit the name, min/max length and mutable property of the custom attribute. Also we can not delete that.
Even though nested groups are not supported in Cognito, is it not an option to create groups like: category_role? example: Customer_ MANAGER?
Do we have the possibility to create different users which see specific content types in Strapi?
Yes, you'd just need to create a tagging system, you can do this by creating a user field, that takes in a list of tags essentially then associate content to user tags and vice versa to give you a many to many scenario.
I have users in a team having access to particular fields on lead, opportunity and account entities. I have few users who are in team they just need access to fields on lead and Opportunity entity not on account ?
I thought Ill use field level security on the fields to achieve this, having field level security will have effect other functionality in the system. Any thoughts on how to achieve this ?
Breaking down CRM security levels:
Role level - Entity level (e.g. access to Lead but not marketing list)
Record level - Read/Write/Access (e.g. read lead record but not modify them)
Field level - Field level show/hide (e.g. hide a lead's account field for certain users or team).
In your case, it depends on what defines having access (is it more of a don't need to see or a should not see scenario). If it is just a case of a set of users don't have to deal with certain fields use different CRM forms for different teams, if it is a case of they should not be seeing the data use field level security.
This also would hopefully answer "having field level security will have effect other functionality in the system?" questions, if field level security is implemented, the fields which are restricted read won't show up in the advanced find queries or reports for the users who are not assigned the field level security profiles. Also once you have secured the field, every new user or team needs the field level security profile assigned, else they won't be able to see the field.
I am working on an ASP.NET MVC 3 application where users can be assigned different roles for different asset types. They are able to view assets that belong to different groups (asset type), one at a time.
Depending on the asset type of the asset that is being viewed, I would like to update the Principal's roles array to only have the roles that the user has been assigned for that asset type.
I am thinking I would do an authorization filter that takes care of looking up the roles the user has been assigned to based on the asset being viewed and loading them into the roles array. This way, the roles array will always reflect the permissions they have for the asset being viewed.
Then from the view, I can hide/show different parts of the page depending if they are in a specific group (User.isInRole)
Would this be the right approach to switching roles for the user depending on the asset type?
If these roles need to be applied across a request, and you can get the items identifier from header, query string, cookie, or session, i would suggest possibly adding an httpmodule that would bind to the AuthorizeRequest event. In that point you will want to provide your IPrinciple object with its custom implementation
the IsInRoles based on your rules.
Would this work, I'm mainly just guessing about your setup and on an ipad.
So I'm building out a web app using rails and devise for authentication, and I've run into a conceptual question concerning the setup of my database.
The idea of the site is that there are two different types of users, each has its own permissions and views. For instance, when somebody registers they choose to have either user type 1 or user type 2. Then after sign up, depending on their choice, they are presented with different forms to fill in their profile, etc. The permissions come into play because type 1 users can see type 2 users but can't see other type 1 users' profiles, while type 2 users can see everyone's profiles.
Now the way I set it up, I have two separate models; one for each type of user. However, after browsing a bunch online, I've read that a lot of people only use one model, namely User, with a user-type column that identifies their type to load the appropriate resources. Before I get too far along in my approach, I'm just wondering what are the pros and cons of having multiple models for user types?
I suggest you use Single Table Inheritance:
class User < ActiveRecord::Base
# Data shared by all kinds of users
end
class Type1User < User
# Data specific to type 1 user
end
class Type2User < User
# Data specific to type 2 user
end
All these models will be saved on the users table, but will have a type column which allows you to tell them apart. Users returned by find and company will also be instances of the appropriate class.
Related:
Single Table Inheritance And where to use it in Rails
Martin Fowler on Single Table Inheritance