Survey: JasperReports printing - What Options would you like to see for the default language?

[Andreas Sumerauer]

Hi all,

I am planning to create a plugin that allows language selection in the jasper viewer window.
It is going to add a language selector dropdown to the jasper report viewer.
I am not really happy with the current default selection of the document language. 
So I am going to offer a number of options to customize this setting.

I want this the Plugin to be useful to a wide range of users. 

Here is a small survey to get an idea of your requirements.
Please answer if you are interested in seeing the plugin being made.

1. On what base should the initial language be set? Some Options:
   
• client language
• Business partner language
• Language of current user
• Client language for incoming documents, Business Partner language for outgoing documents 
• User definable SQL for even weirder requirements.
• anything else?
  
  
2. Where should the initial language be stored?
• Client
• Document record
• Print Format
• Document type
• anything else?
  
  
3. At a later stage I might add some further customizations. 
• customizable PDF Name:
  e.g. prefix-documentNo-postfix.pdf
• Auto archiving according to the rules set in the client
• Do you have any further wishes with regards to Jasper Report Printing that could be useful to you or to your clients? 

Thanks for any helpful hints and comments

Andreas

[Nicolas Micoud]

Hello Andreas,

Here's my thoughts :

Initial language based on BPartner. In all cases, you should be able to retrieve a AD_User record which should be linked to a BPartner and so, be able to read language there.
If no BPartner or if BPartner.Language is empty, you can use the language defined at Tenant level.

For the customizable file name, I think we need here a common approach.
When you download a report, you can only select the type (Excel, Pdf, ...). A textbox (pre-filled with 'default file name' - which should already be defined on the print format AFAIR) would be really useful.

Regards,

Nicolas

[Andreas Sumerauer]

Thanks Nicolas,

Initial language based on BPartner. In all cases, you should be able to retrieve a AD_User record which should be linked to a BPartner and so, be able to read language there.
If no BPartner or if BPartner.Language is empty, you can use the language defined at Tenant level.

I think this is the right scheme for incoming documents, for internal documents and for reports that are meant to be used internally.
For outgoing documents (e.g. customer invoice) we are using the language of the recipient. Does this make sense for you as a hard coded default option?
I am anyway planning to add a column for the language setting to the AD_PrintFormat table where the user can override the default.  

For the customizable file name, I think we need here a common approach.
When you download a report, you can only select the type (Excel, Pdf, ...). A textbox (pre-filled with 'default file name' - which should already be defined on the print format AFAIR) would be really useful.

I am afraid I didn't find it there. I am thinking of adding a field to the Print Format where the user can compose the file name string from a given number of parameters.
e.g. @DocTypeSymbol@ + @SomeDate@ + "-" +  @DocumentNo@   

[Nicolas Micoud]

Hi,

For outgoing documents (e.g. customer invoice) we are using the language of the recipient. Does this make sense for you as a hard coded default option?

IMHO, Yes (with a fallback on AD_Client.Language to avoid NPE)

I am anyway planning to add a column for the language setting to the AD_PrintFormat table where the user can override the default. 

