This is probably a simple answer (I hope it is). I just haven't figured it out yet. I have an Accordion Container with Navigators. In my database I have a normal Notes document being used as a profile document for the user. I simply would like to open that document from a link on the Navigator in edit mode but I can only get it to open a new doc. Also, need to check to see if the profile exists and if not, open a new one. I can open it if in the xPage I set all the fields manually but when it saves, it creates a new document. Maybe this is the answer, how do I set the data source (document1) when the xpage is opened. Thank you for your expertise.....
Without seeing what you have tried, I'll suggest a technique...
In the Data definition for the <xp:DominoDocument> set the ignoreRequestParams="true" then compute the <xp.this.documentId> to be the unid of the Profile document. (This assumes that the "Profile document" is a standard Notes document and not a Notes Profile Document. The latter have many issues and is a bit difficult to acces and manipulate using XPages.)
Related
Appreciate your help.
I have old lotus notes database. Even having manager access it cannot open in designer.
So, took archive of the database was able to open in designer. Now when I am trying to open code of agents, scripts, formula, etc in current lotus notes version 8.5.3.
It throws error "the design element is hidden and cannot be edited".
Please could you guide on how to view code.
You have a database with hidden design here. Unless you find the template, that it was created from, there is no way to "unhide" the design as it is only stored "Compiled" in this case.
It it possible to get back "some" of the information using a HEX- Editor on the nsf file, but this will not bring you further than you already are with your backup: You can open in designer but not see any formula (in forms or views)...
When updating a database from a template you can choose to "Hide formulas and LotusScript" and this will result in what you see.
Some vendors already hide the design of their templates to protect their intellectual property. In that case you will not find an "open" template and cannot get the code back.
I am trying to insert the version number stored in SharePoint Online into my Word document - I've done the following thus far:
Activated the Library and Folder Based Retention Site Collection feature
Checked "Enable Labels" in the Information Management Policy Settings for the Document Content Type, and entered "{Version}" into the Label format field
Created a Word document in my library
Opened the document in Word, and inserted a Quick Part (Document Property > Label)
What shows up on the document is {_UIVersionString}, not the actual version number. Not sure what's going on - it seems so close.
In my test, I cannot reproduce your problem.
I can display the correct version number in the document. Below is a screenshot of my test:
This may be caused by the cache, I suggest you to clean up the cache of the SharePoint page and Office first.
You can provide your detailed screenshots, which can help us solve the problem better.
How do i restore a deleted NewForm.aspx file?
I dont want it back through the recycle bin, since i made a mess of it, i just want to recreate the original file.
Sharepoint 2003 was able to do this.
could you restore it from the recycle bin and then in sharepoint designer try a "restore to site definition" (right mouse click on the file). P.S. Never change the out of the box newform / editform etc. Copy it, then in the list settings in sharepoint designer (right mouse on list) set the newform property to point to the new copied custom form. This way you can alwys go back by just resetting the property in the list settings instead of getting the problems you have now.
Here's an in-depth explanation: WinSmarts article
As Colin mentioned, always make a copy. Of course, you can recover from deleting or corrupting your newform but it's a little bit of a pain. SharePoint's odd behaviour causes lots of people to do this... very often we create a new SharePoint form but the list refuses to use it as a replacement newform or editform so we delete the original.
Off of the top of my head, I believe you can copy the newform.aspx from another list or library and then update the GUIDs in the source view. Once you retrieve the file, however, you will have to complete 2 additional steps in order to get it to work. SharePoint requires a strange synergy between lists and libraries and their supporting pages. People are aware of the first, which is called Supporting Files, by right mouse keying on list you can choose supporting files for display, edit and new. What most people don't know is that these files, well actaully their components, must be "aware" of the fact that they are of type display, edit, or new. If they are not "aware" then any changes you make to "Supporting Files" will not stik.
To create a new page or update an existing one, locate your newly created or broken newform.aspx, if you are creating it from scratch go to Insert >> SharePoint Controlls >> Form Web Part... select the form web part of your choice and add it. Upon insertion view the properties of the form control andselect the radio button "NEW ITEM FORM". After you save the page you can then select the page as a supporting file for the list and the setting will stick.
The best options is as follows:
Simply delete the bad ListFormWebPart form page if it still exists
Make a copy of one of your good ListFormWebPart form page
Rename the copied ListFormWebPart form page to whatever the name of the bad one was
This works for New, Edit and Display and is the best option because it basically restores you back to the factory default OOB ListFormWebPart instead of creating DataFormWebParts, which have their pros and cons.
I have had to deal with corruption issues with Sharepoint so this is somewhat related.
Create a new list and using SPD, Copy the WebPartPages Section:
<WebPartPages:ListFormWebPart runat="server" __MarkupType="xmlmarkup" WebPart="true" __WebPartId="{203BDF1B-4980-4FEF-A4B5-C5A4C4A1BFA7}" >
...
</WebPartPages:ListFormWebPart>
Now in your list with the corrupt or missing form. Create a new form with SPD. Yes we know it's not the same. Bear with me.
In the WebPart Pages you copied from the donor list you need to replace the ID, webpartid, ListName id and, ListID from the new form you just created onto the save we pulled from the donor list.
On the Newform you just created. delete everything between and replace with the modified donor webpart you just modified.
Save and visit your new default form.
For what it is worth, I was able to recover.
Here is what I did. First, I mapped my Share to a Z drive.
Then, in SharePoint Designer, I renamed my list to list-bak.
Then, I created a new list of the original name (in SharePoint Designer).
Then, I updated the ListName GUID in the EditForm for the New List.
Next, in Command Prompt, I moved my dummy list to bak2, and moved by bak list back to the original name.
At this point, I had my EditForm restored, but it still wasn't working (as it was trying to reference the EditForm.aspx from the bak2 list).
Finally, I moved the EditForm.aspx from the bak2 to the original list, and was able to restore.
I hope this helps some other poor sap.
EDIT: to the OPs question, obviously you would do the same steps, but with NewForm instead of EditForm
I am trying to create a link to an existing Shared Documents folder on another site. Both sites are on the same server.
Here are the steps I take to create a link to an existing Document Library:
I create a document library web page in Share Point 2007.
I open the document library (AllItems.ASPX) in Share Point Designer.
I delete the existing web part for the list.
In the Data Source Library, I click on "connect to another library" and create a connection to the other site.
I select the document library, click show data, select my rows and click Insert Multiple Item View.
I then configure the look for each field (hyperlinks, etc).
I edit the Filter for this view to show only the files that are for this location.
I click on Data View Properties and select "Enable sorting and filtering on columns (basic table layout only).
Basically I am trying to have a central location for all files for a site and sub sites. I want the sub sites to see the documents for their own location, be able to search through the files, etc.
The problems I am having are:
I am unable to open the links in a new window, even when I set the hyperlink to do so. I would prefer the file be opened in its native application (ie. A Word doc open in Word).
I am unable to show the file icon in the same way it shows up in the original document library.
When I go to the header and click ANY field, I can sort the field ascending or descending but I always get a message stating "This column type cannot be filtered".
Is there an easier way to do this? Or can someone tell me what I am doing wrong? I am new to using Share Point. Thanks for the help!
Some help for problem 1 (unable to open the links in a new window)...
I'm not sure if this will work using the Data View Web Part you have configured. However there is a technique for the List View Web Part. If you add a boolean field called OpenInNewWindow to your document library then documents that have this set to Yes will open in a new window. Try this out - it may work.
If you need to open PDF files in a new window, beware that there is an ActiveX control that will get in the way. Read this question for more information.
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.