Transition Technology: Ticket Query

#772: new TIs not appearing on staging until caches flushed

annesley — Tue, 05 Aug 2014 09:26:32 GMT

i added a new Mulling transition initiative on staging in Afghanistan and it did not appear on the map... i flushed caches and then it started appearing on the main initiatives map. is this intended? is it a known?

#741: Views editor disappears in backend

annesley — Thu, 12 Jun 2014 10:42:13 GMT

admin > views > edit the view editor interface appears and then disappears immediately this happens in Chrome / Ubuntu and Firefox / Mac

#787: Access to Parrot

annesley — Mon, 15 Sep 2014 07:21:51 GMT

is it ok for me to send through my normal, non-passphrase protected public key to you Chris for parrot?

the documentation wants a passphrase protected key. however this may be what is causing the access issues from my laptop. i certainly could find a way around it but would suggest that the passphrase is not a great improvement to security anyway in this instance so it would be ok to use my normal public key. note that i can access all my other servers with the normal key without problems.

#860: More details on Server provision

annesley — Fri, 19 Jun 2015 10:29:09 GMT

we would like the following details on all servers provided by WebArchitects? (Penguin, Puffin and Parrot):

CPU type, speed, and characteristics Disk Space RAID type Traffic limits and characteristics Bandwidth limits and characteristics

Thanks!

#882: Login to PiWik stats

annesley — Tue, 03 Nov 2015 10:52:30 GMT

hi Chris! could i have a login to PiWik? stats please?

#764: Policy decisions re-assessment on BOA and Drupal security updates

annesley — Tue, 22 Jul 2014 14:10:38 GMT

on-line meeting 5 / August @ 14:00 GMT: we are phasing out the current D6 / BOA system. the new system may not use either. The TN.org website is not attractive to high level hackers or DOS attacks.

what are the risks with cancelling all further Unix, BOA and Drupal updates completely that do not allow direct un-mitigated access to the backend via bad PHP code / SQL?

#865: synchronisation

annesley — Wed, 15 Jul 2015 13:26:48 GMT

ideas. please query them.

we are synchronising between different data structures: WordPress and Drupal and anything else the plugin is installed on. therefore standard *database level* distributed synchronisation management tools will not be appropriate. this is unfortunate because synchronisation is a big task. however, it is possible that there are some CRUD / REST based sync tools. so: we need an XML abstraction layer (partially done already) produced by the Drupal, Wordpress, etc. plugin that is standardised and can then be compared and synced via standard API calls.

Steps:

new Transition Town registration on server A notify server B that there is new data and send the GUID of this new data server B then requests only the new data from server A (incremental) using the GUID server B creates the new item in it's database with a new native ID using the abstraction layer in it's plugin / module

addtions to this universal data pool, e.g. a new Transition Town, will be propagated via a network sync request at point of addition. "listener servers" will then request the new data (incremental only) and, in turn push that out to all other listeners. each plugin will therefore extend and expose it's CRUD style synchronisation abstraction functions:

add-user add-local-group change-user etc.

many of these are already available as part of the framework-independent plugin / module

currently, i suggest that ALL plugins contain ALL the international user and Transition Town data. passwords and emails, contact info will be handled by a 3rd server, either Mozilla Persona or Open ID. user accounts will also be synchronised on to ALL plugins but without passwords as those are held on the 3rd server. thus far had already been agreed with Ed. but, ofc, can be changed :)

new plugin installations will receive a full complement of data at time of installation. check digits will be periodically shared to check that all data is in-line. all users will be able to register and edit their data on ANY website holding the plugin. TT and USER changes and registrations will then propagate via PUSH notifications across the entire network all native IDs will be different. i.e. TT Brixton will have a different ID on each server. thus, as always with synchronissation, all IDs will be transformed to GUIDs by the abstraction API and only GUIDs will be used to analyse the network of data and synchronisation. login to any website containing the plugin will be transparent (unlike the demo i set up) through the normal wordpress and drupal login screens. the plugin will intercept failed authentication and attempt to authenticate against the universal servers. new accounts created via universal registration on any server will have a framework specific configurable role and thus permissions on that server will be set by the administrator specific to that server.