We have used the case Entity, there is default user that is used to assign a case on new creation or reactivation.
We have a workflow created for Case Reactivation, so whenever a case is reopen it is assigned to the default system user. It was working fine till September 20, but now when you give the survey after case resolution and then try to reactivate it it throws error in workflow. It works fine when you try to reactivate without giving the survey.
Error:
The real-time workflow named "Case is Resolved/Reopened" failed with the error "Principal user (Id, type=8, roleCount=1, privilegeCount=619, accessMode=0), is missing prvReadmsfp_questionresponse privilege (Id) on OTC=10247 for entity 'msfp_questionresponse'.
The System user has the role assigned as of salesperson, giving permission for this entity to salesperson does solve the issue, but the salesperson role is being used by many others to whom permission for this entity can't be given.
Can anyone tell us why this started causing issue after a particular time. Was there any updates from Microsoft Forms Pro for this entity?
Its very possible there have been updates from MS. You can review the solution history in make.powerplatorm.
https://learn.microsoft.com/en-us/powerapps/maker/common-data-service/solution-history
Look for the forms pro solution and check the solution history.
Is the "Default" user an actual person that logs in? Or a Service account that is only used for automation/workflows?
In any case, I'd suggest creating an add-on or feature role called something like "Question Response Reader" that only has the read permission for that entity. You can then add that role to the default user, and any other users that need to read that entity.
Probably Microsoft changed something in the background especially w.r.t security of forms Response entity msfp_questionresponse.
You easily solution is to give proper security rights to user who is ruining your workflow.
If it is run by the owner of the workflow then that user, if workflow runs under the context of user then that user should have read rights for entity msfp_questionresponse
Related
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
When creating a case I get the below error.
Access Error The system could not log you on. This could be because
your user record or the business unit you belong to has been disabled
in Microsoft Dynamics 365. If you contact support, please provide the
technical details.
This occurred shortly after deleting the CRM Admin user and creating a new CRM Admin user in the Office 365 users screen.
The more technical message is
The user with
SystemUserId=bb51ba1c-66e8-4dc1-82ca-cb64e25f3ff9 in
OrganizationContext=7e061672-3a31-4588-9770-9f94711c7f09 is
disabledDetail.
The error message is saying that the user with that ID is disabled so the first thing to do would be to open that record and check which user it is.
To do that, use the URL below but replace the xx's and the yourregion part of the url (I've already added your user id).
https://xxxxxxxx.yourregion.dynamics.com/main.aspx?etc=8&extraqs=&histKey=952109180&id={bb51ba1c-66e8-4dc1-82ca-cb64e25f3ff9}&newWindow=true&pagetype=entityrecord
You will then need to enable that user or resolve problems from there.
I would also check that you don't have any plugins or workflows which have been setup to run as that user when creating a case.
I am using Microsoft Dynamics 365 and I am attempting to change the Owner of an Opportunity. I have System Administrator privileges, but I still get this error message:
<Message>Principal user ... is missing prvReadps_application privilege (Id=75b45303-d5b2-494f-9300-04ffa37d2fee)</Message>
The prvReadps_application privilege is missing from the Dynamics documentation so I'm having a hard time tracking down what privilege is missing from my role. How can I use the privilege name or Id to add the privilege to my role?
It is not you that are missing the privilege - it's the user whom you are trying to give ownership of the Opportunity to. Let's say you have an account owned by User A. If you want to assign this account to user B, user B MUST have at least User-level Read privilege for the account entity. That is how Dynamics CRM/365 works. The user that you are trying to assign the Opportunity to is probably missing proper the security role.
As other pointed out, ps_application is a custom entity - You should go to your System Customizations area and check its display name (I bet it's something like Application). Now you should check what the security roles of the user are to whom you are trying to change ownership to - you should grant this role Read privilege for this entity (it will be on the last tab of Security Role configuration page).
So, why are you getting this error when assigning Opportunity? I bet that this ps_application entity is related to the Opportunity and the relationship is configured to propagate owner, so by changing owner on Opportunity, you are changing owner of related ps_applications -> and thus you are getting the error, as the user cannot be the owner for such records (does not have read privilege).
ps_application is your custom entity. That's why its missing in MS documentation.
prvReadps_application - says Read privilege missing, so look for Custom entity tab in Security role.
But System Administrator is a dynamic role, the privilege should be added when a new custom entity is added to the system. Make sure you didn't remove any privileges explicitly.
Also Verify the Security roles of the owner you are trying to assign, for Read privilege of this custom entity.
Arun V.'s answer made me realize that I missed the part about you being a System Administrator. Thanks Arun V., and my apologies.
Now I would say that you'll want to focus on the privs of the user to whom are you assigning the record. Their lack of permissions is likely what is preventing the assignment.
As Arun V. pointed out, ps_application could be a custom entity.
I'm seeking for the solution or suggestion, to find out that did this function is able to work in CRM 2016.
"User A" is opening an (account record form A), in the moment the "User A" is trying to open the another (account record form B) while the previous account record form still haven't close.
Here the requirement from my client.
The (account record form B) is unable to open while there is existing (account record form A) is opened up.
That means the User is only can open the Account record form once at a same time.
I am appreciate if anyone can leave a comment.
Thanks in advance.
This is not possible not only in Dynamics CRM, but also in any Web Application or website out there. This is technically not possible, because user can always open a different browser or browser in private mode and you will not be able to control that (unless you deploy some malware software on all users computer, but this is clearily not a Dynamics CRM customizations thing)
Pawel makes a good point about web apps in general.
Because we have the plugin model and JavaScript in CRM, there is a hypothetical possibility of building something for this - though it pushes the boundaries of abuse of the CRM extension model.
The idea would be something like this:
Create an external table to maintain a list of open Account forms by user.
Register a plugin on the retrieve message of the Account. When the user retrieves an account, populate an entry into the table.
If the user attempts to retrieve another Account, check the table. If they have an open Account form, prevent the retrieve.
Create JavaScript on the Account form to remove the entry in the external table when the user closes the Account form.
If this could even work, it would be a complex, fragile solution that would likely also harm performance.
Unless you want to share the reason why you want only one Account open at a time so we can discuss alternative options, I'd recommend letting this one go.
Ok, so imagine a bank has a call-centre filled with low-trust staff. The staff need to provide basic service to customers over the phone. The call centre staff take calls from a customer, ask them certain security questions, and then service the accounts in some way.
Now, from the customer's point of view, the bank is verifying who they are by asking the security questions. This is subtly different from the bank's point of view: It is verifying that the call centre employee is talking to the customer.
Why is this difference important? The bank wants to restrict these low trust staff, so they cannot view any details of the accounts until the customer calls them. So a call centre employee can't browse account details of customers that haven't just contacted him and asked for service.
So the question is:
Is this sort of setup possible in Dynamics CRM 2011? How would one go about implementing it? Some level of customization would be OK, but a bespoke application driven from the CRM data is not.
I'm thinking that maybe it's possible to create a custom component that temporarily modifies the user's permissions to a record (and all its children) after answering some security questions. However, I'm not even sure that record-based security (beyond Ownership) is supported in CRM...? I guess one could temporarily assign ownership to the user. Is that wise?
Please note: Simply hiding views & find buttons from the GUI isn't the sort of level of security we're looking for here. We're looking to literally restrict the user from accesing the records in question.
I can see a couple of options:
Working within the permissions model. This could work. You could have access restricted by default, and then have another entity where you'd enter in the account details, a plugin would run and verify the details, and then share the record to the current user. I'd be a little concerned, however, on how the unsharing would work. What would trigger it? Would there be a process that just runs outside of CRM and unshares records periodically. What if that process fails? We've also had performance issues in the past with this type of model... CRM seems to do a lot of work under the hood every time an individual record's permissions are changed like this.
Reassigning the owner, as you suggest. Would multiple users ever need to look at the same data? Does the owner of the record need to be maintained for any other reason (e.g. This is Joe's account because he's the owner).
Working exclusively with plugins. You could have a plugin registered on Retrieve and RetrieveMultiple of a record. This plugin could filter out all the details you want to hide from the end user. When the user needs to view the rest of the data, they fill out a form or dialog or something with the data. This data is then included in the Retrieve call for the record. The plugin checks for the hidden data, verifies that it's there and correct, then strips it out and lets the request continue, only this time it retrieves all attributes, and the form populates as expected.
Disclaimer: this answer is based on plenty of CRM 4.0 experience and reading the release notes for 2011.
Short answer: no.
Long answer: yes, but the customisation would be major. The 'easiest' option that springs to mind, is that the authentication process is carried out as a bespoke asp.net page that either a) uses a service account to re-assign an entity to an individual and then returns them to the relevant CRM form, then a plug in that re-assigns it back on saving changes
or
b) has it's own set of forms to that update and retrieve information as a service account, and only do so after answering the security questions.
As an aside, any kind of 'scripted' form is almost impossible in CRM 4.0. I believe 2011 slightly improves on that, but what I've seen is still not encouraging. Using CRM in a contact centre for us has meant investing in a piece of third party form building software and creating bespoke forms that can be launched from CRM and return data via the web services (which are impressively flexible). We only use the CRM interface for viewing historic requests - even most updates trigger one of the bespoke forms.
If I was to implement such a scenario I would create a customer access record (new_custaccess) that is linked to the customer record (new_customer). For this example - keeping it simple - I'm going to assume that the customer has a simple access code they must provide before the bank employee (Operator) can access the record. The access code is stored on new_custaccess in a field (new_secretcode).
Security is that the Operator has no privileges to new_customer and read/update privileges to new_custaccess.
There is a single field (new_secretcodeoperator) on new_custaccess that the operator can update. All other fields are restricted from update (and, if appropriate, read) to the Operator.
When the Customer calls and the Operator searches for the appropriate new_custaccess record. Once they locate the record they enter the Customer provided secret code into the field new_secretcode and do a save.
A Pre-Update query executes on new_custaccess in the context of a user with full privileges (call it MASTER, for fun here.) That plug-in checks to see if the provided code matches the secret code. If it doesn't it throws an error and the Operator can retry. If it does match the plug-in strips the field new_secretcodeoperator from the record, to keep it from saving the value. It also shares appropriate permission on the record new_customer to the appropriate operator.
The Operator now has access to the Customer record (you'll have to decide whether to cascade permissions or share on each record - that decision is beyond this discussion.)
We now need to deal with rescinding permission on the Customer record. I would handle this by having an entity new_customeraccess that is generated by the previous plug-in whenever access is granted to a Customer record. A workflow should be triggered on Create of new_customeraccess that cause new_customeraccess to be updated every 20 minutes (or whatever time the client prefers.)
A plugin is registered on Update of new_customeraccess that fires when the field updated by the workflow is modified. This plug-in will determine - via whatever criteria is decided on by the business - whether to continue sharing or revoke sharing.
I would also create some javascript/html based pop-up from the new_customer ribbon to end sharing by updating a field on new_customeraccess. Provide the Operator with limited Update privs on new_customeraccess via field level security.
This should accomplish what you want without going outside the standard CRM customization model. Not exactly sure of where you draw the line on bespoke but this is probably as close as you'll get to OOTB. A few plug-ins are all the C# you'll need. And the only JavaScript will be for usability, not functionality.
Let me know if you have questions.