Patch Defaults no longer working correctly

[Slaverty]

Hey all,

*** EDIT***

Ok, so solved this simply by removing the "Required" property of each column within Sharepoint.  Still think there's something odd about this behaviour though.  Unless I added the "Required" property after I tested the code, pretty sure this isn't how it used to work, and it can make forms a little trickier to deal with if you're relying on the "Required" field.

*** EDIT ***

Am I going crazy or is Patch Defaults no longer working right?  Specifically, using Defaults but specifying other columns too.

I've got a Sharepoint list with user settings in it.  The settings all have default values assigned within Sharepoint (size, colour ect), and for months I've had a bit of code in the OnStart of my app which does the following

Patch(Source_UserSettings, Defaults(Source_UserSettings), {FullName: User().FullName})
Source_UserSettings being my Sharepoint list.  All of a sudden, I'm testing something else out and discover this no longer works!  It seems to ignore the default values and gives me an error "Size: field is required". 

Using

Patch(Source_UserSettings, Defaults(Source_UserSettings)) 
works just fine, and my columns are populated with the correct default values by Sharepoint, but of course I now have no username tied to the settings so they're useless.

After some googling there's quite a few posts suggesting my exact syntax, as well as the manual pages, so not sure what's going on...

Anyone shed some light for me please? 🙂

[Pstork1]

If Fullname is a field in the SharePoint list then your Patch syntax is correct.  I just tried to reproduce your issue and the syntax still works for me.  One potential problem could be that you are using the same field name in SharePoint that is used by the User() function.  Try the same syntax but use a different field.

[WarrenBelz]

Hi @Slaverty 

I suspect @Pstork1 is correct here - I have had some bad experiences using "reserved" words as variables or field names. The problem is just what you are experiencing - you get no errors, but it simply does not work.

[Slaverty]

A good shout, but unfortunately made no difference.  

So I created a new Sharepoint list, importing my original UserSettings Excel sheet but with the "FullName" column changed to "FullNameTest" (prior to import).

I also created a brand new Powerapp to make sure none of my other code was interfering.  The new Powerapp has 2 buttons and nothing else besides some forms that display a locally created collection.  These buttons patch back to each UserSettings list.

New code is as follows

RemoveIf(Source_UserSettingsTest, FullNameTest = User().FullName);
Patch(Source_UserSettingsTest, Defaults(Source_UserSettingsTest), {FullNameTest: User().FullName})

Still get same error, "Size: Field Required".  Taking out the first line makes no difference either, though the first line does successfully remove entries.

The columns in my list are as follows

ID, FullNameIGNORE, FullNameTest, Size, IcnSizeMultp, Shade, PrimaryColour, __PowerAppsId__

The ID column is auto generated by Sharepoint, and similarly the __PowerAppsId__ was auto generated by Powerapps.

The "FullNameIGNORE" column was due to Sharepoint locking down the first data column during import, so I duplicate the first column so I still retain control over the copy.  The "IGNORE" column is usually hidden and ignored by app.

It's almost as if when Powerapps calls the Defaults when other columns are explicitly specified, it tries to do so by creating a new, blank record, which Sharepoint rejects as certain fields are marked as required.

[WarrenBelz]

Hi @Slaverty ,

The may be a bit "left field", but I never use User().FullName directly - I always set a Global variable at App Start Set(vUser,User().FullName) and then use that for everything related. It also gets around delegation issues.

[Slaverty]

@WarrenBelz, thanks for the suggestion!  Whilst it doesn't resolve this problem, it does get rid of all those pesky delegation warnings which was on my list to fix!

But yeah, same situation using "gloCurUser" in-place of "User().FullName" and defining gloCurUser on AppStart

[WarrenBelz]

Hi @Slaverty ,

I am really wondering why 
Patch(Source_UserSettingsTest, Defaults(Source_UserSettingsTest), {FullNameTest: gloCurUser})

is not working - it is the most simple Patch (one field in a new record)

I will go further left field - you can use Collect to write new records to SharePoint so:-

ClearCollect(colUser,{<YourSPFieldName>:User().FullName});
Collect(Source_UserSettingsTest,ColUser)

[Anonymous]

Just following along in this thread because I've had a simple Patch() function start doing some strange things as well in the last couple of days.

My situation

- gallery with Items set to a collection built from SP

- inside the gallery, a number of textinput fields

- OnChange event for these textinputs set to Patch( myCollection, ThisItem, {myColumnName: textinput1.Text} )

- simple

This was working Friday but not today. I have made some changes throughout the app but none that I can think of that affect this Patch. 

Only thing I can think of is that some of the columns in my collection have become corrupted, somehow? Not even sure if that's a thing? I'm going to try renaming this collection tomorrow, a big job in this app, and see if that corrects it.

@Slaverty  Like you I built a simple test app and this Patch function worked no dramas

[Slaverty]

@WarrenBelz 

I gave the collect a shot, but it did nothing.  No errors, no changes to the data source, just sat there.  Tried messing around with adding a Patch to your snippet of code but the furthest I got was getting an error "The column "Author" doesn't exist".

@Anonymous 
Frustrated to hear your new Powerapp worked without issue.  
I ended up creating a brand new Sharepoint list, Source_TestingList

This list contains 5 columns,

TestingA, TestingB, TestingC, TestingD, TestingE

Each column A-E has a default value of 1-5 respectively.

Using the following code in my brand new Powerapp:

Patch(Source_TestingList, Defaults(Source_TestingList))

Works and the table is populated with 1-5 as it should.

Using:

Patch(Source_TestingList, Defaults(Source_TestingList), {TestingA: 2})

Provides error "TestingB: Field Required"

Removing requirement from TestingB column produces error "TestingC: Field Required"

Removing requirement from TestingB-E (So only A is required) works, the data is added, B-E populated by default values and A populated with "2"

But @Anonymous , regarding your situation, I don't believe Collections can be corrupted as they're created from scratch when the app starts.  I did wonder the same during my own app development, though, as I was getting strange things.  It turned out to be a type mis-match between the collection definition and an object that was using that collection entry, eg collection created with ColumnA in type TEXT, but object is expecting type NUMBER.  I, like you, renamed my entire collection throughout the app before discovering this.  Wasn't till I came to renaming one particular part that I saw the error and realised the problem.

[Anonymous]

@Slaverty 

Yes, I think mine is a type mismatch. I changed a variable type (Record --> Date) today but thought I double checked EVERYTHING first, I may have missed something? Lots of boring debugging tomorrow, haha