Enterprise Client Community

We see that there are certain incompatibilities in the definition of the scales. Instead of "xscale" and "yscale" with some array info inside you now have to define:

Code:

         "scales": 
         {
             "x": 
             {
                 "display": true,
                 "scaleLabel": 
                 {
                     "display": true,
                     "labelString": "Month"
                 }
             },
             "y": 
             {
                 "display": true,
                 "stacked": true,
                 "scaleLabel": 
                 {
                     "display": true,
                     "labelString": "Revenue"
                 }
             }

We updated out demos accordingly. (Part of today's update.)

Kind regards! Björn

(problem reported by mail - response through forum)

After updating the Captaincasa version from 20231004 to 20231127, barcharts no longer work correctly: in stacked column charts the stacks are now shown as separate columns next to each other, in layer charts the largest layer is now displayed as the top one, which means that you can only see the other layers at the edge of the diagram sees points. We suspect this is related to the Chart.js update?

Hi,

FIELD and TEXTAREA are sized accoeding to the WIDTH/HEIGHT definition you pass... - so you are right: there is no possibility to define "size with content".

Currently there is only the option to use TEXTPANE with width 100% and no height for displaying the text, then converting component into a TEXTAREA when the user wants to edit (or open TEXTAREA in popup).

Kind regards! Björn

...and: The possibility to have an editable text area with growing content is a nice feature, so we will think about, adding it into our development plan...

HI,

status quo: not possible.
Always the full text of a field is editable.

Could you please check the following: the FIELD has a property UNITTEXT. Typical use case is: you define a value, and the unit of the value is shown as part of the field (and not as extra label).

I could imagine that this is also some nice solution: put the suffix into the UNITTEXT. (I am glad that you talk about a suffix and not a prefix...)

Kind regards! Björn

...is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog

Stupid bug detected....:

Hi, unfortunately there is a bug in 20231127. The text "1" and text "true" are not correctly rendered in buttons and in labels wihtout width definition. You only see some 1px wide text...

The bug only occurs with these two strings. THere is no problem with strings containing "1" (e.g. "213") or containing "true" as a part of of the string.

There is a Maven version available fixing this issue: 20231130_INT - Of course this fix also is available with next Monday's update.

King regards! Björn

...is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog

"got it!"...

Way out:

1. Leave currentSessionTimeOut at "-1" and do not reset! ;-)

or

2. Initiate resetting of the timeout to its old value with an explicit request;

In other words, trigger the method via the client and then reset the timer in the ActionListener of this method. Triggering a method through the client is done by component CALLSERVERONTRIGGER:

Code:

 Page...:
 
 <t:beanprocessing ...>
     <t:callserverontrigger trigger="#{d.Xxx.longActionEndedTrigger}" actionListener="#{d.Xxxx.onResetTimeoutAction}"/>
 </t:beanprocessing>
 ...
 <t:button actionListener="d.Xxx.onStartLonnnnngAction" .../>
 
 
 Code:
 
 
 int m_currentSessionTimeOut;
 Trigger m_longActionEndedTrigger = new Trigger();
 public Trigger getLongActionEndedTrigger() { return m_longActionEndedTrigger; }
 
 public void onStartLonnnnngAction(ActionEvent event)
  {
      m_currentSessionTimeOut = HttpSessionAccess.getCurrentHttpSession().getMaxInactiveInterval();
      try
      {
          HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(-1);
          ...
          ... the lonnnnng processing
          ...
      }
      finally
      {
         m_longActionEndedTrigger.trigger();
      }
  }
 
 public void onResetTimeoutAction(ActionEvent event)
 {
     HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(m_currentSessionTimeout);
 }

Kind regards! Björn

...received following message on this topic...:

Unfortunately that didn't quite work for me yet.

I believe the problem is the following flow:

1. Initially set: currentSessionTimeOut := X sec.

2. At startup: setMaxInactiveInterval = -1

3. the long-running process runs through unmolested in > X seconds

4. then set again: setMaxInactiveInterval(currentSessionTimeOut) i.e. X sec.

5. but the “last access time” was not updated, so the time has now expired: remainingTime < 0 s

6. And so the session is apparently considered “invalid” the next time it is accessed. Error: a complete restart occurs

...we found the reason.

We changed the calculation of the device pixel ratio for Chrome with 20230612. (Thanks for your perfect analysis on the versions!)

Before we used "window.devicePixelRatio" which does not take into consideration the scaling that is applied by the operating system. So we changed to a way to acutally measure the screen size by measuring the outer width of the window against the inner width of the browser content (https://stackoverflow.com/questions/1713771/how-to-detect-page-zoom-level-in-all-modern-browsers).

In case of tabs which are "prepared" in the background (due to opening the browser with last opened pages) the width of the browser is passed back as "0"... So some calculations are wrongly executed with a wrong pixel ratio.

We will fix - for next update! (next Monday)

...we can reproduce on our side as well: activating Chrome's function "Start > Show last displayed pages" and having a grid in one of the pages will not show the scrollar of the grid...

Björn

(sent by mail > cont. processing in forum)

Some users have reported a problem with the display, that the height of the grid's rows are different than normal, and that the vertical scroll bar is missing.

I was able to reproduce the problem when I start our Captaincasa app in a browser tab without focus. Some of our users seem to load the last open tabs when starting the browser, then several instances of our MES application can be started at the same time without the TAB being in focus.

Browser is Edge (but should behave like Chrome)

The problem does not exist with version 20230605, but the problem occurs with version 20230612.

...just finished a Screensharsession in which the following problem was discussed...

1. A button in a dialog starts a processing on server side which takes long time (1 to 2 hours...)

2. The session timeout in web.xml is configured to 60 minutes.

PROBLEM The servlet engine ends the session after 60 minutes... The whole scenario is moved into some "confusing situation" as result.

WHAT ARE THE WAYS OUT?

The normal advice is: separate the long lasting operation into some own thread. And use control LONGPOLLING with websocket communication to observe this thread until it's finished. By observing the thread, regularly new http-requests are sent from the client to the server, which keep the session awake. (And of course: the user likes to continue to work or to at least be informed about updates on server side...)

In the concrete scenario this was not possible: the long lasting processing requires access to the http session. (You may discuss, if this is a really good idea... but the effort to change this, is not adequate.) So moving into another thread is not an option.

...the first idea, was to use the BlockerInfo messaging: by API BlockerInfo you can send a text and a progress message to the client which is shown in an info window. This is of course some "dramatic" increase of useability - but: it does not have any consequences for the session timeout. The BlockerInfo internally uses a WebSocket connection - and using a WebSocket is not considered as an activity to keep the session alive. Only receiving new http-requests are the ones to update the timeout management of servlet engines.

Finally the way to go for this scenario: use the HttpSession-APIs...

Code:

 public void onStartLonnnnngAction(ActionEvent event)
 {
     int currentSessionTimeOut = HttpSessionAccess.getCurrentHttpSession().getMaxInactiveInterval();
     try
     {
         HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(-1);
         ...
         ... the lonnnnng processing
         ...
     }
     finally
     {
         HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(currentSessionTimeOut);
     }
 }

So for the duration of the long processing you switch the session timeout to "inifinite" (-1) - and you reset it to the previous value afterwards.

Remark for super-experts: in case of session management by Cookies, it can happen that several requests are running in parallel! The "HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(...);" is used across these threads, so there is a multi-threading issue as consequence. In order to solve this, you just need to shift corresponding data to the HttpSession level - because that's the one which is the common object seen by all parallel threads. - The principle stays the same: deactivate the session timeout for the duration of the long operation.

For next update we added:

1. embedded pages inside CaptainCasa do not come with default "sameorigin" for "x-frame-options" - but with no seteting of this parameters (so they can be embedded in any scenario)

2. By system.xml you can explicitly override this. There are three catergories:
a. internal bridge pages (e.g. to chart.js, quill-editor, OSM, ...)
b. BufferedContent pages
c. TempFile pages
So if you (or some auditor) explicitly wants to see certain parameters then you can do so.

So the problem you raised should not occur anymore - while keeping the explicit configure-ability.

Kind regards! Björn

...goood question! ;-)

By default pages rendered by DefaultBufferedContent are returned with "sameorigin" as "x-frame-options" header parameter.

In your constellation I believe there is...
Code:

 Some outer page with IFRAME
     in which a .risc page is opened
         in which a PDF pages is created with DefaultBufferedContent

If your x-frame-otions are now set in the following way...
Code:

 (outest)
     "true" by system.xml
         "sameorigin" by DefaultBufferedContent

...then the PDF page will not be shown.

Currently the only way to overcome to override the following method within your DefaultBufferedContent extension...
Code:

     /**
      * In the default implementation the header parameter "x-frame-options" is set
      * to "sameorigin" so that the buffered content is not embed-able into pages
      * coming from some different host. You may override this behavior.
      */
     public void preProcessResponse(HttpServletResponse response)
     {
         ServletUtil.setResponseHeader(response,"x-frame-options","sameorigin");
     }

and set/not set the parameter properly. (In case you want to net set things at all you just override by:
Code:

     public void preProcessResponse(HttpServletResponse response)
     {
         // do nothing!
     }

This smells like some area of improvement.
In one of our next updates we can provide a configuration for the default that is curerently coded to "sameorigin".

Kind regards! Björn

PS: for other readers the security guide https://www.captaincasa.com/docu/eclnt_risc_securityguide/ contains all information "around"...