Duplicate functionality of Mudbag chapter database in the new Semantic Mediawiki chapters database

Bug #125185 reported by Gavin Baker on 2007-07-11
10
Affects Status Importance Assigned to Milestone
Web Team projects
Critical
Asheesh Laroia

Bug Description

We need to finish transitioning from our old Mudbag database and semi-old Turbogears database to the shiny new Semantic Mediawiki database.

Here are the requirements before we can mark this as "fix released":

(0) Import all of the "old" data from Turbogears db
(1) make it easy to read the data we have
(2) make it easy for people to fix their existing data
(3) make it easy for new chapters to register
(4) Finish duplicating the functionality of the old Mudbag form/database. This includes:
   (a) sending an e-mail to <email address hidden> whenever a new chapter registers, with the complete contents of the submission
   (b) sending a confirmation e-mail to the registrant, letting them know that their chapter registration was successful (and at some point they should verify that their e-mail address actually works)
   (c) ability to vet chapters, i.e. newly registered chapters are hidden from the world at large until an admin marks them as an official chapter
   (d) integration with the official Wordpress chapters page, only for official chapters
  *(e) auto-subscribing new chapter representatives to the Chapters mailing list, or at least auto-requesting (we can manually confirm their request through Mailman)

Once these features are complete, we can file new bugs for new features that we want.

Copypasta from Bug #42961

* There should be a field in the chapter reg form for their blog's RSS feed (or we should be smart enough to auto-discover the feed)
* All of the RSS feeds currently in the Chapters aggregator should be imported into the chapters database
* Each RSS feed should be automatically added to our chapter aggregator once the chapter is marked as "active", i.e. they have been officially approved by us. "Inactive" chapters should not be aggregated, just as they should not appear on the Chapters page.

Changed in web:
importance: Undecided → Medium
status: New → Confirmed

It would be great for this to lead into the single login system (Bug #110174).

e.g. When registering a new chapter, it says "Thanks for registering! If you haven't, you should create an account with FreeCulture.org..." Alternatively, that should happen in the opposite order (i.e. "Create an account with FreeCulture.org, then login with your account to register a new chapter")

This has to go live by 2007-07-29 -- it's Critical.

Changed in web:
importance: Medium → Critical

Is the system installed and functional to our satisfaction -- can we close this bug? (We can file other bugs for future tweaks if this is fundamentally working.)

Changed in web:
status: Confirmed → Triaged

It's up with CatWalk, it's not too bizarrely insecure, and it uses a reasonable and future-thinking schema.

Yee-haw!

Changed in web:
assignee: nobody → ubuntu-asheesh
status: Triaged → Fix Released

I'm reopening this bug b/c the Turbogears/Catwalk database was completely inadequate, and we ended up reimplementing the entire thing in Semantic Mediawiki. Fun.

Here are the requirements before we can mark this as "fix released":

(0) Import all of the "old" data from Turbogears db
(1) make it easy to read the data we have
(2) make it easy for people to fix their existing data
(3) make it easy for new chapters to register
(4) Finish duplicating the functionality of the old Mudbag form/database. This includes:
   (a) sending an e-mail to <email address hidden> whenever a new chapter registers, with the complete contents of the submission
   (b) sending a confirmation e-mail to the registrant, letting them know that their chapter registration was successful (and at some point they should verify that their e-mail address actually works)
   (c) ability to vet chapters, i.e. newly registered chapters are hidden from the world at large until an admin marks them as an official chapter
   (d) integration with the official Wordpress chapters page, only for official chapters

Once these features are complete, we can file new bugs for new features that we want

Changed in web:
status: Fix Released → In Progress
description: updated
Asheesh Laroia (paulproteus) wrote :

0) Done, I think

1) http://wiki.freeculture.org/Chapters - easy enough to click through I think

2) http://wiki.freeculture.org/Chapters - when you click through, you get nice "Edit with form" links - I'd appreciate specific advice on what needs to be changed before we can call that done

3) Is the form @ http://wiki.freeculture.org/Chapters easy enough? Someone let me know.

I'd really really love it if someone were to sit me down at some given time, register a new/fake chapter and a new/fake contact, and both (a) write documentation for it for end-users and (b) show me what bugs/niceties I can fix/improve. Nelson, can we pick a time sometime soon maybe, like Tuesday evening for you or Wednesday sometime?

4) That's a separate ticket, imho; let's get 0123 done first at least.

(4)(a) at least is vital and I don't consider the database done until we do that... at least I don't want to register any new chapters until we have it. I want chapter registrations backed up to e-mail, and I want to be informed whenever a new chapter registers.

