RefApp 2.11 QA: Did we intend to create multiple new time durations in the patient dashboard?

@dkayiwa @sharif @tendomart @mozzy it looks like there’s a new difference in the Patient Dashboard between the 2.10 and 2.11 RefApps:

So you can see now there are kind of weird mentions about “the last 730 days” or “the last 30 days”; I don’t see this in the 2.10 version, and I used exactly the same information to create these 2 patients. Is this intentional? If not, what could be causing it?

Sorry for late reply, Yes these time durations message were introduced coreapps in refApp 2.11, this is intentional because it indicates the current periodic time/duration updates about the diagnosis or an encounter.

1 Like

@sharif which ticket was it?

RA-1370. On the one hand, where these widgets have configured periods of time that they’re searching, it’s a good idea to include a message to that effect. On the other hand, it would likely be better if these were using actual calendar periods rather than approximations of them by days (2 years rather than 730 days, etc.). Note, though, that RA-1370 didn’t add the time constraints, it simply made the visible in the UI.

One thing I missed in my review of that issue, though, is what happens if a date period is not configured for a widget, where we might get a bit of nonsense displayed.

2 Likes

@ibacher should therefore be another ticket to fix this or have this re-opened ?

Thanks @ibacher for this, i agree with your opinion on this, do you mind us create a followup ticket regarding your option to track it

I think it’s a great idea to open a follow-up ticket to track this part of the work.

However, we should also make sure that the widgets work when no time period is configured; that part I think should be done as part of the already-existing ticket.

I think a couple of other things broke in 2.11.0

coreapp 1.31.0

Does not show any Results under " Health Trend summary " widget

After starting a visit / past visit and adding several vitals on my newly created instance, This applies for qa-server as well

demo is ok since it’s running on the previous versions.

ref : [RA-1864] obsacrossencounters Requires an EncounterType which is an optional field - OpenMRS Issues

1 Like

gggggg

1 Like

This is demo running on previous versions

@tendomart I tried to file this here as well; can you add any details you found to this ticket: https://issues.openmrs.org/browse/RA-1871

And if you’re already working on this issue, can you assign it to yourself? :slight_smile:

Do you think this should block our release? Personally, I would normally say yes, but since it’s so urgent to update our modules for other reasons right now, I think we could fix this after the release instead.

@grace i think @ssmusoke badly needs it for UgandaEMR at https://issues.openmrs.org/browse/RA-1864?src=confmacro

and thanks for reporting this https://issues.openmrs.org/browse/RA-1871 , I think it should come first.