I'm working on a Rails application. Two of my models are notes and attachments. The user can create notes and add attachments to them. This is standard stuff and I already have this working fine.
Currently, the user must create a note before they can add attachments to it. I'm looking to implement a more streamlined workflow for the user, similar to the familiar email workflow where you can add attachments to an unsaved email. However, the key is that I don't want the user to even have to save a draft of the note before the attachment can be added, and I want this unsaved note to be abandoned if the user navigates away (I don't want to have the additional complexity of unsaved/unpublished notes).
I know that when the note hasn't initially been saved yet, I can create the attachments without the link to the note, and then establish the link when the note gets saved. The part I'm drawing a blank on is how do I remove the unused attachments if the user breaks off the note creation process? Is there a hook that I'm missing that allows me to see that the user broke off?
Without such a hook, the first solution that comes to mind is a nightly cleanup script that runs via cron that would find all of the unattached attachments and remove them (perhaps filtering by attachments that have been created more than 24 hours ago). Is this the best solution?
There really isn't any kind of trigger to let you know when to clean those up, since a user can just leave the site without "logging out" or some other action. So that leaves you with a background job not attached to user action. In your case I think a nightly cron is nice and simple and would fit this situation well.
Related
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.
If I make an edit to a Trac ticket, but someone beat me to it, this message is displayed:
Ideally, I would read this message and figure out what I can overwrite and what I should not. But, depending on this message to keep users from overwriting what was submitted is not something that we should depend on:
This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it.
Is there a better way to prevent these overwrites in Trac - e.g., if a ticket has been modified while you were modifying it, you must refresh the page, etc?
Yes, if the server would send the page modified outside and if the javascript running in your browser could merge that into your local changes. But noone has implemented it in the current trac.
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 was expecting this to be a simple thing, but I am not quite sure how to go about doing it.
Basically on the current project we are trialling YouTrack and the agile board is great, but they could do with knowing who raised certain issues in case they need to go question them further on the issue. However I cannot seem to find a simple way to display this information.
I presumed it would be a custom field of type user, but it appears that this would manually need filling in and would not just be able to be pre-populated by the user who is making the task.
So is this possible?
Currently you can view only the assigned user's name on a ticket in Agile board.
I've created a task based on your request http://youtrack.jetbrains.com/issue/JT-19118, you are welcome to vote and leave comments.
As a rough workaround, you can configure notifications on created issues in your projects.
In this way, developers will be notified about all created issues and their reporters.
For that, create a saved search (i.e created by: {Testers}), make this search visible to needed group (by clicking "Edit" on the saved search) and enable notification "on issue created" in user's "Profile". Also, user with admin permissions is able to allow this notifications for all needed users by himself(navigate to "Administration" area -> "Users" -> {user} ->"Profile").
Note, that you can receive notifications both via email and jabber.
Thank you.
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