Changing per-install categories in production deployment.

[Julian Smith]

How does a technical (developer) user change these key/value paid in
production code?

<>/accounting/control/editPaymentMethodType

Re: OFBiz and Google Summer of Code (GsoC) 2018 ?

[Taher Alkhateeb]

Hi Michael, Sharan, all

I would volunteer as a mentor. Michael raised a good point regarding
the complexity level of the tasks assigned to these participants.

So the question is, what kind of tasks are suitable for such students?
It's hard to think of logic simpler than writing some documentation,
or some groovy services, or some unit tests. Do you have in mind some
tasks that might be simpler? Or do you simply think entry-level people
might not be able to absorb a framework like OFBiz?

On Fri, Jan 26, 2018 at 11:47 AM, Michael Brohl
 wrote:
> Hi Sharan,
>
> I think a participation in the GsoC is a good idea in general.
>
> I'm not sure if the proposed topics are suitable for such a program,
> especially if the students are not familiar with OFBiz. They need a lot of
> knowhow and learning before one can be productive and the mentors must spent
> a significant amount of time to support them.
>
> So, from the ASF perspective this might be a good idea, but for the project
> it is not efficient.
>
> We should find some simpler topics for the GsoC to make this a reasonable
> initiative. At the moment, I have not the right idea what this could be.
>
> Best regards,
>
> Michael
>
>
> Am 25.01.18 um 15:02 schrieb Sharan Foga:
>>
>> Hi All
>>
>> The ASF is registering to be a participating organisation for GsoC 2018.
>> We are in the middle of doing a lot of work. Would it be interesting for us
>> to add some of these tasks to the GsoC list and mentor some students? It is
>> a good way of encouraging new people to become involved with the project and
>> maybe also promote OFBiz too.
>>
>> If any of our tasks are selected, then we would need official mentors from
>> our community to work with the student on a regular basis to provide
>> feedback. There is also a regular reporting that the mentor needs to file
>> about the student's progress.
>>
>> If the mentor misses filing a report for a student then it reflects badly
>> on the ASF as a mentoring organisation. I mention this because it is
>> important that anyone wanitng to be a mentor for a GsoC student realises
>> that if they sign up to do it – then they need to do it!
>>
>> Some initial suggestions for GsoC tasks from Taher were:
>>
>> - convert minilang services to groovy
>> - documenting the components using the documentation framework we're
>> implementing
>> - convert integration tests to unit tests where possible
>>
>> If you have any other suggestions for potential tasks then please respond
>> with the details.
>>
>> None of this is any good – if we don't have any mentors, so we need
>> people willing to be GsoC mentors.
>>
>> So what's next?
>>
>> - First I'd like to get feedback on whether people think it is a good idea
>> for OFBiz to participate
>> - If, so then second I would like to see if we should use the suggestions
>> for tasks above or have any more
>> - Finally, and most importantly I'd like to know who would be willing to
>> be a mentor for a student selecting to take on one of our tasks
>>
>> Please let me have your comments and feedback
>>
>> Thanks
>> Sharan
>
>
>

Re: select your pdf document template from organizational party

[Nicolas Malin]

Hello Pierre,
On 27/01/2018 16:20, Pierre Smits wrote:

Hey Nicolas,

Is this a follow-up of the 'template-able' solution you proposed back in
2014/2015? If I remember correctly, your solution envisioned having
FTL-templates for invoice, order, shipment and other documents which could
be retrieved through the content component based on passed parameters.
Yes my solution is more generic that this previous idea, (because I grow 
;) )


I  orientated my thinking about to two axes :
* Unique area to configure document template for an existing list easily
* support tenant and plugin system as well

So I oriented my solution on new entity related to PartyAcctgPreference 
and an other entity CustomScreen to list all configured screen on the 
system. As I work only with the screen, you can custom your template as 
you want without limitation that the content system can introduce. But 
you can create a content library for your template and like to your 
organization the screen rendering a content (we need to define standard 
rules for the content resolution)


I put on the issue https://issues.apache.org/jira/browse/OFBIZ-10186 a 
patch for analyze my POC, all don't work but the main structure is present.


I imagine tomorrow to introduce new template as plugin like :
* template-invoice-detail-shipping
* template-invoice-europeen-flower
* template-order-consolidate-lines
and this without framework modification :)

Nicolas



Best regards,

Pierre Smits

V.P. Apache Trafodion

On Tue, Jan 23, 2018 at 9:10 PM, Nicolas Malin 
wrote:


Hi all,

Currently, I work on a pdf invoice creation for a personal project and I
wish go for this time to improve the printable document configuration (like
order pdf, invoice pdf, shipment pdf, and soon) related to the
organizational party that at its origin.

