I'm trying to keep track of the number of comments made about a user in my application. These comments can be made by other user and of course these other users can't update the User they're commenting about. So i was wondering if there was any way to do this with Cloud code on Parse.
Edit :I'm also looking to update a value called "latestPostTime" that will get the current time of the latest post. any help would be amazing thank you
You can, have a look at beforeSave and afterSave triggers. For example you can create an afterSave trigger for your comments class and then update the user object the comment has been made on/about.
Have a look at the Cloud Code documentation for the triggers, that should help to get you started.
If you run into ACL issues, you can enable usage of the master key in a Cloud Code function as well to update the count field of the user object.
Related
I have a custom module for user to upload some information and files
I can use forms and make the module accessible from the website but I need them to be able to edit there recored also, exactly like if they are internal user but only for y custom module
anyone knows how to do that thank u very much in advance.
edit
after reading the comment of #KevalMehta
I think my question should be how to update a record from a form
this is my code to create a new record in my module
request.env['manager.create_company_link'].sudo().create(kw)
so first I think I need the id of the record I need to update before how to update it
I thing #KevalMehta is referring to me using .sudo() how to give the right access
Currently creating an automation using zapier which should change the lead owner in salesforce when the event takes place. It successfully reaches salesforce but does not actually change the "lead owner" but it is instead reflected in the lead history section. There is no clear salesforce workflow or rule in place which should prevent this automation from occurring.
When the automation executes as you can see above, the lead owner successfully changes in the lead history but it does not actually change the lead owner of the actual lead so we are manually having to go back and change this.
Has anybody else faced similar issues when working with the salesforce API when changing the lead owner and if so what was the solution?
Check Lead assignment rules. It's separate area in Setup, different from workflows, flows, process builder and triggers.
You probably have an active rule that runs on update, not only on insert. Your API call works OK, changes the OwnerId field but then the assignment rule overwrites that. That's why you see it as 2 entries in history.
You can also confirm what's going on byenabling debug logging on the integration user and check if it captures anything.
Optionally you could also suppress the assignment rule during the update. This is... questionable. I mean talk with your SF admin first, if you suppress the rule then you moved bit of logic out of salesforce. 2 months later nobody will remember why something doesn't fire, it's cleaner to just modify the rule to skip these records.
If Zapier uses SF REST API there's a HTTP header it should send, Sforce-Auto-Assign: FALSE. If it uses SOAP API - similar thing will have to be set in the SOAP message's header, check the WSDL for exact syntax?
We solved this, just broke down the issue and resolved by doing the following (This was beyond the standard salesforce scope of support as we use custom prefill URL's for anybody wondering):
Create a new hidden field called something such as 'tmp_owner'
Assign the new lead owner ID to a new text field called 'tmp_owner' which is hidden on
the lead field to other salesforce org users
Added a salesforce workflow rule when this 'tmp_owner' is populated replace the 'lead owner' field with the data.
I can see that getRecord call has CREATEORREAD action. Is it possible to make it read only? I need it to properly limit client permissions.
Thank you in advance!
Do you mean to avoid creating it if user does not have permissions? If the user does not have permissions for UPDATE or PATCH this will stop him from being able to update anything, but we don't yet have an individual READ action to avoid the record from being created initially. We'll raise that as an issue and try implement it soon.
Edit:
Issue created on github
As a tester, I'd like to know whether it is possible to restrict the manual creation of new objects by the user. The restriction should be done programatically in ABAP, not by removal of permissions.
Background information: we have quite complex objects which are hard to set up manually. Therefore we have implemented a wizard, which does all the condition checking etc. when creating the object. Also, if the wizard shall work, the user must have appropriate permissions to create the object.
Is it possible to remove the object type for that complex object from the list which appears when creating a new object (pressing the New button)?
As I'm only a tester for this part of our software, I can't show any existing code. I just got the feedback "It's not possible" and that's hard to believe for me at the moment. Usability really suffers, because people try to create those objects manually and can't make it work.
I also don't need a working code example, just a hint (class or method or setting) for the developer where to find a solution. I'll then insist that he implements it :-)
Update
Today, the user can click the "New" icon. Then, a dialog appears with 4 choices. 3 choices are for simple objects which he shall create like this. However, the first item in that list is for the complex object, which is impossible to create manually (why we have the wizard). I'd like to know whether it is possible to remove that item from the list programatically.
ᵺṓᵯᶏᵴ, the information you have provided is still a bit vague. However, here is an idea that may work for you.
It might not be possible to completely automate this process, but you could ask your developer to enhance the code that processes the New button, so that it would reject any attempt to bypass the wizard for the first item on the list.
Your developer can tell you if it is feasible in your case, to have the enhancement raise an error (message of type E) to stop the user from proceeding.
This would have to be combined with end-user training to tell people to avoid the New button for that item, and use the wizard instead
ᵺṓᵯᶏᵴ, it looks like a custom dialog so it should be possible to remove it the option, alternatively if it is a standard dialog in a SAP app there is always a way to restrict it, it can be as simple as disallow entry from specific transaction codes. for example the developer could set a variable at the start of the wizard and then check for that variable when creating the object, if it not there he can show a dialog "Please use the Wizard we carefully crafted for your use......" Ok maybe you wont say all of that but you get it.
So the answer to your query is yes it can be done but the approach will depend on what it is your changing custom or standard object etc,.
Later..
I am working on a google apps script that is being published as a service, and accessed by multiple users via the UI.
The problem I'm having is that when one user causes a UserProperty to be set, all the users subsequently have their UserProperty set to that also. In other words it is acting like a ScriptProperty, rather than a UserProperty, in that it is not User specific. All users appear to cause this to happen.
I have studies my code and I just cannot see that it is anything to do with that. I make no reference to EffectiveUser, so only ActiveUser could ever be setting these values.
My guesses are:
- I am misunderstanding the scope of UserProperties
- My variables have somehow become corrupted (I have had problems with other UserProperties variables doing some odd stuff)
Has anyone experienced this, or does anyone have any suggestions?
Regards
Chris
UserProperties are better suited for scripts that run inside Spreadsheets and not published ones. The reason is that a published script runs under the user id of the user who created the script and not as the person who invokes it.
So, if the script is written by someone#example.com, then the UserProperty will be that of someone#example.com irrespective of who invokes the script. So, when one user writes a UserProperty, all others see the same value