Maybe a textbox where user can write its preference (eg: 1;2;3 would mean "1-BP Language" ; if not found use "2-LoggedUserLanguage" ; if not found use "TenantLanguage"  ?

I am afraid I didn't find it there. I am thinking of adding a field to the Print Format where the user can compose the file name string from a given number of parameters.
e.g. @DocTypeSymbol@ + @SomeDate@ + "-" +  @DocumentNo@  

I'm pretty sure we worked on that (or maybe just talked) years ago but I can't find related ticked on Jira :-/ Carlos, any idea ?

Thanks,

Nicolas

[Carlos Antonio Ruiz Gomez]

My 2¢

- must it be consistent with ReportEngine.get ?

- being jasper part of core at this moment - maybe would be good to check if these options are valuable for trunk instead of creating a new plugin ?

Regards,

Carlos Ruiz

Am 02.12.19 um 14:03 schrieb Andreas Sumerauer:

[Andreas Sumerauer]

Thanks Carlos,
Your questions really made me reconsider my project on another level.

 

must it be consistent with ReportEngine.get ?

As I see it this would require:

• A JasperReportEngine class that extends ReportEngine.
• The JasperReportEngine would have to override the document getter functions (getPdf(), getHTML(), getCSV(), ...)
• What about the other inherited public functions? should they throw an exception or just log an error?
• ReportEngine.get() would have to be rewritten to serve a JasperReportEngine where required.
• Would it make sense to have a ReportEngine baseclass that only implemented the basic functionalities while the render engine specific stuff is only prototyped and gets handled by child classes?

ReportEngine.get() mainly appears in the getPdf function that is copied all over the document model classes. 
It looks more or less like this:

public File createPDF (File file)
{
    ReportEngine re = ReportEngine.get (getCtx(), ReportEngine.INVOICE, getC_Invoice_ID(), get_TrxName());
    if (re == null)
        return null;
    MPrintFormat format = re.getPrintFormat();
    // We have a Jasper Print Format
    // ==============================
    if(format.getJasperProcess_ID() > 0)
    {
        ProcessInfo pi = new ProcessInfo ("", format.getJasperProcess_ID());
        pi.setRecord_ID ( getC_Invoice_ID() );
        pi.setIsBatch(true);
       
        ServerProcessCtl.process(pi, null);
       
        return pi.getPDFReport();
    }
    // Standard Print Format (Non-Jasper)
    // ==================================
    return re.getPDF(file);
} // createPDF

some models that do not produce a pdf use this implementation (again it's copied all over the place):

public File createPDF (File file)
{
   return null;
} // createPDF

What speaks against doing some cleanup here by moving the createPDF implementation up into the base class?

class PO {
  private boolean m_canCreatePdf = false;
  private int m_type = -1;

  (...)

  public File createPDF (File file) {
    if(!m_canCreatePdf) return null;

    ReportEngine re = ReportEngine.get (getCtx(), m_type, getC_Invoice_ID());
    // Jasper related stuff gets handled by ReportEngine.get() 

    if (re == null)

      return null;

    return re.getPDF(file);

  } // createPDF         

}

with member variables po.m_type, po.m_canCreatePdf to be set before any call to getPdf().

being jasper part of core at this moment - maybe would be good to check if these options are valuable for trunk instead of creating a new plugin ?

I don't think so. Apart from the changes outlined above (and probably some further adaptions that I can't assess at the moment) I would rather keep the rest of the implementation within a plugin.

As long as  PrintFormat + PrintFormatItem is the default way of generating reports and documents I don't see a point in bringing the entire handling of raw JasperReports into the core, since not everybody wants to use that option.

What I think is required though is an improved API for the usage of alternative report renderers. There is a current need to use JasperReport right now. IMO the API could and should be open or at least extensible for other solutions that someone might want to use in the future.

For me there is also a practical reason to go for the implementation as a plugin: We do not use the swing client and have no intention to implement that side of the solution. IMO that needs to be part of a core implementation.
It is also easier to a plugin funded that I can get into a working state rather quickly instead of a core extension that needs to be discussed and assessed on many more levels before it can be  considered right for integration.
Of course I will always do my best to make a later transition to trunk not too difficult and will surely be happy to contribute if it is found worthwhile. 

Andreas

[Carlos Antonio Ruiz Gomez]

Hi Andreas,

When I mentioned being consistent with ReportEngine.get I was meaning just about the language discovery query that is in that class.  Not to replace the entire report engine.

Also, a plugin is fine - I was just mentioning that most of those ideas are good in general, not for a custom implementation.  It sounds maybe that jasper is another candidate to split out of core.

Regards,

Carlos Ruiz

Am 04.12.19 um 11:52 schrieb Andreas Sumerauer:

[Andreas Sumerauer]

... Not to replace the entire report engine.

But what else could then best constitute an API to the document engine plugin? looking at the code this seemed to me the least intrusive option. 

Andreas

[Michal Zilincar]

Hi, 

I already did 2 similar small modification in core. With little bit different approach.

1) Language selection for jasper reporting - if printing process has parameter AD_Language_ID I will pass language from there to jasper report.

Initial language selection logic for parameter was enough for me.

2) I have added to ad_process field "FileName" . Where you can use classic iDempiere context values from records.

pls see attached picture.

At this moment I am trying to catch up with latest core dev. and synch my changes. Than I should be able to commit it to Jira for review.

If anybody is interested with this functionality.,