cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Helper II
Helper II

Use button to fill in data card text box with Office365Users.MyProfile().DisplayName info.

Is it possible to do this. Use button to fill in data card text box with Office365Users.MyProfile().DisplayName info?

1 ACCEPTED SOLUTION

Accepted Solutions

I think something got lost in transmission... if you are going to match my naming suggestions (or even just to make sense of my naming suggestions) this is what you would have to do:

 

SharePoint list field is named "DigitalSig"

DataCard on form is named "DigitalSig_EditScreen" (or something similar... something NOT "_DigitalSig")

Context variable is named "_DigitalSig"

 

Then put the code into the various parts of the app as I described (creating the context variable in the OnVisible event of the form, changing it in the button OnClick, etc.).

 

Finally, make the Default of the DataCardValue51 control to be "_DigitalSig"... if you do NOT have your datacard named this, there should be no confusion, and the app should read the context variable into the textbox.

 

 

View solution in original post

14 REPLIES 14
Solution Sage
Solution Sage

Chances are your datacard box is going to have something to do with the thing that is the ThisItem... and if you don't hit the button but you have data in that part of ThisItem, you want that data to display, right?

 

For instance, User1 creates a work order and puts some value in a field. Later, User2 opens the work order because some bit of the work has been completed, requiring the data to be specifically updated (maybe zeroed out, maybe set to "Complete", whatever). Until that button is hit, though, you want to show the original data that User1 entered.

 

So set the button to update a context variable:

UpdateContext({myFieldOverride:"Completed"})

...and in the DataCard textbox, use an If() statement to check if there is a value in myFieldOverride:

If(IsBlank(myFieldOverride),ThisItem.myField,myFieldOverride)

Completely air coded that, but it should work. Smiley Very Happy

Hi TimRohr,

 

Thanks for responding so quickly. You are on the right track on what I want to accomplish but essentially the field would be emply until the user clicked the button and then I would fill with the users Display Name. I have an edit form where some of the data cards autofill with info. For instance, the Employee Name data card has Office365Users.MyProfile().DisplayName in the DataCardValue box. Right now it happens automatically but I want to control it with a button for another DataCard. I hope that make it more clear. 

It should work to just sub in the DisplayName portion for what you store in the Context Variable:

 

UpdateContext({myFieldOverride:Office365Users.MyProfile().DisplayName})

 

The trick is just making sure you don't overwrite the data that might be there that you want to keep... that's where the If() statement comes in.

 

For instance, you want to track who picks a ticket up out of a queue first, you can fill the context variable on the button click. Set the CV and have the textbox set to read that. In order to avoid someone else overwriting that, you need either an If() on the button click, or on the Text property of the textbox. Hope that makes sense.

So I think we are almost there but there is one issue. I added what you suggested to the button "UpdateContext({myFieldOverride:Office365Users.MyProfile().DisplayName})" and for the DataCardValue box I added this "If(IsBlank(myFieldOverride),ThisItem.'Employee Name',myFieldOverride)". The DataCardValue box is autofilling with the Display name which is not what I want. I want it to be blank until I press the button and then it fills in with the display name. Thanks.

So, you can replace the ThisItem... portion of the Text property with nothing if you really want it to display nothing until the user selects the button.

 

The question I would have, though, is... if the field is logically tied to the data that was selected in another form, why are you hiding it until the button changes it?

 

If I understand a little more of the logic of what you're trying to accomplish and why you feel you have to have a blank textbox until the button is clicked, there might be a better solution than just leaving the "ThisItem..." portion of the If() statement empty. Can you explain that for me?

Sorry for not being clear before. So its basically a form for the users to fill out their goals for the year. The form connects to List in SharePoint Online. The first part of the form autofills with the Employee Name, Managers Email Address, Job Title, etc. and all the other info they have to input manually. At the bottom of the form we want them to press a button so that it fills in their display name as a sort of digital signature. I hope that's more clear. If you need more info let me know. Thanks,

You shouldn't have a datacard tied to existing data if you need it as a digital signature. It should be its own field, only filled when the form is "signed."

 

It can get filled with the display name (through the context variable), but it should not automatically point at it.

 

1) Make sure you have a dedicated field to hold the digital signature SEPARATE FROM the user information. That is, the employee's name, ID, boss, etc., can all be there, but that data must be held in different fields from the signature.

 

2) OnVisible of the screen, fill your context variable with the contents of the signature field. If it is blank (that is, never signed), your variable should be blank. In the datacard for the new field, set the textbox to pull from the context variable rather than ThisItem. This way, it will automatically come in "blank" until they have digitally signed the form (by clicking on the button). Once they have signed it, if they return to this form they will see their name in the field since it is looking at the signature field.

 

3) Use your button to update the context variable to the user's Display Name. You won't need an IF() statement anymore as you are now talking about a dedicated piece of data; there's no chance of it overwriting unless that is exactly what you & the user intend.

 

4) If the form data changes after digital signing, you can remove the digital signature (with or without a prompt) by blanking out the context variable... so if the user changes their goals, s/he must "re-sign" the form.

 

If you aren't able to add a field to the list, you can manage the same effect with a related list... Track the users that have "signed" their goals in a separate list, imposing all of the "change=required re-signing" logic from above. You would have to put a second form on the same screen (pointing to your different list), but the user would never know the difference.

Hi TimRohr

 

I'm not sure how I would go about what you describe below. I'm still pretty new to PowerApps so excuse my ignorance but I think I will need an example of how the formulas would look. The way I have it now, the form connects to the SharePoint online list. The columns that update with the user info are just single line text boxes with Office365Users.MyProfile().DisplayName (for instance) in the Default property. They are all separate and autofill when the screen loads with their individual property. What would I put for the default property of the signature box and the OnSelect for the button? 

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.

Helpful resources

Announcements
New Badges

New Solution Badges!

Check out our new profile badges recognizing authored solutions!

New Power Super Users

Congratulations!

We are excited to announce the Power Apps Super Users!

Power Apps Community Call

Power Apps Community Call: February

Did you miss the call? Check out the Power Apps Community Call here.

Top Solution Authors
Top Kudoed Authors
Users online (41,238)