OK... let me try to clarify. The formulas are easy enough, but part of what I'm describing is a change to the architecture of your record (adding a new field) to more appropriately handle the new information. Let's talk about the new field, first.
You shouldn't task a field in your record to be both (1) the person to whom the record belongs (or is assigned, etc.), and (2) the "signature" of that person acknowledging the record. Each of these jobs requires a field in the list. The first field can show the user's name (in the same bank of info and in the same way that it might show other data about the user -- manager, phone, department, etc.). This is simply normalized data ABOUT the person to whom the record belongs. There's no reason to hide the name, or populate it after a click, etc. The record ALWAYS belongs to that user, at least as far as we're concerned.
The second field, the signature field, then is free to represent ONLY the signature of the user. It can similarly store the user's displayname, but that isn't the point. The point is that, logically, this field is a binary test: if there is data, the record is signed/acknowledged/confirmed. We just happen to choose the user's displayname as the piece of data that we're going to store, here.
If that makes sense, the next step is to think of your usage of the field...
...if the record is "unsigned" (i.e., the field in the sharepoint list is blank), you want the signature field to be blank
...if the record is "signed", you want the signature field to show the data (the displayname stored in the field)
...if the record is blank and the user clicks on a button, you want to automatically fill the field with the displayname
...presumably you would have a mechanic where the user could "clear" their signature -- maybe they made a change to the form and you want to force them to re-sign the form; in this case, you need to be able to "blank" the signature field again
With all of that, you don't want to point the textbox to have a Text property of "ThisItem..." You need a context variable.
1) Add the new field to your SharePoint list (I'll imagine it call DigitalSig)
2) Add a datacard for DigitalSig to your form
3) Create the context variable in the OnVisible event of the screen:
UpdateContext({_DigitalSig: First(Filter(yourDataSource, yourIDField = yourLogicalTest)).DigitalSig})
EXPLAINED:
_DigitalSig -- this is the context variable you are creating. You can name it anything, within the bounds of PowerApps allowed names. I chose a naming convention that appending an underscore ("_") to the beginning of the field to which it was going to refer ("DigitalSig")
yourDataSource -- your SharePoint list, where you created the DigitalSig field
yourIDField -- the field that identifies the appropriate record in the SharePoint list; for instance, if each user has one entry in this list, you probably want to pull the UserID field
yourLogicalTest -- the piece of data that identifies the record in your form; for instance, if each user has one entry in the SharePoint list, you would probably select the current user's UserID (the same piece of data that would be stored in the SharePoint list)
First(Filter()).DigitalSig -- Filter() returns a table; First() returns a record. Since you have a record, you can use dot-notation to get at the fields of the record. This is the field in the SharePoint list that you created to hold the signature
4) Point your textbox (in the datacard for the new DigitalSig field) to show the _DigitalSig context variable. If it is blank (ie., unsigned), the textbox will be blank.
5) In your button's OnClick event, put the following code:
UpdateContext({_DigitalSig: Office365USers.MyProfile().DisplayName})...once clicked, your "signature" textbox will show the DisplayName (your convention for the form being signed).
6) It would be a good practice to now disallow further edits to the form (i.e., navigate them to a Display version of the form)
7) In whatever capacity you want to allow them to edit a previously signed form, you will need to blank their signature, forcing them to re-sign the form again after their edits are done. To do that, use this code:
UpdateContext({_DigitalSig: Blank()})NOTE: since this is a context variable, it needs to happen in the screen where the user would sign. This means you need to make sure this statement runs either AFTER or IN PLACE OF the UpdateContext({)} statement mentioned previously that fills the variable. An alternative would be to use Patch() to blank the field at the SharePoint level BEFORE navigating to the form to allow edits of the record. In that case, the context variable would be blank when it went to pull the field from SharePoint.
This should satisfy all of our use-cases, and should function the way you expect it to. Post back if you still have questions.
