US users adding Ini profiles through the US site

[ed]

This is *the* big job for phase 4. The US is a pilot for other countries, and other content types. The aim is for TN to be able to publish project directory on TI sites, and enable anyone to add a project via the TI sites in the long term.

1. US user can add an ini profile to the US site which is also added to the TN directory
2. US site has a special map and directory view of US inis only (both muller and official)
3. US user can edit the ini profile via the US site (possibly not on TN site)
4. US user account: with TN or TUS? tbd
5. Creation of a 'slimline' user acct showing only 'critical data'?
6. Creation of a 'slimline' ini profile showing only'critical data'?
7. This is a pilot for other countries in the future
8. This process will be used in some way to enable anyone to add project information from and through TI sites
9. Fiddle with slimline user accounts and/or use third party process a la facebook/google/yahoo accts?
10. US has a US-only map view of users who are speakers

[ed]

notes from Carl, Jim, Ed meeting:
AGREED:

1. user accts, authentication, initiative adding ALL handled on US site
2. US happy with holding only stripped down versions of content types (ie less 'extra fields' that UK might choose to represent)
3. US happy to show all ini profiles on worldwide map (centred on US), therefore, to have a mirror of the initiative dataset (core data only?)
4. Users can add an ini from the US site to any country, based on the US' concept of 'core data' plus whatever the US thinks (relevant to later)
5. US/UK management will include some text encouraging users to register their inis via their local National site

ACTIONS:
JK to write out outline for design and development
EM to secure TN management buy in to idea of simplified data types, handling of user and ini data on TUS site, and that the core data profile for an ini is acceptable:

INITIATIVES:

Title
Status (muller/official)
Location (zipcode/postcode?)
Website (http:)
Feed URL (http:)
Initiative number (might be two for US/UK)
Description (txt)

USERS:

Firstname
Lastname
Email address

RULES:

Email *never* displayed
Ini and User profiles only editable by users at point of creation
Admins at National sites can edit ini profiles with extra data
Admins at National sites can edit author information to enable user (from other site) to edit ini profile (NOT recommended)

[ed]

Jim to advise Carl on storage and bandwidth implications...

[ed]

Design and logic, 'core' data types and ownership and authentication: accepted by Ben Brangwyn and Pete Lipman. i.e. management green light. Much admiration sent to JK from them for such excellent head baking work.

[ed]

Questions from Ben for general thought:

1. Ini registered on TN with fuller profile, what does it show on TUS:

1a. just core stuff
1b. all data added

2. Need management agreement on handling user data, and newsletters

3. what happens if primary contact is changed on TUS site?

4. 'remote' ini, when presented on TN site, shoudl include a link to the 'original' location on source site

[jim]

Answers:
1 - It shows a) Just core stuff... HOWEVER it's possible (probably another time) to wrap and render all the other UK-specific fields into a 'Extra' HTML field that could be shown on any site that wants to.

2 - There will be no user handling - we're gonna leave that well alone as discussed.

3 - Primary Contact stuff is an issue since a user ref won't work outside it's origin site... We're going to need to deconstruct a user reference into fields for name and email and add these to TN.org. The user ID field might be handy as a GUID somehow, and to allow links to user contact forms.

4 - Agreed. All ini records will need 'source' (site) and 'original' (page) urls anyway, so this is no problem.

[ed]

Notes from Jim/Carl? email exchange: Carl's comments in Jim's mail below:

On Fri, Jul 15, 2011 at 6:23 AM, Jim Kirkpatrick <bad.octopus@…> wrote:
Hi Carl,

This is one of a few emails I'll be sending about this topic -- and this one's all about what data YOU want on TUS. And since Ed's away he's copied in, but I'm going run with it and make any 'executive decisions' that may crop up in his absence.

So far I've done a load of research into Drupal modules that might do the job... Short story: Most promising modules won't work because of our peculiar setup and needs. So I'm going ahead with creating and sharing a common data set and using Views + Feeds as originally planned for now. One day this might all be better done by Services or one of the other dozen such modules, but this is a proof of concept really so best to go with the simplest approach.

So... All the work is happening with copies of the site on my machine, and I've got the views set up on TN side, and mostly set up on TUS side... The TUS Initiative content type is pretty simple and uses Flexifield (currently rather broken, unmaintained) to relate an Contact Person to the ini, plus Location and status. As you know the TN inis are more complex, which brings up some questions:

Questions
Shall we dump Flexifield? I'm yet to see data in it, and it crashes on admin pages. Or is it working ok for you, admin screen aside?

CS: I totally differ you on this. I would think mimicing TN in terms of the Drupal plumbing is probably good practice.