To realize it I started a POC where a add a new entity
PartyAcctgPrefTplDoc (maybe you have a better name) that associate an
organizational party (PartyAcctgPreference), a documentType (invoiceType,
orderType...) and a content.
The content return the screen to use (as blog concept) and the standard
document screen return the given screen or call the default screen is empty.

With this improvement, you can create your own pdf template document in
your custom plugin with associate data and use it without any framework
modification.

More, if you have a specific case to rendering different document
following functional case, you can implement it on your screen.

Also, we can have a standard choice to rendering your document from a
content, manageable from PartyContent association.

The life isn't pretty ? (french expression, if you not understant, just
ignore it :)

Feel free if you have some remarks, I will create an issue for each
document type manageable by this concept to detail more this idea.

For example :
Content data
  -

 

 

 

 

  --

   Standard screen (application/accounting/widget
/AccountinPrintScreens.xml)
  -
...
  
  
   
  
 

 
 .
  

GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if didn't
found any configuration for the invoice.partyIdFrom (for sales) or
invoice.partyId (for purchase)

Cheers,

Nicolas

--
logoNrd 
 Nicolas Malin
The apache way  : *Charity* Apache’s mission is
providing software for the public good.
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way <
http://theapacheway.com/>|réseau LE 

Re: [DISCUSSION] Disentanglement of the ExampleExt component

[Jacques Le Roux]

We have lazy consensus and vote for that.

But after them we still need action. I keep note about things I want to do. Sometimes it happens years after, and I have also seen others doing things 
I waited for years. It warms my heart then :)


Just an human

Jacques


Le 27/01/2018 à 16:00, Pierre Smits a écrit :

I noticed discussions not followed by action (at least Jiras creation, or
even closing) are useless as they almost sublimate in the void.

Jacques



How unfortunate. But when each comment added inserts a (new) viewpoint
about other aspects of the code base, then it is very hard for each
participant in this project to determine what kind of contribution will be
most beneficial to the project. Confusion leads to stagnation.

Best regards,

Pierre

Re: [Discussion] documentation framework for OFBiz

[Jacques Le Roux]

\o/

Jacques


Le 28/01/2018 à 11:12, Taher Alkhateeb a écrit :

Like Michael I think it is also a minor point. The reason I chose this
structure is because it is the default one for asciidoctor and is flexible
for the future, so Paul also makes a good point. Any structure is fine by
me, the real important work is getting the documentation right which is
very exciting to me.

I will create a patch soon for a base level structure and publishing
options for both HTML and PDF. It would be fantastic if we can unify _all_
of our documentation here including stuff currently in the wiki. This way
any changes to code are reflected (probably in the same commit) with the
relevant documentation.

I think we should start to consider maybe forming a team willing to help.
This is a big, but extremely important thing to have. If we do this right
then I think adoption rates would increase and our community would get
larger.

On Jan 28, 2018 12:19 PM, "Michael Brohl"  wrote:

Hi Paul,

this is only a minor point for me, it just saves one folder/structure level.

If we want to stay open for other documentation frameworks in the future,
it might be better to keep the proposed structure.

Best regards,

Michael


Am 28.01.18 um 02:54 schrieb Paul Foxworthy:

On 26 January 2018 at 19:53, Michael Brohl  wrote:


with a small modification: I don't think we'll need a two-folder structure

/docs/asciidoc, only /docs should be sufficient, no?

Hi Michael,

We have streamlined the build system in other places by having folders for
the source language: groovyScripts, minilang, src/main/java .

It means Groovy and other build tools can have default rules for what to do
with the contents of a language folder, and allows for the possibility of
other languages in future if necessary.

The extra layer is only a minor nuisance. I think I'd prefer to keep it.
What do you see as the disadvantages?

Cheers

Paul Foxworthy

Re: [FYI] BuildBot current situation

[Jacques Le Roux]

Hi,

I just reopened. https://issues.apache.org/jira/browse/INFRA-15836

I found the reason why we have still some successive repetitive alerts and 
explained in my last comment.

It concerns only the plugins branches, both trunk and releases.

I think we can close again and let it be.

Without other opinions I'll do so

Jacques


Le 19/01/2018 à 14:35, Jacques Le Roux a écrit :

I decided to for now close

 INFRA-15836     Buildbot sends repetitive success, or failure, reports

So the situation is clear, except if we get other repetitive emails of the same 
status.

Jacques



Le 16/01/2018 à 17:07, Jacques Le Roux a écrit :

Hi,

After recently
 INFRA-15785     OFBiz: remove R14 and R15, add R17
 INFRA-15829     OFBiz Buildbot tests don't pass, 8080 port error
 INFRA-15836     Buildbot sends repetitive success, or failure, reports,
 INFRA-15842     OFBiz Buildbot change the structure of tests logs
We have only
 INFRA-15836     Buildbot sends repetitive success, or failure, reports,
 INFRA-15842     OFBiz Buildbot change the structure of tests logs
open.

