We're using CRM 2011 here, soon upgrading to 2016. We have a deployment issue right with 2011. We have a way to export & import custom JavaScript for several of our Forms. However, one of them is missing an OnSave event handler. I don't know how to explain this without getting down into the weeds, so here goes.
In CRM 2011, if you open up a new form and go to the Customize tab on the ribbon, you can select "Form" from the ribbon. Clicking that opens up a new page. On that page, there is a "Form Properties" button. Clicking that opens a Form Properties dialog. Under "Event Handler", you can specify JavaScript methods for particular events. In our case, it's the OnSave event we want to assign to a JavaScript function. Doing that is not a problem (in a new dialog, you just enter the function name). But we haven't found a way to Export that selection.
We can export the page in a solution. But that just exports the JavaScript (and maybe some other settings on the form), but it doesn't save this one setting. Is there a way to export the setting so it can be imported?
The deployment guys just want us to include instructions on how to do it manually, but I figure there must be some way to export/import this selection. After all, there are dozens of forms, all with their own settings.
Things to keep in mind and also a few best practices:
Always use a solution for all of your customizations, even if the
change is as small as the one you have listed, refrain from making
changes to the default base solution.
After you customize your form (adding event handlers, adding removing fields) always save and publish so your solution when exported has the latest changes.
Keep an eye on the import order while importing unmanaged solutions as the last one always wins (overwrites the changes of the previous solution).
Upon importing the solution to the target system, always publish to ensure the changes are promoted right away.
Updating the answer based on the comment history:
You need to export the entity form for the event handlers to end up in the target system. Create a new solution, add the entity and the form, export the solution and import it to your target system
Related
I've created a version tracking that will show all the edited document inside view. What if I want to make all document be draft at the same time, and during that, document can't be edit. And after I click save, all draft document will be saved at the same time.
Edit 1
I have one more question when I do version tracking, how can I make all response document cannot be edit? only current document can be edit?
UPDATE QUESTION
Currently, I am using version tracking to show all list with all edit document. So for now, every time I click EDIT, it will show all history of updated.
So I want create a situation where I have 2 edit option which is EDIT and PC Specification. I want to set PC Specification after edit document, it updated all history under version tracking, but for EDIT I don't want it update under version tracking. Because, for EDIT function, it only for edit one or two information BUT for PC Specification, it is to update all information. For example, I have 3 documents inside the "Computer" view.
When I open one document, it will show document details. On top menu, I have two buttons which are Edit and Close Windows. So can I add one more toolbar? Which is PC Spec as below?
So I will click the PC Spec button on the toolbar then the documents will open as a new document with same document information. Same as edit function. After I click save, it overwrite document + show edit history
For another situation where I click EDIT, same as PC Spec but after I click save, it overwrite document only.
As shown below, the history is when document edit using PC Spec only.
Another question, I have "Archived" view. How can I show only history of document inside "Archived" view?
Hope you guys can understand this. Please ask me anything if you not understand. Any help will be appreciated. Thanks! :)
Regarding your second question, to make all response documents non-editable, you will have to
Give your regular users Author access instead of Editor access in the database's Access Control List and assign them a role, which I'll call "AppUsers".
Give yourself and anyone else who will be responsible for managing the app a role which I'll call "AppAdmins".
Add a hidden computed field with type "Authors" to the form and set the initial value formula to
#If(#IsResponseDoc;"[AppAdmins]";"[AppUsers]":"[AppAdmins]")
Note that this will not have any effect on existing documents until you refresh and re-save them.
Then, you're going to have to hope that automatic versioning refreshes the documents. I'm not sure if it does or does not. If it does not, then you're probably going to have to give up on using the native versioning and write your own version using LotusScript. As I recall, that's what was done in the standard Lotus document library template, because the native versioning is pretty limited in what it can do.
As for your first question, I'm sorry but I really don't understand what you're asking. I can't tell in some parts whether you are telling us what you have already done, or what you want to do. Here on StackOverflow, the best way to get useful answers is to show us very clearly what you have tried, tell us what happens, and tell us what you thought should have happened instead. This is a place for helping you fix your code, not a place to get tutorials that amount to explicit instructions on how to write your code in the first place.
I have a ribbon button on the case entity that updates a single two-option field on the form via javascript. When this is used on a case that has been resolved/closed it returns an error as the form is now read only.
Is there a way in javascript that I could get it to re-activate the form, change the field and then put it back to the way it was before? I have tried to force the change on the form but even if i manage to make it appear that you can save it, it will return the error as the form record is still counted as de-activated, even though you can change the fields
Thanks
You should be able to use a SOAP call for this, its a little involved, I would suggest starting here. You have to generate XML that represents the request, the link provides some tools to do this.
I believe you will need to issue JavaScript versions of SetStateRequest (to open) and CloseIncidentRequest (to close).
On the other hand, which is a different approach entirely, is to disable the button when the record is deactivated, then users have to manually renable the record make the change and close again. This is closer to 'working with the system' which I have touched upon here, its a different situation but the principle still applies.
Here's the deal, I have various event receivers registered to a document library:
ItemAdded
ItemAdding
ItemFileMoved
ItemUpdating
These event receivers work as expected in all cases, APART FROM copying and pasting into explorer view. It's worth noting that the event receivers do fire off when MOVING from explorer view into explorer view!
Has anyone else experienced this? Is there a way to fix this?
Workaround:
Create a SharePoint Designer Workflow, attach it to your Doc Library.
Make it run when the item is changed or updated
Give it a simple step with the following Action (no conditions)
Update field in the Current Item
Select the "Title" field, set it to "Changed".
You are probably able to capture the events from your .NET logic now.
The problem you are encountering is one of the most annoying features of SharePoint, for some reason it not only overlooks our metadata requirements but also the events you are trying to capture when using the explorer view or unc path. I beleive the only workaround for this is to create a WWF workflow.
If you are thinking of keeping the drag and drop functionality, and losing the Explorer view, you might want to look at this..
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.
I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.
Is this expected?
How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.
FWIW, this is the MOSS 2007 Standard version.
Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.
I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.
To give you a few hints and tips, the following should set you off in the right direction:
Created a new list definition.
Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
Copied the standard Rendering Template, but then made the changes to it that I
needed.
Wrapped it all up in a solution, and deployed.
My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.
Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.
I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.
Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}
Perhaps they grab the context back each time programmatically using these values.
I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.
I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.
I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).
Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.