Milestones

Today, Eran and I discussed the layout for milestones and began laboring over the list view.

Eran gave me a nice high-level diagram of Django’s treatment of a URL. I got a sense of it in the tutorial, but having the diagram in front of me was a tremendous help.

We plan to have two views: milestone_list and milestone_detail. milestone_list displays all milestone names with their associated progress bars. Clicking on a name will take you to that milestone’s detail page. The list view also allows users to add new milestones. milestone_detail contains the following info about a particular milestone: name, due date, tickets. It also gives you the ability to “close” that milestone.

There will also be a milestone field within the ticket dialog box wherein you can pick a milestone from a drop-down list or simply select ‘None’ (so that you can create a milestone later from the list view).

For now, we have the bulk of the list view complete. What remains is a way to pass the % complete values to the template. I am away for the majority of next week, but will attempt to do this from home.

Commited!

Notes:

• Before running, you need to create a DrProject environment. Then, edit conf/drproject.ini to point at your SQL data dump.
• Usage: python drp2basie.py/tools <db_url>
• A log called ‘errorlog’ is created in your root directory which documents runtime errors during the conversion.
• If the script comes across any anomalous users within map_emails(), it will automatically create them.
• If the script comes across any anomalous emails within map_messages(), it will attempt to read the file ‘unregist_emails’ if it exists in your Basie root directory.
• ‘unregist_emails’ is formatted as follows:

address1 username1
address2 username2
…

• This will create a UserEmail objects with the associated address and user. If the user does not exist in the database, it will attempt to create him/her.
• The script runs quite slow, but I will fix that if I get a tick! :S

Submitted 2nd revision

Greg has asked me to only take into consideration the preferences with values of ‘true’ or ‘yes’ and interpret that as send_email=True in a Basie membership. All other values imply send_email=False.

With that, I have made the appropriate changes and am awaiting a review.

2nd revision done

Updated drp2basie.py using Eran’s feedback… awaiting Greg’s response on how to handle the send_email field in Membership.

Small tweaks

Here’s what I’ve been up to on the drp2basie front. Small fixes, as you can see.

• Eliminated tab characters from my code
• Started testing on the csc49x database
• Restricted locked projects to be either true or false
• Added a progress bar feature

Still reading up on Django as well!

Not much today…

…to be perfectly honest. Eran got me familiarized with Review Board, I submitted my copy of drp2basie.py.

But, alas, the struggle continues. After updating my working copy of Basie, I run into the same import errors as before. Eran is attributing it to an error in the buildout script, so in the meantime I’ve just been refreshing my memory on Django. I plan to walk through the whole tutorial before getting to work on the Milestone model.

Tested…

Everything looks fine. The description field in each new ticket is a little messy, but the information is there. I am just awaiting the newest unregist_emails file from Greg before we try this out.

Just testing…

I have sent Greg the list of unregistered emails and am awaiting the updated copy. Until then, I am just doing some light testing. So far, I’m getting no errors during the migration except for the non-unique WikiPage one as stated in a previous post. I still am operating under the assumption that the Basie wikis have the project “All” associated with them since I cannot figure out a way to extract that information on the DrProject end.

Currently, I’m struggling with messages. All messages are being instantiated with NULL in their user field despite this code:

djemail = UserEmail.objects.get(address=message.address)
djuser = djemail.user

djmessage = MailMessage.objects.create(user=djuser, body=message.body, \
subject=message.subject, date=message.date, \
project=Project.objects.get(name='All'))

Victory is near, mind you. I can smell it!

Migration going well

I’ve made some further judgment calls. They are as follows:

• If the real name which identifies a message does not match a corresponding user entry, then the migrated message object has a null ‘user’ field.
• type, milestone, priority and comments are now crammed into the ‘description’ field in the new ticket entry
• In WikiPage, ‘last_editor’ is simply assigned the user whose name corresponds with ‘author’. If none such user exists, the field will be assigned NULL.

Progress:

projects: done
users: done
roles: done
memberships: done
emails: done (assuming Postgres is reliable)
messages: probably done (though I cannot spend an hour waiting for the test to finish)
tickets: done
wikis: done (but with errors)

As you can see, wikis are troublesome. The problem is that when I query the full set of WikiPage entries from the DrProject end, I get many duplicates. This gives me an error which reads like “project, slug not unique” when I try to create the Django object. But, wiki pages are being mapped, so I think that’s it!

Tomorrow, I will test the attributes of each object to see if they were migrated properly.

Complete (with a few reservations)

I have done some very essential tests (specifically, using count comparisons between tables in DrProject vs those in Basie). All entries are being mapped completely except for Email, MailMessage, Ticket and WikiPage. However, some entries are being mapped from the four tables mentioned above. The issue lies in Postgres (from what I’ve induced). That is, not all users have been added to the database and I’m not quite sure why. In any case, what values are living in my database are getting mapped appropriately.

I’m using a logfile to print errors in the following format:

ModelType Instance ErrorMessage

If someone could supply me with a working database or inform me of the correct means of acquiring one, I could test this properly… but until then, I’m not interested in “shaving the yak”, as Greg put it.

I’ve also made a few assumptions. First, I am assuming that all wikis, tickets and messages being mapped from DrProject belong to the project labeled “All”. Also, I’ve made some formatting decisions for the Ticket map. Thirdly, I understand that any occurrences of a role labeled “ticket_filer” should be inserted to the Basie database as “viewer”. I’ve gone ahead and made this change.

Next up… further testing!!