(4)(d) is also pretty important b/c having outdated information on our website is a huge no-no, and the public chapter list has been outdated all semester. And (d) depends to some extent on (c). So all except (b) are very important, and if we're doing (a), (b) should be trivial to implement at the same time.

I don't want to close this bug until (4) is done, sorry... I won't consider the chapters DB open for business until (4) is complete, except perhaps (b).

On Wed, 28 Nov 2007, Nelson Pavlosky wrote:

> I don't want to close this bug until (4) is done, sorry... I won't
> consider the chapters DB open for business until (4) is complete, except
> perhaps (b).

Sounds fine, keep working with me on IRC and we'll get closer and closer
until we'll suddenly be done. (-;

-- Asheesh.

--
Have you reconsidered a computer career?

I finally finished a prototype table printer. Here's its sample output for Harvard. Note that this only (currently...?) gets public information, not private information like cell phone number.

That's all the work I can possible do on this for one day, but I can get back to working on this (and sliding it actually into place) tomorrow hopefully.

Information about <http://wiki.freeculture.org/Special:URIResolver/Harvard_Free_Culture>:

Approved by SFC : Yes
Blog : http://hcs.harvard.edu/~freeculture/
Budget : Yes
Contact : http://wiki.freeculture.org/Special:URIResolver/User-3AEmstark
Coremembers : 6
Is active : Yes
Mailinglist : http://hcs.harvard.edu/mailman/listinfo/freeculture-discuss
Name : Harvard Free Culture
School : http://wiki.freeculture.org/Special:URIResolver/Harvard_University
Ship cc : Yes
Ship eff : Yes
Ship pk : Yes
Subdomain : harvard
Uri : http://hcs.harvard.edu/~freeculture/
Wiki : http://hcs.harvard.edu/~freeculture/wiki

Information about other linked resources:

Information about <http://wiki.freeculture.org/Special:URIResolver/Harvard_University>:

Address : 02138
Coordinates : 0°0′0″N, 0°0′0″E
Name : Harvard University
Uri : http://www.harvard.edu/

Information about <http://wiki.freeculture.org/Special:URIResolver/User-3AEmstark>:

AIM : emstark
Email : mailto:<email address hidden>
Name : Elizabeth Stark
Uri : http://reasoner.experiencethis.org

This definitely needs to include private data as well. I want this to
be a complete data backup which is easily searchable when the website is
down or I'm offline.

Other than that, this is looking great! Is this done once we include
private data, or are there other reasons this is a prototype?

~Nelson~

Asheesh Laroia wrote:
> I finally finished a prototype table printer. Here's its sample output
> for Harvard. Note that this only (currently...?) gets public
> information, not private information like cell phone number.

Asheesh Laroia (paulproteus) wrote :

On Mon, 24 Dec 2007, Nelson Pavlosky wrote:

> This definitely needs to include private data as well. I want this to
> be a complete data backup which is easily searchable when the website is
> down or I'm offline.

Makes sense.

> Other than that, this is looking great! Is this done once we include
> private data, or are there other reasons this is a prototype?

"All" that remains is:

* Private data, and
* hooking it to the postsave hook.

-- Asheesh.

--
The moving cursor writes, and having written, blinks on.

Asheesh Laroia wrote:
> "All" that remains is:
>
> * Private data, and
> * hooking it to the postsave hook.
>

What does "hooking it to the postsave hook" mean? What should be
happening after we save the page which currently does not happen?

~Nelson~

Asheesh Laroia (paulproteus) wrote :

On Sun, 30 Dec 2007, Nelson Pavlosky wrote:

> Asheesh Laroia wrote:
>> "All" that remains is:
>>
>> * Private data, and
>> * hooking it to the postsave hook.
>
> What does "hooking it to the postsave hook" mean? What should be
> happening after we save the page which currently does not happen?

The email generation code is written, as you see, but our wiki isn't
configured to talk to that code.

That'll happen sometime.

-- Asheesh.

--
Don't quit now, we might just as well lock the door and throw away the key.

Wow, I somehow left (4)(e) off of the list of requirements, even though it is something that we had in the original Mudbag database that we no longer have:

(e) auto-subscribing new chapter representatives to the Chapters mailing list, or at least auto-requesting (we can manually confirm their request through Mailman)

This is essential, we need to have a mailing list with every chapter rep on it, and automating that is the easiest way to ensure it.

description: updated
Changed in web:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers