Custom location labels and custom location lists

Hi KC,
thanks for your contribution. I'd personally take a slightly different approach. Let me try to explain my ideas.

I'd like to merge your idea of user customized lists (managed by user) with the idea of site customized list (managed by admins).
A couple of facts first.
* Someone in the issue queue was asking to have the ability to override a location' label, so to have "Granpa house" instead of "Usa/CT" or whatever.
* In pixture's mind the admins should have the ability to change the worldclock_location table directly so they don't have to open a ticket here for each small glitch.

I'm not sure what to think about this. I'd like worldclock to provide correct data for the locations it provides. And for this to happen, we need people to report back to us the errors they find. Furthermore, I think we can safely assume worldclock provides data for all possible existing timezones. These thoughts suggest the module should not provide an interface to alter timezone values (except for the label). Please correct me if I am making wrong assumptions here.

So we are still left with 2 things: 1) location relabeling and 2) custom user lists.
The following approach is somehow inspired by reaneyk above patch and from studying how core actions module stores system default data and custom actions (add a custom action and have a look at the actions.aid column).
Let's have a table worldclock_custom with fields:
* wid: contains worldclock_location wid for which this row contains overriding values;
* scope: this will be a varchar (instead of just an integer) and will contain either a uid numeric value (to identify personal location lists) or a string 'system' (to identify locations changed by admin);
* values: serialized array of all data regarding this override. When a location will be loaded, the values in this array will override the original values. So for the example above we'd have array('name' => 'Granpa house'). Using the serialized approach makes extension to other fields easier (in case we want to be able to override timezone data in the future).

What do you think?
Francesco

PS: just a quick favour: if it's just a matter of 2 files, it would be more useful if you attached them separatedly, so one can review the patch directly without download/untar'ing the archive. Also, if you name an archive tar.gz you are supposed to tar and zip it, while the attachment at #2 is only tar'ed and not zipped. Thank you!

Renaming more appropriately.

Hi KC,
I see no db structure changes or custom labeling functionality. Possibly you updated the wrong patch or did you overlook the patch file?
Francesco

Great job KC! Now, stop me whenever you get tired of this going back-and-forth, but please keep in mind I'm striving to find the best way to handle this issue.

I think we should change a bit the rationale behind the 2 tables.

We should make "worldclock_locations" editable by admins. I know I said we would like administrators to report back any errors, but I feel this should trust them to do so instead of just precluding the possibility and force them to mess directly with db. Probably we could put a notice whenever they edit any default location, to report back to us if they find errors.

So "worldclock_locations" will contain the default locations we have and any other admin-added/edited/cloned location, which will be available to all users. Probably we'll need an additional field to differentiate module-provided data vs admin-provided data, more on this later.

"worlclock_custom" will contain user-related data. The schema remains the same but dropping the "scope" column, which is now pointless to have.

If we take this approach, I would delay a bit the integration of user custom lists, in order to concentrate on getting the module core stuff right. Custom user lists feature could probably re-use a lot of code by then.

I have opened these related issues. I think we need to address at least the first two before going on with this one. Want to help?
#350963: Editable locations: simplify database structure
#350964: Editable locations: create interface for adding/removing/editing/cloning locations for admins

This is a feature pixture suggested but not prioritary now:
#350966: Editable locations: import/export
If you are still with me, I'd still like to concentrate only on extending current functionality (as in getting the structural ability to override/customize right) rather than introducing new features (as in adding custom user lists). Let's focus on db structure and admin interaction for adding/removing/editing locations. Custom lists feature will probably re-use a lot of code by then.

What are your thoughts about all this?
Have a nice Christmas,
Francesco