Recently, we updated the URL for our Sharepoint site. I have added AAMs to direct any users trying to access the site through the old URL to the new URL. So far, everything has been working fine. Recently, while browsing through a document library, I noticed when I clicked on the ellipses on the name of a document so I could copy the link associated to the document, the URL appears as http://NewSiteURl/http://OldSiteURL/...
I notice it is not every single document in my library that presents links like this, but I do notice it in random documents throughout the library. How can I fix this issue so all links to documents within the library so it doesn't contain the old site url?
Related
I am working on an automate flow that emails a share point page to a list of subscribers whenever the page is updated.
Everything works except the links contained in the email (/page). On share point i am able to navigate to the link however in the email the page redirects me to /sites/xxx/xxx.aspx. It is missing the tenant information.
Is there a setting i missed or something that is preventing sharepoint from including the full link when sending the email?
I made sure the full link was typed when the hyperlink was created and am using an HTTP to share point (in automate) and inserting the "CanvasContent1" into the email. I checked the html being sent and the link title is given as the full link but the href is given as /sites/xxx/xxx.aspx.
Thank you for everything
On a SharePoint page, links will be converted to relative links when the page is saved.
If you copy the page content as rendered into an email, then, yes, the tenant will not be included in the link, since the link is never intended to be used outside of the context of the page, where the link works fine.
So, you need to change your approach when emailing the page. Maybe email just a link to the page, then people can take it from there. Or, manipulate the html content in PowerAutomate and replace /sites/xxx with https://Yourtenant.sharepoint.com/sites.xxx
I have a question about sharepoint combined with the graph API. I'm trying to do a GET request against a sharepoint site, but it doesn't populate when the url has a .aspx extension. For example if I do 'GET https://graph.microsoft.com/v1.0/sites/hostname.sharepoint.com:/sites/blablabla/UK' this populates a response fine, but if I do 'GET https://graph.microsoft.com/v1.0/sites/hostname.sharepoint.com:/sites/blablabla/UKDTAppKZ/something.aspx' then I get a 404 error suggesting this site doesn't exist... Could I get some clarification on how to use graph GET queries with sharepoint urls, specifically .aspx extensions?
In your first URL you're accessing the Site object for the /sites/blablabla/UK sub site, so you should get back a valid site object (assuming the URL is correct) as you indicated. To access the files in that site you need to access the Drives (Document Libraries) and then get the children or the specific item you're looking for. So the URL would look something like:
Path support isn't always consistent right now so wherever possible I like to use IDs if I know them.
So with an ID it would be:
https://graph.microsoft.com/v1.0/sites/HOSTNAME.sharepoint.com,SITECOLLECTIONGUID,SITEGUID/drives/DRIVEID/root/children
OR
https://graph.microsoft.com/v1.0/sites/HOSTNAME.sharepoint.com,SITECOLLECTIONGUID,SITEGUID/drives/DRIVEID/items/ITEMID
For Pages specifically though I would take a look at the Beta Pages API we added recently. If you want to do any operations (like publishing) to the page you'll want that API instead of the basic drive API.
The context here is that, in a CMS type of app, the users that create content like to reproduce Notes' way of having attachments anywhere in the text, not just a list of attachments at the bottom of the page. When creating a page, they want to be able to create links to the attachments right away, using a link and an img tag, not saving the document first and then edit it again.
I have found the YouAtNotes HTML5 Multi File Upload control, which enables the users to upload the attachments before the document is actually saved. The URL for attachment uploaded befor ethe doc is saved is then:
http://myserver/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I use this URL in the CKEditor to create an image and it looks OK: the image shows up in the editor and has this URL:
/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/insanity.jpg
I then save the document, and it still looks good. The image is showing up and the URL is still:
http://myserver/mydb.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I close my browser, and open up the page again, and now I see that my image is not showing up, but the URL is still:
/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
But if I look at the URL that is used by the download control, this is what is has:
http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg
Why did it change?
Is there documentation on how that whole attachmentprocess works, so I can understand it and give proper indications to the users so they can create valid links.
We also have a particularity in our publishing code: we need to keep the UNID of the published document so links that were made using UNIDs are still working. It is an app with a lot of content and many external apps link to it. So when we publish, we actually copy all the content of the draft into the already published document, so the UNID is different from the draft document, and we have issues with attachment links because of that. But that is something else...
The URL "/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg" relates to a temporary location before the docment has been saved. This is standard functionality because
For SSJS / Java to save an file into an NSF, it's got to have been uploaded to the server prior to the commit.
The user has not chosen to save the file yet, so it shouldn't be added to the NSF.
The document hasn't been saved yet, so even if it should be saved to the NSF, no document yet exists to save it to.
The components of the URL are:
"/Belair/xBiblio.nsf", the URL of the database it will finally need to be committed to.
"xsp/.ibmmodres/persistence", a URL that corresponds to a physical folder location where temporary files for this NSF are stored, based on xsp.properties of the NSF; if nothing is defined in xsp.properties of the NSF, xsp.properties of the server is used; if nothing is defined there, a default location is used.
"DominoDoc-NEW_569", a temporary reference to the new, unsaved dominoDocument datasource. If you close the browser and re-open it, you'll be getting a different temporary dominoDocument datasource reference, so I wouldn't expect the image to show up. Otherwise, different users could get one another's attachments.
"-Body", the field the file needs saving into.
"/indifference.jpg" the file name.
Once the document is saved, the file is stored into the Body field of the relevant document, and the file system cleaned up. The URL has to change, because otherwise the attachment would not be available on other replicas, because only the database gets replicated, and it could not be managed by DAOS.
The new URL "http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg" corresponds to:
"myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment", shorthand URL to open the relevant attachment.
"/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE", the location of the document the attachment is stored in.
"/Body", the field name.
"/indifference.jpg", the attachment name (the field could have multiple attachments, of course).
The information above is based on what has been documented in XPages Portable Command Guide (for xsp.properties settings for changing the default temporary locations) and Mastering XPages 2nd Edition.
I'm not sure what the YouAtNotes uploader does, so I can't say whether it should be changing the URL or not on save. But in more recent versions of Domino, attachments can be uploaded without a full refresh, which may be of use as an alternative.
When you're copying documents, if you're storing HTML that references images by their URLs, including UNIDs, you'll need to modify those references.
If you want to keep UNIDs, remember that they are read-write - you can set them as well as get them. However, bear in mind that you'll have problems if you change the URL to the same URL of an existing document. Bear in mind this is also XPages, so the data accessed via the XPages applications don't have to be in the same database.
i need to redirect the current user to a custom url after successfully uploading a document.
the user clicks "+ new document" in the document library
the user selects a local document
the document gets uploaded and in that moment after it is successfully uploaded and the item is created in the list, i want to redirect the user to a custom url
Normally after successfully uploading a document to a document library under SharePoint 2010, the user gets a modal dialog where he sees only the field "Name" with the filename.
I want to prevent this. How could i achieve this?
Update
Isn't it possible to redirect a User after Document uploading inside a Document Library to redirect from Upload Form to a custom page instead of Edit.aspx within ann EventReceiver?
I am really frustated! I am now trying for over 3 days to get it working.
Here is my sample solution:
http://www.bog1.de/downloads/errd01.zip
You must create a document library "doclib" to get it work.
But it does not work! I have used samples from several sites. I have added the logic inside the ItemAdded event. But nothing happens. I only want to redirect the user to another page after successfully adding a document to a library. Is this such a hard problem to get it work untder sp2010?
It seems, that it is not possible in SharePoint 2010 inside an EventReceiver to redirect to a SharePoint page withoug haveing a modal dialog as in CancelWithRedirectUrl.
After using Zend_GData to retrieve a document list feed, I can use the content URLs in the form:
http://docs.google.com/document/edit?id=<docid>&hl=en
but the source URLs in the form
http://docs.google.com/feeds/download/documents/Export?docId=<docid>&exportFormat=html
are returning 404 errors. That URL should return the content of the document in the requested format but it is returning 404.
This problem is mentioned without resolution on a Google API forum. As indicated in that forum post, this problem only seems to affect new documents. My code works perfectly retrieving old documents, but new ones are 404.
Has something changed in the way Google references new documents or in the way permissions are assigned?
The code I'm using is essentially the same as the code on this page but this does not seem to be an issue specific to PHP/Zend_Gdata.
This appears to be a bug in Google's code. Fix pending:
http://code.google.com/p/gdata-issues/issues/detail?id=2023
Apparently, the (current) correct download URL for a document is
https://docs.google.com/feeds/download/documents/export/Export?id=<docid>&format=<format>