Builds and Phone Field - phone has disappeared

After the last upgrade, our default field phone disappeared causing all sorts of problems in chapter updates by managers. However, no one mentioned it until today, Lists work because phone remains in the table and we have another field which "copies" it. We have had sufficient transactions that we can't revert to a backup before the upgrade. Is there a TESTED stable build we should use?
We can add the phone field back in the fields table and copy the attributes from an old backup with a little bit of problems. I will look at your sample code in the main forum. Is that working?

This issue is already fixed in the latest build, but if you're already bugged see the below.

www.joomlapolis.com/forum/146-general/235543-6381-after-update-to-2-1-cb-phone-is-alias-field?limitstart=0#289205

Best solution is to revert to a backup and install the latest build.

Is there a TESTED stable build we should use?

For the record we test every build. How was I supposed to know old sample data fields were using reserved field ids they never should've been using? I'm sorry this happened, but it's a bit insulting to think we don't test our code....

With the latest build the alias field no longer uses a reserved field id and is entirely unique by name (other fields will be doing the same in a future CB release so we can stop using reserved field ids in general). Also worth mentioning our nightly builds go through the same testing as our stable builds. There's literally no difference between the two now in that regard.

Sorry, all our sites were built using your original sample data which is how the fields got created. Can I safely use the field name phone or do I have to go through all our code to change to cb_store? My workplan is to readd the field with a new field id but the old field name, Do I need to reorder the actual table or can I leave the table untouched.

Have same problem except my Phone field was a Default with the Name "Phone" and Title "Home Phone". Title was changed to alias and the "Phone" Named field is no longer found in Field Management. It stills displays in the SQL Database Comprofiler but data can't be entered from the Edit User screen. If I want to add data it has to be done in Comprofiler. The fix in the link is for a User created cb-phone field not the default Phone.

You say that there should be no fields below 54. As noted above, all our sites were started some years ago with your default fields. I have attached a workbook with the current field definitions. There are numerous fields below 54 that contain data. Are you expecting us to adjust all these fields to ids higher than 54? If so, I suggest a general post should be sent to all members because I am sure there are lots of sites that have legacy issues such as this.

Sorry, all our sites were built using your original sample data which is how the fields got created. Can I safely use the field name phone or do I have to go through all our code to change to cb_store? My workplan is to readd the field with a new field id but the old field name, Do I need to reorder the actual table or can I leave the table untouched.

The cb_phone database column should still exist. If not then it was replaced by alias column where the cb_phone column values should be still stored. You can make a new cb_phone field and transfer the values to it using the query linked above. The alternative is basically to revert the changes. By that I mean change the alias field row in _comprofiler_fields back to cb_phone for the name and tablecolumns columns then install latest CB build for it to remake the alias field properly. Make a backup before doing this I can not stress this enough though.

This won't be an issue ever again for future usages as we are no longer going to be using reserved ids for anything (plugins, tabs, or fields) when adding new core rows.

You say that there should be no fields below 54. As noted above, all our sites were started some years ago with your default fields. I have attached a workbook with the current field definitions. There are numerous fields below 54 that contain data. Are you expecting us to adjust all these fields to ids higher than 54? If so, I suggest a general post should be sent to all members because I am sure there are lots of sites that have legacy issues such as this.

Only core fields should be using an id of 54 or above. CB 1.x incorrectly created sample data using reserved ids. It no longer does this. I'm not expecting you to adjust anything. Again, it has been fixed in latest build. The alias field no longer cares what its id is and future additions will follow the same behavior. The general post on this matter is below and is tagged with the bug ticket associated with it.

www.joomlapolis.com/forum/146-general/235543-6381-after-update-to-2-1-cb-phone-is-alias-field