.fullname Options in List field
3 posts by 2 authors in: Forums > CMS Builder
Last Post: July 24, 2012 (RSS)
By InHouse - July 24, 2012
I'm trying to understand the rules related to the use of .fullname in the list of columsn to display in an editors List View.
Can anyone clarify when this will work and when it wont? Which fields will it work with? I keep seeing the use of 'createdBy.fullname' but createdBy is not a field that appears in tables. Applying the .fullname to createdByUserNum seems to mostly generate a value of '0' except for sometimes it will actually work - all in the same column. Weird!
I'd really love it always work with any instance of 'createdByUserNum'. [;)]
I'm also interested in whether it will work with the Membership Plugin if you have two tables of users. The first being the admin user table, and the second being the members table.
Cheers,
J.
Can anyone clarify when this will work and when it wont? Which fields will it work with? I keep seeing the use of 'createdBy.fullname' but createdBy is not a field that appears in tables. Applying the .fullname to createdByUserNum seems to mostly generate a value of '0' except for sometimes it will actually work - all in the same column. Weird!
I'd really love it always work with any instance of 'createdByUserNum'. [;)]
I'm also interested in whether it will work with the Membership Plugin if you have two tables of users. The first being the admin user table, and the second being the members table.
Cheers,
J.
Re: [InHouse] .fullname Options in List field
By Jason - July 24, 2012
Hi,
The createdBy. set of fields are pseudo fields generated by the getRecords() function. What it does is look at the createdByUserNum field value, and attempt to find a record with the same num value in the accounts table. If it does, it adds "fields" into the returned record set like createdBy.fullname
I'm actually pretty suprised the createdByUserNum.fullname wouldn't always return an error, since that index should never be created.
It's important to note that this pseudo field is only created when getRecords() is called. If you retrieve the record by any other means (mysql_select() for example), you won't get these values.
You can also turn off these pseudo fields by using the options:
in getRecords().
Currently, getRecords only looks in the accounts table, and not in the website membership table. If that type of functionality is required, we could create a simple custom plugin to get that.
Hope this helps clarify. Please let me know if you have any other questions.
Thanks,
The createdBy. set of fields are pseudo fields generated by the getRecords() function. What it does is look at the createdByUserNum field value, and attempt to find a record with the same num value in the accounts table. If it does, it adds "fields" into the returned record set like createdBy.fullname
I'm actually pretty suprised the createdByUserNum.fullname wouldn't always return an error, since that index should never be created.
It's important to note that this pseudo field is only created when getRecords() is called. If you retrieve the record by any other means (mysql_select() for example), you won't get these values.
You can also turn off these pseudo fields by using the options:
'loadCreatedBy' => false,in getRecords().
Currently, getRecords only looks in the accounts table, and not in the website membership table. If that type of functionality is required, we could create a simple custom plugin to get that.
Hope this helps clarify. Please let me know if you have any other questions.
Thanks,
---------------------------------------------------
Jason Sauchuk - Project Manager
interactivetools.com
Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/
Jason Sauchuk - Project Manager
interactivetools.com
Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/
Re: [Jason] .fullname Options in List field
By InHouse - July 24, 2012
Many thanks Jason. That does clarify a number of items for me.
I have to wonder at the odd instance where this worked on a simple-cart orders table. Most of the time, the .fullname column showed '0' as you'd expect. But in one case at least, a single row held the correct full user name. If you're interested, it was the GSG project.
Best wishes,
J.
I have to wonder at the odd instance where this worked on a simple-cart orders table. Most of the time, the .fullname column showed '0' as you'd expect. But in one case at least, a single row held the correct full user name. If you're interested, it was the GSG project.
Best wishes,
J.