Transition Technology: Ticket #262: US users adding Ini profiles through the US site

type changed

ed — Fri, 17 Jun 2011 18:29:59 GMT

type changed from enhancement to innovation

ed — Mon, 20 Jun 2011 16:39:55 GMT

notes from Carl, Jim, Ed meeting: AGREED:

user accts, authentication, initiative adding ALL handled on US site
US happy with holding only stripped down versions of content types (ie less 'extra fields' that UK might choose to represent)
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?)
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)
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 — Tue, 21 Jun 2011 06:58:06 GMT

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

ed — Wed, 22 Jun 2011 17:41:45 GMT

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 — Wed, 22 Jun 2011 17:44:04 GMT

Questions from Ben for general thought:

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

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

Need management agreement on handling user data, and newsletters

what happens if primary contact is changed on TUS site?

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

jim — Wed, 22 Jun 2011 18:22:25 GMT

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 — Thu, 11 Aug 2011 10:33:40 GMT

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

owner, status, milestone changed

ed — Tue, 13 Sep 2011 15:24:30 GMT

owner changed from jim to ed
status changed from new to assigned
milestone changed from Phase 4 to Phase 5

Ed to update following discusssion with jim

ed — Thu, 22 Sep 2011 11:33:06 GMT

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 — Thu, 06 Oct 2011 13:15:27 GMT

showing the data - maps, lists, etc. (widgets/and or panel panes on drupal websites)
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 — Wed, 19 Oct 2011 08:29:01 GMT

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

owner changed

ed — Wed, 19 Oct 2011 15:51:54 GMT

owner changed from ed to jim

milestone changed

ed — Thu, 27 Oct 2011 13:42:46 GMT

milestone changed from Phase 5 to PSE

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

jim — Sat, 26 Nov 2011 14:07:47 GMT

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

ed — Thu, 01 Dec 2011 03:48:45 GMT

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

jim — Thu, 01 Dec 2011 14:50:23 GMT

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

attachment set

jim — Thu, 01 Dec 2011 18:08:59 GMT

attachment set to PSE - basic process and behaviour.doc

first draft of PSE process

attachment set

jim — Thu, 01 Dec 2011 18:09:22 GMT

attachment set to PSE - basic process and behaviour.pdf

first draft of PSE process (PDF)

hours, totalhours changed

jim — Thu, 01 Dec 2011 18:10:31 GMT

hours changed from 0.0 to 2.5
totalhours changed from 0.0 to 2.5

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

ed — Fri, 02 Dec 2011 00:02:44 GMT

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

priority changed

ed — Tue, 20 Dec 2011 23:26:49 GMT

priority changed from critical to major

downgrading as not vital to PSE work

priority, description changed

ed — Mon, 18 Feb 2013 10:56:47 GMT

priority changed from major to minor
description modified (diff)

taking down to minor