Are you cool with me adding a few fields to Inis? Not many needed, but certainly the mandatory missing ones below which are just "uuid" and "original url"...
CS: Go for it. Add away. How are you going to handle the "official" number assignment across two database instances? FYI, adding the TI number as part of the title was how they chose to track and sort before I got here!
Do you want to keep your current data? Is TUS data fully represented on TN.org or is some unique to TUS? Can we just dump your TUS data then? The reason for asking is can't lose your existing nodes then we'll probably have a manual job of saying 'this US ini = TN ini here' via the uuid field below...
If the answer to 2 is "everything on TUS is on TN" then could I dump the TUS Ini content and content type and create a new slimline one that matches the field list below? Are there any fields below in bold your DON'T want -- note the colour coding...
CS: I would do an export out to .xls before cutting over to PROD just as a backup but wiping the current "initiative" content is fine. Definitely need 'Description' field.
During sync, are you happy for empty fields to be filled in by other sites, then re-imported into yours (assuming your site can take the data)? For example, if a ini description is missing on TUS, but someone enters one on TN is that ok to re-import back to TUS?
CS: Yes. This begs the question will a person have to go to his/her site of origin (TN or TUS) to update their profile?
TN.org relies on the site's contact forms to be accessible to hide email addresses from prying eyes and ensure lower levels of spam. TUS doesn't allow access to them presently but I was passing the url to a contact form around because it then allows secure contact to happen without a admin getting involved. So would you be ok with me enabling access to them (with anti-spam tech in there obviously)? If not we'll need some 'contact' fields added to the TUS type
CS: No problem. Feel free to enable
Can you do a skype sometime soon? Whenever you're ready, just want reasurance I'm ok to add the odd field/tweak the odd thing in TUS. I'll press on in the mean time...
The plan is a little disruption to TUS as possible, but obviously depending on your answers above I might need to to more or less work. I'll go with the simplest solution for now, and assume that the TUS data can be dropped since I think it was said that all the inis are present on TN... But please confirm!

CS: TI data can be dropped from TUS site. Not all official US TIs are represented on TN but I can fix that before cutting over.

Best,

Jim

Fields/Content?
Key: mandatory field ... not mandatory (or used by TUS) but I reckon should be ... optional fields - can be in feed or not, but not processed if receiving site doesn't support them

(Core data - found on all Transition Entities)
#uuid missing (universally unique identifier module) - so items can be referred uniquely to across the whole internet
Auto generated and associated with nodes by the module, but in absence of module this could easily be a uniquely crafted URL etc. This is the 'global key' for all data. By using the module we save coding and let the Drupal community do some of our work. E.g. "2fa71586-ae43-11e0-8dfe-f1ebc51c3cd8",

origin_url missing - this holds the originating url - the source site/address, if you wish. Note this field must be added to both sites
E.g. "​http://www.transtionnetwork.org/initiatives/totnes". It's so we can say 'this node comes from here originally, so we can allow it to be edited/deleted etc.' or 'this node is not one of ours, show a little box on the page letting users know where it's from' It's separate from the guid because it can change according to the title and owning site over time.

title - no problem
though I see many TUS include the ini number in the title... more on that later on...

updated - date node last updated, key for syncing...
Drupal does this for us.

description - the node body
I realise TN has other fields we won't include, but this is an important 'about' field that TUS doesn't seem to use. Can include basic HTML.

website_home - "​http://www.my-exciting-ini-site.org",
website_others - an array of other sites like twitter, facebook etc
website_feeds_news - for sharing engine
website_feeds_events - for future sharing engine
website_feeds_projects - for future sharing engine
language - defaults to English

author_display - username/person name. e.g. "Dave Jones", drupal makes this for us
author_contact_url - user contact page e.g. ​http://dev.tt.org/user/1316/contact", --- SEE question 6 above
author_user_url - user page e.g. ​http://dev.tt.org/user/1316",

(Initiative specific)
initiative_official - says 'official' or 'unofficial' (muller)
initiative_type - can be "Local Initiative", "Local Coordinating Hub", "Regional Coordinating Hub" but defaults to local ini if missing

contact_primary_display - like author, except for contact for ini e.g. "Lou Brown"... Will use author_display if missing.
contact_primary_contact_url - see author and question 6
contact_primary_user_url - see author

location_city - e.g. "Totnes",
location_province_name - e.g. "Devon"
location_country_name" - e.g. "United Kingdom"
location_latitude" - e.g. "50.431213" -- can be 0.0
location_longitude" - e.g. "-3.685455" -- can be 0.0

[ed]

Ed to update following discusssion with jim

[ed]

Jim, Ed, Ben = best to proceed with PSE approach (ie not sharing data, use widgets instead). Carl approve in principle, Ed has sent positioning paper to Carl. Some work in phase 5 would be useful, not sure if it's critical if we can do this in PSE work?

[ed]

1. showing the data - maps, lists, etc. (widgets/and or panel panes on drupal websites)
2. data entry (hopefully a form that can be ajax-squirted)

Action: EM to organise skype with carl with jim.
Action: JK to do some research into third party auth (openid), and widget stuff

[ed]

please have a good think about this one and the widget approach before we talk to carl today at 4

[ed]

putting into pse for now to see if we can work it in there...

[jim]

Will do this early next week, prior to the PSE Skype on Thursday.

[ed]

Excellent - looking forward to hearing all about it in 19 hours time :)

[jim]

6 hours to go! working on it right now...

[jim]

first draft of PSE process

[jim]

first draft of PSE process (PDF)

[jim]

Please see attachments for first draft of this... and apologies for the delay.

[ed]

good work - next steps for Ed and Laura to digest and prep for PSE design meet Tuesday 6/12

[ed]

downgrading as not vital to PSE work

[ed]

taking down to minor