Member Data Changes

[Midnight Modding]

When updating a member record ($member) for something important, such as $member->name or $member->member_group_id, am I overlooking anything additional I should do, such as updating any particular cache, logging, or anything else?

I see in my 3.x code there was a built in IPS method for updating the member's name, but I don't see anything like that in 4.x.

Also, in 3.x I was working around display name changes per x amount of time in the group settings, which needed to just be ignored, so I assume now I could just ignore that, as I don't see anything in function save() that would stop the name change, ie if there is still a limit, it must get checked by us ourselves, if we care.

For some reason in 3.x I was even updating the group settings and setting g_dname_changes and g_dname_date, looks like to get around the limit, then change it back to what it originally was. That was sure awkward.... so this will be much cleaner now, since I can avoid any such check from the start. I wouldn't be surprised if 3.x had a parameter to have it ignore that check and I didn't notice it. lol.

[bfarber]

You can set the member object property and call save() against the object afterwards, but be sure you perform any necessary checks in your userland code first (i.e. that the username is not already taken, for instance).

[Midnight Modding]

5 hours ago, bfarber said:

You can set the member object property and call save() against the object afterwards, but be sure you perform any necessary checks in your userland code first (i.e. that the username is not already taken, for instance).

Thanks. Just was being sure I wasn't overlooking anything other than checks. I wish related methods existed within the Member source file to make it simpler doing checks, though. In 3.x there was one, so I just called it and that was it. Now I'll have to look through IPS' checks from the acp form. Shouldn't be a big deal for me to do it, still, though. :)

[Midnight Modding]

It looks a lot easier than doing my own checks.

I see all I have to do is a text input and then pass the member object as accountUsername. I went through the form helper file for it and it looks like it does everything I need.

I also see where g_dname_changes is checked. That is checked within the internal method when changing the username on the front end by the member himself/herself.

So this is all very nice now. I can change the name, have the checks done by IPS's form helper, and skip the display name change per x time check. Nice, nice, nice. I think what it was is he wanted to limit their ability to change their OWN username x times per y period of time, but wanted the ability to ignore that for this feature in the app.

[Adriano Faria]

1 minute ago, Midnight Modding said:

accountUsername

You can also add your own validation check, in case you need.

Ex.: I worked on a character app last month that couldn’t allow use names from members and from other characters. So I used accountUsername to check the existing members and added my own check with a query in characters table. 

[Midnight Modding]

1 minute ago, Adriano Faria said:

You can also add your own validation check, in case you need.

Ex.: I worked on a character app last month that couldn’t allow use names from members and from other characters. So I used accountUsername to check the existing members and added my own check with a query in characters table. 

if you mean a custom validation check within your form element, I've done that on some others, but luckily on this username changing it's so simple I don't think I need to do anything.

Unrelated to this, but I wish there was an easy built in way to filter which members can be added in a form\Member input. I think in 3.x I managed to change which members would show in a type-ahead. I need to play around with a type-ahead in a future app. This current app doesn't need it.

It feels so nice when I am looking for something in files now, since I finally learned how it all works and fits together. My main issue now is I way underestimate hours an app will take, so I undercharge. I will finish this app probably next week, though. (this is just a a small one... the other one was very large.)