D4Science Infrastructure

I've used the following portlet:

https://bluebridge.d4science.org/group/protectedareaimpactmaps/mpa-reporting

Hi @emmanuel.blondel@fao.org, this is not the correct approach to manage issues related to production VREs and I would not have expected this reaction from you.

Any time we deploy a new release we have to verify that all the environments works as expected. In this particular case, you are right saying that the issue was observed in the past but we don't know if it was expected to be resolved with this release. The fact that the user interface allows to submit a request by selecting specific parameters through the interface suggests that the fix was implemented. An advice on the interface would have avoided this issue.

As far as Blue Commons, if you have identified issues please open as many tickets as needed.
As far as the management of the effort of the technical team, this is something that is managed by myself and by Blue Commons and criticisms are clearly appreciated but should be raised in a different context, as the Tcom for example.

Emmanuel, sarcasm is hard to detect and tough to convey in written messages, a misplaced sentence could easily change a neutral–sounding email into a thinly-veiled attack, which I am sure is not your intention. May I suggest you to re-read your posted message?

The purpose of this incident was to (help) let you know that your algorithm for particular values wouldn't work. We had no idea you were already aware of it and we are in no doubt that you all are hard working to make MPA better and better.

Is there a ticket (task) stating that this algorithm for particular values doesn't work? If so, please link the ticket to this incident and close it. If not, please create one, link it to this ticket and close the incident.

Dear Lino, If the scope is a gcube release, then the testing should bind to scope of gcube components. Here the component highlighted is the portlet, the container, which is a generic one, and their tests should be bound to what the component is aimed to.

Tests for this generic portlet are as follow:

• allow to configure a website application through the Liferay configuration panel
• allow to configure a URL token application parameter through the Lieferay configuration panel
• the application should be displayed once the portlet is reloaded (functional iframe)
• an application invoking a gcube token based service within the portlet (e.g. MPA application) is working.

If QA tests have to be performed on the "PublicWebappPortlet" component (mpa-reporting is an instance of it), IMHO they should be be bound to that container and its features, not the content. In the case of MPA webapp, without doing execution tests (backed by Dataminer), your team may be able to check quickly since the MPA web-app will start by inheriting user profile through social-network service based on token and this is reported as javascript log and available if you open chrome dev console.

Your team is also welcome to create improvement requests for this portlet (i'm still talking of the gcube portlet container), or even to contribute directly it (I know that @massimiliano.assante@isti.cnr.it had already pointed out some wicknesses to tackle in the past).

MPA application (not the portlet container, but the content) is out of gcube release and built by community, and data are in a continuous process to be improved. Levi (and also Anton) already reported issues dealing with data, and these are being tackled by GRID-ARENDAL. I suppose that these tests are targeting the gcube components, not the thematic web-apps, nor every single data stream. Of course in this context it would not make sense to create a ticket for each execution param attempted, while the issue would be a common one.

Hope this clarifies,

Kind regards

Hi @massimiliano.assante@isti.cnr.it creating incidents on rush is not appropriate, hence my rush answer, although we all tempt to try to use this ticketing system. For future testing dealing with an thematic application and their data streams, it's better to liaise with people involved, and ask them "is it normal?", and your help you will be much appreciated. I think we were advised in several occasions by Lino to use social-networking instead or even messaging, we are trying to, and it would be a better place to ask about unexpected data & thematic app issues when it is known that they are ongoing activities on it.

The log reported deals with a WFS data fetching issue, which unfortunately in geoserver occurs unexpectedly sometimes, and in this case Data is being improved and updated, so WFS data fetching may be naturally impacted.

@debhasish.bhakta@grida.no can you please inspect the R process and logs, and see which feature fetching is failing.

Thanks