User Profile
SimonChalfont
Brass Contributor
Joined 9 years ago
User Widgets
Recent Discussions
SharePoint Move File action in Power Automate breaks Document ID Service assigned value
I've posted the full details over in the Power Automate Community forums (https://powerusers.microsoft.com/t5/Building-Flows/SharePoint-Move-File-action-breaks-Document-ID-Service-assigned/m-p/401417) but thought I'd post here to raise awareness. We have had a system in production for a couple of years now, however, in the last week or so we have observed that the Move File action in Flow results in the moved document being assigned a new Document ID when the Document ID Service feature (https://support.office.com/en-gb/article/enable-and-configure-unique-document-ids-ea7fee86-bd6f-4cc8...) is enabled in the Site Collection. This is a change in behaviour for the action as this was not happening previously. To compound this, the native "Move to..." action in the UI works flawlessly and preserves the Document ID assigned to the item. Below is a screenshot of "LibraryA" showing 3 documents, each with a value assigned to "Document ID" by the Document ID Service. I have duplicated these values in a text field called "DocumentID History". I have a Flow that is configured to run when the file is created/modified and a Yes/No field (not shown) that permits a document to be moved, via the Move File action, from LibraryA to LibraryB. Below is the screenshot of after "DocA" was moved via the Flow and "DocB" was moved using the native "Move to" button in the Action Bar. Notice that the Document ID value has been replaced in "DocA" (unexpected) but not "DocB" (expected). This behaviour was not happening a week or so ago and so represents a change in the way the File Move action appears to be working. I have raised a ticket with the Power Platform Support but thought I'd share this with the community now.Modern UI bulk edit changes content type of selected items to first one selected
Update 21-Feb-19: After being acknowledged by SharePoint Engineering, it seems this bug has been fixed now. I've tested on a couple of different tenants, including one on Standard Release. Having spent the best part of a week trying to convince MS Support to escalate to SharePoint Engineering, I thought I'd ask the question here to see if anyone else can corroborate my findings. I have a document library with multiple content types. When I select multiple documents and make a change to a common metadata column (e.g. a choice field) then when I hit save not only do all items get that selected value (i.e. the intended outcome) but the content type of all the selected items is changed to the value of the first item selected (with absolutely nothing done with the Content Type dropdown in the Details Pane). I'd imagine this has some pretty serious implications. Can anyone else confirm this is happening in their tenants too?Bug: Uppercase file extensions cause file to be renamed in Modern UI Details pane [Update]
Update 21-Feb-19: After being acknowledged by SharePoint Engineering, it seems this bug has been fixed now. I've tested on a couple of different tenants, including one on Standard Release. We have encountered an issue that we believe is a bug would be grateful if anyone could corroborate our findings. If a file is uploaded to SharePoint Online with an uppercase file extension (for example, the native Snipping Tool in Windows saves files as ".PNG" rather than ".png") and the Name field is clicked into in the Details pane, then the UI seems to get confused when trying to truncate the file extension from the filename and ends up duplicating the entire filename including the extension. When the user then just clicks away the file gets renamed. Here are 2 documents in a standard document library: Opening the Details pane and just clicking in the Name field results in the entire filename being duplicated: Simply clicking away from the field (i.e. without making any edits) results in the Name field being updated and now the file has a double extension. And you can repeat the process over and over... By comparison, a file uploaded with a lowercase file extension doesn't exhibit the same behaviour: Can anyone else verify that they are experiencing the same issue? Our tenant is on Standard Release. It appears the bug is also triggered by using the "Edit all" link in the Details pane. When the edit controls are rendered the user doesn't even need to click into the Name field as the UI has already duplicated the extension in the filename. Should the user then click "Save" (with or without making any actual other metadata changes), the file is saved with another instance of the extension tagged onto the end of the filename.Re: Modern UI bulk edit changes content type of selected items to first one selected
Hi Elena Nakhmanson , Prompted by your message, I have just checked and the bug appears to have been fixed. I think it is a recent update as I'm sure I checked not that long ago and it was still happening. Sadly, despite raising the issue via Microsoft Support, the only notification I received was that the Engineering team had acknowledged the issue. There was no notification received to say the fix was being rolled out.Re: Modern UI bulk edit changes content type of selected items to first one selected
I think the point is that I am updating existing items that already have applied metadata, including the selection of the content type. In the example screenshots above I've simplified down the content types and columns for the benefit of MS Support (so that there can be no ambiguity about the issue) but in other examples the content type might have many more fields (e.g. "Effective Date" or "Projected Cost") and in the modern UI bulk editing experience if these columns are not modified then the underlying items retain whatever original value they have (i.e. they are not changed). The exception being "Content Type", which is arbitrarily overridden and set to the value of the first item selected. I think the implications of this unexpected (and frankly wrong) behaviour has the potential to be highly damaging especially if processing logic is triggered on the change of items and decisions are based off the Content Type or how it might affect Labels, classification & retention in a large scale document management system. I'm glad that it appears that others are able to confirm that they are able to re-create the issue. Time will tell how long it lands in front of someone in SharePoint Engineering.
