I'm using CRM2013 on-premise, and I have a simple background workflow setup, to email the assignee, when a record is assigned to another person. This workflow works as is expected, however if I share the same record and grant "Assign" permissions (R/W), they workflow does not send the e-mail.
Any ideas why this is happening? Is "Assign" via Share different than the owernship assign? If so, is it possible to modify my workflow to trigger on "assigned" records when they have been shared?
When you share a record with another user and select Assign, you are not assigning the record to the other user. The ownership of the shared record will not change. Instead you are giving the other user the permission to be able to assign the shared record to another user.
Your workflow should still fire if the user you shared the record with assigns the record to someone else.
Related
My problem is that on my development system, I flushed all my users, and now I don't have the hyperwallet user's id. I could retrieve it from hyperwallet API and put in back in place. But what if I want to recreate the user's hyperwallet account?
The error is "DUPLICATE_EMAIL_REGISTRATION" and I couldn't find a single way of removing the user from hyperwallet.
This is the same for the transfer method which state "DUPLICATE_EXTERNAL_ACCOUNT_CREATION" but I do not have, nor in the API, nor in the sandbox interface, the possibility to remove transfer method.
How do you achieve this ? I'd like to not create a new sandbox account just to start from scratch because once in production, I won't be able to resolve this problem.
EDIT :
The whole documentation doesn't contain a single mention of the possibility to delete an account nor to create a new account with the same email.
Also users contains an attribute "Status" but the "Update user" section doesn't mention possibility to update the said status, and the "status transition" chapter only allow to change the "status" for bank accounts/prepaid card account/paypal account etc. But it doesn't seem possible to change de status of the user itself.
Sorry for the issue, we're actually in the process of rolling out this documentation.
There are 2 ways of solving this:
1) we can close existing accounts for you, so you are able to recreate them
2) we can provide you with a report of existing accounts, so you can backfill your system. Accounts in our system have your reference id (clientUserId) as well as ours (token).
Please contact our Developer Support (devsupport#hyperwallet.com) and please reference to me and add a reference to your question here. We'll be happy to assist you.
Thank you,
Willem
I have set up a form where when someone presses the "Submit" button it initiates a site workflow to create a list item. It all works well when I (full control permissions) do it, but if someone with contribute permissions tries, it fails. I tried adding an impersonation step, but that doesn't seem to be working either. Also, I am trying to record the person who created the list item, and the impersonation step uses my name (workflow author) for "Created By."
Any suggestions as to what I could've possible done wrong, or what I should try to do/add? Thanks in advance...
Simple answer is No.
As you can see the checkboxes in workflow property, you can set the trigger to be
trigger itself when item added or modified.
manually start by users.
For the read-only user, they are not able to click the "start a workflow" button. Also, these users do not have permission to add or modify list item.
You can configure your workflow with "impersonation step". In this way, the workflow will be running under the account of "workflow creator" instead of the user trigger the workflow. However, even you applied "impersonation step", the read-only user still not able to trigger a workflow
I am developing a POC (SahrePoint 2010) where I can demonstrate that the users can be granted certain permissions on a list for a Date range (for example contribute access for a selected week). I will be breaking permission inheritance and create unique permissions for a list.
I would like the permissions to be revoked automatically after the expiry date. Also, I would like to do this using the Manage Permissions list (_layouts/user.aspx) so that I don't have to maintain a separate list.
I have a couple of questions regarding this:
1. I assume that the custom permissions for any list must be stored n some list. How can get to know in which list the permissions are getting stored?
2. If at all I get to know in which list the permissions are getting stored, will I be able to add columns to that particular list?
I hope that the question is clear.
Permissions are not stored in any list. Rather, every securable object (including sites, lists, folders, and items) has a Role Assignments property that indicates what groups/users currently have access, and what their permissions are (if not inherited).
See the SPRoleAssignment class documentation for more information.
Note that the User Information list is not a "Manage Permissions" list; it stores profile information about users who access the site, but does not store any permission-related information. Further, it's not a typical list at all, in that it does not show up in the SPWeb.Lists collection for a subsite, and its fields are automatically populated by SharePoint's User Profile Service. While you could potentially add more columns to it, you'd be better off using a separate list to store and track your permission information instead of contaminating the site collection user info list.
To have permission changes take place based on an expiry date, you'll need to implement a time-based solution that runs on a regular basis to see if any changes need to be made, such as a custom timer job, a custom site workflow that runs on a schedule, or a Windows scheduled task.
I have an entity titled Document Access. Now, this entity Document Access has a N:1 relationship with Incident (One Incident can have many Document Access).
When someone creates a new Document Access record, I have a JS which checks if the person who is creating the record (current logged in user) is the same as the Incident's owner. If not, I disallow the creation (this is set on the Save of the record).
The Document Access record's owner can be anyone (not necessarily the Incident's owner). How can I ensure the prevention of the deletion of these Document Access records unless it is done by the Owner of the Incident?
Can I achieve it via Security Roles? I am not able to come up with a solution that can achieve this via Security Roles so that the Delete button does not even appear when a View or a Form is displayed.
Can I achieve the same via JavaScript hooking into the Delete button as part of
the ribbon? If so, how can I get the Incident id that is being selected for Deletion? Would it also be triggered if we did a bulk delete?
If it is a plugin, should it be on the Pre-Validation stage of the Delete operation?
I'll attempt to answer and qualify each of your own options:
Using Security Roles. No because you want to control the deletion based on the ownership of a related entity which isn't possible.
Using JavaScript. You could hide the buttons with a custom JavaScript ribbon rule that compares the Incident owner to the Document Access record owner. However, this approach won't support all use cases including bulk delete.
Using a Plugin. This is the correct approach and registering on Pre-Validation is fine. It will enforce your business rule regardless of where the delete request originates. This could be from a user via the UI, a bulk delete or platform operation such as an external integration request. Make sure you return a meaningful message in the exception that explains the business rule.
The best approcah is to do this through a plugin on Delete of Document Access records.
In your code you may follow this steps:
Retrieve the Owner of the Incident related with the Document Access:
Guid incidentId --> You get this form the lookup field, you have in Document Access to Incident
Entity incident = service.Retrive("incident", incidentId, new ColumnSet("onwerid"));
Check if the user who triggered the plugin is the Owner of the Incident
// context --> execution plugin context
Guid ownerIncident = ((EntityReference)incident.Attributes["ownerid"]).Id;
if(ownerIncident != context.InitiatingUserId)
{
throw new InvalidPluginExecutionContext("Can't delete Documet Access record");
} // otherwise let the record to be deleted
I am working on a Titanium Alloy project where in I am creating custom objects using ACS. I also have different users in the Users ACS. I wish to associate a particular custom object to a particular logged in user.
For example, If user A is logged in the custom object created by that user should be associated to user A. Same for user B and so on. How do I create this association? Currently my Custom objects get created but they are not associated to the logged in user.
After a little discussion, I realised I should add my scenario too.
My scenario is, a user changes a few settings using the toggle switch. This information should be stored for a user and later on push notification for selected settings should be sent to the user.
Any help in this regard is greatly appreciated.
Regards,
Shreerang
So i think you should store custom object in database with its user name so whenever you want you can get back with user's name.