Acting as if there's an {if} when there's not...?

[Former Member]

So if you look at this thread list alcryst.proboards.com/board/194/testing
the colored names should have a name to the right of them in brackets, which is a custom profile field code:
{foreach $[thread.last_post.created_by_user.custom_field]}{if $[thread.last_post.created_by_user.custom_field.name] == "OOC Account"}[$[thread.last_post.created_by_user.custom_field.value]]{/if}{/foreach}

This is supposed to show up if that field is filled out, and these accounts have them filled out but they are not showing up. If I fill out this field on my main admin account, it does show up. It's acting as if I have an {if $[user.group.id] == "somenumber"} in there, which is admittedly something VERY frequent in my layotut templates because I have it all divided up by member group, but I don't have any specifications. It's simply supposed to show up if it's filled out, member group shouldn't be affecting it.

Can an admin look into my layout template for Thread List and help me figure out why the field isn't showing up for certain members/member groups?

It appears to be a problem for my other areas as well. Board List, Board Info Center, and Currently Online in the Info Center. No idea what's going on. =/

[Brian]

Hi, ₪» ⅀ ƪ Ƒ «₪.

After some testing, it seems that information is only available if you're logged in as that user, likely because the way we output the information has all of the current user's information available at all times, while any other users on the page only have the necessary information from their profile tied to the created_by variable (you'll notice varying results in availability whenever you fetch user information in different areas). That's just a guess though, since I'm not a dev.

I'll add a feature request internally to see if we can get all information in each tree that calls user info to output in all instances. Just keep in mind that as far as I know, there's going to likely be a reason it was done this way, and I suspect it'll be server load.

[Former Member]

Dang. x.x' That's quite defeating of the purpose. Oh well, it's not an essential aspect of my site, just a very useful one. I appreciate the feature request =)

[Wormopolis]

This might be hampering the request to have custom field values available on the editor page as well. It might have to be compromised to be a true or false if it has a stored value or not. At least for the editor part

[Former Member]

Has this been looked into at all yet? =)

[Tim Camara]

It's on our list of things to look at, but no progress has been made in that direction recently.

[Former Member]

No problem, just checking in. ^^ Thanks for the update! =)

[Former Member]

I know that there hasn't been any progress toward this yet because you guys have been working like crazy with forums.net, and I know you haven't even gotten lunches in weeks really Tim Camara, so this isn't to pressure--just wanted to ask if this is near the top of the list for what you'll be working on when the heat from forums.net dies down, or if it's middle/lower? Thank you for any responses I get, and sorry for bumping an old topic and possibly being annoying

[Tim Camara]

It's not at the top, but it shouldn't be more than a few weeks off.