INFRA-15842 is trivial (just few logs dir to delete)
INFRA-15836 is a bit more annoying. We need to wait to see if this continues to happen and especially wait for feedback from the Infra team to see 
if it happens in other projects. We can also ask on HipChat if they forget to answer.


So we have a new BuildBot config which should be the basis after the framework 
and plugins splits and the R17 branch creation.

I'll complete the BuildBot doc, all comments are welcome...

Jacques


Le 13/01/2018 à 12:07, Jacques Le Roux a écrit :

I created INFRA-15836

Jacques


Le 13/01/2018 à 11:59, Jacques Le Roux a écrit :


This was intended to dev ML, at least the attachment passed

 Message transféré 
Sujet : Re: buildbot success in on ofbizTrunkFrameworkPlugins
Date : Sat, 13 Jan 2018 11:38:59 +0100
De : Jacques Le Roux 
Répondre à : dev@ofbiz.apache.org
Organisation : Les Arts Informatiques
Pour : comm...@ofbiz.apache.org

It seems it happened again (2 successful build messages, previous attached) 
when it's normally handled with INFRA-15394
But I think I know why. Those were triggered for different reasons:

Here

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1821053
Blamelist: deepak

Previous

Build Reason: downstream
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1821039
Blamelist: jleroux

So Deepak committed directly to plugins and that actioned testIntegration (we 
can't test plugins changes else)
When I committed to trunk and that also actioned testIntegration to test for no 
regression in plugins (the plugins build is also dependent from the
trunk commit)

So we need to find a way to make those two cases same for OFBiz.

I'll open a request to Infra because the dependent solution was suggested and 
coded by Gavin and it's a bit over my BuildBot competences.
I'll thought check if I can't find a solution by myself and help is welcome

Jacques


Le 13/01/2018 à 10:08,build...@apache.org  a écrit :
> The Buildbot has detected a restored build on builder 
ofbizTrunkFrameworkPlugins while building . Full details are available at:
> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/37
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
> Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1821053
> Blamelist: deepak
>
> Build succeeded!
>
> Sincerely,
>   -The Buildbot
>
>
>
>

Re: [Discussion] documentation framework for OFBiz

[Taher Alkhateeb]

Like Michael I think it is also a minor point. The reason I chose this
structure is because it is the default one for asciidoctor and is flexible
for the future, so Paul also makes a good point. Any structure is fine by
me, the real important work is getting the documentation right which is
very exciting to me.

I will create a patch soon for a base level structure and publishing
options for both HTML and PDF. It would be fantastic if we can unify _all_
of our documentation here including stuff currently in the wiki. This way
any changes to code are reflected (probably in the same commit) with the
relevant documentation.

I think we should start to consider maybe forming a team willing to help.
This is a big, but extremely important thing to have. If we do this right
then I think adoption rates would increase and our community would get
larger.

On Jan 28, 2018 12:19 PM, "Michael Brohl"  wrote:

Hi Paul,

this is only a minor point for me, it just saves one folder/structure level.

If we want to stay open for other documentation frameworks in the future,
it might be better to keep the proposed structure.

Best regards,

Michael


Am 28.01.18 um 02:54 schrieb Paul Foxworthy:

On 26 January 2018 at 19:53, Michael Brohl  wrote:
>
>
> with a small modification: I don't think we'll need a two-folder structure
>> /docs/asciidoc, only /docs should be sufficient, no?
>>
>> Hi Michael,
>
> We have streamlined the build system in other places by having folders for
> the source language: groovyScripts, minilang, src/main/java .
>
> It means Groovy and other build tools can have default rules for what to do
> with the contents of a language folder, and allows for the possibility of
> other languages in future if necessary.
>
> The extra layer is only a minor nuisance. I think I'd prefer to keep it.
> What do you see as the disadvantages?
>
> Cheers
>
> Paul Foxworthy
>
>

Re: [Discussion] documentation framework for OFBiz

[Michael Brohl]

Hi Paul,

this is only a minor point for me, it just saves one folder/structure level.

If we want to stay open for other documentation frameworks in the 
future, it might be better to keep the proposed structure.


Best regards,

Michael


Am 28.01.18 um 02:54 schrieb Paul Foxworthy:

On 26 January 2018 at 19:53, Michael Brohl  wrote:



with a small modification: I don't think we'll need a two-folder structure
/docs/asciidoc, only /docs should be sufficient, no?


Hi Michael,

We have streamlined the build system in other places by having folders for
the source language: groovyScripts, minilang, src/main/java .

It means Groovy and other build tools can have default rules for what to do
with the contents of a language folder, and allows for the possibility of
other languages in future if necessary.

The extra layer is only a minor nuisance. I think I'd prefer to keep it.
What do you see as the disadvantages?

Cheers

Paul Foxworthy






smime.p7s
Description: S/MIME Cryptographic Signature