I want to extend the security role entity to include some custom permissions relating to my business.
For instance, I might want to add things like 'Can approve an order of up to X $' or 'can update leads whose name begins with Y' (just some examples, of course).
I will then use these permissions in workflows, plugins and iframes which I will develop.
I haven't found a good way to do it- as far as I can tell, the security role entity is not customizable, so I can't add any fields to it.
I thought about creating a custom entity Role exstension which will hold this data for me and will have a 1:1 relationship with security role. However, I haven't been able to find a way to create a relationship with the role entity.
Anyone has any thoughts?
You are right you cannot extend the security role entity. I would recommend setting up a new entity called “Role Extension” (as you mentioned) and relating it to either a user directly or a team with a N:N relationship type. You could then use the built in CRM subgrids or a small Silverlight part to manage the roles
I think you can implement this kind of functionality quite nicely with plugins. Using plugins embeds the rules into the pipeline and ensures if you are using the SDK, they will be implemented.
e.g. enforce rule that only users with Role 'My Custom Sales Role' can approve order of more than 5 products
Create plugin that runs on order status change
Detect if quantity is > 5
If not, carryon
If so, get executing user guid
Retrieve user roles
Check for 'My Custom Sales Role'
Allow action if exists, if not throw exception 'You do not have permissions blah blah'
This keeps your rules in one place (a single library can encapsulate all rules). It does depend a bit on how many you have, but keeping them in the pipeline sounds like a reasonable approach to me.
Related
How would one effectively implement a custom sign-in experience for multiple clients/customers while adhering to the DRY principle?
Requirements
The look and feel needs to be customized to our design but the same* for all customers
*The logo needs to be specific to the customer
Implementation Idea 1
I could create a policy for each customer/client and then a custom HTML page with the img/logo different in each page but this doesn't scale very well.
Idea
Is there a way to pass along parameter(s) to the Custom Page URI defined here?
Reference: I've gone through this demo example.
Unfortunately, multiple policies would be the only approach that would work to enable your scenario. The only fields we pass through right now is ui-locales, used to localize your HTML content based on the requested language.
If you're interested in bringing attention to this feature to the product team, please create an entry on https://feedback.azure.com/. You will also be notified by the product team if there is any change for that feature.
We are using the Tuleap 7.0 for Project management. We have a new requirement that we need to provide access permission to specific users other than administrator role to create field's value with dependencies. For eg: We are having a field called category. Categories are SUV, Sedan, etc., Now we want to add a new category name called Wagon. But I do not want the administrator to add this each and every time instead I need to give permission to either project manager or to some other user roles to add the same. Also we have to add subcategories to corresponding categories. So either we need to provide access permission to specific user or a external interface other than tuleap to add the category and subcategory with field dependencies.
If we have to create an external interface, we do not know in which table the data and dependencies will be available. So kindly let us know is it possible to provide access permission to specific users for creating field's values and dependencies or else let us know detail on table structure that where the insertion of field values happen and the dependencies between fields will be available. Table schema will be more easier. Please help
It is possible for a group to be Trackers administrators but not fully Project administrators, maybe it answers your need but not sure. If you want to go this way, you have to choice: either you set it in the Trackers > administration > manage permissions for each project or in the global administration of the platform in admin > permissions delegation.
If you only want people to only be able to add values to this particular field, I don't think it is really possible. What you can do is to put an openlist instead of a simple list or even modify your trackers structure to have a tracker that represents all the category and set category by doing an artifact link. So to add a category simply submit a new artifact in the category tracker.
For the table schema I'm sorry but I don't have such document.
I have two security roles ProjectLead and Developer ; also I have one custom entity named Project. Is it possible that ProjectLead and Project have 1:N relation(one ProjectLead can work in more than one Project)
and Developer and Project have 1:1 relation(one developer can work in one project)?
Thanks.
I don't understand your problem. You want make relationship between a role and a entity, this ins't possible and don't make any sense. You want restrict the access to projects? This can be done with roles, in Developer role for project entity you can put the read action in user option (just one level) like that the developer only viewed that project or if you have a team with many developers you that team can own that project.
For ProjectLead you can put access at Business unit level.
I am trying to set up dynamics for a call centre that just wants to do cas management. How do I turn off these things off so there is no evidence of them for a user of the system?
A good place to start would be to edit the SiteMap.
There is a project on codeplex which might be helpful, otherwise you can find good guides dotted around the place:
Editing the SiteMap
Editing the SiteMap 2
With this you could hide Sales & Marketing, which would be a good start. You may also want to look at amending permissions for Leads/Opportunities which can be done by editing security roles. This will help nosey/inquisitive users from creating records if they find links elsewhere.
I presume that you are referring to the subsections of the native CRM navigation structure which shows Workplace, Sales, Marketing, Service and Settings.
Visibility of these areas can be driven in two different ways. You may choose to employ both methods.
Firstly record-type visibility is governed by a user's permissions. Remove a users read access to Invoices for example and it will cease to appear as a navigable option in their UI. Similarly the sub-areas that I previously mentioned will cease to appear if a user has no access to any of the record types that it contains.
consequently it may be possible to achieve some of your aims by giving users the least possible permissions required to do their job (though you should be doing this anyway really) by granting the correct ouot-of-the-box roles or cloning and customising one of those roles. The problem is that the Sales section , for example, contains record types that your users will need to see, e.g. contacts. you won't be able to revoke access to contacts so you'll likely need technique #2 as well:
The CRM sitemap can be customized to contain whatever you want and can even contain new areas. One feature available is to alter or create rules that show/hide areas based on record permissions. I'd recommend downloading the Visual SiteMap Editor and read this part of the CRM SDK
How to manage the security on the list , while one group users can modify all the fields of an item and one group users can only modify some of the fields.
AFAIK there isn't a way to do this out of the box, so you have to do it in code. This discussion at Microsoft's TechNet forum talks about some free and pay tools that address this need.
Then again based on your needs you might be able to do something with web forms, i.e. create a form to edit those items that allows one group to edit all fields and another group to only edit some fields. It's cumbersome since you'd have to create a form for every list you need to restrict at the column level, plus manage permissions, but with this at least you have a functional workaround.