Hi there,
I can’t seem to find SQL views in DHIS2 2.31. According to the documentation it seems to say that it should be in Data Administration but I can’t find it there. Same issue with the playground instance.
Speaking of playground, can someone explain the difference between http://play.dhis2.org/2.31dev and http://play.dhis2.org/2.31 (which redirects to 2.31.0, which appears to be down…)?
Thanks,
Hi @Jasper_Timm,
sorry for the error in the documentation at the start of section 23.15.1. We will fix that!
Section 23 is about the Maintenance App, and that is where you will find SQL views.
2.31.0 is the last stable patch of 2.31 (in this case 2.31.0 is the initial release).
2.31dev has the latest fixes in, but is not considered stable. These fixes will be tested further and released in the next patch, 2.31.1. When that is released, 2.31 will redirect to 2.31.1 and 2.31dev will continue to show the changes in preparation for 2.31.2.
I hope that clarifies a little!
Kind regards,
Phil
Thanks @phil! I did find it within Maintenance. I see that there’s no shortcut to them via the apps menu, might that be something worth adding? It’s a bit hard to hunt them down within Maintenance.
And thanks for the clarification on the playground builds. So 2.31dev is the CI build of the 2.31 branch I suppose.
Looks like the 2.31.0 instance is back up again too.
Cheers,
Hi @Jasper_Timm,
You can add a feature request for the shortcut if you like, but I think it’s only difficult to find if you are coming from an older version (expecting a different location) or if our documentation is telling you the wrong thing (We’ve fixed it now!); so it may not be very high priority compared with other features on the roadmap.
Re: playground - exactly! 2.31dev is the CI build of the release branch! 
Hi @phil,
I’m going to be a bit cheeky here, but isn’t there an existing “feature” in DHIS2, whereby all sub-apps of the Maintenance app can be searched for individually in the “Search apps” bar? In which case, couldn’t we consider the omission of just one sub-app a bug, rather than a feature request… 
Cheers, Sam.
Hi @SamuelJohnson,
We could argue over whether it is a “feature”; someone could also regard the display of the sub-apps as a bug that confuses the app search… 
Anyway, ultimately we are splitting hairs. The truth is that we know it is very convenient for “power” users, but in the new app architecture with improved component reuse I understand it is not trivial to implement.
For that reason it would be much better as a feature request, for which the product managers can evaluate the level of need and prioritise accordingly, in line with the required effort.
So my point is that, honestly, it will gain more ground (if indeed it warrants it) as a feature request.
Kind regards,
Phil
Hi Philip,
I respect the need for the team to prioritise, and to allocate scarce resources carefully. And I know that we both place a high priority on user experience. Where I suspect we might disagree (given your earlier comment that this request would probably be given a low priority) is on how important consistency is to that user experience. I very much like the ‘sub-app’ search feature, but I would actually be happier seeing it removed than applied inconsistently. My experience has been that every little exception or special case in DHIS2 (and there are plenty of them) results in additional confusion, additional training time and additional admin work…
The reason I landed on this page was that I was trying to figure out where on earth the SQL views had gone, and I ended up spending 10mins wandering through the interface and looking through user manuals before I finally found this ticket. The very first thing I did was type ‘SQL’ into the search bar - if it had been there, that would have saved 10mins of my time…
I’m not saying this to push this particular request (you’ve explained it probably won’t get a high priority, and I respect that), but just to explain that I feel consistency in the user interface is extremely important, and for that reason I would definitely consider this a bug, not a feature request.
Cheers, Sam.
Hi @SamuelJohnson,
We agree on the importance of consistency. One of the driving factors here is the harmonisation of components and their consistent application across the platform: header bar implemented once and used across all apps, app search implemented once and used across all apps, org tree implemented once… and so on. (So this hidden search “feature” will eventually be removed completely - unless planned and re-implemented).
The price, of course, is that in the transition we lost some “consistency” from version to version, depending on how we harmonise and refactor existing alternate implementations.
Kind regards,
Phil
I’m with Sam on this. If you bother to introduce a feature then it should work consistently with what users expect. I too wasted time searching for the SQL views recently and it was definitely annoying that the search did not help!
I think we all agree that the feature is useful. But, for example, you could not find SQL Views in 2.29 or previous versions, where it existed in Data Administration instead of Maintenance. I apologise that the user guide displayed the wrong location after the move, but we did updated it as soon as Jasper reported it above.
My point is that instead of relying on a hack in the Maintenance App, and just trying to patch that up (as a bug), we should define the use cases and features needed in a proper feature request. For example, should it be restricted to searching for sub-apps of the Maintenance App? Perhaps that could be considered inconsistent behaviour; and one should expect to be able to search for a variety of components within the platform (here is a related feature request, for example, referring to searching across analytics apps: [DHIS2-1075] - Jira).
I’m just trying to be honest with you all about the challenges of this type of issue. You can of course raise it as a bug. We won’t ignore it. I suspect it would eventually be converted to a feature and combined with issues like 1075 to define different use cases we will eventually support. The important thing is that it goes into Jira and captures all of the necessary detail regarding what the users expect. Our product managers are the ones with the unenviable job of prioritising everything we implement on the platform; and it will reach them faster as a feature.
Kind regards,
Phil