UserProperties being shared between users in Google Apps Script published UI service - properties

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

Related

What is the process for changing the "lead owner" through the salesforce API?

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.

SharePoint Workflow Only Works For Me?

Ok, I have a workflow built in SharePoint 2010, built in SharePoint Designer. It is set up to begin whenever a new item is created. The library is also set up to create new items based on email attachments. So the goal is for users to email the attachments to the library and the workflow takes over.
The workflow only works for me. The other people attempting to use it are listed as Full Control in the permissions. They are using the correct email address, and the library is creating the new items based on the attachments. The problem is that the workflow keeps saying error occurred.
The error says something about some columns needing different types of data, but when I email to the library it goes off without a hitch.
I am completely stumped as to what could be different about them sending the email instead of me.
Sorry I got kind of long winded, and thanks in advance for any help.
The system account is not allowed to initiate workflow on its own. There is a powershell that you need to run to enable system account to run workflow. Also try impersonation in workflow.
Here found it.
stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes
Not sure what was wrong with it, but I just deleted it then rebuilt it and now it works. Don't think I did anything different so I'm not sure.

Alfresco permissions depending on whether document is currently part of workflow or not

Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.

google app script gmail testing

I want to make a clean up script for Gmail to my needs. I happy to use a script, which code I found in a blog, but now I need to modify it.
How can I test it without risking my Gmail box? I'm not good or experienced inJS, so I'm pretty sure there will be some mistakes. And I don't want my emails messed up. Is there a sandbox, or some kind of testing environment?
No, there is not. You should create a test account for you to work with.
Also, when working with your account. You could always just log an action instead of doing it. i.e. instead of
thread.moveToTrash()
do a
Logger.log('move thread "'+thread.getFirstMessageSubject()+'" to trash');
Then check menu View > Logs to verify the actions your script would do. You could also create a TEST variable and use it as condition in your code to determine if it should perform an action or just log it (or both).

Avoid creation of objects through SAP GUI

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..