Order Entry UI Sprint 8 Progress

efosa · July 30, 2018, 4:37pm

Hello everyone,

Order Entry UI Sprint 8 has been going on a little over a week now and It’s my pleasure to share the progress the team has made since the beginning of the sprint.

As a reminder, below are the objectives set for the ongoing sprint,

Implement adding lab tests to draft orders
Implement saving lab orders from the draft list
Implement Adjusting the urgency of a lab order
Implement unmovable lab tests panel

It is my pleasure to announce that the tickets for all the objectives have been implemented, meaning that all are either in the Done or Code-Review stage.

The feature(s) we plan to still integrate into the project during this sprint is;

Generate available lab tests dynamically

The feature has been broken down into four different subtasks and two of the subtasks has been implemented already while the remaining two subtasks are currently in progress.

here is the link to the main ticket for this feature;

Sprint JIRA Board;

https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=167&view=detail&selectedIssue=OEUI-174

Project’s Github repository;

mogoodrich · July 30, 2018, 6:00pm

@efosa @dkayiwa @ddesimone @rhenshaw56 @jeiddiah @tunmi @topseysuave

Dave and myself were starting to test tickets and I picked up OEUI-177 and it wasn’t working, but Rowland mentioned that it was because the fix for OEUI-195 had not been merged in yet… I think we need another column on our board to distinguish between those that are ready for code review and those that are actually ready for test?

Take care, Mark

mogoodrich · July 30, 2018, 6:09pm

@efosa @dkayiwa @ddesimone @rhenshaw56 @jeiddiah @tunmi @topseysuave @mseaton

I went ahead and added separate column to our board for “Code Review (Post-Commit)”. I’m thinking we can use this column to note when a ticket is ready for test? Does that make sense to everyone? Feel free to move any of the tickets in the “Code Review (Initial Commit)” into the next column…

efosa · July 30, 2018, 6:17pm

That makes sense, Thanks @mogoodrich

rhenshaw56 · July 30, 2018, 6:45pm

That makes sense @mogoodrich we would also need to specify the test branch on the ticket

mogoodrich · July 30, 2018, 7:23pm

Thanks @rhenshaw56… I do think that once it goes into the “Committed code” category (or whatever category we use for “Ready for Test”) it should be in the main branch, but this should be the point that a BA or another tester can test by going to our staging server, which will just be running the master branch.

mogoodrich · July 31, 2018, 5:54pm

I’m also okay with being a little more aggressive when merging in code, especially now we have a staging server where @ddesimone and myself can test… worst comes to worst, we can revert a change if it breaks something… right now we have 5 tickets in “Code Review Initial Commit” that we can’t test because the code it is in local forks.

What’s our current policy for marking a ticket as ready to merge? Do we want a certain number of people to review it first? If something looks good to me, can I go ahead and merge it in?

Thought ? @efosa @dkayiwa @ddesimone @rhenshaw56 @jeiddiah @tunmi @topseysuave

Take care, Mark

dkayiwa · July 31, 2018, 7:49pm

Our policy has been requiring the team to first review among themselves. This has not been a blocker because it was a matter of the ticket authors pinging the other team members to immediately review as expected, because they are all working full time on this.

Is there any, where this has been done but it is still not yet merged?

mogoodrich · July 31, 2018, 8:18pm

@dkayiwa, thanks, I will check! I know that most have been reviewed by at least one other team member… were we expecting all the team members to review, or only 1 or them, or 2 of them, etc? I don’t mind triaging and merging ones that seem ready based on the number of reviewers, but I was’t sure what the intent was.

Take care, Mark

dkayiwa · July 31, 2018, 8:33pm

We originally started with just a few reviewers. But i ended up with a bigger load while pointing out things that some other team members were in position to help with. So requiring everyone on the team to first review, not only ended up encouraging knowledge sharing, but also reduced my load because by the time i review, most of the necessary feedback has been given by the team members.

This requirement can be relaxed if you share my load.

mogoodrich · July 31, 2018, 8:43pm

Got it, definitely willing to help out @dkayiwa!

efosa · July 31, 2018, 10:01pm

We would be glad if you could actively participate in the reviewing process as well because it would surely make sure expectations is reiterated and feedbacks based on that can be communicated soonest and would speed up the implementation-lifecycle.

Since you’ve indicated interest in participating in the reviewing process, It might interest you to know that apart from the demo server, every assignee also uploads a .zip file on every ticket that contains the build of the current changes, with that, Reviewers( gets to test and assess the changes made on their local machine and feedback is given appropriately on the Pull request for that ticket.

Thanks, Efosa @mogoodrich

mogoodrich · August 1, 2018, 7:28pm

Thanks @efosa!

mogoodrich · August 1, 2018, 7:31pm

@dkayiwa do you know where this “patient note” design in the Order Entry patient header comes from:

github.com

openmrs/openmrs-react-components/blob/master/src/components/header/PatientHeader.jsx#L134


              </a>
            </small>
          </div>
        </div>
        }
      </h1>
    </div>
  );
}


renderPatientIdentifier() {
  const { patient } = this.props;
  return (
    <div className="identifiers">
      <em>Patient ID</em>
      <span>{patient.patientIdentifier.identifier}</span>
      <br />
    </div>
  );
}

Seems like a neat feature, but it isn’t in the existing Core Apps patient header, and I’m unsure if there’s a means to enter this information for the first time? Was wondering if we should just remove this, or document it as not fully functional?

dkayiwa · August 1, 2018, 8:31pm

We could just remove it.