Custom Query (15 matches)

Currently, information about speakers and the location is stored in a wse_events specific record. It would be nice if this data were available elsewhere, especially in an address database of people and locations that future event teams can use, and also for the events calendar. That would reduce redundancy and make maintaining the information a lot easier.

The calendar extension cal offers three ways of storing its location and organizer information:

# In its own record format # In tt_address records # In partners records

In addition, the user authentification is also able to store information about FE users:

# In its own record format # In tt_address records

So I think storing stuff in tt_address could greatly improve things.

Currently, information about speakers and the location is stored in a wse_events specific record. It would be nice if this data were available elsewhere, especially in an address database of people and locations that future event teams can use, and also for the events calendar. That would reduce redundancy and make maintaining the information a lot easier.

The calendar extension cal offers three ways of storing its location and organizer information:

1. In its own record format
2. In tt_address records
3. In partners records

In addition, the user authentification is also able to store information about FE users:

1. In its own record format
2. In tt_address records

So I think storing stuff in tt_address could greatly improve things.

It seems that there is a problem regarding interaction with the latest static_info_tables extension. This version corrected some wrongly set default values. I get lots of errors regarding country codes. Please see the PDF file.

This happens with the speaker and timeslot list views.