Person attribute edit permission option

Posted June 17, 2008 by Upul Indika Godage
Categories: OpenMRS

Tonight I did the person attribute edit permission task and attached the patch. The person attribute type will have a new property, edit priviledge.  Only users who have this priviledge can edit that person attribute values. Also I have submitted a request to remove printing a stack trace in the log which is an issue for the Tribe module. Otherwise a long stack trace is printed on the OpenMRS startup everytime.

Third OpenMRS Implementers Meeting began today in Durban, South Africa.

Advertisements

Tribe module changes

Posted June 10, 2008 by Upul Indika Godage
Categories: OpenMRS

Last night and tonight, I did the modifications to the Tribe module as advised by my mentor, Ben. Mostly I integrated the SQL upgrade scripts to the module activator start up code. Ben wanted to make the module upgrade path as easy as possible to the users. This way users do not have to run a separate SQL script. Also I added the tribe field to the patient dashboard header. Also privilege annotations, save,purge style persistence code were introduced and the module will validate whether it is running in an old OpenMRS system.

It has been 21 years since the Aranthalawa Massacre. On June 2, 1987, LTTE (Liberation Tigers of Tamil Eelam) killed with guns and swords 30 young novice monks, less than 10 years old, hacked to death. Two photos are in here.

Tribe module checked in

Posted June 2, 2008 by Upul Indika Godage
Categories: OpenMRS

I have checked in the inital version of the tribe module.  (I think I changed the id in the .project file.) I will wait and see what my mentor, Ben has to say. There will be changes to make.  Or may be completely redo it. I am going start the next project in a few days, may be the end of the week. I have some assignments to do.

Today I got the Google’s payment card. It is a MasterCard credit card in appearance with the name XXXX GSOC 2008 STUDENT.

Looks like tribe project is complete

Posted June 1, 2008 by Upul Indika Godage
Categories: OpenMRS

Tribe module is ready to be checked in. I have attached the core OpenMRS system changes to the ticket. There is another update to the core system to allow registering module level FieldGenHandlers. I have written an SQL script to upgrade an existing implementation, by moving the patient tribe values to a person attribute type value as follows.

— disable auto commit
SET @currentAutoCommit = @@autocommit;
SET @@autocommit = 0;

START TRANSACTION;

— create the tribe person attribute type
INSERT INTO person_attribute_type
(name, description, format, creator, date_created)
VALUES (‘Tribe’, ‘Tribe of the person’, ‘org.openmrs.module.tribe.Tribe’, 1, NOW());

SET @tribeTypeId = LAST_INSERT_ID();

— insert person attributes for patient tribe values
INSERT INTO person_attribute (person_id, value, person_attribute_type_id, creator, date_created)
SELECT patient_id, tribe, @tribeTypeId, 1, now() FROM patient WHERE tribe IS NOT NULL;

— remove tribe column
ALTER TABLE patient DROP FOREIGN KEY belongs_to_tribe;
ALTER TABLE patient DROP COLUMN tribe;

— commit everything and restore auto commit value
COMMIT;
SET @@autocommit = @currentAutoCommit;

MySQL stored procedure to upgrade tribe

Posted June 1, 2008 by Upul Indika Godage
Categories: OpenMRS

Tags: , ,

I wrote a MySQL stored procedure to upgrade the existing patient tribe values to a person attribute type.  This method is not going to be used, so it will not be checked in. So I am putting it here so that somebody may get some use out of it.

— define the procedure
DELIMITER $$

DROP PROCEDURE IF EXISTS `openmrs`.`convert_tribe`$$
CREATE PROCEDURE `openmrs`.`convert_tribe` ()
BEGIN
DECLARE currentAutoCommit BOOLEAN;

DECLARE tribeTypeId INT(11); — tribe person attribute type id

— fetched values of patients with tribe are stored in the following variables
DECLARE patientId INT(11);
DECLARE tribeId INT(11);

DECLARE noMoreRows INT(11) DEFAULT 0;

DECLARE patientsWithTribe CURSOR FOR
SELECT patient_id, tribe FROM patient WHERE tribe IS NOT NULL;

DECLARE CONTINUE HANDLER FOR NOT FOUND
BEGIN
SET noMoreRows = 1;
END;

— disable auto commit
SELECT @@autocommit INTO currentAutoCommit;
SET autocommit = 0;

START TRANSACTION;

— create the tribe person attribute type
INSERT INTO person_attribute_type
(name, description, format, creator, date_created)
VALUES (‘Tribe’, ‘Tribe of the person’, ‘org.openmrs.module.tribe.Tribe’, 1, NOW());
— get the created tribe person attribute type id
SELECT person_attribute_type_id into tribeTypeId FROM person_attribute_type WHERE name = ‘Tribe’;

— read patient tribe values and add new person attributes
OPEN patientsWithTribe;
cursorLoop : LOOP
FETCH patientsWithTribe INTO patientId, tribeId;
IF noMoreRows = 1 THEN
LEAVE cursorLoop;
END IF;

INSERT INTO person_attribute (person_id, value, person_attribute_type_id, creator, date_created)
VALUES (patientId, tribeId, tribeTypeId, 1, now());
END LOOP cursorLoop;

CLOSE patientsWithTribe;

— remove tribe column
ALTER TABLE patient DROP FOREIGN KEY belongs_to_tribe;
ALTER TABLE patient DROP COLUMN tribe;

— commit everything and restore auto commit value
COMMIT;
SET autocommit = currentAutoCommit;
END$$

DELIMITER ;

— run the procedure
CALL convert_tribe;

— drop the procedure
DROP PROCEDURE convert_tribe;

FieldGenHandler for tribe

Posted May 30, 2008 by Upul Indika Godage
Categories: OpenMRS

Tonight I got a working FieldGenHandler for the tribe object. The registering of FieldGenHandlers through modules is working now. All the existing FieldGenHandler code exist in the core OpenMRS system. Because the tribe is inside a module, core system cannot have a dependency on the tribe module. Until midnight I could not think of a way to get the core system to work with the tribe objects. I was sleepy and was going to call it a day. But then I started the machine again and tried one last time. In around fifiteen minutes I got it working. I created a generic fieldgen code and added it to the core system and used it to show the tribe objects. All the risky parts of the project are now complete. What remains is creating the SQL to upgrade an existing implementation to use the new tribe module.

Tribe as a person attribute object

Posted May 29, 2008 by Upul Indika Godage
Categories: OpenMRS

So far everything was going okay. Tonight I implemented the Attributable interface. Now I can add tribe as a person attribute using the manage person attribute types page in the OpenMRS administration. But I cannot add or edit values for tribe person attribute type. I checked the source to learn how location and other person attributes are doing it.

I have to add a FieldGenHandler for the tribe object to make it editable and to let the user add or make changes to the tribe field. But so far all the FieldGenHandlers are made for core OpenMRS objects. My mentor Ben provided a fix to register handlers outside the core system. For the last 3 days Ben has checked in code to fix some issues I faced within a few minutes after I asked, without which could not proceed with coding.