It's no more possible to enter a date manually

[Olivier Heintz]

Hello,

It's a question before creating a Jira.

In a datetime field, I'm not able to enter in the field, directly the date-time 
I want, because going to the next field with tab, erase it.
If I use datetimepicker icon it works.

Second point: With en language, the tooltips in the fields says the format is 
-MM-dd HH.mm.ss.SSS when it is MM/dd/ hh:mm:ss a

It seem that it was'nt like this few months ago. Can anyone confirm this ?

Olivier

Re: Kickoff Meeting - Apache OFBiz Tutorial Project

[Olivier Heintz]

+1

Le 09/12/2020 à 08:39, Pranay Pandey a écrit :

Hello Tutorial Project Volunteers,

First of all thank you so much for showing interest in volunteering the
Apache OFBiz Tutorial Project.

With this email I want to propose an online meeting to kickoff the project.
This meeting will help us in knowing each other. After this meeting we will
continue doing offline communication on email, OFBiz mailing list, Slack
Channel to make progress with our work. We can surely plan online meetings
in future as well as and when needed. This way the community will also be
updated all the time.

It's a great opportunity for all of us to learn from each other and to also
prepare some robust content for OFBiz developers/users/evaluators. What
we'll generate will be a next level set of tutorials and guides for the
community and will be a proven asset for the project.

How about meeting on this Friday 1:00 PM GMT? Does this day and time work
for all of you? Please confirm your availability and we'll go from there.

Available: +1
May be: 0
Not Available: -1

Kind regards,
Pranay Pandey
https://ofbiz.apache.org/

Where to put video, result from selenium about functional process

[Olivier Heintz]

Hi community,

I have just migrated a wiki page "How to Create the main Company in Party 
Manager" to the user-manual.
https://ci.apache.org/projects/ofbiz/site/trunk/ofbizdoc/html5/user-manual.html#_parties_processes

As it describe a process, I have create a selenium webdriver test similar to 
what is described in the doc to
1. check all works as it's describe in the doc
2. be able to have a video to show the process (with some little comment at 
each step)
   (https://video.ploud.fr/videos/watch/d7d00dc4-9ad2-445b-baab-a15cd2ba099b)

So the question, where can I put (or where it's better to put) this video and 
after added a link to it, in the user-manual.

Currently I use a PeerTube server for the 3 first video : 
https://video.ploud.fr/video-channels/ofbizextra_tutorial/videos

Re: Volunteer Apache OFBiz Tutorial Project

[Olivier Heintz]

Good idea

Le 27/11/2020 à 07:13, Pranay Pandey a écrit :

Hello Devs,

Calling out for volunteers for help in building a good set of
developer/architect tutorial sessions on the below-given topics for The
Apache OFBiz community:
0. Getting Started - Local build - What is required and how to do it? 1.
Entity Engine 2. Service Engine 3. Workflow Management(Async Calls, EECA,
SECA, Group Service, etc.) 4. Job Management (Scheduling and Execution) 5.
Transaction Management 6. Log Management 7. Production Setup and Monitoring
. any other essential topic. These topics will be broken down into many
sessions based on the planning that we will do together. Interested in
volunteering for this project? If yes, please fill this form
https://forms.gle/M3m1g5V1TqgQueySA



done


Kind regards,
Pranay Pandey

Re: Documentation "issues" Status

[Olivier Heintz]

Hi all,

First step for migration from docbook to asciidoc seem to be done.
All help files and documentations files have been migrated and all help link 
are now for html files generated from asciidoc.
If someone see a link which still go a the old help system, open a Jira or a 
message on the mailing-list.
The Jira OFBIZ-11587 will be closed after all ...HelpData.xml will be removed

There are still some points to do for the help system migration:
* OFBIZ-11364 OFBiz Documentation System, How to write it
* OFBIZ-12030 Help System can be on user language

If you know some JIRA relative to documentation, please check if they have the 
Label "Documentation"

About other Documentation Jira
>>> There are few minor things and some others more systemic. What are your 
>>> thought about them? Take your time ;)
>>>
>>> Among the minor issues:
>>> 
>>>
>>>
>>> https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML:
>>> This is now broken. I guess after you removed some files referenced by 
>>> documents in /plugins/cmssite/documents
>>> Related with OFBIZ-11364 I guess.

Currently, there is no more demo available, and ofbizextra one have not the 
cmssite plugin installed, so I will put it and check

>>>
>>> OFBIZ-6243:
>>> Having a README.md in each component ?

I don't think it's a good idea to have documentation in multiple format,
so I propose to replace them by a README.adoc with only one line with a link to 
the user-manual.

I will check if for each component, content of current README.md is in 
component intrduction in user-manual.

>>>
>>> Among the more serious ones:
>>> =
>>>
>>> OFBIZ-10285:
>>> What are your thoughts about this one (sorry not enough time to dig in)?

I propose to close this task, and check if all sub-task have the Documentation 
label associated
  if needed I will create new one for ofbiz-architecture schema

>>>
>>> Also we need to update, actually  mainly prune, the wiki, there is too much 
>>> deprecated and MISLEADING documentation there!
>>>

First finish / closed the more obvious Jira, ex: OFBIZ-11364 to have a clear 
and up to date rules about where and how write documentation with which
conventions


Le 29/08/2020 à 17:09, Jacques Le Roux a écrit :
> Note: weirdly we have almost no documentation in source for ecommerce
> 
> Le 29/08/2020 à 12:03, Jacques Le Roux a écrit :
>> Hi,
>>
>> Some update here...
>>
>> Le 17/07/2020 à 09:46, Jacques Le Roux a écrit :
>>> Hi All, Olivier,
>>>
>>> Again Olivier, I must say I'm so glad that you took the documentation 
>>> challenge in hands. That's very promising for the future of the project. 
>>> Thanks for your work!
>>>
>>> At this stage I'd like to clean the situation as much as possible. It's not 
>>> about your work, but about all that we have left behind us. It's 
>>> difficult to figure out what the situation really is.
>>>
>>> There are few minor things and some others more systemic. What are your 
>>> thought about them? Take your time ;)
>>>
>>> Among the minor issues:
>>> 
>>>
>>> I think we should begin to close issues like:
>>>
>>> OFBIZ-6644:
>>> This is deprecated with its sub-tasks
>>
>> Done
>>
>>
>>>
>>> OFBIZ-11893:
>>> Trivial issues I collected before forgetting them. You might found more.
>>
>> Updated with more info
>>
>>
>>>
>>> https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML:
>>> This is now broken. I guess after you removed some files referenced by 
>>> documents in /plugins/cmssite/documents
>>> Related with OFBIZ-11364 I guess.
>>
>> WIP by Olivier...
>>
>>
>>> OFBIZ-9926 should be closed.
>>
>> Done
>>
>>
>>>
>>> OFBIZ-6243:
>>> Should we take the burden of migrating the existing README.md?
>>> I don't think so. I'd like to remove them with the related wiki pages, like:
>>> https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting
>>> All that is mostly deprecated and redundant.
>>
>> I have updated or removed deprecated information in README.md files.
>>
>> I started with wiki pages but almost all of them will be moved to wiki attic 
>> with OFBIZ-11619
>>
>>
>> Did not have time to continue on the rest below
>>
>> Jacques
>>
>>>
>>> Among the more serious ones:
>>> =
>>>
>>> OFBIZ-10285:
>>> What are your thoughts about this one (sorry not enough time to dig in)?
>>> It's clearly time to prune the sub-tasks, I mean close them if possible, 
>>> like:
>>> OFBIZ-10251
>>> OFBIZ-10255
>>> OFBIZ-11364
>>> etc.
>>>
>>> Also we need to update, actually  mainly prune, the wiki, there is too much 
>>> deprecated and MISLEADING documentation there!
>>>
>>> A bit of pontification :):
>>>
>>> One thing I learned is that it's hard to maintain a documentation. Because 
>>> things evolve and are not always related to each other (like code).
>>> So we should restrain ourselves to refer to things that may disappear or 
>>> change in the future. If not possible we need to 

Re: Documentation "issues"

[Olivier Heintz]

Thanks Jacques, for this list,

I will finish the plugins docbook migration to asciidoc
and I will continue with these JIRA, with a first step to be sure to migrate 
all old format to the new one.

This list is a good road to clean before doing some new doc.

Thanks

Olivier

Le 17/07/2020 à 09:46, Jacques Le Roux a écrit :
> Hi All, Olivier,
> 
> Again Olivier, I must say I'm so glad that you took the documentation 
> challenge in hands. That's very promising for the future of the project. 
> Thanks 
> for your work!
> 
> At this stage I'd like to clean the situation as much as possible. It's not 
> about your work, but about all that we have left behind us. It's difficult 
> to figure out what the situation really is.
> 
> There are few minor things and some others more systemic. What are your 
> thought about them? Take your time ;)
> 
> Among the minor issues:
> 
> 
> I think we should begin to close issues like:
> 
> OFBIZ-6644:
> This is deprecated with its sub-tasks
> 
> OFBIZ-11893:
> Trivial issues I collected before forgetting them. You might found more.
> 
> https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML:
> This is now broken. I guess after you removed some files referenced by 
> documents in /plugins/cmssite/documents
> Related with OFBIZ-11364 I guess.
> OFBIZ-9926 should be closed.
> 
> OFBIZ-6243:
> Should we take the burden of migrating the existing README.md?
> I don't think so. I'd like to remove them with the related wiki pages, like:
> https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting
> All that is mostly deprecated and redundant.
> 
> Among the more serious ones:
> =
> 
> OFBIZ-10285:
> What are your thoughts about this one (sorry not enough time to dig in)?
> It's clearly time to prune the sub-tasks, I mean close them if possible, like:
> OFBIZ-10251
> OFBIZ-10255
> OFBIZ-11364
> etc.
> 
> Also we need to update, actually  mainly prune, the wiki, there is too much 
> deprecated and MISLEADING documentation there!
> 
> A bit of pontification :):
> 
> One thing I learned is that it's hard to maintain a documentation. Because 
> things evolve and are not always related to each other (like code).
> So we should restrain ourselves to refer to things that may disappear or 
> change in the future. If not possible we need to generalise them as much as 
> possible.
> An example is OFBIZ-6243.
> 
> Jacques
> 

Re: Plugins documentation and framework

[Olivier Heintz]

My point of view about my question ;-)

On a Documentation, point of view, I prefer the solution 2, (with a clear flag 
to say it's a with the plugin )

On a technical point of view to have minimum dependency between framework and 
plugins, solution 3 is the better one

Le 15/07/2020 à 10:53, Olivier Heintz a écrit :
> Hi Community,
> 
> I start migrate plugins docbook for ofbiz-plugins and I have a question about
> How to manage plugins documentation, in the structure of user-documentation 
> and developper-manual ?
> 
> I see 3 possible solutions
> 1) Current solution: one document per plugin, and link to its in the correct 
> chapter
>example: plugins ldap, doc SingleSignOn : it is generated as
> https://ci.apache.org/projects/ofbiz/site/trunk/pluginsdoc/ldap/html5/SingleSignOn.html
> in developper-manual, put a link to this doc in the Deployment 
> chapter
> 
> 2) add a "include::" in the correct chapter (created a dependency between 
> framework and plugins)
>example: currently in Deployment chapter there is the "11.2. OFBiz Single 
> Sign On using CAS and LDAP" as sub-chapter
> 
> 3) add a "include::" to a doc/asciidoc/plugins-user-documentation in 
> user-ddocumentation
>   and one to doc/asciidoc/plugins-developper-manual in 
> developper-manual
>In each file there will be all the include to tha appropriate plugins.
> 

Plugins documentation and framework

[Olivier Heintz]

Hi Community,

I start migrate plugins docbook for ofbiz-plugins and I have a question about
How to manage plugins documentation, in the structure of user-documentation and 
developper-manual ?

I see 3 possible solutions
1) Current solution: one document per plugin, and link to its in the correct 
chapter
   example: plugins ldap, doc SingleSignOn : it is generated as
https://ci.apache.org/projects/ofbiz/site/trunk/pluginsdoc/ldap/html5/SingleSignOn.html
in developper-manual, put a link to this doc in the Deployment 
chapter

2) add a "include::" in the correct chapter (created a dependency between 
framework and plugins)
   example: currently in Deployment chapter there is the "11.2. OFBiz Single 
Sign On using CAS and LDAP" as sub-chapter

3) add a "include::" to a doc/asciidoc/plugins-user-documentation in 
user-ddocumentation
  and one to doc/asciidoc/plugins-developper-manual in developper-manual
   In each file there will be all the include to tha appropriate plugins.

Re: API Reference on OFBiz site

[Olivier Heintz]

+1 to the 2nd option

Le 15/07/2020 à 09:58, Devanshu Vyas a écrit :
> +1 to the 2nd option.
> 
> Thanks & Regards,
> Devanshu Vyas.
> 
> 
> On Wed, Jul 15, 2020 at 10:56 AM Pritam Kute 
> wrote:
> 
>> I am also inclined to 2nd option.
>>
>> Thanks, Pawan for pointing this.
>>
>> Kind Regards,
>> --
>> Pritam Kute
>>
>>
>> On Wed, Jul 15, 2020 at 1:24 AM Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>> Thanks Pawan,
>>>
>>> The 2nd options looks like a good idea to me.
>>>
>>> Jacques
>>>
>>> Le 14/07/2020 à 15:38, Pawan Verma a écrit :
 Hello Devs,

 Since Oliver has refactored documentation with new directories
>> structure
 with the trunk, next and stable API Reference link becomes stale.

 Question: What should be the API Reference link on the site?

 Possible Solutions:
 #1: We can use the link for stable APIs for Site as suggested by
>> Jacques
>>> on
 Jira OFBIZ-11888.

 #2: We can show the link for both trunk and stable release like Build
>> and
 Run section.
 Example:
 * OFBiz API Reference*

 - *Trunk API Reference*
 - *Release 17.12 API Reference*

 Please share your thoughts on this. TIA!

>>>
>>
> 

Re: Add CHANGELOG.md file

[Olivier Heintz]

+1 for CHANGELOG.adoc ;-)

Le 17/06/2020 à 07:52, Deepak Dixit a écrit :
> Hi Dev,
> 
> As we have already moved to git for the version control system, I propose
> to add a changelog file to maintain the changelogs[1].
> What is a changelog?
> 
> A changelog is a file which contains a curated, chronologically ordered
> list of notable changes for each version of a project.
> Why keep a changelog?
> 
> To make it easier for users and contributors to see precisely what notable
> changes have been made between each release (or version) of the project.
> Who needs a changelog?
> 
> People do. Whether consumers or developers, the end users of software are
> human beings who care about what's in the software. When the software
> changes, people want to know why and how.
> 
> We can have our own process to generate changelog, It may be either manual
> entries, or some tool or using git log. We can discuss this independently.
> 
> https://keepachangelog.com/en/1.0.0/
> 
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
> 

Re: Use Compound Widget on rest of the project

[Olivier Heintz]

Hi James,

It's a good idea, but question is, how to group ?
I have tested compound Widget for the POC VueJs, and I use it with one compound 
widget file by resouceName (on a REST uri format point of view). In
example, 4 files: Example, ExampleItem, ExampleFeature, ExampleFeatureAppl
I'm waiting for more time using them to say if it's the correct group size or 
not.

So I suggest to use compound Widget, but not convert all xml files immediately, 
we need more developer experience to find the correct group size.

Regards,
Olivier

Le 13/06/2020 à 14:32, James Yong a écrit :
> Hi all,
> 
> Currently, compound widget tag is only used in Examples application.
> Propose to convert rest of the project to use compound widget, so that 
> dependencies are grouped together.
> 
> Regards,
> James 
> 

Re: OFBIZ-8459 and plugins as a submodule

[Olivier Heintz]

+1 for plugins dir is not a submodule of ofbiz-framework

Le 07/06/2020 à 17:52, Jacques Le Roux a écrit :
> Hi,
> 
> While checking OFBIZ-11745, I found several commits done with OFBIZ-8459 
> where the plugins dir was successively added, reverted and added again as a 
> submodule of ofbiz-framework.
> https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b39c179
> https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=3a4d22
> https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=bda6192
> 
> I guess we all missed it and have removed it. I'd like to know if we all 
> agree that plugins dir is not a submodule of ofbiz-framework.
> 
> Thanks
> 
> Jacques
> 
> 

Re: LineLength for checkstyle

[Olivier Heintz]

+1

Le 23/05/2020 à 17:29, Suraj Khurana a écrit :
> Hello Devs,
> 
> Recently we are facing some checkstyle issues and one cause of it is
> LineLength property.
> Currently we have set it to 120, I think we should make it to 150 instead.
> It is pretty visible in 13/14 font sizes as well.
> 
> Please share your thoughts on this.
> 
> --
> Best Regards,
> Suraj Khurana
> Senior Technical Consultant
> 

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Olivier Heintz]

Hi Jacques,

I have created https://issues.apache.org/jira/browse/INFRA-20311 "we need 
directories per release under ci.apache.org/projects/ofbiz/site/"

Currently there is :
projects/ofbiz/site/
  ├── javadocs
  ├── ofbizdoc
  └── pluginsdoc

we want
projects/ofbiz/site/
  ├── stable
  | ├── javadocs
  | ├── ofbizdoc
  | └── pluginsdoc
  ├── next
  | ├── javadocs
  | ├── ofbizdoc
  | └── pluginsdoc
  └── trunk
   ├── javadocs
   ├── ofbizdoc
   └── pluginsdoc


I have prepared modification in buildbot/.../ofbiz.conf
who can commit it when new directory will be created,
me or you prefer I create a OFBiz Jira ?

Olivier

Le 23/05/2020 à 11:51, Jacques Le Roux a écrit :
> Hi Olivier:
> 
> It's only in R17, see content of a 
> https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins build
> 
> If you want to know more look at 'f_ofb_branch17_framework_plugins' in 
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf/
>  (only committers)
> 
> All builds mention: "The Documentation is only generated for the next stable 
> version, at the moment R17"
> 
> Jobs to do are:
> 
> Adds the same in trunk and R18
> 
> And especially before ask the same than in 
> https://issues.apache.org/jira/browse/INFRA-17258 distinguishing each case. 
> Better call them stable, next 
> and trunk than R17, R18 and trunk (OK trunk never "change" ;) )...
> 
> HTH
> 
> Jacques
> 
> Le 23/05/2020 à 11:27, Olivier Heintz a écrit :
>> Thanks Jacques for the clarification,
>>
>> But, I'm not sure to understand,
>> currently, doc is generated only for R17 and are only included in buildbot 
>> job for trunkFrameworkPlugin  ?
>> Work to do is to add for job R17Framework and R18Framework ?
>> Infra help is needed to publish for multi-release ?
>>
>> can I help about one of these points ?
>>
>> Olivier
>>
>> Le 20/05/2020 à 17:15, Jacques Le Roux a écrit :
>>> Thanks Olivier,
>>>
>>> I must add that it's the current location and it would need more work to 
>>> change it, notably Infra help
>>>
>>> Jacques
>>>
>>> Le 20/05/2020 à 16:24, Olivier Heintz a écrit :
>>>> Yes, of course
>>>>
>>>> My explanation was not clear, I propose to have one documentation by 
>>>> release and use it in the relative help
>>>>
>>>> My question is more about using (or not) 
>>>> ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc
>>>>
>>>> Le 20/05/2020 à 08:32, Michael Brohl a écrit :
>>>>> Hi Olivier,
>>>>>
>>>>> wouldn't it be better to have different documentation paths for the
>>>>> different branches?
>>>>>
>>>>> If we would show the trunk documentation/help for stable branches, it
>>>>> will most likely be wrong in some cases.
>>>>>
>>>>> Another thought: it would be great if we could have the docs available
>>>>> at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael Brohl
>>>>>
>>>>> ecomify GmbH - www.ecomify.de
>>>>>
>>>>>
>>>>> Am 19.05.20 um 11:54 schrieb Olivier Heintz:
>>>>>> Hi Community,
>>>>>>
>>>>>> I need some comment or thought about one of point of the solution 
>>>>>> proposed.
>>>>>>
>>>>>> Is there some people against the fact of used 
>>>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for 
>>>>>> the ofbiz help ?
>>>>>>
>>>>>> As I explained in my previous email, 
>>>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc would be the default value 
>>>>>> for userDocUri, (but value in
>>>>>> general.properties can be change with the local place of doc generation).
>>>>>>
>>>>>> If community think, it's a good step solution (on the road to the new 
>>>>>> help system), I will create a JIRA for generating the doc on all 
>>>>>> supported
>>>>>> branches (currently, it's only done for r17)
>>>>>>
>>>>>> I just finished to migrate AccountingHelpData.xml to added the >>>>> field="helpAnchor" to the correct screens, so now it's really possible 
>>>>>> to

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Olivier Heintz]

Thanks Jacques for the clarification,

But, I'm not sure to understand,
currently, doc is generated only for R17 and are only included in buildbot job 
for trunkFrameworkPlugin  ?
Work to do is to add for job R17Framework and R18Framework ?
Infra help is needed to publish for multi-release ?

can I help about one of these points ?

Olivier

Le 20/05/2020 à 17:15, Jacques Le Roux a écrit :
> Thanks Olivier,
> 
> I must add that it's the current location and it would need more work to 
> change it, notably Infra help
> 
> Jacques
> 
> Le 20/05/2020 à 16:24, Olivier Heintz a écrit :
>> Yes, of course
>>
>> My explanation was not clear, I propose to have one documentation by release 
>> and use it in the relative help
>>
>> My question is more about using (or not) 
>> ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc
>>
>> Le 20/05/2020 à 08:32, Michael Brohl a écrit :
>>> Hi Olivier,
>>>
>>> wouldn't it be better to have different documentation paths for the
>>> different branches?
>>>
>>> If we would show the trunk documentation/help for stable branches, it
>>> will most likely be wrong in some cases.
>>>
>>> Another thought: it would be great if we could have the docs available
>>> at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.
>>>
>>> Thanks,
>>>
>>> Michael Brohl
>>>
>>> ecomify GmbH - www.ecomify.de
>>>
>>>
>>> Am 19.05.20 um 11:54 schrieb Olivier Heintz:
>>>> Hi Community,
>>>>
>>>> I need some comment or thought about one of point of the solution proposed.
>>>>
>>>> Is there some people against the fact of used 
>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for 
>>>> the ofbiz help ?
>>>>
>>>> As I explained in my previous email, 
>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc would be the default value for 
>>>> userDocUri, (but value in
>>>> general.properties can be change with the local place of doc generation).
>>>>
>>>> If community think, it's a good step solution (on the road to the new help 
>>>> system), I will create a JIRA for generating the doc on all supported
>>>> branches (currently, it's only done for r17)
>>>>
>>>> I just finished to migrate AccountingHelpData.xml to added the >>> field="helpAnchor" to the correct screens, so now it's really possible to 
>>>> see if
>>>> it's usable. I will updated the JIRA 11693.
>>>>
>>>> Olivier
>>>>
>>>> Le 12/05/2020 à 16:42, Olivier Heintz a écrit :
>>>>> Jira 11693 created with a patch proposed
>>>>>
>>>>> if this solution is accepted, (and all asciidoc integrated) next step is 
>>>>> to work component by component
>>>>> For each:
>>>>> 1. add in the component decorator >>>> Title in user-documentation
>>>>> 2. using heldata.xml to update all screens which had a dedicated text for 
>>>>> help, with the new helpAnchor value
>>>>>
>>>>> It's not a too large task, which can be maybe add in the task list for 
>>>>> the next community days, and so finish the migration from docbook to 
>>>>> asciidoc ;-)
>>>>>
>>>>> any thoughts?
>>>>>
>>>>> ps: this week, I will do this job for accounting component
>>>>>
>>>>> Le 11/05/2020 à 15:38, Olivier Heintz a écrit :
>>>>>> Hi community,
>>>>>>
>>>>>> First step about Docbook migration to asciidoc is done, all existing 
>>>>>> files have been converted
>>>>>> (waiting a review before PR merge)
>>>>>>
>>>>>> Next step is to have a new help system,
>>>>>>
>>>>>> I propose to do a very simple solution which would be a link to a 
>>>>>> documentation site.
>>>>>> This solution would use
>>>>>> 1. at ofbiz level, a default proprety for documentation website uri
>>>>>> 2. at the screen level
>>>>>>   * it would be possible to give a other uri (for user documentation)
>>>>>>   * if the anchor in the user documentation for this screen is put, 
>>>>>> the new help is used otherwise the older link is used
>>>>>>
>>>&g

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Olivier Heintz]

Yes, of course

My explanation was not clear, I propose to have one documentation by release 
and use it in the relative help

My question is more about using (or not) 
ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc

Le 20/05/2020 à 08:32, Michael Brohl a écrit :
> Hi Olivier,
> 
> wouldn't it be better to have different documentation paths for the 
> different branches?
> 
> If we would show the trunk documentation/help for stable branches, it 
> will most likely be wrong in some cases.
> 
> Another thought: it would be great if we could have the docs available 
> at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.
> 
> Thanks,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 19.05.20 um 11:54 schrieb Olivier Heintz:
>> Hi Community,
>>
>> I need some comment or thought about one of point of the solution proposed.
>>
>> Is there some people against the fact of used 
>> ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for the 
>> ofbiz help ?
>>
>> As I explained in my previous email, 
>> ci.apache.org/projects/ofbiz/site/ofbizdoc would be the default value for 
>> userDocUri, (but value in
>> general.properties can be change with the local place of doc generation).
>>
>> If community think, it's a good step solution (on the road to the new help 
>> system), I will create a JIRA for generating the doc on all supported
>> branches (currently, it's only done for r17)
>>
>> I just finished to migrate AccountingHelpData.xml to added the > field="helpAnchor" to the correct screens, so now it's really possible to 
>> see if
>> it's usable. I will updated the JIRA 11693.
>>
>> Olivier
>>
>> Le 12/05/2020 à 16:42, Olivier Heintz a écrit :
>>> Jira 11693 created with a patch proposed
>>>
>>> if this solution is accepted, (and all asciidoc integrated) next step is to 
>>> work component by component
>>> For each:
>>> 1. add in the component decorator >> Title in user-documentation
>>> 2. using heldata.xml to update all screens which had a dedicated text for 
>>> help, with the new helpAnchor value
>>>
>>> It's not a too large task, which can be maybe add in the task list for the 
>>> next community days, and so finish the migration from docbook to asciidoc 
>>> ;-)
>>>
>>> any thoughts?
>>>
>>> ps: this week, I will do this job for accounting component
>>>
>>> Le 11/05/2020 à 15:38, Olivier Heintz a écrit :
>>>> Hi community,
>>>>
>>>> First step about Docbook migration to asciidoc is done, all existing files 
>>>> have been converted
>>>> (waiting a review before PR merge)
>>>>
>>>> Next step is to have a new help system,
>>>>
>>>> I propose to do a very simple solution which would be a link to a 
>>>> documentation site.
>>>> This solution would use
>>>>1. at ofbiz level, a default proprety for documentation website uri
>>>>2. at the screen level
>>>>  * it would be possible to give a other uri (for user documentation)
>>>>  * if the anchor in the user documentation for this screen is put, the 
>>>> new help is used otherwise the older link is used
>>>>
>>>> If this solution is validated, next step will be to update all the screens 
>>>> with the correct link value
>>>>
>>>> I propose to create the Jira (and the implmentation) with this very simple 
>>>> solution (using the doc generated by Buildbot as documentation site)
>>>> when some other people with a good knowledge of gradle and/or ofbiz cms 
>>>> have time to do a internal documentation website, it will be possible to
>>>> change the default uri ;-)
>>>>
>>>> what's your opinion about ?
>>>>
>>>>
>>>> Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
>>>>> inline
>>>>>
>>>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>>>>>> Hello Olivier,
>>>>>>
>>>>>> Without digging into much detail, I can say that it's a good idea to
>>>>>> switch the online help system to asciidoc.
>>>>>>
>>>>>> The current structure of asciidoc templates is designed to be a full
>>>>>> manual document. To link up different pages to different sections, you
>>>>>> need to break the documenta

enter a date directly, no more possible

[Olivier Heintz]

Hi,

This morning on demo-trunk, it seems, it's no more possible to enter a 
date-time in a date-time field without using the calendar icon !

ex: on party, added a security group
The field seems to be disable

is it normal ?  it's not really convenient

Olivier

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Olivier Heintz]

Hi Community,

I need some comment or thought about one of point of the solution proposed.

Is there some people against the fact of used 
ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for the 
ofbiz help ?

As I explained in my previous email, ci.apache.org/projects/ofbiz/site/ofbizdoc 
would be the default value for userDocUri, (but value in
general.properties can be change with the local place of doc generation).

If community think, it's a good step solution (on the road to the new help 
system), I will create a JIRA for generating the doc on all supported
branches (currently, it's only done for r17)

I just finished to migrate AccountingHelpData.xml to added the  Jira 11693 created with a patch proposed
> 
> if this solution is accepted, (and all asciidoc integrated) next step is to 
> work component by component
> For each:
> 1. add in the component decorator  Title in user-documentation
> 2. using heldata.xml to update all screens which had a dedicated text for 
> help, with the new helpAnchor value
> 
> It's not a too large task, which can be maybe add in the task list for the 
> next community days, and so finish the migration from docbook to asciidoc ;-)
> 
> any thoughts?
> 
> ps: this week, I will do this job for accounting component
> 
> Le 11/05/2020 à 15:38, Olivier Heintz a écrit :
>> Hi community,
>>
>> First step about Docbook migration to asciidoc is done, all existing files 
>> have been converted
>> (waiting a review before PR merge)
>>
>> Next step is to have a new help system,
>>
>> I propose to do a very simple solution which would be a link to a 
>> documentation site.
>> This solution would use
>>   1. at ofbiz level, a default proprety for documentation website uri
>>   2. at the screen level
>> * it would be possible to give a other uri (for user documentation)
>> * if the anchor in the user documentation for this screen is put, the 
>> new help is used otherwise the older link is used
>>
>> If this solution is validated, next step will be to update all the screens 
>> with the correct link value
>>
>> I propose to create the Jira (and the implmentation) with this very simple 
>> solution (using the doc generated by Buildbot as documentation site)
>> when some other people with a good knowledge of gradle and/or ofbiz cms have 
>> time to do a internal documentation website, it will be possible to
>> change the default uri ;-)
>>
>> what's your opinion about ?
>>
>>
>> Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
>>> inline
>>>
>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>>>> Hello Olivier,
>>>>
>>>> Without digging into much detail, I can say that it's a good idea to
>>>> switch the online help system to asciidoc.
>>>>
>>>> The current structure of asciidoc templates is designed to be a full
>>>> manual document. To link up different pages to different sections, you
>>>> need to break the documentation down to smaller files and then combine
>>>> them. This way you can have both the "big" manual and the "per screen"
>>>> help section.
>>>
>>> In my experience, as I'm working with
>>>   - current ofbiz online help
>>>   - ofbiz webhelp
>>>   - some static doc website done with Grav (build with multiple small files)
>>>   - some static doc website done with asciidoc (only one large file)
>>>   - ...
>>>
>>> With multiple small files it's needed to have a very good search engine and 
>>> a global index / TOC
>>>
>>> With the One page doc, the TOC is very large and not always very 
>>> convenient, but exist and the browser-find works
>>>   and it's easy to navigate between details and generality
>>>
>>> So, as a user, I prefer help base on One page documentation.
>>>>
>>>> Also, gradle might not be enough for online help. A more robust
>>>> solution could involve integrating asciidoc at the framework level to
>>>> dynamically generate help. So this is another idea to consider.
>>>
>>> When we have tried, in the past to dynamically generate html from standard 
>>> docbook process it was too slow
>>>   it's why it was decide to use a freemarker template to do the generation, 
>>> even if only 5% of docbook syntax
>>>   was managed.
>>>
>>> Documentation not change very often, static page seem enough for our need.
>>>
>>>>
>>>> On Wed, Feb 26, 2020 at 2:29 PM Ol

FTL not work after: commit branch trunk updated: Improved: widget tag (OFBIZ-11686)

[Olivier Heintz]

Hi James,

In HR, on main page, on tree company organization, with a Right Click, there is 
a menu with
as last item "Remove Internal Organization" which call RemoveInternalOrg.ftl

before your commit this function works
now nothing is done

after remove multi-block="true"  in the line
 
it works again

Can you have a look at this problem
Thank you



Le 15/05/2020 à 05:17, jamesy...@apache.org a écrit :
> This is an automated email from the ASF dual-hosted git repository.
> 
> jamesyong pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> 
> 
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 60c78d2  Improved:  widget tag (OFBIZ-11686)
> 60c78d2 is described below
> 
> commit 60c78d24be4ab2b4f8aa2f6603968863c12b9b92
> Author: James Yong 
> AuthorDate: Fri May 15 11:16:15 2020 +0800
> 
> Improved:  widget tag (OFBIZ-11686)
> 
> Removed script-template tag.
> Use multi-block=true on html-template tag instead.
> ---
>  applications/order/template/order/FindOrders.ftl   |  72 +++-
>  .../order/template/order/FindOrders.js.ftl |  86 --
>  .../order/widget/ordermgr/OrderViewScreens.xml |   3 +-
>  .../webapp/ftl/ScriptTemplateListTransform.java|   5 +-
>  framework/widget/dtd/widget-screen.xsd |   9 +-
>  .../widget/artifact/ArtifactInfoGatherer.java  |   5 -
>  .../org/apache/ofbiz/widget/model/HtmlWidget.java  | 124 
> +
>  .../ofbiz/widget/model/ModelWidgetVisitor.java |   2 -
>  .../ofbiz/widget/model/ScriptTemplateUtil.java |  43 ---
>  .../ofbiz/widget/model/XmlWidgetVisitor.java   |  10 +-
>  .../ofbiz/widget/renderer/ScreenRenderer.java  |   7 +-
>  11 files changed, 160 insertions(+), 206 deletions(-)
> 
> diff --git a/applications/order/template/order/FindOrders.ftl 
> b/applications/order/template/order/FindOrders.ftl
> index 0d1923d..6eaff5b 100644
> --- a/applications/order/template/order/FindOrders.ftl
> +++ b/applications/order/template/order/FindOrders.ftl
> @@ -17,6 +17,76 @@ specific language governing permissions and limitations
>  under the License.
>  -->
>  
> +
> +function lookupOrders(click) {
> +orderIdValue = document.lookuporder.orderId.value;
> +if (orderIdValue.length > 1) {
> +document.lookuporder.action = "<@ofbizUrl>orderview";
> +document.lookuporder.method = "get";
> +} else {
> +document.lookuporder.action = "<@ofbizUrl>searchorders";
> +}
> +
> +if (click) {
> +document.lookuporder.submit();
> +}
> +return true;
> +}
> +function toggleOrderId(master) {
> +var form = document.massOrderChangeForm;
> +var orders = form.elements.length;
> +for (var i = 0; i < orders; i++) {
> +var element = form.elements[i];
> +if ("orderIdList" == element.name) {
> +element.checked = master.checked;
> +}
> +}
> +toggleOrderIdList();
> +}
> +function setServiceName(selection) {
> +document.massOrderChangeForm.action = selection.value;
> +}
> +function runAction() {
> +var form = document.massOrderChangeForm;
> +form.submit();
> +}
> +
> +function toggleOrderIdList() {
> +var form = document.massOrderChangeForm;
> +var orders = form.elements.length;
> +var isAllSelected = true;
> +var isSingle = true;
> +for (var i = 0; i < orders; i++) {
> +var element = form.elements[i];
> +if ("orderIdList" == element.name) {
> +if (element.checked) {
> +isSingle = false;
> +} else {
> +isAllSelected = false;
> +}
> +}
> +}
> +if (isAllSelected) {
> +jQuery('#checkAllOrders').attr('checked', true);
> +} else {
> +jQuery('#checkAllOrders').attr('checked', false);
> +}
> +jQuery('#checkAllOrders').attr("checked", isAllSelected);
> +if (!isSingle && jQuery('#serviceName').val() != "") {
> +jQuery('#submitButton').removeAttr("disabled");
> +} else {
> +jQuery('#submitButton').attr('disabled', true);
> +}
> +}
> +
> +function paginateOrderList(viewSize, viewIndex, hideFields) {
> +document.paginationForm.viewSize.value = viewSize;
> +document.paginationForm.viewIndex.value = viewIndex;
> +document.paginationForm.hideFields.value = hideFields;
> +document.paginationForm.submit();
> +}
> +
> +
>  <#if security.hasEntityPermission("ORDERMGR", "_VIEW", session)>
>  <#if parameters.hideFields?has_content>
>   method="post" action="<@ofbizUrl>searchorders">
> @@ -404,9 +474,7 @@ under the License.
>  
>  <#if requestParameters.hideFields?default("N") != "Y">
>  
> -
>  
>  
>  
> diff --git a/applications/order/template/order/FindOrders.js.ftl 
> b/applications/order/template/order/FindOrders.js.ftl
> deleted file mode 100644
> index 

Re: Chapter two: Rules to dynamize screen

[Olivier Heintz]

Hi,

After gil remarks and test with the POC-Vue.js

We are now working with two new "action" usable by link - hyperlink
 * set-area
 * set-watcher
and in container, we have added attribute watcher-name, and using 
auto-update-target as target

set-area is used to update a containerId, and, most of the time, uses only for 
included containerId
set-watcher put some "parameters" in a watcher-name

when whatcher-name change, all containerId which watch it, use their 
auto-update-target as target and watcher-name content as parameters to update 
the
container content.

Hoping that this solution responds correctly to the problem raised

Le 15/05/2020 à 18:08, James Yong a écrit :
> Hi Gil,
> 
> Sorry for the late reply. 
> I agree that button actions should be decoupled from forms.
> Shall we continue with Part 3?
> 
> Regards,
> James
> 
> On 2020/01/10 17:58:59, Gil Portenseigne  wrote: 
>> Hello !
>>
>> In previous thread we focused on the process of how to define a dynamic
>> workflow that raises some questions.
>>
>> Let's go back to our principles: we have to find simple things, limit
>> the possibilities (do little but good) and remember that on the
>> backoffice it's end-users who are focused on specific tasks.
>>
>> To make it simple, implement screen dynamism that will generate
>> alterations of the dom, to limit side effects, we establish the
>> following principles:
>>   * We can only ask for an update of the area known by the calling
>> element.
>>
>> Knowing that the element of coherence in the screen engine is the
>> screen itself, we can refine this rule on the following basis
>>   * An element triggering a screen update, can only update elements
>> present within the screen where it belongs.
>>
>> Why did we made this choice? We will see it below, but the goal is
>> always to make writing easier for the developer by avoiding him to
>> wonder what is the value of the area to be refreshed.
>>
>> If for various reasons we need to update an area outside the screen
>> where the call is located, it is better to ask for a global refresh of
>> the page. (Always simpler for the developer)
>>
>> Another point to aim for simplicity, which zone to update?
>> We can identify several actions:
>>  * I'm on an item and I want to see related items data
>>  * I'm on an item and I want to refresh that item data
>>
>> The first case is a defined relation, I will refresh this area with
>> this screen, area that will be generally determined by the decorator.
>> Then, we will talk about the so-called embedded screens: "embedded
>> screen".
>>
>> The second case is about updating oneself following some sort of
>> procedure, I have to refresh myself. Nothing is best than "knowing it
>> yourself".
>>
>> It was needed to implement an optimization to facilitate the application
>> of these principles. The idea is that in most cases, the developer
>> doesn't have to think about which zone he needs to specify to display
>> his data.
>>
>> In order to apply the operation in a homogeneous way, we added new
>> structuring decorators in the common-theme with dedicated zone
>> identifiers allowing each implementation to exploit the refresh.
>>
>> For example, for a detail screen of an entity (e.g. product categories),
>> we use a "DetailScreenDecorator" decorator. The main refresh area
>> "Associated Objects Details" is the main dynamic area of the screen.
>> We are going to identify precise areas so that each theme can be used in
>> knowledge:
>> * breadcrumb: to display how we see the path to an entity
>> * summary: to display a quick information on this entity
>> * action: different actions available to this entity
>> * navigation: links or other element who help user to navigate on
>>   the entity relation
>> * detail: to display a relation
>>
>> In our searchn once the list of needs is done, we have exploited the
>> areas for our theme as follows:
>>
>>
>>+-+
>>| Catalog -> Category  (BreadCrumb)   |
>>| +-+ |
>>| |   ++| |
>>| |   | Quick Menu || |
>>| |   ++| |
>>| | | |
>>| |  Category Summary   | |
>>| | | |
>>| +-+ |
>>| |
>>| +-+ |
>>| |Tab Menu | menu1 | menu2 | menu3 | |
>>| |-| |
>>| || |
>>| | | |
>>| |  Associated Objects Details | |
>>| |  

Re: New Online Help, need some ideas

[Olivier Heintz]

Jira 11693 created with a patch proposed

if this solution is accepted, (and all asciidoc integrated) next step is to 
work component by component
For each:
1. add in the component decorator  Hi community,
> 
> First step about Docbook migration to asciidoc is done, all existing files 
> have been converted
> (waiting a review before PR merge)
> 
> Next step is to have a new help system,
> 
> I propose to do a very simple solution which would be a link to a 
> documentation site.
> This solution would use
>   1. at ofbiz level, a default proprety for documentation website uri
>   2. at the screen level
> * it would be possible to give a other uri (for user documentation)
> * if the anchor in the user documentation for this screen is put, the new 
> help is used otherwise the older link is used
> 
> If this solution is validated, next step will be to update all the screens 
> with the correct link value
> 
> I propose to create the Jira (and the implmentation) with this very simple 
> solution (using the doc generated by Buildbot as documentation site)
> when some other people with a good knowledge of gradle and/or ofbiz cms have 
> time to do a internal documentation website, it will be possible to
> change the default uri ;-)
> 
> what's your opinion about ?
> 
> 
> Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
>> inline
>>
>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>>> Hello Olivier,
>>>
>>> Without digging into much detail, I can say that it's a good idea to
>>> switch the online help system to asciidoc.
>>>
>>> The current structure of asciidoc templates is designed to be a full
>>> manual document. To link up different pages to different sections, you
>>> need to break the documentation down to smaller files and then combine
>>> them. This way you can have both the "big" manual and the "per screen"
>>> help section.
>>
>> In my experience, as I'm working with
>>   - current ofbiz online help
>>   - ofbiz webhelp
>>   - some static doc website done with Grav (build with multiple small files)
>>   - some static doc website done with asciidoc (only one large file)
>>   - ...
>>
>> With multiple small files it's needed to have a very good search engine and 
>> a global index / TOC
>>
>> With the One page doc, the TOC is very large and not always very convenient, 
>> but exist and the browser-find works
>>   and it's easy to navigate between details and generality
>>
>> So, as a user, I prefer help base on One page documentation.
>>>
>>> Also, gradle might not be enough for online help. A more robust
>>> solution could involve integrating asciidoc at the framework level to
>>> dynamically generate help. So this is another idea to consider.
>>
>> When we have tried, in the past to dynamically generate html from standard 
>> docbook process it was too slow
>>   it's why it was decide to use a freemarker template to do the generation, 
>> even if only 5% of docbook syntax
>>   was managed.
>>
>> Documentation not change very often, static page seem enough for our need.
>>
>>>
>>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Currently OFBiz Online help work with docbook files with html generation 
>>>> done by a ftl template.
>>>>  Link between screen and file to show is done with some content associated 
>>>> with key-word
>>>>
>>>> Decision has been done to no more used docbook format but now use asciidoc 
>>>> format.
>>>>
>>>> User-manual.adoc should be the new reference for user help. How to use it 
>>>> for online help ?
>>>>
>>>> I think it's important that online help is link to a internal help (which 
>>>> can be modified) not to a Apache-OFBiz-website-Help
>>>> but this point of view can be discuss.
>>>>
>>>> To be able to have OFBiz internal help, three points should be solved :
>>>> 1) with asciidoc we have multiple documentations, it seem important to 
>>>> have a "website" to be able to access easily all the doc.
>>>>how to "encapsulate" each html documentation generated in a "website"
>>>> 2) generation doc process put html and pdf files in build directory, how 
>>>> it's possible to access them from ofbiz
>>>> 3) For online help it's necessary to be able to create link between screen 
>>>> and html anchor.
>>>>In documentation generate from asciidoc, all title can be used.
>>>>How to to say this screen should go to this documentation at this title.
>>>>
>>>> I suppose content application, can help to solve this points.
>>>> I need some help from OFBiz-Content experts.
>>>>
>>>> For point (1) I'm using jBake but maybe it's possible to do something 
>>>> similar with templating in Content
>>>> Who has some idea ?
>>>>
>>>> For point (2) I suppose it's a "gradle configuration" and "content 
>>>> configuration"
>>>> Who has some idea ?
>>>>
>>>> For point (3) the more simple solution is to add 1 (or 2) field in context 
>>>> which contain help_title,(help_documentation) and
>>>> so it will be simple to build the correct help link
>>>>

Re: New Online Help, need some ideas

[Olivier Heintz]

Hi community,

First step about Docbook migration to asciidoc is done, all existing files have 
been converted
(waiting a review before PR merge)

Next step is to have a new help system,

I propose to do a very simple solution which would be a link to a documentation 
site.
This solution would use
  1. at ofbiz level, a default proprety for documentation website uri
  2. at the screen level
* it would be possible to give a other uri (for user documentation)
* if the anchor in the user documentation for this screen is put, the new 
help is used otherwise the older link is used

If this solution is validated, next step will be to update all the screens with 
the correct link value

I propose to create the Jira (and the implmentation) with this very simple 
solution (using the doc generated by Buildbot as documentation site)
when some other people with a good knowledge of gradle and/or ofbiz cms have 
time to do a internal documentation website, it will be possible to
change the default uri ;-)

what's your opinion about ?


Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
> inline
> 
> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>> Hello Olivier,
>>
>> Without digging into much detail, I can say that it's a good idea to
>> switch the online help system to asciidoc.
>>
>> The current structure of asciidoc templates is designed to be a full
>> manual document. To link up different pages to different sections, you
>> need to break the documentation down to smaller files and then combine
>> them. This way you can have both the "big" manual and the "per screen"
>> help section.
> 
> In my experience, as I'm working with
>   - current ofbiz online help
>   - ofbiz webhelp
>   - some static doc website done with Grav (build with multiple small files)
>   - some static doc website done with asciidoc (only one large file)
>   - ...
> 
> With multiple small files it's needed to have a very good search engine and a 
> global index / TOC
> 
> With the One page doc, the TOC is very large and not always very convenient, 
> but exist and the browser-find works
>   and it's easy to navigate between details and generality
> 
> So, as a user, I prefer help base on One page documentation.
>>
>> Also, gradle might not be enough for online help. A more robust
>> solution could involve integrating asciidoc at the framework level to
>> dynamically generate help. So this is another idea to consider.
> 
> When we have tried, in the past to dynamically generate html from standard 
> docbook process it was too slow
>   it's why it was decide to use a freemarker template to do the generation, 
> even if only 5% of docbook syntax
>   was managed.
> 
> Documentation not change very often, static page seem enough for our need.
> 
>>
>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>>>
>>> Hi all,
>>>
>>> Currently OFBiz Online help work with docbook files with html generation 
>>> done by a ftl template.
>>>  Link between screen and file to show is done with some content associated 
>>> with key-word
>>>
>>> Decision has been done to no more used docbook format but now use asciidoc 
>>> format.
>>>
>>> User-manual.adoc should be the new reference for user help. How to use it 
>>> for online help ?
>>>
>>> I think it's important that online help is link to a internal help (which 
>>> can be modified) not to a Apache-OFBiz-website-Help
>>> but this point of view can be discuss.
>>>
>>> To be able to have OFBiz internal help, three points should be solved :
>>> 1) with asciidoc we have multiple documentations, it seem important to have 
>>> a "website" to be able to access easily all the doc.
>>>how to "encapsulate" each html documentation generated in a "website"
>>> 2) generation doc process put html and pdf files in build directory, how 
>>> it's possible to access them from ofbiz
>>> 3) For online help it's necessary to be able to create link between screen 
>>> and html anchor.
>>>In documentation generate from asciidoc, all title can be used.
>>>How to to say this screen should go to this documentation at this title.
>>>
>>> I suppose content application, can help to solve this points.
>>> I need some help from OFBiz-Content experts.
>>>
>>> For point (1) I'm using jBake but maybe it's possible to do something 
>>> similar with templating in Content
>>> Who has some idea ?
>>>
>>> For point (2) I suppose it's a "gradle configuration" and "content 
>>> configuration"
>>> Who has some idea ?
>>>
>>> For point (3) the more simple solution is to add 1 (or 2) field in context 
>>> which contain help_title,(help_documentation) and
>>> so it will be simple to build the correct help link
>>>

Re: [POC Vue.js] Cleaning - Screen - rest - compound

[Olivier Heintz]

Hi,

main repo is on https://gitlab.ofbizextra.org/ofbizextra
* plugin
  ** vuejs: https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/vuejsPortal
  ** flatgreyfjs: 
https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/flatgreyfjs
  ** examplefjs: 
https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/examplefjs
  ** partyfjs: https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins/partymgrfjs

for vuejs, there is a clone on github: https://github.com/ofbizextra/vuejsPortal

For documentation: 
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_poc_vuejsportal_installation


Le 04/05/2020 à 20:35, Taher Alkhateeb a écrit :
> 
> Hi Olivier,
> 
> I think to engage the community you need to expose the code more than just 
> sharing a hosted server. Perhaps posting a repo on github might do the trick. 
> Either way, good luck with the initiative.
> 
> 
> On Monday, May 04, 2020 18:02 +03, Olivier Heintz  wrote:
>  Hi Community,
> 
> Some news about the POC Vue.js,
> since last mails (4 month ago), some works have been done, and compared to 
> what was planned as the next step, we have taken a step backwards, in order to
> 1. take into account the remarks of the community
> 2. make better progress after :-)
> 
> * First of all, the cleaning of the POCs (not yet finished), after the first 
> few months where we tried a few solutions, we worked to eliminate all the
> non-validated tests or workaround solutions used.
> At the JsonRenderer level we try to clearly show what is used and functional, 
> and which attributes / tags not yet implemented, The idea is to have
> less but correctly tested.
> 
> * Some simplifications in screen "json representation", ex: field title 
> attributes are now in the field attribute, to be able to have a better
> presentation (title integrated in field)
> ** all generic template use vuetify
> ** a more beautiful contactMech screenlet
> 
> * All can be done with "standard" screens, (without portal - portlet), 
>  other widget or itself if a specific "watcher - content" change): a more 
> clear and logical screen update process
> ** we use grid style for  
> * for Example and ExampleItem, all uri used are at the REST format and http 
> method is define.
> The template use for uri is the same define for webtools
> {ResourceName}/{cover}/{Pkvalue: .*}
> For Example we have
> | URI | method | Goal
> | Example/find | get | find form to select options for list
> | Example/list | get (via post)| Example list, +
> => with a get (so without parameters) all the examples +
> => with a post (parameters and _method="GET") examples selected by options
> | Example/create | get | create form
> | Example/edit/{exampleId} | get | edit form and data for the id sent
> | Example/show/{exampleId} | get | show form and data for the id sent
> | Example/summary/{exampleId} | get | summary form and data for the id sent
> | Example/data/{exampleId} | get | just data for the id sent
> | Example/change | post | create a example
> | Example/change/{exampleId} | put (via post)| update example with exampleId
> | Example/change/{exampleId} | delete | delete example with exampleId
> 
> each time a request need multiple parameters, a POST is used with the _method 
> param to which http method should used
> 
> * Compound file by Resource name, to have more modularity and reusability 
> (organize by functional Resource), all widget data are in the same file
> controller / menu / form / widget
> 
> It's still a POC, so it's still a support to discuss about technical or GUI 
> point.
> All current choices can be challenged to find the correct or strong solution 
> and quickly see the result on a user point of view.
> 
> To view/test, there are two testing environments :
> * ofbiz-selenium[1] used by the continuous integration process and some debug 
> process, so vue.js application is build with dev option
> With this env. it's possible to see a lot of information about data store and 
> component with browser vuejs tools, but application is more slow
> * demo-vuejs[2], the standard POC demo build, more stable and build with prod 
> option.
> 
> on menu, "Examples management" is done with Screen et Rest-uri
> and "Examples management (MgmtPageFrontJs)" is done with portal-portlet
> 
> [1] 
> https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
> [2] 
> https://demo-vuejs.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
> 
> We work on a agile mode, so most of the parts are prototype which should be 
> reviewed and/or optimize before finalized
> 
> For the next step: we're back on schedule (the POC-UI)
> https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui
>  
> 

[POC Vue.js] Cleaning - Screen - rest - compound

[Olivier Heintz]

Hi Community,

Some news about the POC Vue.js,
since last mails (4 month ago), some works have been done, and compared to what 
was planned as the next step, we have taken a step backwards, in order to
1. take into account the remarks of the community
2. make better progress after :-)

* First of all, the cleaning of the POCs (not yet finished), after the first 
few months where we tried a few solutions, we worked to eliminate all the
non-validated tests or workaround solutions used.
At the JsonRenderer level we try to clearly show what is used and functional, 
and which attributes / tags not yet implemented, The idea is to have
less but correctly tested.

* Some simplifications in screen  "json representation", ex: field title 
attributes are now in the field attribute, to be able to have a better
presentation (title integrated in field)
** all generic template use vuetify
** a more beautiful contactMech screenlet

* All can be done with "standard" screens, (without portal - portlet), 
 with a get (so without 
parameters) all the examples +
=> with a post (parameters and 
_method="GET") examples selected by options
| Example/create  | get   | create form
| Example/edit/{exampleId}| get   | edit form and data for the id 
sent
| Example/show/{exampleId}| get   | show form and data for the id 
sent
| Example/summary/{exampleId} | get   | summary form and data for the 
id sent
| Example/data/{exampleId}| get   | just data for the id sent
| Example/change  | post  | create a example
| Example/change/{exampleId}  | put (via post)| update example with exampleId
| Example/change/{exampleId}  | delete| delete example with exampleId

each time a request need multiple parameters, a POST is used with the _method 
param to which http method should used

* Compound file by Resource name, to have more modularity and reusability 
(organize by functional Resource), all widget data are in the same file
  controller / menu / form / widget

It's still a POC, so it's still a support to discuss about technical or GUI 
point.
All current choices can be challenged to find the correct or strong solution 
and quickly see the result on a user point of view.

To view/test, there are two testing environments :
* ofbiz-selenium[1] used by the continuous integration process and some debug 
process, so vue.js application is build with dev option
  With this env. it's possible to see a lot of information about data store and 
component with browser vuejs tools, but application is more slow
* demo-vuejs[2], the standard POC demo build, more stable and build with prod 
option.

on menu, "Examples management" is done with Screen et Rest-uri
and "Examples management (MgmtPageFrontJs)"  is done with portal-portlet

[1] 
https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
[2] 
https://demo-vuejs.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg

We work on a agile mode, so most of the parts are prototype which should be 
reviewed and/or optimize before finalized

For the next step: we're back on schedule (the POC-UI)
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui

Re: Welcome new commiter and PMC member

[Olivier Heintz]

Congratulations to Girish Vasmatkar and James Young

Best regards to all

Le 22/04/2020 à 12:28, James Yong a écrit :
> Hi all, 
> 
> Thank you for your words of congratulations.
> Hope everyone is well and safe.
> Also thanks PMC for the kind invitation.
> Looking forward to deeper collaboration.
> 
> Regards,
> James
> 
> On 2020/04/22 10:16:36, Deepak Nigam  wrote: 
>> Congratulations James!!!
>>
>> Regards
>> --
>> Deepak Nigam
>>
>>
>>
>> On Wed, Apr 22, 2020, 3:25 PM Pawan Verma  wrote:
>>
>>> Congratulations James!
>>> --
>>> Thanks & Regards
>>> Pawan Verma
>>> ofbiz.apache.org
>>>
>>>
>>> On Wed, Apr 22, 2020 at 3:16 PM Suraj Khurana 
>>> wrote:
>>>
 Congratulations James !!

 --
 Best Regards,
 Suraj Khurana
 Senior Technical Consultant


 On Wed, Apr 22, 2020 at 3:15 PM Ashish Vijaywargiya <
 ashish.vijaywarg...@hotwaxsystems.com> wrote:

> Congrats James!
>
> --
> Kind Regards,
> Ashish Vijaywargiya
> Vice President of Operations
> *HotWax Systems*
> *Enterprise open source experts*
> cell: +91-9893479711
> http://www.hotwaxsystems.com
>
>
>
> On Wed, Apr 22, 2020 at 2:08 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> The OFBiz PMC has invited James Young to become member of the
>>> committee
>> and we are glad to announce that he has accepted the nomination.
>>
>> On behalf of the OFBiz PMC, welcome on board!
>>
>>
>

>>>
>>

Re: GraphQL API for OFBiz

[Olivier Heintz]

+1

Le 26/03/2020 à 18:17, Pierre Smits a écrit :
> Great initiative, Girish.
> 
> Op do 26 mrt. 2020 16:48 schreef Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com>:
> 
>> Hi All
>>
>> I'm planning an introduction of the OFBiz-GraphQL component that we have
>> developed so far. Please find below the hangout meet details -
>>
>> Date : 03/27/2020 9:00 PM IST, 11:30 AM EST, 3:30 PM GMT.
>> Join Hangout Meet : https://meet.google.com/gja-jdwt-wpi
>> Join By Phone : +1 661-237-5173‬ PIN: ‪585 477 050‬#
>>
>> Meeting agenda -
>>
>>- GraphQL briefing
>>   - Queries
>>   - Mutations
>>- OFBiz-GraphQL component
>>   - Architecture
>>   - Entity Fetchers
>>   - Service Fetchers
>>- What Next
>>   - Pagination
>>   - Interface
>>   - Batching
>>   - Subscriptions
>>
>>
>> Best Regards
>> Girish Vasmatkar
>>
>>
>>
>> On Wed, Feb 12, 2020 at 7:04 PM Girish Vasmatkar <
>> girish.vasmat...@hotwaxsystems.com> wrote:
>>
>>> Thanks Pierre.
>>>
>>> Here's the ticket for the same. I'll keep posting updates to it.
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ-11347
>>>
>>> Best,
>>> Girish
>>>
>>> On Mon, Feb 10, 2020 at 4:48 PM Pierre Smits 
>>> wrote:
>>>
 Hi Girish,

 Thank you for making the greater OFBiz community aware of this
>> endeavour.
 I
 welcome such initiatives as it increases the appeal of our main product.
 Not only does it increase the appeal of OFBiz for (potential) adopters,
 but
 it may also lead to more parties willing to contribute.

 Best regards,

 Pierre Smits
 *Proud* *contributor* (but without privileges)* of* Apache OFBiz
 , since 2008

 *Apache Trafodion , Vice President*
 *Apache Directory , PMC Member*
 Apache Incubator , committer
 Apache Steve , committer


 On Mon, Feb 10, 2020 at 11:40 AM Girish Vasmatkar <
 girish.vasmat...@hotwaxsystems.com> wrote:

> Hello
>
> I had been working on adding GraphQL support to OFBiz and could come
>> up
> with something that might be of interest to the community. Wanted to
 gauge
> community's interest on the same.
>
> Essentially, I have first tried to enable GraphQL support such that
 OFBiz
> is able to server GraphQL queries, mutations and subscriptions as per
 the
> GraphQL specification (http://spec.graphql.org/). The Java GraphQL
 library
> mostly takes care of it.
>
> The other major part is writing GraphQL schema and I have tried to
 include
> both SDL and programmatic approach to generate the schema. Included a
 demo
> query in the SDL approach to showcase hw OFBiz can server GraphQL
 requests.
>
> This is the part that I feel needs more work in order to make it more
> generalised and I am still working on this.
>
> I have included GraphiQL(https://github.com/graphql/graphiql) and
> Playground (https://github.com/prisma-labs/graphql-playground) as two
> visual editor tools as well.
>
> Here's the github link for the plug in.
> https://github.com/hotwax/ofbiz-graphql
>
> Any feedback, questions, concerns or suggestions are welcome.
>
> Best,
> Girish
>

>>>
>>
> 

Re: New Online Help, need some ideas

[Olivier Heintz]

TOC in left is not the main point ;-)
the most important is the "Documentation" and "Doc(pdf)" menu where it's 
possible to choose which doc to go

Le 26/02/2020 à 17:28, Jacques Le Roux a écrit :
> I guess, if it's only that this would work: 
> https://github.com/asciidoctor/asciidoctor/issues/2545
> 
> Le 26/02/2020 à 16:54, Olivier Heintz a écrit :
>> Thank you Jacques,
>>
>> Yes I know this "site"
>> and it's why I say, we should find something to be able to navigate from  
>> one document to an other.
>>
>> I prefer the website generate by Jbake (1) in ofbizextra
>> https://ofbizextra.org/ofbiz_adocs/docs/asciidoc/user-manual.html
>> there is alway the menu to easly change to an other document ;-)
>>
>> (1) https://jbake.org/: use to include some asciidoc files in template 
>> writing with freemarker
>>
>> Le 26/02/2020 à 15:19, Jacques Le Roux a écrit :
>>> Hi Olivier,
>>>
>>> You might be interested by
>>>
>>> https://ci.apache.org/projects/ofbiz/site/ofbizdoc/
>>> and
>>> https://ci.apache.org/projects/ofbiz/site/pluginsdoc/
>>>
>>> Where the doc is currently generated from *.adoc files by Buildbot
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>>>> Hello Olivier,
>>>>
>>>> Without digging into much detail, I can say that it's a good idea to
>>>> switch the online help system to asciidoc.
>>>>
>>>> The current structure of asciidoc templates is designed to be a full
>>>> manual document. To link up different pages to different sections, you
>>>> need to break the documentation down to smaller files and then combine
>>>> them. This way you can have both the "big" manual and the "per screen"
>>>> help section.
>>>>
>>>> Also, gradle might not be enough for online help. A more robust
>>>> solution could involve integrating asciidoc at the framework level to
>>>> dynamically generate help. So this is another idea to consider.
>>>>
>>>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>>>>> Hi all,
>>>>>
>>>>> Currently OFBiz Online help work with docbook files with html generation 
>>>>> done by a ftl template.
>>>>>Link between screen and file to show is done with some content 
>>>>> associated with key-word
>>>>>
>>>>> Decision has been done to no more used docbook format but now use 
>>>>> asciidoc format.
>>>>>
>>>>> User-manual.adoc should be the new reference for user help. How to use it 
>>>>> for online help ?
>>>>>
>>>>> I think it's important that online help is link to a internal help (which 
>>>>> can be modified) not to a Apache-OFBiz-website-Help
>>>>> but this point of view can be discuss.
>>>>>
>>>>> To be able to have OFBiz internal help, three points should be solved :
>>>>> 1) with asciidoc we have multiple documentations, it seem important to 
>>>>> have a "website" to be able to access easily all the doc.
>>>>>  how to "encapsulate" each html documentation generated in a "website"
>>>>> 2) generation doc process put html and pdf files in build directory, how 
>>>>> it's possible to access them from ofbiz
>>>>> 3) For online help it's necessary to be able to create link between 
>>>>> screen and html anchor.
>>>>>  In documentation generate from asciidoc, all title can be used.
>>>>>  How to to say this screen should go to this documentation at this 
>>>>> title.
>>>>>
>>>>> I suppose content application, can help to solve this points.
>>>>> I need some help from OFBiz-Content experts.
>>>>>
>>>>> For point (1) I'm using jBake but maybe it's possible to do something 
>>>>> similar with templating in Content
>>>>> Who has some idea ?
>>>>>
>>>>> For point (2) I suppose it's a "gradle configuration" and "content 
>>>>> configuration"
>>>>> Who has some idea ?
>>>>>
>>>>> For point (3) the more simple solution is to add 1 (or 2) field in 
>>>>> context which contain help_title,(help_documentation) and
>>>>> so it will be simple to build the correct help link
>>>>>

Re: New Online Help, need some ideas

[Olivier Heintz]

inline

Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
> Hello Olivier,
> 
> Without digging into much detail, I can say that it's a good idea to
> switch the online help system to asciidoc.
> 
> The current structure of asciidoc templates is designed to be a full
> manual document. To link up different pages to different sections, you
> need to break the documentation down to smaller files and then combine
> them. This way you can have both the "big" manual and the "per screen"
> help section.

In my experience, as I'm working with
  - current ofbiz online help
  - ofbiz webhelp
  - some static doc website done with Grav (build with multiple small files)
  - some static doc website done with asciidoc (only one large file)
  - ...

With multiple small files it's needed to have a very good search engine and a 
global index / TOC

With the One page doc, the TOC is very large and not always very convenient, 
but exist and the browser-find works
  and it's easy to navigate between details and generality

So, as a user, I prefer help base on One page documentation.
> 
> Also, gradle might not be enough for online help. A more robust
> solution could involve integrating asciidoc at the framework level to
> dynamically generate help. So this is another idea to consider.

When we have tried, in the past to dynamically generate html from standard 
docbook process it was too slow
  it's why it was decide to use a freemarker template to do the generation, 
even if only 5% of docbook syntax
  was managed.

Documentation not change very often, static page seem enough for our need.

> 
> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>>
>> Hi all,
>>
>> Currently OFBiz Online help work with docbook files with html generation 
>> done by a ftl template.
>>  Link between screen and file to show is done with some content associated 
>> with key-word
>>
>> Decision has been done to no more used docbook format but now use asciidoc 
>> format.
>>
>> User-manual.adoc should be the new reference for user help. How to use it 
>> for online help ?
>>
>> I think it's important that online help is link to a internal help (which 
>> can be modified) not to a Apache-OFBiz-website-Help
>> but this point of view can be discuss.
>>
>> To be able to have OFBiz internal help, three points should be solved :
>> 1) with asciidoc we have multiple documentations, it seem important to have 
>> a "website" to be able to access easily all the doc.
>>how to "encapsulate" each html documentation generated in a "website"
>> 2) generation doc process put html and pdf files in build directory, how 
>> it's possible to access them from ofbiz
>> 3) For online help it's necessary to be able to create link between screen 
>> and html anchor.
>>In documentation generate from asciidoc, all title can be used.
>>How to to say this screen should go to this documentation at this title.
>>
>> I suppose content application, can help to solve this points.
>> I need some help from OFBiz-Content experts.
>>
>> For point (1) I'm using jBake but maybe it's possible to do something 
>> similar with templating in Content
>> Who has some idea ?
>>
>> For point (2) I suppose it's a "gradle configuration" and "content 
>> configuration"
>> Who has some idea ?
>>
>> For point (3) the more simple solution is to add 1 (or 2) field in context 
>> which contain help_title,(help_documentation) and
>> so it will be simple to build the correct help link
>>

Re: New Online Help, need some ideas

[Olivier Heintz]

Thank you Jacques,

Yes I know this "site"
and it's why I say, we should find something to be able to navigate from  one 
document to an other.

I prefer the website generate by Jbake (1) in ofbizextra
https://ofbizextra.org/ofbiz_adocs/docs/asciidoc/user-manual.html
there is alway the menu to easly change to an other document ;-)

(1) https://jbake.org/: use to include some asciidoc files in template 
writing with freemarker

Le 26/02/2020 à 15:19, Jacques Le Roux a écrit :
> Hi Olivier,
> 
> You might be interested by
> 
> https://ci.apache.org/projects/ofbiz/site/ofbizdoc/
> and
> https://ci.apache.org/projects/ofbiz/site/pluginsdoc/
> 
> Where the doc is currently generated from *.adoc files by Buildbot
> 
> HTH
> 
> Jacques
> 
> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>> Hello Olivier,
>>
>> Without digging into much detail, I can say that it's a good idea to
>> switch the online help system to asciidoc.
>>
>> The current structure of asciidoc templates is designed to be a full
>> manual document. To link up different pages to different sections, you
>> need to break the documentation down to smaller files and then combine
>> them. This way you can have both the "big" manual and the "per screen"
>> help section.
>>
>> Also, gradle might not be enough for online help. A more robust
>> solution could involve integrating asciidoc at the framework level to
>> dynamically generate help. So this is another idea to consider.
>>
>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>>> Hi all,
>>>
>>> Currently OFBiz Online help work with docbook files with html generation 
>>> done by a ftl template.
>>>   Link between screen and file to show is done with some content associated 
>>> with key-word
>>>
>>> Decision has been done to no more used docbook format but now use asciidoc 
>>> format.
>>>
>>> User-manual.adoc should be the new reference for user help. How to use it 
>>> for online help ?
>>>
>>> I think it's important that online help is link to a internal help (which 
>>> can be modified) not to a Apache-OFBiz-website-Help
>>> but this point of view can be discuss.
>>>
>>> To be able to have OFBiz internal help, three points should be solved :
>>> 1) with asciidoc we have multiple documentations, it seem important to have 
>>> a "website" to be able to access easily all the doc.
>>> how to "encapsulate" each html documentation generated in a "website"
>>> 2) generation doc process put html and pdf files in build directory, how 
>>> it's possible to access them from ofbiz
>>> 3) For online help it's necessary to be able to create link between screen 
>>> and html anchor.
>>> In documentation generate from asciidoc, all title can be used.
>>> How to to say this screen should go to this documentation at this title.
>>>
>>> I suppose content application, can help to solve this points.
>>> I need some help from OFBiz-Content experts.
>>>
>>> For point (1) I'm using jBake but maybe it's possible to do something 
>>> similar with templating in Content
>>> Who has some idea ?
>>>
>>> For point (2) I suppose it's a "gradle configuration" and "content 
>>> configuration"
>>> Who has some idea ?
>>>
>>> For point (3) the more simple solution is to add 1 (or 2) field in context 
>>> which contain help_title,(help_documentation) and
>>> so it will be simple to build the correct help link
>>>

New Online Help, need some ideas

[Olivier Heintz]

Hi all,

Currently OFBiz Online help work with docbook files with html generation done 
by a ftl template.
 Link between screen and file to show is done with some content associated with 
key-word

Decision has been done to no more used docbook format but now use asciidoc 
format.

User-manual.adoc should be the new reference for user help. How to use it for 
online help ?

I think it's important that online help is link to a internal help (which can 
be modified) not to a Apache-OFBiz-website-Help
but this point of view can be discuss.

To be able to have OFBiz internal help, three points should be solved :
1) with asciidoc we have multiple documentations, it seem important to have a 
"website" to be able to access easily all the doc.
   how to "encapsulate" each html documentation generated in a "website"
2) generation doc process put html and pdf files in build directory, how it's 
possible to access them from ofbiz
3) For online help it's necessary to be able to create link between screen and 
html anchor.
   In documentation generate from asciidoc, all title can be used.
   How to to say this screen should go to this documentation at this title.

I suppose content application, can help to solve this points.
I need some help from OFBiz-Content experts.

For point (1) I'm using jBake but maybe it's possible to do something similar 
with templating in Content
Who has some idea ?

For point (2) I suppose it's a "gradle configuration" and "content 
configuration"
Who has some idea ?

For point (3) the more simple solution is to add 1 (or 2) field in context 
which contain help_title,(help_documentation) and
so it will be simple to build the correct help link

Migrate all docbook files to asciidoc ?

[Olivier Heintz]

Hi everyone,

I wanted to make progress on the OFBiz documentation, and thus continue the 
existing tasks, at first the one on the accounting component.

It's a bit painful to have to work between the old files in docbook and the new 
ones in asciidoc.
For me it would be simpler to migrate all the docbooks first, and then rework 
the result.

Does this process bother anyone ?

Olivier

Re: What is OFBiz public API?

[Olivier Heintz]

Hi, everybody,

It is not easy to add something in the discussion among the different 
arguments! (and on the different topics)

I will, however, try to give some summary of my position on the various 
subjects discussed.

1) As Jacques recall "Community over code" so :
  1.1 : It is important to trust all the members of the community in their will 
to improve OFBiz
  1.2 : the discussion cannot take place in 2 or 3 days, it is rather in a week 
or a month that it will take place.
(I don't have 2 or 3 hours to read (and answer) the mail every day, but I can 
find them during a week..
This is an advantage of mailing list discussions over chat discussions.

2) Deprecated (with documentation) before removing is a very good solution,
in a release migration process, when something has disappears (not yet move to 
the new solution), it's more easy to retrieve file when it was
deprecated to read associated documentation and know how to migrate.
  the rule is the same even it's simple util java method ;-)

3) I clearly not understand all implications/advantages/constrains ... or 
whatever about depend-on or component-load
what I only can be say is :
In a functional consultant point of view which want to configure an ofbiz with 
a lot of plugins (between 20 and 40) it's more easy to have a depend-on
on each plugin to be sure the loading order will be correct.

4) implementation detail or core choice, often, it's depend of point of view 
you use
On ERP development / implementation there are multiple type of people working 
on it with each one, specifics knowledge, usage, practice and point of view.
When someone says, it's a big change,
   start by trusting him and find out which process is affected to propose a 
solution;
   he doesn't want to block something, he wants to help you come up with a 
better solution that solves more cases.

5) patching is wrong : very often there are patch because hook or extend 
mechanism not exist so
When a plugin contains a patch, framework expert should explain
  or how to use existing extensibility mechanism to avoid the patch
  or how to improve the framework to provide a extensibility mechanism for this 
case
this point is also an example about previous point ;-)

6) what is OFBiz,
  - not only a public API ;-)
  - not only a framework
  - currently not a OOTB ERP  but I hope what, in future, there will contain 
some OOTB applications
In my long term view Apache OFBiz could be like linux, a core/kernel as small 
as possible with multiple components (the plugins) and so with some
distributions.
So, clearly, for me it is not possible to define the boundary between what is 
public (with backward compatibility) and what is only implementation.
Even on data model I can give some examples where not everyone will agree on 
what is in kernel and what is in components

just my 6 cents


Olivier

Le 06/01/2020 à 10:29, Samuel Trégouët a écrit :

> 
> I also hope others contributors will eventually join (many thanks to
> Jacques for joining!) since this discussion  seems to me to be larger
> than a particular feature (component-load.xml): it is about the process
> of contributing to OFBiz.
> 
>

Re: PortalPage / Portlet / parameters : SGBD versus XML file

[Olivier Heintz]

Thank you Mathieu and Nicolas for your remarks
They help me identify the highest priority tasks...


some comments in line

Le 30/12/2019 à 17:43, Nicolas Malin a écrit :
> Hello,
> 
> Ten yearsagoI would've leaned over on a solution to improve on this way, but 
> now with practical field experience I understood that it was a chimera on
> business production site.
> 
> All is currently present on screen-widget.xsd to define easily a screen 
> structure.
> 
> The scenario “ProductOwner/keyUser/endUser” is already supported, I didn't 
> hear at Néréide for functional developer that they are some difficulties to
> translate businessspecificationsfromany of theserolesthrough screen 
> definition.

Currently, without portal-portlet, it's necessary to have a functional 
developer with its development environment to change some screen parameters, or
page organization. Parameters available are not easily readable.

With current PortalPage tools, I have already seen some ProductOwner/keyUsers 
test some solutions alone before choosing the right one (for them), it's
very efficient for functional consultant.

> 
> Rather than concentrating on adding model layers, we willwin not to let the 
> code grow too much and identify what is really missing on screensand rely
> on portal page only for caseswhere the end user can edit his own 
> configuration page.

You are totally right, and clearly my next priority will be to check if I find 
a Portal-Portlet configuration feature that I can't easily achieve with
"classical" screen / decorator.

If I find one, I will ask you how to solve the issue, because I already assume 
it will be possible. ;-)

> 
> I'm more in favor to put away all current portal page out of the framework, 
> keep only one plugin as example and convert them with good practice to
> help other developersand functional developersto extend the framework.
> 
> In this way I found the Mathieu'sbelowidea: fun :)
> 
> Nicolas
> 
> On 29/12/2019 11:36, Mathieu Lirzin wrote:
>> Hello Olivier,[...]
>>
>> One idea would be to have a specific webtools screen taking the form of
>> a client-side Javascript program allowing users to compose a screen
>> graphically and to export it as XML. This would fit the scenario you
>> describe without the need of adding a general screen configuration
>> mechanism inside the database.
>>
>> What do you think?

That's a part of my proposal, and your implementation proposition give me a 
better idea of how to present it..
Well, first of all.
   I will re-uses portalPage, column, portlet, attribute entities to be able to 
design a short POC.
   I'm not sure to generate the xml directly, but something similar; the goal 
being a ready-to-use XML
In the second stage
   This will involve identifying the screens that can be used as a "component" 
(in a GUI point of view)



>>

Re: [DISCUSSION] Make Back-Office screens dynamic

[Olivier Heintz]

very quick answer (inline)

Best Regards

Le 08/01/2020 à 17:39, Gavin Mabie a écrit :
> Hi Olivier
> 
> Quick question: Are you using NodeJs & NPM in your POC? 
yes
And if so are you
> integrating with Gradle?
Not yet

> 
> Cheers
> 
> Gavin
> 

Re: [DISCUSSION] separating GUI from the application

[Olivier Heintz]

ot;,
>   "value": "HOMEINIT_CLIENT",
>   "required": false,
>   "type": "hidden"
> },
> {
>   "title": "First Name",
>   "name": "firstName",
>   "value": "",
>   "id": "EditPerson_firstName",
>   "required": true,
>   "type": "text"
> },
> {
>   "title": "Last Name",
>   "name": "lastName",
>   "value": "",
>   "id": "EditPerson_lastName",
>   "required": true,
>   "type": "text"
> },
> {
>   "title": "Gender",
>   "name": "gender",
>   "value": "",
>   "id": "EditPerson_gender",
>   "required": false,
>   "type": "dropdown",
>   "allOptionValues": [
> {
>   "key": "M",
>   "description": "Male"
> },
> {
>   "key": "F",
>   "description": "Female"
> }
>   ],
>   "textSize": 0
> },
> {
>   "title": "Birth Date",
>   "name": "birthDate",
>   "value": "",
>   "id": "EditPerson_birthDate",
>   "required": false,
>   "type": "datetime"
> },
> {
>   "title": "Height",
>   "name": "height",
>   "value": "",
>   "id": "EditPerson_height",
>   "event": "",
>   "required": false,
>   "type": "text"
> },
> {
>   "title": "Weight",
>   "name": "weight",
>   "value": "",
>   "id": "EditPerson_weight",
>   "event": "",
>   "required": false,
>   "type": "text"
> },
> {
>   "title": "Marital Status",
>   "name": "maritalStatus",
>   "value": "",
>   "id": "EditPerson_maritalStatus",
>   "event": "",
>   "required": false,
>   "type": "dropdown",
>   "allOptionValues": [
> {
>   "key": "S",
>   "description": "Single"
> },
> {
>   "key": "M",
>   "description": "Married"
> },
> {
>   "key": "P",
>   "description": "Separated"
> },
> {
>   "key": "D",
>   "description": "Divorced"
> },
> {
>   "key": "W",
>   "description": "Widowed"
> }
>   ],
>   "textSize": 0
> },
> {
>   "title": "RSA ID",
>   "name": "socialSecurityNumber",
>   "value": "",
>   "id": "EditPerson_socialSecurityNumber",
>   "required": false,
>   "type": "text"
> },
> {
>   "title": "Passport Number",
>   "name": "passportNumber",
>   "value": "",
>   "id": "EditPerson_passportNumber",
>   "required": false,
>   "type": "text"
> },
> {
>   "title": "Employment Status Enum Id",
>   "name": "employmentStatusEnumId",
>   "value": "",
>   "id": "EditPerson_employmentStatusEnumId",
>   "event": "",
>   "required": false,
>   "type": "dropdown",
>   "allOptionValues": [
> {
>   "key": "EMPS_FULLTIME",
>   "description": "Full-time Employed [FULLTIME]"
> },
> {
>   "key": "EMPS_PARTTI

Re: [DISCUSSION] Make Back-Office screens dynamic

[Olivier Heintz]

Le 17/12/2019 à 15:12, Gil Portenseigne a écrit :
> Hello Taher,
> 
> The proposition you saw with your first glance is 
.

> 
> In that vision implementing a theme for SPA application should be
> possible, but in our opinion a gigantic task to support the screen
> engine. We think that for back office application, we should stay with
> the classic way to implement screens, and improve it to get more
> efficient.
> 

The implementation of a theme for a SPA application is a big task and should be 
studied from an agile perspective.
POC-VueJs was initiated and realized in this perspective.
The POC should allow to :
 * to be able to test a simple conversion from macro.ftl to the vuejs component 
(or other SPA framework)
 * be able to test the advanced functionalities of the SPA framework from the 
point of view of an ERP back office application
 * to be able to test new uses of the graphical interface linked to the SPA 
concept

I think this is only possible if there are enough screens / components 
available in the POC.
We chose Party because it will be possible to derive it to HR / CRM B2C / 
eCommerce Profile pages / CRM B2B / facilities workers.
Currently, only the main screens of Party are working, it is possible to play 
with them at
https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/main (vuejs is in dev 
mode so it is possible to view components and store areas)
https://demo-vuejs.ofbizextra.org/partymgrfjs/control/main (vuejs is in prod 
mode)

POC-VueJs is not a theme but there are already very similar points and we 
should work in this direction too.
Even if some modifications should be made on a component before using this 
"kind of theme", we should consider rendering it - component VueJs as a theme.

POC will have several steps before it is possible to choose and validate the 
right solutions.
During POC we store the "migration time" per component / screens to be able to 
have an evaluation of the migration ofbiz applications in the future.

PortalPage / Portlet / parameters : SGBD versus XML file

[Olivier Heintz]

Hello, community,

In OFBiz,
  * definition of portalPortlets,
  * definition and content of the portalPages (column and which portlet in each 
one)
  * portalPortlet attributes for a portalPage
  * and some other details about the organization of the portal
are stored in the ofbiz database.

As Nicolas says, it is not practical/advisable to manage/sharing GUI changes in 
a development process (and continuous integration) because they are
not managed by a VCS (svn or git).

So I propose to
  * create a widget-portal.xsd
  * a new general property to read (or not) the database for the organization 
of the portal
  * some modifications on include-portal to read the portal information on the 
xml file and if the property is Yes the complementary elements in the
database.

With these modifications it will be possible to dynamically add portalPage or 
Portlet and use editParam features when working with
ProductOwner/keyUser/endUser but not in a production environment.
After the workshop, the consultant will have to formalize what has been 
validated in the appropriate xml file and commit it in order to have it in
production environment if the GUI test are ok (the modifications don't break 
anything ;-)

What do you think about this ?

Olivier

Re: [DISCUSSION] separating GUI from the application

[Olivier Heintz]

Hi Gavin,

Separation completely GUI and application could be exploring, but I think it 
will be in a future step.

Currently, one of step which can easily be done is having API for all services 
already used by the screen, (the future POST, PUT, PATCH and DELETE)
be able to call them without a screen as return flow, return flow will be only 
success or error and messages associated
Maybe a controller file could be dedicated by component with these URI.
I supposed , you have done something similar for your Angular custom app, for 
the POC-VueJS it's needed.

Separation completely GUI from application needed too, to be able to have GET 
to read data, to know which data to send in which context, and currently
it's, most of time, executed/filtered by screen/forms.
Realize a complete new set of API for GET using logic used by screen/form 
(security / display-entity, ...) will be a very large task and I think it
will be better to work on using screen/form and having a correct rendering data 
on a intermediate step.
Difficulties to have a correct data rendering is :
When rendering, as JSON flow, for some "field", it's not easily to say what is 
only data, what is user presentation data. I will try to explain by
some example :
1) field with hyperlink,
  * only data is clear it's description, but when it's a image the data is more 
the image logical name (edit / remove / deactivate ...)
  * hyperlink parameters : I think it's data but on the data sent is it 
sub-data of fieldName or data at the same level
2) field display,
  * red-when is it data ?
  * format, if it exist, data should be with format used or not
3) required attribute : is it data

I think it is possible to decide for each what is the choice of the community 
but as a intermediate step send a little more data is a solution too ;-)

In the POC-VueJs, we have decided to send screen/form tag and attributes, this 
gives the user/SPA-GUI-developer the choice

Olivier

PS: Many thanks for your questions / remarks, they helped me to see things more 
clearly, and to decide the points to continue to study or where to go
for the next step.


Le 17/12/2019 à 12:28, Gavin Mabie a écrit :
> Hi Oliver
> 
> I think separating the GUI completely from the application layer could be
> an option worthy of exploring.  That would mean api requests and with
> standard responses in JSON or XML.  What the end user does with the
> response is entirely up to him/her. In this scenario the responses and
> their shapes are highly structured leaving the chosen GUI framework up to
> the user.  Not easy as business/workflow processes would have to be
> represented by well defined api endpoints. Although the current view
> renderer accommodates abstraction for different view implementations it
> only really result in HTML in the end.
> 
> Your question: is it clever to have same functionality with the multiple
> renderer?
> My response: don't have a view renderer at all.
> 
> What do you think?
> 
> Gavin
> 
> 
> On Tue, Dec 17, 2019 at 12:22 PM Olivier Heintz  wrote:
> 
>> Hello Taher,
>>
>>> Do you want an SPA framework now or in the future,
>> is a very important question but
>> which road to use to go is important too.
>>
>> As with the current gui renderer architecture, it's possible to have
>> multiple rendrer engine for the "same" screen/menu/form xml files,
>> one question is : is it clever to have same functionality with the
>> multiple renderer ?
>> maybe the html should be oriented low-technology approach, and so no
>> javascript or minimum (in futur)
>>   the SPA should oriented multi-device and "modern" approach
>>
>> In all case evolution can be step by step and having clear xml formal
>> expression for user interaction is good.
>>
>> With POC-VueJs we wanted to answerd to the question : is it possible to
>> have screen/menu/form xml files AND SPA renderer with all advantage of SPA.
>> Currently, answer is clearly Yes.
>> Our choices or codes are maybe not correct but it's not with a lot of
>> workaround to be able to say it works.
>> Some value are bind on the front end and when back-end is consulted, value
>> in front end are updated and so screen are updated.
>> (one more time, our code is only a demonstration code to help to find the
>> goods one)
>>
>> 80-20 rule is always true, with SPA too
>> so I'm really confident than 80% of xml screen/menu/form can be renderer
>> with a SPA and having a very good SPA advantage usage.
>> For the 20%, it will need to have dedicated SPA component, and during
>> "migration" process which screen should be in 20% will be discuss.
>>
>> Olivier
>>
>>
>>
>> Le 14/12/2019 à 17:51, Tah

Re: [DISCUSSION] Make Back-Office screens dynamic

[Olivier Heintz]

Hello Taher,

> Do you want an SPA framework now or in the future,
is a very important question but
which road to use to go is important too.

As with the current gui renderer architecture, it's possible to have multiple 
rendrer engine for the "same" screen/menu/form xml files,
one question is : is it clever to have same functionality with the multiple 
renderer ?
maybe the html should be oriented low-technology approach, and so no javascript 
or minimum (in futur)
  the SPA should oriented multi-device and "modern" approach

In all case evolution can be step by step and having clear xml formal 
expression for user interaction is good.

With POC-VueJs we wanted to answerd to the question : is it possible to have 
screen/menu/form xml files AND SPA renderer with all advantage of SPA.
Currently, answer is clearly Yes.
Our choices or codes are maybe not correct but it's not with a lot of 
workaround to be able to say it works.
Some value are bind on the front end and when back-end is consulted, value in 
front end are updated and so screen are updated.
(one more time, our code is only a demonstration code to help to find the goods 
one)

80-20 rule is always true, with SPA too
so I'm really confident than 80% of xml screen/menu/form can be renderer with a 
SPA and having a very good SPA advantage usage.
For the 20%, it will need to have dedicated SPA component, and during 
"migration" process which screen should be in 20% will be discuss.

Olivier



Le 14/12/2019 à 17:51, Taher Alkhateeb a écrit :
> Hello Gil,
> 
> Great research on the subject, thank you for sharing.
> 
> I could be wrong here, but at a first glance it seems you want to
> essentially create a tag " another screen dynamically upon clicking / activating the URL. If my
> understanding is correct, then most likely they way you want to
> implement this is probably some web request to the backend which
> renders back a partial screen that you insert into the DOM right?
> 
> If what I describe above is close to your idea, then I think the
> implementation might be relying on the server to do the work of
> painting instead of relying on the browser to do the heavy lifting.
> This also only works with one widget, which is the URL widget as
> opposed to having a general purpose dynamic behavior in the system
> (assuming this is desired).
> 
> However, having a general purpose dynamic behavior means we need a
> method to bind variables to values at the front end without consulting
> the back-end. This reduces the load on the server and provides a
> faster / richer experience to the user. But it would be too painful to
> rely on plain javascript or jQuery to achieve such a result which is
> the reason why frameworks like React, Vue, and others emerged as
> modern SPA frameworks. Adopting an SPA framework would provide dynamic
> behavior (everywhere) instead of certain widgets, and it can be
> expanded to even include page navigation and whatnot. Of course this
> is more work than what you're suggesting here. but if we continue with
> such small improvements, you might end up having lots of javascript
> (maybe that's already the case) which might increase the difficulty of
> adopting an SPA framework in the future.
> 
> So it comes down to this question (which I don't necessarily have an answer 
> to):
> 
> Do you want an SPA framework now or in the future, or do you want to
> continue with status quo into the future? If you want an SPA
> framework, then we should minimize the usage of custom javascript
> everywhere and adopt a framework that completely replaces all the
> javascript that currently exists for all the widgets. If not, then we
> can proceed with your proposition and any others in the future knowing
> that an overhaul is not needed.
> 
> Cheers,
> 
> Taher Alkhateeb
> 
> On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne
>  wrote:
>>
>> Chapter One: How to manage the updating area
>>
>> Hello,
>>
>> After different discussions already listed by Taher [1-9], Leila,
>> Nicolas and me tried another approach.
>> Instead of analyzing how to implement different functionalities offered
>> by modern js framework, we did analyzed how end user use, in general,
>> OFBiz and where we, as an integrator, waste more time to create a
>> screen.
>>
>> To help on this huge task, we set some basic rules :
>> * Work only on screens supported by the theme, defined mainly in xml
>> * This concerns only screens used for back-office applications,
>>   oriented to manage data
>> * A developer does not have to know all of js language (or other)
>>   but can concentrate on the process/view with the end user to
>>   manage a data
>>
>>
>> After a first brainstorm, we have identified three major cases :
>> 1. Navigation and data display
>> 2. View event result (data modification, calculation service, ...)
>> 3. Update an area to refresh data (after data modification)
>>
>> Case 1 and 2 are easy and currently managed by OFBiz (and 

Re: [POC Vue.Js] GUI modularity and attributes

[Olivier Heintz]

Le 13/12/2019 à 23:58, Nicolas Malin a écrit :
> Hello, inline,
> 
> On 13/12/2019 12:47, Olivier Heintz wrote:
>> Hello Community,
>>
>> [...]
>> 1. homogeneous in each component and between components
> This is the way started with the common-theme creation. Move all 
> structural and technical concept on the theming, promoting decorator 
> usage for screen structure
>> 2. modularity :
>>* having "micro-service" on a GUI point of view
>> ** having a level (screen / portlet / screenlet /...) which are able to 
>> be use in a multiple context without technical modification
>      Yes reusability is a nice way to ease custom plugin development, 
> with KISS in mind for the developer. What do you refer as technical 
> modification ?
only task needed too many training before be able to do it
xml with sxd and so auto-completion and auto-documentation are not technical

>> ** menu and screen are decoupled, it's possible to change one without 
>> modifications in the second
> Isn't that already the case ? Not sure I understand what you mean ?
last mail from Gil is the answer
>> ** one function, with maybe some parameters available on 
>> installation/personalisation at the server level.
personalisation for gui is sometime understanding as ability for the end-user 
to change some screen elements for himself.
When I say  "at the server level" I mean, in a implementation process, manage 
as part of production environment (with a version control tools, like
your good remark below about continuous integration process)
and not for a simple user but for business user group.
> 
> There I don't understand for sure, can you elaborate ?
> 
> Modularity is a concept where we store what we need to show.
>     We prefertolimit the modularity concept tothe simple expression, 
> "how to reuse or extend standard code".
>     Or to support this concept, we need to ensure each component work on 
> they cover :
> controller: ensure to identify each in/out
> screen: point to generate coherent rendering
+1

> 
>> 3. be able to have in the OFBiz technical architecture, a layer dedicated to 
>> functional/business consultant (some files or in SGBD)
> Is really a finality for ourcommunity ?
> For a software editor itcan be a good purpose but for us, is ouradded 
> value to create huge quantity of screen with massive parameter based on 
> business suggest ?
I don't see link with editor or community, but of course for not open source 
editor, parameters are mandatory :-)
> Step by step, we have currently some difficulty to convert ftl screen to 
> xml (1. homogenize).
Clearly each evolution should be manage as part of (already decided) current 
action.

Add some parameters for existing screens/forms should be done only when a use 
case exist and simplifying existing situation.
If screen is with ftl, migration should be done first, Clearly.
> 
> We can take a true story to illustrate this : a screen createdfor 
> managingall partyrelationships.
> First you create an isolatedscreen with a search on partyRelationship 
> entity with load from 'site parameters' to instantiate some potential filter
> Who look the relation (to/from), manage history (Y/N), filter relation 
> type, role and some other
>     This first step is a big task to arrive on satisfactory outcome.
> After sharing with end user, you load and configure the screen with 
> desiredinformation on global page
> The end user return you that it's not what he want, he just want only a 
> specific relationType 'A', easy change site parameters
> But heforgot the case of relationType B when roleTo is 'C' ... damned 
> you can't use your generic screen as it and need to override all the 
> search part
> Who said override a part said override all the screen.
Very good example, when I speak about parameters, I do not say be able to do 
all implementation process with parameters.
The 80-20 rule is always true.
Most of personalisation are very simple, remove a menu option, add a hidden 
parameter (ex roleType) in a search form, ...
I think theses tasks could be done with parameters
but the 20% of specifics screen should be develop

> 
>      In final try to make a generic screen based on supposition make 2 
> to 3 days,
> Search it on library, test, configure, valid based on business 
> discussion easly 1 to 2 days,
> Create screen from scratch with business condition:3 hours

:-) I have other "during task" in mind, but it's maybe link to the expertise 
domain of each :-)
In implmentation process, it's needed to have multiple profil to work together
Not a group of expert which not understand the others, but multi-knowledge 
people with expertise domain to be able to help other co-worker.

in a functi

Re: [DISCUSSION] Make Back-Office screens dynamic

[Olivier Heintz]

Hello Gil, (and Néréide Team)

Thank you for sharing research and formal process to be concentrated on concept 
first.

just short remarks inline


Le 13/12/2019 à 16:52, Gil Portenseigne a écrit :
> Chapter One: How to manage the updating area
> 
> Hello,
> 
> After different discussions already listed by Taher [1-9], Leila,
> Nicolas and me tried another approach.
> Instead of analyzing how to implement different functionalities offered
> by modern js framework, we did analyzed how end user use, in general,
> OFBiz and where we, as an integrator, waste more time to create a
> screen.
> 
> To help on this huge task, we set some basic rules :
> * Work only on screens supported by the theme, defined mainly in xml
> * This concerns only screens used for back-office applications,
>   oriented to manage data
> * A developer does not have to know all of js language (or other)
>   but can concentrate on the process/view with the end user to
>   manage a data
++1

> 
> 
> After a first brainstorm, we have identified three major cases :
> 1. Navigation and data display
> 2. View event result (data modification, calculation service, ...)
> 3. Update an area to refresh data (after data modification)
> 
> Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
> will be simple to add), we concentrate our attention on case 3.
there are still some point to study for 1 and 2, but one point by one point is 
a good approach

> 
> To update an area, we follow this pattern
> 
> 1. We start from a context that display different information
> 
> 2. That context display a submit form, use a link or another
> mechanism to call an OFBiz event
> 
> 3. After receiving the event return, we refresh the desired area
> with parameters that can come from origin context or from event
> return.
> 
> 
> Currently with the screen widget, we can use within a form the element
> ``.
> 
> The problem with this use, is that your form needs to know the origin
> context, to identify what are the areas to update and what are the
> target to use for the refresh.
> 
> So your form needs to know where it comes from, what information need to
> be updated in OFBiz and what will be updated after.
> 
> This increases complexity for the developer in the way that current form
> implementation manages :
>   * the data and target to communicate with the server
>   * the behaviour (refreshment) to apply when receiving server response.
> 
> Example :
>  target="createPartyRole">
> 
> ...
>area-target="PartyRolesCustom">
> 
> 
> 
> 
> If you want to reuse the same form, you need to create another screen
> with a new form to redefine the on-event-update-area (for instance
> create a PartyRole).
> 
> We change the thinking, because since it is the starting context that
> better knows itself, it's the starting context that will realize the
> updating operation. The starting context is the screen/menu that call
> this form.
> 
> In general a form is contained in a screen (classic) that is called
> through a link. So we move the idea on this link :
> 
> 
>  from-field="customerParty.partyId"/>
> 
>  from-field="customerParty.partyId"/>
> 
> 
> 
> And the form :
> 
> 
>
>...
> 
> 
> With this logic you can define a new usage of createPartyRole
> without redefining a form just :
> 
> 
>  from-field="partyRelationship.partyIdTo"/>
> 
>  from-field="partyRelationship.partyIdTo"/>
>  value="IRL_LIKE"/>
> 
> 
> 
> After some use we identified as pro and con feedback :
> * updating form is reusable and contains only code related to the
>   form action
+1
> * link being in origin context, the developer knows where he is and
>   where he wants to go
+1
> * Menu oriented management offers a quick vision on how the screen will 
> works
+1
> 
> * update-area seems to be a too technical name
0 because name seem clear
> * we always have to manage area to update manually
+1 UI is area management and their content

Other case is sometime area area watching event to update themself
> * too many areas to update become a headache and not only for the 
> developer
+1
> 
> We did not explain how we have done it, to try to focus the discussion
> on the principles.
> 
> It would be a pleasure to have some criticism of this approach, and we
> would try, in a second chapter to introduce other concepts that appeared
> after the screens were made more dynamic and others to lowers the
> identified cons.
In the POC-Vuejs we have started working on similar idea (using logical field 
name for area and field value send by the 

Re: [POC Vue.Js] GUI modularity and attributes

[Olivier Heintz]

Hello Community,

After Nicolas remarks (thanks to the team for sharing their experiences and 
thoughts)

I propose to discuss about GUI best practice in OFBiz, which one are the most 
priority for the future.
I have already described my point of view and approach 3 years ago in a mail 
[1] and I continue on same ideas ;-)

Maybe, the priorities are not the same for the front-end and the back-end, I 
propose to start discussion by the back-end.

1. homogeneous in each component and between components
2. modularity :
  * having "micro-service" on a GUI point of view
   ** having a level (screen / portlet / screenlet /...) which are able to be 
use in a multiple context without technical modification
   ** menu and screen are decoupled, it's possible to change one without 
modifications in the second
   ** one function, with maybe some parameters available on 
installation/personalisation at the server level.
3. be able to have in the OFBiz technical architecture, a layer dedicated to 
functional/business consultant (some files or in SGBD)

I give only the first 3 to help discussion focus on main priorities. When there 
will be a consensus for the first 3, it will be time to discuss for
the next 3 ;-)

My wording are maybe/certainly not correct and often bad wording create 
confusion, so correct me on idea and/or wording.

Olivier

[1] https://ofbiz.markmail.org/thread/s7pf246hk3uc2mlq
or
[1] 
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui



Le 05/12/2019 à 16:44, Nicolas Malin a écrit :
> Hello,
> I tend to agree with Mathieu to concentrate the effort on json to 
> integrate Vue.js or some other js framework.
> On 31/10/2019 17:03, Olivier Heintz wrote:
>> Hi Community,
>>
>> As explained in a previous mail, we (me and others co-worker in a company I 
>> am working for) are working on a POC for using Vue.js as GUI generated
>> from the current screens/forms/menu xml ofbiz files.
>> The customer goals is to be able to migrate a lot of existing Portal / 
>> portlet developed with ofbiz R13.07 on trunk and on a modern GUI.
>>
>> The main customer specification / requirement are, for the first step of 
>> migration
>> 1. minimum of modifications on xml file, to have the easier and quicker 
>> migration
>> 2. same GUI rules, to facilitate user acceptance
>> 3. new GUI for a component should be working with classic GUI for other 
>> components
>> Enhancement can be possible but will be applied in a second step with 
>> productOwner check and validation. [...]
> After the rollback of all the work done at Nereide usingportal page to 
> manage screen, we came to the conclusion that to create user friendly 
> interfaces, based on customer feedback, the following constraintsare a 
> good goal to achieve:
> 
> * simple to use : user keep his concentration on his current work
> * simple to develop : "make it simple" concept, limit the code but all 
> can be read from screen source.
> * naturally extensible : respect the common theme system.
> 
> Our conclusion(Gil, Leila and me)is that the solution isn't about the 
> technology but toidentify what we really need.
> 
> Finally we determine some basics rules and concept to generate strong 
> screens. We are also currently workingon a POC and some first try with 
> few code are reallyencouraging. I will detailour work onanother thread 
> as soon as it will be presentable.
> 
> So allto say, if you also wantto improve application's screen on 
> trunk,you maywant to see what we have experimented and may want to 
> benefit from our experience on this part.
> 
> Cheers,
> Nicolas
> 

[POC Vue.Js] Party as a usable testing environment

[Olivier Heintz]

Hi Community,

In November, we have worked to be able to test in a more "real situation" the 
POC. We have migrated the party portlet used by PartyProfile page.
So, there is a new plugin in the POC-vusjs group (in the ofbizextra gitlab[1]) 
: partymgrfjs

Currently, there are a lot of functionality working, but still some other one, 
not yet operational.
Next step is to have a full automate User Test Scenario to be sure all is 
operational and usable.

There are two testing environments :
* ofbiz-selenium[2] used by the continuous integration process and some debug 
process, so vue.js application is build with dev option
  With this env. it's possible to see a lot of information about data store and 
component with browser vuejs tools, but application is more slow
* demo-vuejs[3], the standard POC demo build, more stable and build with prod 
option.

Not all xml tag and properties (screen / form / menu) are currently manage, but 
70-80%.
On the first steps we works on Portal / Portlet to better view what it's 
possible to do in a "classical" One Page approach, but we have started to
migrate the "Find - List" decorator to be able to use it with Vue.Js component.
(one of main POC goal is to show that there are minimum of modifications on xml 
file, to have the easier and quicker migration, for most of OFBiz GUI)

In Party, PartyContactMech is manage with a ftl file, so we have tested to 
create a dedicated vuejs components for it and use existing (and new) uri
returning data on json format. (on screen in   a new 
tag https://ofbizextra.org/

It's a POC, so it's a support to discuss about technical or GUI point. All 
current choices can be challenged to find the correct or strong solution
and quickly see the result on a user point of view.
We work on a agile mode, so most of the parts are prototype which should be 
reviewed and/or optimize before finalized

Waiting for feeback, questions and remarks

Next step will be :
1. work on json renderer (as discuss with mathieu) to be more clean and clear
2. having a full automate User Test Scenario with party to be sure all new GUI 
is operational and usable


[1] https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins
[2] 
https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs
[3] 
https://demo-vuejs.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs

Re: [POC Vue.Js] first presentation / summary

[Olivier Heintz]

answer inline

Le 27/11/2019 à 19:02, Mathieu Lirzin a écrit :
> Hello Olivier,
> 
> Olivier Heintz  writes:
> 
>> As explained in a previous mail, we (me and others co-worker in a company I 
>> am working for) are working on a POC for using Vue.js as GUI generated
>> from the current screens/forms/menu xml ofbiz files.
>> The customer goals is to be able to migrate a lot of existing Portal / 
>> portlet developed with ofbiz R13.07 on trunk and on a modern GUI.
>>
>> The main customer specification / requirement are, for the first step of 
>> migration
>> 1. minimum of modifications on xml file, to have the easier and quicker 
>> migration
>> 2. same GUI rules, to facilitate user acceptance
>> 3. new GUI for a component should be working with classic GUI for other 
>> components
>> Enhancement can be possible but will be applied in a second step with 
>> productOwner check and validation.
>>
>> Current POC status is : done with example for some screen / field /menu, 
>> waiting user testing feed back before starting partymgr migration.
>>
>> Our demo platform is 
>> https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin / 
>> ofbiz
>>
>> the chosen architecture is,
>> 1. a new ScreenViewHandler which
>> - use new renderer for screen / form /menu
>> - to return a json with 2 map
>> * ViewScreen with detail about presentation (similar to xml tag and 
>> properies)
>> * ViewEntity with data to populate ui generated (extract from screen/forms 
>> data)
> 
> Providing a JSON view handler is very interesting because it enables any kind
> of Javascript front-end to consume data rendered by existing OFBiz screens
> (with data preparation, etc).  This contributes to the current effort of
> implementing a REST API by enabling consumers to have a JSON representation of
> the retrieved data which is convenient to manipulate from Javascript [1].
> 
> Would you be interested in spending some time integrating this view handler
> inside the framework?
of course, I can created a Jira with the java and update them when there are 
remarks or discussions
> 
> The requirements for such task would be to lint the code, write some
> integration tests, some javadoc, some comments explaining the non-obvious
> parts of the implementation, ... well a non-negligeable amount of work which
> is important for maintainability reasons.
the amount of work is not the main problem ;-)
My knowledge and skill will be more difficult to solve,
I am a business/functional consultant and so a java copy/paste developer (or a 
"java simple/procedural" business process developer)
not a java framework developer.
In the team I'm working, other Co-workers are front-end  developer or profile 
similar than me.

So,
1) javadoc no problem and documentation in adoc format no problem too
2) cleaning code, and applying best practice, no problem if reviewer can give 
me some link or example
3) integration test, when I read the ModelFormFieldTest.java I don't understand 
what it does and the java ... so I will need some help for this sub-task
> 
> For example one requirement would be to use ‘org.apache.ofbiz.base.lang.JSON’
> instead of ‘org.json.simple.JSONObject’ in order to avoid depending on
> multiple JSON libraries.
Clear, I have done it.
Thank you for the remark

> 
> Moreover on the features side, it might be interesting to make the
> presentation related stuff optional for consumers only interested by the data
> aspect of the data.
> 
> What do you think?
Yes it's in the POC plan, but currently we are more focus on having a clear 
user demonstration in a business environment.
This month a large part of Party component have been done and we are working on 
solving all bugs/"form xml functionality not yet implemented"
Hoping to have a usable demo next week. 
(https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs)

Next week I will do a mail with the detail of what is usable and which next 
step are possible
If you or community think that implemented this option is a priority, we will 
do it, I think it will not too difficult.
> 
> [1] https://issues.apache.org/jira/browse/OFBIZ-4274
Yes I know it, but very too technical for me, too many word I don't understand 
;-)
> 

[POC Vue.Js] first presentation / summary

[Olivier Heintz]

Hi Community,

As explained in a previous mail, we (me and others co-worker in a company I am 
working for) are working on a POC for using Vue.js as GUI generated
from the current screens/forms/menu xml ofbiz files.
The customer goals is to be able to migrate a lot of existing Portal / portlet 
developed with ofbiz R13.07 on trunk and on a modern GUI.

The main customer specification / requirement are, for the first step of 
migration
1. minimum of modifications on xml file, to have the easier and quicker 
migration
2. same GUI rules, to facilitate user acceptance
3. new GUI for a component should be working with classic GUI for other 
components
Enhancement can be possible but will be applied in a second step with 
productOwner check and validation.

Current POC status is : done with example for some screen / field /menu, 
waiting user testing feed back before starting partymgr migration.

Our demo platform is 
https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin / ofbiz

the chosen architecture is,
1. a new ScreenViewHandler which
- use new renderer for screen / form /menu
- to return a json with 2 map
* ViewScreen with detail about presentation (similar to xml tag and properies)
* ViewEntity with data to populate ui generated (extract from screen/forms data)
2. a vue.js app with one component per "ofbiz xml tag" (similar to macro ftl)
3. using the event-update-area to do the extra action (ex: update a watcher, 
and so portlet which have subscribed to this watcher is updated)

It's a POC, so it's a support to discuss about technical or GUI point. All 
current choices can be challenged to find the correct or strong solution
and quickly see the result.

We work on a agile mode, so most of the parts are prototype which should be 
reviewed and maybe finalized.

Documentation has begun
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_frontjs_portal

if you want to test it in your environment, the 3 plugins
* vusjsportal : all vuejs components and new handler and new renderers and all 
common files for all fjs components
* examplefjs : specifics files for the ofbiz example component using vue.js
* flatgreyfjs : dedicated theme for vue.js with vuetify
are available on https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins.

I don't detail more, it's better to answer questions or remarks than a too long 
mail !

Next step seems to be to migrate all party portlets to
1. check if current component are enough for all common screens / fields / menus
2. have more real use case to test

Re: [Discussion] Introduction of Bootstrap and Vue.js

[Olivier Heintz]

Hi Tomek,

Nobody in a community base project can answers to "when it will be done".
Some people in the community work on implementing all that is needed to have a 
complete REST API but for all of them, most of time, customer priority
is not the same as community priority, so it will be done when it will be done, 
but be sure it's one of the OFBiz community priority.

Currently we (me and others colleges in company I am working for) are working 
on a POC for using Vue.js as GUI generated from the current
screens/forms/menu xml ofbiz files.

The customer goals is to be able to migrate a lot of existing Portal / portlet 
developed with ofbiz R13.07 on trunk and on a modern GUI.

I will present this POC in a few days to the community, and it's a POC, the 
choices for realizing it are maybe no the corrects ones, but it's possible
to discuss about real demonstration, not only concept.
As it's a POC, it's clearly not an answer to "does the community will create a 
GUI with Vue.js and when".

For the POC we have used example component to demonstrate a rendering of most 
of classical ofbiz form field / menu.
One week ago, in the POC presentation with the customer, he asked us to have a 
more "modern UI" and so developers have changed the template
from "ofbiz - html" to using vuetify lib.
It's really better.

This POC consist of three ofbiz plugins :
* vusjsportal : all vuejs components and new handler and new renderers
* examplefjs : specifics files for the ofbiz example component using vue.js
* flatgreyfjs : dedicated theme for vue.js with vuetify

In the next mail I will detail major principles used and will give access to a 
demo.

Olivier


Le 21/10/2019 à 12:48, Tomek a écrit :
> Hi everyone,
> 
> I consider to use Apache Ofbiz because it seems very good solution but I 
> agree that the UI of the project is not modern. I think that the 
> proposed features like REST API and modern UI based on Bootstrap and 
> Vue.js are great things and it is sensible way to improve Ofbiz. I'm 
> looking forward to the above features and I would like to ask when it 
> will be done?
> 
> Tomek
> 

Re: HR-Documentation by process

[Olivier Heintz]

Hello Everyone,

I have started the process "Employee Salary and Benefits Administration" and 
for the beginning of this process
some corrections or enhancement are needed.

I have done the first 3 steps of the process :
Pay Grade and Salary Step
PositionType Rate and Grade
Employment and Salary history

and it's now included in the HR-Documentation POC 
https://ofbizadoc.ofbizextra.org/html5/user-manual.html
and you can easily compare with the current trunk release at 
https://ofbizadoc.ofbizextra.org/html5/user-manual-std.html

the current video include the HR modifications proposed

I will start to create (or update existing one) JIRA for each doc modification 
proposition
and for HR corrections or modifications (around employment)

Olivier


Le 22/03/2019 à 15:38, Olivier Heintz a écrit :
> Hello Everyone,
> 
> I propose some modifications on HR documentation,
> but I want to present the options I have chosen to be able to discuss with 
> the community if they are a consensus or not for these options.
> 
> To help the discussion, I have done a part of HR documentation with these 
> option to better explain ;-)
> an example is often more clear than a long explanation.
> 
> You can see the documentation modified at 
> https://ofbizadoc.ofbizextra.org/html5/user-manual.html
> you can easily compare with the current trunk release at 
> https://ofbizadoc.ofbizextra.org/html5/user-manual-std.html 
> Same for pdf
> 
> Option 1: documentation drive by process
> =
> Each process is described via a scenario explained like a tutorial, and each 
> time a core object is used, a link is done to its chapter.
> It's done for the first process "Organization, Job Position and Definition"
> current HR TOC
> --
> 3.2. Human Resources
>     3.2.1. About Human Resources
>     3.2.2. Human Resources Processes
>     3.2.3. Employee Positions
>     3.2.4. Employees
>     3.2.5. Employments
>     3.2.6. Performance Review
>     3.2.7. Qualifications
>     3.2.8. Recruitment
>     3.2.9. Skills
>     3.2.10. Resumes
>     3.2.11. Training
>     3.2.12. Leave
>     3.2.13. Security
>     3.2.14. Global HR Settings
>     3.2.15. Glossary
> Proposed HR TOC
> 
> 4. Human Resources
>     4.1. About this documentation
>     4.2. About Human Resources
>     4.3. HR Processes
>     4.3.1. Organization, Job Position and Definition
>     4.3.2. Recruitment, Candidate Selection and Hiring
>     4.3.3. Employee Training and Development
>     4.3.4. Performance Management and Employee Evaluation
>     4.3.5. Employee Salary and Benefits Administration
>     4.4. HR core object
>     4.4.1. Employee Positions
>     4.4.2. Employees
>     4.4.3. Employments
>     4.4.4. Performance Review
>     4.4.5. Qualifications
>     4.4.6. Recruitment
>     4.4.7. Skills
>     4.4.8. Resumes
>     4.4.9. Training
>     4.4.10. Leave
>     4.4.11. Security
>     4.5. Global HR Settings
>     4.5.1. Skills Types
>     4.6. HR Data model
>     4.6.1. Employee Position
>     4.6.2. Employment
>     4.6.3. Qualification, Skill, Review
>     4.6.4. HR App intra-application integration
>     4.7. Glossary
> 
> option 2: Associated a scenario UI test for each process
> =
> I have done one for the first process : "Organization, Job Position and 
> Definition"
> with WebDriver-selenium
> to check if it works, I run it each days on the demo trunk environment 
> https://demo-trunk.ofbiz.apache.org
> and you can download the video (with comment) at
> https://jenkins.ofbizextra.org/view/Trunk-Sel./job/02_Ofbiz_trunk_wktr1_SeleniumWebDriver_tests/168/artifact/build/test-output/CompanyOrganization-implementation.avi
> 
> it's speed on the video but it's easy to slow it by your video reader to have 
> time to read comment or understand which action is done.
> 
> 
> option 3: change the level  of  from 2 (==) to 1 
> (=)
> =
> TOC become
> ...
> Core Business Applications
>     3. Accounting
>     4. Human Resources
> 
> 
> option 4: add a chapter "About this documentation"
> =
> This chapter present the main OFBiz GUI rules with some screenshot
> 
> and link between tutorial and video of "Scenario GUI Test"
> 
> 
> option 5: add a HR Data model with partial diagram
> =
> Each diagram is focus on One (or two) main entity(ies)
> Each diagram show only main relationship between entities to better explain 
> the major entity of the diagram
> 
> 
> option 6: add a general OFBiz Glossary
> =
> For all general concept used by multipl

Re: PrepareLocalesForDropDown.groovy

[Olivier Heintz]

One of Example Component goal is to have some example of code or manner to do.

So, code present in example not using in a production environment is not a 
argument to say we should remove it or not.

If this code could be use in a localized OFBiz, we should retain it.

My 2 cent.
Olivier


Le 16/04/2019 à 08:37, Pierre Smits a écrit :
> Why is this even a discussion topic? Are we not going overboard here with
> having to discuss everything and thus stifling furthering the code and the
> project?
> 
> We should not keep stuff in the code base that is not used in production
> implementations and/or for development.
> 
> Best regards,
> 
> Pierre Smits
> 
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
> 
> 
> On Tue, Apr 16, 2019 at 8:30 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Thanks Nicolas,
>>
>> Removed at revision: 1857622
>>
>> Jacques
>>
>> Le 15/04/2019 à 15:49, Nicolas Malin a écrit :
>>> :) ok for me just go out
>>>
>>> Nicolas
>>>
>>> On 14/04/2019 20:42, Jacques Le Roux wrote:
 This: plugins\example\groovyScripts\PrepareLocalesForDropDown.groovy

 Le 14/04/2019 à 19:01, Nicolas Malin a écrit :
> Hello
>
> poveglia$ svn up
>
> Actualisé à la révision 1857522.
> poveglia$ find . -iname PrepareLocalesForDropDown.groovy
> poveglia$
>
> What this file ?
>
> Nicolas
>
> On 14/04/2019 18:44, Jacques Le Roux wrote:
>> Hi,
>>
>> PrepareLocalesForDropDown.groovy is not used at all OOTB
>>
>> Should we not remove it?
>>
>> Jacques
>>
>>
>

>>>
>>
> 

POC of HR-Documentation by process

[Olivier Heintz]

Hello Everyone,

I propose some modifications on HR documentation,
but I want to present the options I have chosen to be able to discuss with the 
community if they are a consensus or not for these options.

To help the discussion, I have done a part of HR documentation with these 
option to better explain ;-)
an example is often more clear than a long explanation.

You can see the documentation modified at 
https://ofbizadoc.ofbizextra.org/html5/user-manual.html
you can easily compare with the current trunk release at 
https://ofbizadoc.ofbizextra.org/html5/user-manual-std.html 
Same for pdf

Option 1: documentation drive by process
=
Each process is described via a scenario explained like a tutorial, and each 
time a core object is used, a link is done to its chapter.
It's done for the first process "Organization, Job Position and Definition"
current HR TOC
--
3.2. Human Resources
    3.2.1. About Human Resources
    3.2.2. Human Resources Processes
    3.2.3. Employee Positions
    3.2.4. Employees
    3.2.5. Employments
    3.2.6. Performance Review
    3.2.7. Qualifications
    3.2.8. Recruitment
    3.2.9. Skills
    3.2.10. Resumes
    3.2.11. Training
    3.2.12. Leave
    3.2.13. Security
    3.2.14. Global HR Settings
    3.2.15. Glossary
Proposed HR TOC

4. Human Resources
    4.1. About this documentation
    4.2. About Human Resources
    4.3. HR Processes
    4.3.1. Organization, Job Position and Definition
    4.3.2. Recruitment, Candidate Selection and Hiring
    4.3.3. Employee Training and Development
    4.3.4. Performance Management and Employee Evaluation
    4.3.5. Employee Salary and Benefits Administration
    4.4. HR core object
    4.4.1. Employee Positions
    4.4.2. Employees
    4.4.3. Employments
    4.4.4. Performance Review
    4.4.5. Qualifications
    4.4.6. Recruitment
    4.4.7. Skills
    4.4.8. Resumes
    4.4.9. Training
    4.4.10. Leave
    4.4.11. Security
    4.5. Global HR Settings
    4.5.1. Skills Types
    4.6. HR Data model
    4.6.1. Employee Position
    4.6.2. Employment
    4.6.3. Qualification, Skill, Review
    4.6.4. HR App intra-application integration
    4.7. Glossary

option 2: Associated a scenario UI test for each process
=
I have done one for the first process : "Organization, Job Position and 
Definition"
with WebDriver-selenium
to check if it works, I run it each days on the demo trunk environment 
https://demo-trunk.ofbiz.apache.org
and you can download the video (with comment) at
https://jenkins.ofbizextra.org/view/Trunk-Sel./job/02_Ofbiz_trunk_wktr1_SeleniumWebDriver_tests/168/artifact/build/test-output/CompanyOrganization-implementation.avi

it's speed on the video but it's easy to slow it by your video reader to have 
time to read comment or understand which action is done.


option 3: change the level  of  from 2 (==) to 1 (=)
=
TOC become
...
Core Business Applications
    3. Accounting
    4. Human Resources


option 4: add a chapter "About this documentation"
=
This chapter present the main OFBiz GUI rules with some screenshot

and link between tutorial and video of "Scenario GUI Test"


option 5: add a HR Data model with partial diagram
=
Each diagram is focus on One (or two) main entity(ies)
Each diagram show only main relationship between entities to better explain the 
major entity of the diagram


option 6: add a general OFBiz Glossary
=
For all general concept used by multiples components

Modification 7: Change the Human Resources Generality (the HR starting text)

Re-Used Human Resources introduction done in previous documentation proposition 
(WebHelp).

Modification 8: Remove EmplPosition from HR--Glossary because EmplPosition is a 
chapter of HR Core Object



I proposed to have a two level of discussion :
1) By option, discuss about if it's a good or not idea
2) If there is a consensus about an option that is a good idea, discuss about 
the implementation ( or content) of this option

After it will be easy to create jira by option or by file ...

How does that all sound to you?
Please let me know your thoughts, feedback, and improvement suggestions

gradlew generateOfbizDocumentation error

[Olivier Heintz]

Hello,

on trunk, last release
gradlew generateOfbizDocumentation
generate an error message :

-
└─$ ./gradlew generateOfbizDocumentation
> Task :generateOfbizDocumentation FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateOfbizDocumentation'.
> (LoadError) no such file to load -- asciidoctor

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org


on svn release 1854593 generation seems correct
with 1854595 generation works but with a lot of messages
with 1854818 generation failed

on trunk , if I remove line
    id 'org.owasp.dependencycheck' version '3.0.2' apply false

generation works but with a lot of messages.

Re: Plugin install process pb

[Olivier Heintz]

It works,

Thanks for your reactivity

Le 13/08/2018 à 18:25, Mathieu Lirzin a écrit :
> Hello again,
> 
> Mathieu Lirzin  writes:
> 
>>> In my environment (Linux,  openjdk version "1.8.0_171") plugin install 
>>> process does not work any more since this commit (june, 20)
>>>
>>>  def taskExistsInproject(fullyQualifiedProject, taskName) {
>>> -def taskExists = false
>>> -subprojects.each { subProject ->
>>> -if (subProject.getPath().equals(fullyQualifiedProject.toString())) 
>>> {
>>> -subProject.tasks.each { projTask ->
>>> -if (taskName.equals(projTask.name)) {
>>> -taskExists = true
>>> -}
>>> -}
>>> -}
>>> -}
>>> -return taskExists
>>> +subprojects.stream()
>>> +.filter { it.path == fullyQualifiedProject.toString() }
>>> +.flatMap { it.tasks.stream() }
>>> +.anyMatch taskName.
>>>  }
> 
> The problem is that ‘taskName’ is compares with a task instead of the
> task ‘name’ property.  Here is a patch that fixes the bug.
> 
> 
> 
> 
> Thanks.
> 

Re: Plugin install process pb

[Olivier Heintz]

I'm on a debian stretch,

I'm just testing with a ubuntu 18.04 and Oracle JDK and there is then same 
message

No install task defined for plugin testPlugin1, nothing to do




Le 13/08/2018 à 16:36, Jacques Le Roux a écrit :
> Hi Olivier,
> 
> Did you try with an Oracle JDK? Also which Linux distribution/version are you 
> using?
> 
> Jacques
> 
> 
> Le 13/08/2018 à 16:28, Olivier Heintz a écrit :
>> Yes, I confirm, with the old code it works
>> ( I have found which commit after multiple test, each one for each commit on 
>> build.gradle ;-) )
>>
>> Le 13/08/2018 à 14:12, Taher Alkhateeb a écrit :
>>> Hi Olivier,
>>>
>>> Can you confirm that if you test _before_ this commit that it works?
>>> If yes, then this commit needs to be reverted.
>>> On Mon, Aug 13, 2018 at 1:22 PM Olivier Heintz
>>>  wrote:
>>>> Hi,
>>>>
>>>> In my environment (Linux,  openjdk version "1.8.0_171") plugin install 
>>>> process does not work any more since this commit (june, 20)
>>>>
>>>>   def taskExistsInproject(fullyQualifiedProject, taskName) {
>>>> -def taskExists = false
>>>> -subprojects.each { subProject ->
>>>> -if 
>>>> (subProject.getPath().equals(fullyQualifiedProject.toString())) {
>>>> -subProject.tasks.each { projTask ->
>>>> -if (taskName.equals(projTask.name)) {
>>>> -taskExists = true
>>>> -}
>>>> -}
>>>> -}
>>>> -}
>>>> -return taskExists
>>>> +subprojects.stream()
>>>> +.filter { it.path == fullyQualifiedProject.toString() }
>>>> +.flatMap { it.tasks.stream() }
>>>> +.anyMatch taskName.
>>>>   }
>>>>
>>>>
>>>> When I try to install the message is
>>>>
>>>>   ./gradlew installPlugin -PpluginId=testPlugin1
>>>> :installPlugin
>>>> No install task defined for plugin testPlugin1, nothing to do
>>>>
>>>> BUILD SUCCESSFUL
>>>>
>>>> Total time: 1.516 secs
>>>>
>>>>
>>>> My testPlugin1 build.gradle is very simple
>>>> task install {
>>>>  doLast {
>>>>  println 'install task for my plugin test1'
>>>>  exec{ commandLine 'echo', 'Bonjour' } // this could be 
>>>> what you want
>>>>  }
>>>> }
>>>>
>>>> task uninstall {
>>>>  doLast {
>>>>  println 'un-install task for my plugin test1'
>>>>  exec{ commandLine 'echo', 'Au-revoir' } // this could be 
>>>> what you want
>>>>  }
>>>> }
>>>>
>>>> task hello {
>>>>  doLast {
>>>> println 'tutorialspoint'
>>>>  }
>>>> }
>>>>
>>>>
>>>>
>>>> with the previous version of taskExistsInproject  it works
>>>>
>>>> └─$ ./gradlew installPlugin -PpluginId=testPlugin1
>>>> :plugins:testPlugin1:install
>>>> install task for my plugin test1
>>>> Bonjour
>>>> :installPlugin
>>>> installed plugin testPlugin1
>>>>
>>>> BUILD SUCCESSFUL
>>>>
>>>> Total time: 3.134 secs
> 
> 

Re: Plugin install process pb

[Olivier Heintz]

Yes, I confirm, with the old code it works
( I have found which commit after multiple test, each one for each commit on 
build.gradle ;-) )

Le 13/08/2018 à 14:12, Taher Alkhateeb a écrit :
> Hi Olivier,
> 
> Can you confirm that if you test _before_ this commit that it works?
> If yes, then this commit needs to be reverted.
> On Mon, Aug 13, 2018 at 1:22 PM Olivier Heintz
>  wrote:
>>
>> Hi,
>>
>> In my environment (Linux,  openjdk version "1.8.0_171") plugin install 
>> process does not work any more since this commit (june, 20)
>>
>>  def taskExistsInproject(fullyQualifiedProject, taskName) {
>> -def taskExists = false
>> -subprojects.each { subProject ->
>> -if (subProject.getPath().equals(fullyQualifiedProject.toString())) {
>> -subProject.tasks.each { projTask ->
>> -if (taskName.equals(projTask.name)) {
>> -taskExists = true
>> -}
>> -}
>> -}
>> -}
>> -return taskExists
>> +subprojects.stream()
>> +.filter { it.path == fullyQualifiedProject.toString() }
>> +.flatMap { it.tasks.stream() }
>> +.anyMatch taskName.
>>  }
>>
>>
>> When I try to install the message is
>>
>>  ./gradlew installPlugin -PpluginId=testPlugin1
>> :installPlugin
>> No install task defined for plugin testPlugin1, nothing to do
>>
>> BUILD SUCCESSFUL
>>
>> Total time: 1.516 secs
>>
>>
>> My testPlugin1 build.gradle is very simple
>> task install {
>> doLast {
>> println 'install task for my plugin test1'
>> exec{ commandLine 'echo', 'Bonjour' } // this could be what 
>> you want
>> }
>> }
>>
>> task uninstall {
>> doLast {
>> println 'un-install task for my plugin test1'
>> exec{ commandLine 'echo', 'Au-revoir' } // this could be 
>> what you want
>> }
>> }
>>
>> task hello {
>> doLast {
>>println 'tutorialspoint'
>> }
>> }
>>
>>
>>
>> with the previous version of taskExistsInproject  it works
>>
>> └─$ ./gradlew installPlugin -PpluginId=testPlugin1
>> :plugins:testPlugin1:install
>> install task for my plugin test1
>> Bonjour
>> :installPlugin
>> installed plugin testPlugin1
>>
>> BUILD SUCCESSFUL
>>
>> Total time: 3.134 secs
> 

Plugin install process pb

[Olivier Heintz]

Hi,

In my environment (Linux,  openjdk version "1.8.0_171") plugin install process 
does not work any more since this commit (june, 20)

 def taskExistsInproject(fullyQualifiedProject, taskName) {
-def taskExists = false
-subprojects.each { subProject ->
-if (subProject.getPath().equals(fullyQualifiedProject.toString())) {
-subProject.tasks.each { projTask ->
-if (taskName.equals(projTask.name)) {
-taskExists = true
-}
-}
-}
-}
-return taskExists
+subprojects.stream()
+.filter { it.path == fullyQualifiedProject.toString() }
+.flatMap { it.tasks.stream() }
+.anyMatch taskName.
 }


When I try to install the message is

 ./gradlew installPlugin -PpluginId=testPlugin1
:installPlugin
No install task defined for plugin testPlugin1, nothing to do

BUILD SUCCESSFUL

Total time: 1.516 secs


My testPlugin1 build.gradle is very simple
task install {
doLast {
println 'install task for my plugin test1'
exec{ commandLine 'echo', 'Bonjour' } // this could be what you 
want
}
}

task uninstall {
doLast {
println 'un-install task for my plugin test1'
exec{ commandLine 'echo', 'Au-revoir' } // this could be what 
you want
}
}

task hello {
doLast {
   println 'tutorialspoint'
}
}



with the previous version of taskExistsInproject  it works

└─$ ./gradlew installPlugin -PpluginId=testPlugin1
:plugins:testPlugin1:install
install task for my plugin test1
Bonjour
:installPlugin
installed plugin testPlugin1

BUILD SUCCESSFUL

Total time: 3.134 secs

Re: Website Translation in French need contributors

[Olivier Heintz]

Hi,

Clearly, with only me, it's not possible to publish it.
I will continue to synch french version because it's not a large task and very 
"automatic" (no thinking, only doing), waiting there are more peoples
interesting by a Apache OFBiz website in french.

For history, I will put a comment to jira to say "no-one, currently want (or 
have time) to support translation, so it's normal that it's not publish"

Thanks to all
Olivier

Le 11/05/2018 à 10:36, Sharan Foga a écrit :
> Hi Olivier
> 
> I’ve just noticed this message and am surprised that there has been no 
> responses on this thread, not even from Julien who originally suggested 
> translating our website into French to take the place of the old OFBiz France 
> website.
> 
> Anyway I personally would like to say thank you very much for spending your 
> time and energy on this, and keeping this in synch for the last 6 months by 
> yourself shows great commitment and perseverance  :-) 
> 
> I know that this was done with the intention of helping support our project 
> so without the support of at least some of our French committers or the 
> Francophone community, I’m not sure that this can be progressed any further. 
> 
> Does anyone else have any comments or feedback here?
> 
> Thanks
> Sharan
> 
> 
> On 2018/04/26 16:47:05, Olivier Heintz <holivier.li...@ofbizextra.org> wrote: 
>> Hi all French contributors and committers and all others ;-)
>>
>> I have create a JIRA to propose a French version of the Apache OFBiz 
>> website. (https://issues.apache.org/jira/browse/OFBIZ-9800)
>>
>> The idea is to propose a French version which is just a perfect translation 
>> of the original content and doesn't introduce French specific content, to
>> avoid difficulties for reviewing it for most of the committers and PMC 
>> members.
>>
>> A website translation is acceptable if and only if it is synchronized very 
>> rapidly, each time there is a commit on standard website.
>> For the last 6 month I have done the sync and it's not a big job, BUT, only 
>> one people is not enough for warrantee the it will be maintain in the futur
>>
>> This mail is a call for contributors : who is ready to be record as a 
>> contributor on French translation of the Website ?
>> If there are enough people and the French website is publish,
>> a wiki page will be created with all the names and emails address to contact 
>> you directly if a commit on the website is not manage for the French
>> translation after 1 week.
>>
>> Hoping a lot of of answer ;-)
>> Olivier
>>
>>
>>
>>
>>
>>
> 

Website Translation in French need contributors

[Olivier Heintz]

Hi all French contributors and committers and all others ;-)

I have create a JIRA to propose a French version of the Apache OFBiz website. 
(https://issues.apache.org/jira/browse/OFBIZ-9800)

The idea is to propose a French version which is just a perfect translation of 
the original content and doesn't introduce French specific content, to
avoid difficulties for reviewing it for most of the committers and PMC members.

A website translation is acceptable if and only if it is synchronized very 
rapidly, each time there is a commit on standard website.
For the last 6 month I have done the sync and it's not a big job, BUT, only one 
people is not enough for warrantee the it will be maintain in the futur

This mail is a call for contributors : who is ready to be record as a 
contributor on French translation of the Website ?
If there are enough people and the French website is publish,
a wiki page will be created with all the names and emails address to contact 
you directly if a commit on the website is not manage for the French
translation after 1 week.

Hoping a lot of of answer ;-)
Olivier

Re: [DISCUSSION] Moving the Documentation PoC into the Trunk

[Olivier Heintz]

+1

Thanks

Le 03/03/2018 à 10:00, Sharan Foga a écrit :
> +1 
> 
> Actually I'm in favour of putting what we have in the trunk too and update it 
> as we go.
> 
> Thanks
> Sharan
> 
> On 2018/03/03 07:07:27, Gil Portenseigne  wrote: 
>> +1 for working directly in trunk!
>> Regards 
>>
>> Le 2 mars 2018 21:48:55 GMT+01:00, Michael Brohl  
>> a écrit :
>>> +1 for putting it into trunk and moving forward from there.
>>>
>>> Thanks,
>>> Michael 
>>>
>>>
 Am 02.03.2018 um 19:29 schrieb Sharan Foga :

 Hi All

 I'd like to start the discussion about whether we are ready to move
>>> the documentation framework code into the trunk. Do people think that
>>> more testing is needed or that some updates/fixes need to be put in
>>> place first?

 Thanks
 Sharan
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
> 

Re: [Discussion] documentation framework for OFBiz

[Olivier Heintz]

Thank you for the work, Taher

I have played with it and merge with my tests.
Currently, I have start from Accounting_Agreement, convert from docbook and 
update and
test renderer by both your gradle task and by AsciidocFx html button

With a lot of include, result html file would be very large and in some case it 
will be good to be able to put a link in place
of include. Currenlty the generateOfbizDocumentation task doesn't generate file 
for doc in component even if the adoc file is
not in the _include directory.

Just for information: With AsciidocFx (I have understood it use asciidoctor for 
generate html file, but I'm not sure)
it's not necessary to say include file is in _include directory, it read both 
in the current directory and in the _include one.
The generateOfbizDocumentation task doesn't use the same rule, we should say 
explicitly it's in the _include directory.

The main "malfunction" of the generateOfbizDocumentation task is that it not 
re-generate the html file if it already exist
even if the main adoc file was modified. So it's needed to remove it manually 
before call generateOfbizDocumentation.

Thank you for your usage of leveloffset, it's generated by docbook conversion, 
but now I understand how it works ;-)


Olivier

Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
> Hello documentation team and everyone
> 
> I have created a slightly modified design of the documentation
> framework with some sample contents in [1]. I highlight the changes
> below:
> - Created a new top-level directory called "docs/asciidoc". The reason
> is so that we have more than one possible manual.
> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
> - Created "Apache OFBiz Developer Manual" in 
> docs/asciidoc/developer-manual.adoc
> - Created a sample document in the accounting component to show how
> documents are linked together.
> - Used a special directive called "leveloffset" in the include
> directive. This directive shifts the headers of the included document
> (H2 becomes H3, and so on) so that sub-sections can be published
> separately.
> - Created a task called generateOfbizDocumentation to generate the
> documentation (both PDF and HTML) for framework + core apps
> - Created a task called generatePluginDocumentation
> -PpluginId=whatever to generate the documentation for a single plugin.
> 
> That's it. It's simple, easy to understand and I think you might like
> it. Any feedback is welcome, and I'll talk to you soon over Skype.
> 
> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
> 
> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga  wrote:
>> Hi Taher
>>
>> I think a documentation team would be a great idea. There are people that 
>> have indicated that they'd like to help out with documentation tasks on the 
>> user list so that is where I'd recruit some people from. As long as people 
>> know what they need to do to create the patches then it will become a funnel 
>> process of getting it committed.
>>
>> We need a plan to consolidate the information sitting in the wiki and 
>> getting it put into the documentation framework (and this work will then 
>> significantly clear up the wiki!).
>>
>> My availability is pretty bad this week so hope to pick this up again or 
>> start the recruitment campaign next week :-)
>>
>> Thanks
>> Sharan
>>
>> On 2018/01/28 10:12:41, Taher Alkhateeb  wrote:
>>> 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 

Re: What is the "Apache OFBiz" product?

[Olivier Heintz]

+1 to "Apache OFBiz Enterprise automation Platform"
but +1 too to "Apache OFBiz enterprise automation framework"

+1 on idea that ERP, CRM, eCommerce, ... will be the futurs products (base on 
"Apache OFBiz Enterprise automation PLatform" of course) from Apache
Ofbiz community or Companies

Le 12/01/2017 à 23:48, Scott Gray a écrit :
> I prefer "Business" to "ERP" or "Enterprise" but I'm not sure about the
> repeating syllables involved in saying "Apache OFBiz Business {thing}".
> The biz biz doesn't flow well so I'm inclined to fall back to "Enterprise".
> 
> Another adjective to consider over "framework" might be "platform".
> 
> The framework could be marketed as:
> The Apache OFBiz Enterprise Platform
> with the "core" applications being:
> The Apache OFBiz Core Application Suite
> 
> Regards
> Scott
> 
> 
> On 12 January 2017 at 19:26, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> 
>> On Wed, Jan 11, 2017 at 6:44 PM, Nicolas Malin 
>> wrote:
>>
>>> I don't like the term ERP because is so reduced term for OFBiz dans all
>>> product that can register a task for a party and a product is an ERP
>>>
>>> I prefer "Apache OFBiz enterprise automation framework"
>>>
>>> The term ERP or Business suite will come with the plugin addition to the
>>> OFBiz core.
>>>
>>> Nicolas
>>
>>
>> I also like the shorter ones:
>>
>> The "Apache OFBiz" enterprise framework
>> The "Apache OFBiz" enterprise suite (which is similar to the one proposed
>> by Gavin, that I also like, that has the word "business" instead on
>> "enterprise")
>> My concern with the word ERP is that it is an acronym and ends up being too
>> close to the word OFBiz, which is also some sort of acronym, and the
>> concatenated string may look confusing: "Apache OFBiz ERP".
>> Another concern with the name "enterprise framework" is that, when/if we
>> will release a separate product containing only the OFBiz framework, this
>> name would be confusing: in fact my preference is to allocate "framework"
>> for that product (if we will ever release it).
>>
>> Anyway, great proposals so far... I hope the brainstorming will continue!
>> Any volunteer to list *all* the ideas to a Confluence page (maybe even with
>> relevant comments from this thread behind each proposal)?
>>
>> Jacopo
>>
> 

Re: Proposal to create a separate svn repository for the OFBiz official plugins

[Olivier Heintz]

+1 to the svn folder structure.
and I like separation between ofbiz-framework and ofbiz-core

Le 12/01/2017 à 09:13, Jacopo Cappellato a écrit :
> On Thu, Jan 12, 2017 at 7:40 AM, Nicolas Malin 
> wrote:
> 
>> Why prepare the future in the same time to rename ofbiz as ofbiz-core ?
>> Like that we would have :
>> http://svn.apache.org/repos/asf/ofbiz/ofbiz-core
>> http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugin
> 
> 
> I like it. And maybe in the future we will split framework and core:
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-core
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugin
> 
> representing the three layers:
> * framework: programming framework and api to develop enterprise/business
> applications from scratch
> * core: the OFBiz data model and core (CRUD etc...) services and other
> artifacts (possibly the existing "applications")
> * plugins
> 
> plugins can depend on core and framework
> core depends on framework
> framework doesn't depend on core and plugins
> 
> Jacopo
> 

Use Cases for POC

[Olivier Heintz]

The goal of this mail is only two questions :
1. Is this form of use case like in this mail is usable for new UI POC ? (and 
new Doc POC and Selenium-Webdriver POC)
2. Is these use cases seem to be the correct to have correct POC ?

If answer to these two question seem to be yes, I will created a wiki 
confluence page with these use case and we can start to discuss on each detail
it's necessary to have a correct release of this document, usable for the POCs.

Because, I'm testing some documentation tools, these use cases are also 
readable on
https://olivier-heintz.gitbooks.io/use-cases-for-poc/content/

---

# Use cases for POC

Theses use cases are to be used for new UI POC, documentation associated and 
selenium unit task test.

All these use cases should be done with existing entities and services, if it's 
necessary to develop one, simplify the use case, the goal is UI, not
service or entity.

These use case description are done in a agile philosophy, only main point is 
present and during realization details choices will be discuss and done.

Preliminary remarks :
-
1. In this document, the term "application" corresponding to 
"specialpurpose/component" in the ofbiz terminology
which is not same as a "applications/component" in ofbiz terminology.
An application is dedicated for a business purpose for a user type, it's build 
by assembling piece of ofbiz components, sometimes without any
specifics entities, services and screen (ex: CRM-B2C, CRM-B2B, SFA are 3 
applications uses by sales men)

1. Each use case is on an "application" and is part of one of the menu of this 
application.
Of course, this document describe only menu-option needed by the use-case. As 
it's difficult to do a clear definition of "web-page" because it's
depending of theme/template, use case is for me at two level :

1. screen, which can be well define
2. page, which depend on default theme

  Of course, some of use case (screen or page) will be done by a previous one 
(ex : sometime edit is done by the same screen as add). It's even, one
of the re-usable important point (UI, Doc and Selenium)

1. Each time a line (or point) start by a "?" the question is "is this point is 
needed ?"

## Release and goal

Goal is the POC realization, not doing multiple super applications. POC 
realization should generate discussion and decision, each time be careful to
mainly discuss on UI, Doc or Selenium and not on use case business 
justification. Use case are to be realistic but mainly as a support for a 
specifics
UI, Doc or Selenium needed.

### V1

**Main Goal is to proof the technical points**. Of course UI re-organization is 
the driver for this phase, documentation start to work in parallel but
will wait first realization to test integration for help. For selenium unit 
task, it will be a simple usage of the new UI with the default theme, the
sole purpose being to check that test with default theme is simple.

So never mind if all cases is not done, the list exist to give different 
classic case what we will need to know how to process it. Some case which
seem to be duplicate from other can be use for beginner who want to help and 
check if the concept is understanding.

During V1 realization, UseCase list will be updated

### V2

**Main Goal is to check if** the solution is **useful for the different type of 
contributors**

* experiment developer
* beginner developer
* functional consultant for parameters
* functional consultant for personalization
* ? end user - for parameters ? (if it's still possible with the new 
architecture)

Use Case list will be use as a deployment plan. The list contains similar case 
to these which are realize in V1, so those on V2 can be achieve by all
types of contributors.

### Documentation Goal
- Apache OFBiz web site wiki
- OFBiz Help
- PDF ?

### Selenium test
1. demo data for each use case
1. selenium unit test for each screen
1. selenium scenario test for each page (or page group)

## Simple Party Management

### Which Sub-Application

1. in HR application, simple employee management
2. in CRM B2C application, simple customer (person) management
3. in eCommerce, simple profile page
4. in HR application, simple organization/place (group) management
5. in CRM B2B application, simple customer (company) management
6. in Facility application, simple worker management

### Which Party sub-component

1. Party - Person - PartyGroup
2. Contact Mech,
- with postal address, phone and mail;
- one or two fixes purpose (ex: phone fix number and mobile phone number)
3. Role
4. Party Identification
5. Party association
6. Not ~~UserLogin~~ because all Security entities should be use and it will 
generate a too large domain for this POC

### Which Screen

1. Party
   * find, list
   * A person
 * add / edit, show
   * A group
 * add / edit, show
   * A company
 * add / edit, show
   * show a synthesis view (party/person/company, 

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Olivier Heintz]

Le 29/11/2016 à 22:12, Nicolas Malin a écrit :
> 
> Le 29/11/2016 à 20:21, Olivier Heintz a écrit :
>> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
>>>> Hi Sharan,
>>>>
>>>> Thank you for starting this important topic. OFBiz definitely needs

>>>> 

model.
>>>> - A DSL that hides and abstracts away the complexity of everything 
>>>> (services, entities, widgets, routing, etc...)
>>>>and makes it easy for adopters to provide value quickly.
>>- A plugin system AND a plugin strong organization
> I'm agree to the plugin system but not on plugin strong organization.
> 
> Offer good tools to realize some plugin is different that offer a 
> plateform to deploy and manage a plugin store
> We need to concentrate the effort on the core, have some official plugin 
> for example, special case and define best pratice.
> 
> We are to few to maintain the ofbiz core so for me manage a plugin store 
> is more for integrator company or another dedicate community with 
> different rules.

my formulation was too short and so not clear, << plugin strong organization >>
would have of the being something like
<< plugin metadata and some rules to be able to have efficient documentation to 
find easily what plugin install for the choosing function >>
and nothing about repository management, I apologize for the misunderstanding.

But I immediately add the remark done by sharan, taher, ... It's not a current 
discussion subject for today.
We should have first have some plugin available. (I'm currently testing the 
webdriver-tools addon migrated as a plugin)



> 
> Cheers,
> Nicolas
> 

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Olivier Heintz]

comment in-line

Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
> Hi Sharan,
> 
> Thank you for starting this important topic. OFBiz definitely needs
> strategic objectives and a sense of direction. To try to formulate a
> strategy, I would suggest perhaps we highlight where I think OFBiz delivers
> value and where it does not, and based on that provide a few suggestions on
> moving forward.
> 
> OFBiz main value proposition
> ---
> - A very robust domain model based on the data model resource book.
> - A library of services to control and manipulate the data model.
> - A DSL that hides and abstracts away the complexity of everything (services, 
> entities, widgets, routing, etc...)
>and makes it easy for adopters to provide value quickly.
  - A plugin system AND a plugin strong organization
> - A business automation suite.
> 
> What OFBiz is not (yet?)
> 
> Currently OFBiz may provide some of the below, but it is not the main value
> proposition.
> 
> - A web framework
> - A general purpose programming environment
I prefer : A general purpose programming and parametrized environment
> - An ERP system ready for immediate use by business owners (not geared for 
> end-users)
  - A business functions library usable to build a Vertical Business ERP 
solution
> 
> Where should we focus?
> ---
> If you agree with the above assessment on OFBiz's value proposition, then I
> think we need to focus our limited resources and efforts and utilize the
> help of the community where it provides the highest value for effort. To
> start this discussion I suggest the list of below strategic objectives to
> try and move forward over the next 1-2 years at which time we can review
> and amend the strategy:
> 
> - UI redesign: I think the user interface is one of the weakest points in
> our project and is probably the most critical item for adoption because at
> the end this is what people _see_. Having non-technical people download
> OFBiz, fire it up and start using it immediately without the intervention
> of a consultant or a developer is key to bigger adoption. Bigger adoption
> in turn leads to a more thriving community and business built around OFBiz.
> Hence we need a fully redesigned user interface that is not a reference for
> developers but rather a usable interface immediately to someone who needs
> an ERP platform for their business.
I propose to change the last sentence by :
... developers but rather a usable interface immediately
to demonstrate ofbiz usability and flexibility
to someone who needs an ERP platform for their business.

Maybe the difference at which I want to point is only on the use case 
definition to implement on the OOTB kernel
> 
> - Documentation: We have a lot of documentation resources, but they are
> unorganized, scattered and outdated. Documentation is another key driver of
> adoption and I think a significant amount of work needs to go into
> organizing and cleaning up our documentation. We need a unified resource
> for getting information. I really like for example the documentation of
> Gradle found in docs.gradle.org which breaks things down beautifully into a
> user guide, a DSL reference and JavaDocs with very good sub-categorization
> and hyperlinks between everything.
+10 for
> Documentation is another key driver of
> adoption and I think a significant amount of work needs to go into
> organizing and cleaning up our documentation.
But also at the technical architecture and tools available for the writers.

Documentation (creating / modifying / reading / customizing / organizing) 
should be part of the
" general purpose programming and parametrized environment"
Documentation should be usable as help for key-users/consultant/technical, 
directly from "ofbiz applications".


> - Branding: A new website, activities on social media, success stories
> (updating), references, etc ...
> 
> The reason I recommend the above strategic initiatives is that they are
> relatively easy and most community members can contribute to which would
> provide great value by leveraging the help of as many people as we can.
> 
> Thoughts?
> 
> Cheers,
> 
> Taher Alkhateeb
> 
> On Mon, Nov 28, 2016 at 1:35 PM, Sharan Foga  wrote:
> 
>> There was a bit that I missed - and this is a common thing that keeps
>> coming back up when we get together and talk:
>>
>> OFBiz could deliver more than one product. We could have more than one
>> product active at the same time e.g
>>
>>- Framework with applications
>>- Advanced UI but without all features
>>- Advanced features but with the poor UI
>>
>> This is also something that we could think about for the high level
>> strategy.
>>
>> Thanks
>> Sharan
>>
>> On 2016-11-28 11:08 (+0100), "Sharan Foga" wrote:
>>> Hi Everyone
>>>
>>> One of the topics that came up during the brainstorming in Seville was
>> that 

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Olivier Heintz]

Answers are in-line

Le 28/11/2016 à 11:08, Sharan Foga a écrit :
> Hi Everyone
> 
> One of the topics that came up during the brainstorming in Seville was that 
> the project desperately needs a clear strategy and roadmap. 
>



> 
> So to get the discussion started: 
> 
> 1. Do people agree that the project needs to focus on driving adoption?
+10
but who are ours target :
  1) ERP services company (consultant or/and technical employees with ERP 
knowledge)
  2) or IT services company ( SME )
  3) or end user (manager who need a ERP)
  or both ;-)

( it's ordered in my point of view )

> 2. Do people think that the UI is one of the key things that stops this ? 
> (If, not then please include what do you think is)
+10
but maybe the OOTB UI is not the same than the more professional business 
application plugins.
First should be more fashionable that the second which could be more sober and 
practical (maybe only a theme difference)

> 3. What goals could we set?
Taher start to answer, I will complete...

> 4. Are people interested in working in workgroups, to focus on specific areas 
> (or goals)?
My "contribution areas" are
- UI scenario Test
- documentation (for consultant or/and technical  with ERP knowledge )
- using plugin manager to create small function plugin
- saying if it's usable by a functional consultant ;-)

> 
> (I know there are some ideas/work around the UI going on, but I will post the 
> Seville details and notes about that in separate discussion thread.)
> 
> Thanks
> Sharan
> 
> 

Re: Housekeeping of the OFBiz svn tree: removing some old/unused experimental branches

[Olivier Heintz]

 20120329_portletWidget and  webhelp-2012-12-07 have been migrated as addon on 
ofbizextra so you can remove its.
They are available for trunk and 13.07.

Olivier



Le 30/09/2014 10:02, Jacopo Cappellato a écrit :

New list after Adrian's feedback:

• 2015ScreenWidgetRedesign/
• 20111205EmailHandling/
• 20120209RemoveBsh/
• 20120329_portletWidget/
• 2013_RemoveJavolution/
• addbirt/
• executioncontext20090716/
• executioncontext20090812/
• frontendNewTheme2013-05-10/
• htmlfive_20110529/
• improved-entityengine-features-20120528/
• jackrabbit20100709/
• jquery/
• multitenant20100310/
• webhelp-2012-12-07/

Jacopo

On Sep 30, 2014, at 9:59 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:


executioncontext20091231

is a working copy of the security redesign:

https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign

I still hope there will be some interest in it some day.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 9/30/2014 8:31 AM, Jacopo Cappellato wrote:

What do you think about removing some old and no more active experimental 
branches? Please let me know what are the ones we should keep.

Here is the current list of experimental branches (*):

• 2015ScreenWidgetRedesign/
• 20111205EmailHandling/
• 20120209RemoveBsh/
• 20120329_portletWidget/
• 2013_RemoveJavolution/
• OFBIZ-5312-ofbiz-ecommerce-seo-2013-10-23/
• addbirt/
• executioncontext20090716/
• executioncontext20090812/
• executioncontext20091231/
• frontendNewTheme2013-05-10/
• htmlfive_20110529/
• improved-entityengine-features-20120528/
• jackrabbit20100709/
• jackrabbit20120501/
• jquery/
• multitenant20100310/
• webhelp-2012-12-07/

Regards,

Jacopo


(*) https://svn.apache.org/repos/asf/ofbiz/branches/

[jira] [Comment Edited] (OFBIZ-5408) ProductStoreFacilities page does not refresh information after actions are performed

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14013927#comment-14013927
 ] 

Olivier Heintz edited comment on OFBIZ-5408 at 5/30/14 4:50 PM:


bug corrections : 
1) areaId was wrong in on-event for edit and in delete button in list
2) replace wrong view-map ListProductStoreFacilityFormOnly by 
ListProductStoreFacility

patch is ok for trunk and 13.07


was (Author: holivier):
bug corrections : 
1) areaId was wrong in on-event for edit and in delete button in list
2) replace wrong view-map ListProductStoreFacilityFormOnly by 
ListProductStoreFacility

 ProductStoreFacilities page does not refresh information after actions are 
 performed
 

 Key: OFBIZ-5408
 URL: https://issues.apache.org/jira/browse/OFBIZ-5408
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: SVN trunk
Reporter: Christian Carlow
Priority: Minor
 Attachments: OFBIZ-5408.patch


 The ProductStoreFacilities page does not refresh when actions are performed.  
 When adding or deleting a facility from the store, the result of either 
 action is not reflected on the page even though both are performed.  A 
 loading icon appears after clicking action buttons/links so AJAX is probably 
 being used.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (OFBIZ-5408) ProductStoreFacilities page does not refresh information after actions are performed

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5408:
--

Attachment: OFBIZ-5408.patch

bug corrections : 
1) areaId was wrong in on-event for edit and in delete button in list
2) replace wrong view-map ListProductStoreFacilityFormOnly by 
ListProductStoreFacility

 ProductStoreFacilities page does not refresh information after actions are 
 performed
 

 Key: OFBIZ-5408
 URL: https://issues.apache.org/jira/browse/OFBIZ-5408
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: SVN trunk
Reporter: Christian Carlow
Priority: Minor
 Attachments: OFBIZ-5408.patch


 The ProductStoreFacilities page does not refresh when actions are performed.  
 When adding or deleting a facility from the store, the result of either 
 action is not reflected on the page even though both are performed.  A 
 loading icon appears after clicking action buttons/links so AJAX is probably 
 being used.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886475#comment-13886475
 ] 

Olivier Heintz commented on OFBIZ-4941:
---

Currently, webhelp is available as an addon in the ofbizextra platform and I 
use it on my customer project.
We currently work to have a more usable platform than google-code for 
ofbizextra forge, I hope in 2 or 3 weeks be able to announce the migration and 
a demo environment for all existing and working addons about webhelp and 
portlet-widget.

 Proposal for a new help system
 --

 Key: OFBIZ-4941
 URL: https://issues.apache.org/jira/browse/OFBIZ-4941
 Project: OFBiz
  Issue Type: Wish
  Components: ALL COMPONENTS
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
 HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
 OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
 OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
 WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
 WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
 docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
 help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg


 Quoting Tom Burns at OFBIZ-4869
 {quote}
 This is a status update just to let anyone who is interested know that this 
 item is being worked on.
 I started out using the OFBiz structure for help docs but after a while I 
 needed/wanted something more expressive.
 Here is what I wound up using for development:
 Java Help System http://java.net/projects/javahelp/content
 DocBook 5: The Definitive Guide
 http://www.docbook.org/tdg5/en/html/docbook.html
 http://www.docbook.org/xml/5.0/
 DocBook XSL: The Complete Guide
 http://www.sagehill.net/docbookxsl/index.html
 
 http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
 Help Master - FE for managing java help files. Best feature drag and drop 
 TOC creates TOC matching file folder structure. Convenient launcher for 
 viewing  testing. http://www.halogenware.com/software/helpmaster.html
 XML Mind XML Editor - Free Personal Edition is far better then editing in 
 Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
 Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
 http://www.xmlmind.com/xmleditor/tutorial.html
 Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
 Attached are some screen shots of the results.
 Every screen is/will be documented in a similar structure. This is as much 
 for defining requirements and testing as for help. More work but worth it.
 The screenshots show a Java Help format generated using DocBook XSL. This 
 will likely not be the final presentation format.
 Note the Performance Review screen shots do not match the trunk. There is a 
 bug in update screen and I did some clean up of labels and drop-down list. 
 There are issues like this all through the application so I did not want to 
 get bogged down with patches at this time.
 {quote}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Fwd: svn ommit: r1488315 - in /ofbiz/trunk/framework/widget: dtd/widget-form.xsd src/org/ofbiz/widget/form/MacroFormRenderer.java src/org/ofbiz/widget/form/ModelForm.java

[Olivier Heintz]

Adrian,

The method createAjaxParamsFromUpdateAreas added in this commit return

sb.toString()
and not FlexibleStringExpander.expandString(sb.toString(), context, locale);

like the other method createAjaxParamsFromUpdateAreas, it generate error 
when ${} is used for area-id


is it possible to change ?
Do you want I create a Jira ?

Olivier

 Message original 
Sujet: 	svn commit: r1488315 - in /ofbiz/trunk/framework/widget: 
dtd/widget-form.xsd src/org/ofbiz/widget/form/MacroFormRenderer.java 
src/org/ofbiz/widget/form/ModelForm.java

Date :  Fri, 31 May 2013 17:07:01 -
De :adri...@apache.org
Répondre à :dev@ofbiz.apache.org
Pour :  comm...@ofbiz.apache.org



Author: adrianc
Date: Fri May 31 17:07:00 2013
New Revision: 1488315

URL: http://svn.apache.org/r1488315
Log:
Fixed some bugs in the form widget column sorting code:

1. URL parameters were being mangled by clunky string manipulation code.
2. The sort column logic was piggy-backed on the pagination event. I created a new choice for 
the form widget on-event-update-area element - sort-column - so column sort 
events can update their own areas.
3. The parameter name for the sort column was hard-coded, so column sorting in multiple lists 
on the same screen would not work. I added a new form attribute - 
sort-field-parameter-name - so each list can be sorted separately.

Modified:
ofbiz/trunk/framework/widget/dtd/widget-form.xsd

ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/MacroFormRenderer.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/ModelForm.java


Modified: 
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/MacroFormRenderer.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/MacroFormRenderer.java?rev=1488315r1=1488314r2=1488315view=diff
==
--- 
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/MacroFormRenderer.java 
(original)
+++ 
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/MacroFormRenderer.java 
Fri May 31 17:07:00 2013
 
+/** Create an ajaxXxxx JavaScript CSV string from a list of UpdateArea objects. See

+ * codeselectall.js/code.
+ * @param updateAreas
+ * @param extraParams Renderer-supplied additional target parameters
+ * @param context
+ * @return Parameter string or empty string if no UpdateArea objects were 
found
+ */
+private String createAjaxParamsFromUpdateAreas(ListModelForm.UpdateArea updateAreas, 
MapString, Object extraParams, String anchor, MapString, ? extends Object 
context) {
+StringBuilder sb = new StringBuilder();
+IteratorModelForm.UpdateArea updateAreaIter = updateAreas.iterator();
+while (updateAreaIter.hasNext()) {
+ModelForm.UpdateArea updateArea = updateAreaIter.next();
+sb.append(updateArea.getAreaId()).append(,);
+String ajaxTarget = updateArea.getAreaTarget(context);
+String urlPath = UtilHttp.removeQueryStringFromTarget(ajaxTarget);
+sb.append(this.rh.makeLink(this.request, 
this.response,urlPath)).append(,);
+String queryString = 
UtilHttp.getQueryStringFromTarget(ajaxTarget).replace(?, );
+MapString, Object parameters = 
UtilHttp.getQueryStringOnlyParameterMap(queryString);
+MapString, Object ctx = UtilGenerics.checkMap(context);
+MapString, Object updateParams = 
UtilGenerics.checkMap(updateArea.getParameterMap(ctx));
+parameters.putAll(updateParams);
+UtilHttp.canonicalizeParameterMap(parameters);
+parameters.putAll(extraParams);
+IteratorMap.EntryString, Object paramIter = 
parameters.entrySet().iterator();
+while (paramIter.hasNext()) {
+Map.EntryString, Object entry = paramIter.next();
+sb.append(entry.getKey()).append(=).append(entry.getValue());
+if (paramIter.hasNext()) {
+sb.append();
+}
+}
+if (anchor != null) {
+sb.append(#).append(anchor);
+}
+if (updateAreaIter.hasNext()) {
+sb.append(,);
+}
+}
+return sb.toString();
 }
 
 /** Create an ajaxXxxx JavaScript CSV string from a list of UpdateArea objects. See

[jira] [Updated] (OFBIZ-5189) Portal page personalization is not working

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5189:
--

Attachment: OFBIZ-5189.patch

one other bug in portal page personalization.
When trying to delete portlet or column in portal page, there is an error 
because in delete service, cache is used to read data before remove.

Correction proposed is to remove use-cache=true 

This correction is added with the two previous corrections in the new patch

 Portal page personalization is not working
 --

 Key: OFBIZ-5189
 URL: https://issues.apache.org/jira/browse/OFBIZ-5189
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
 Environment: trunk
Reporter: Olivier Heintz
 Fix For: SVN trunk

 Attachments: OFBIZ-5189.patch, OFBIZ-5189.patch


 Two simples errors after last change from FastList to standard java List :
 1) go to example component / Dasboard 
 1.1) click on edit for one page
 Screen is blocked
 reason : 
 {code}
 for (GenericValue portalPage : portalPages) {
 cond = EntityCondition.makeCondition(UtilMisc.toList(
 
 EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS, 
 userLoginId),
 
 EntityCondition.makeCondition(originalPortalPageId, EntityOperator.EQUALS, 
 portalPage.getString(portalPageId))),
 EntityOperator.AND);
 List GenericValue privatePortalPages = 
 delegator.findList(PortalPage, cond, null, null, null, false);
 if (UtilValidate.isNotEmpty(privatePortalPages)) {
 portalPages.remove(portalPage);
 portalPages.add(privatePortalPages.get(0));
 }
 }
 {code}
 code iterate on a list and modify it, I don't know how it works before ;-)
 I propose to use an other list on iterate 
 2) on appbarclose.ftl for tomawak theme there is
 {code}
 #assign portalPage = delegator.findOne(PortalPage, findMap, true)
 {code}
 when you click to revert to original in dasboard screen
 {code}
 Error on line 45, column 5 in component://tomahawk/includes/appbarClose.ftl 
 delegator.findOne(PortalPage, findMap, true) is undefined. It cannot be 
 assigned to portalPage The problematic instruction: -- == 
 assignment: portalPage=delegator.findOne(PortalPage, findMap, true) [on 
 line 45, column 5 in component://tomahawk/includes/appbarClose.ftl] -
 {code}
 2.1) to see the error, modify ExampleMenus.xml and change menu-item name from 
 Dasboard to Dasboard1 
 2.2) go to example / dashboard and edit one page
 2.3) click to revert to original
 I propose to add ?if_exists 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5189) Portal page personalization is not working

[Olivier Heintz (JIRA)]

Olivier Heintz created OFBIZ-5189:
-

 Summary: Portal page personalization is not working
 Key: OFBIZ-5189
 URL: https://issues.apache.org/jira/browse/OFBIZ-5189
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
 Environment: trunk
Reporter: Olivier Heintz
 Fix For: SVN trunk


Two simples errors after last change from FastList to standard java List :
1) go to example component / Dasboard 
1.1) click on edit for one page
Screen is blocked
reason : 
{{code}}
for (GenericValue portalPage : portalPages) {
cond = EntityCondition.makeCondition(UtilMisc.toList(

EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS, 
userLoginId),

EntityCondition.makeCondition(originalPortalPageId, EntityOperator.EQUALS, 
portalPage.getString(portalPageId))),
EntityOperator.AND);
List GenericValue privatePortalPages = 
delegator.findList(PortalPage, cond, null, null, null, false);
if (UtilValidate.isNotEmpty(privatePortalPages)) {
portalPages.remove(portalPage);
portalPages.add(privatePortalPages.get(0));
}
}
{{code}}
code iterate on a list and modify it, I don't know how it works before ;-)
I propose to use an other list on iterate 

2) on appbarclose.ftl for tomawak theme there is
{{code}}
#assign portalPage = delegator.findOne(PortalPage, findMap, true)
{{code}}
when you click to revert to original in dasboard screen
{{code}}
Error on line 45, column 5 in component://tomahawk/includes/appbarClose.ftl 
delegator.findOne(PortalPage, findMap, true) is undefined. It cannot be 
assigned to portalPage The problematic instruction: -- == assignment: 
portalPage=delegator.findOne(PortalPage, findMap, true) [on line 45, column 5 
in component://tomahawk/includes/appbarClose.ftl] -
{{code}}
2.1) to see the error, modify ExampleMenus.xml and change menu-item name from 
Dasboard to Dasboard1 
2.2) go to example / dashboard and edit one page
2.3) click to revert to original
I propose to add ?if_exists 




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5189) Portal page personalization is not working

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5189:
--

Attachment: OFBIZ-5189.patch

 Portal page personalization is not working
 --

 Key: OFBIZ-5189
 URL: https://issues.apache.org/jira/browse/OFBIZ-5189
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
 Environment: trunk
Reporter: Olivier Heintz
 Fix For: SVN trunk

 Attachments: OFBIZ-5189.patch


 Two simples errors after last change from FastList to standard java List :
 1) go to example component / Dasboard 
 1.1) click on edit for one page
 Screen is blocked
 reason : 
 {{code}}
 for (GenericValue portalPage : portalPages) {
 cond = EntityCondition.makeCondition(UtilMisc.toList(
 
 EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS, 
 userLoginId),
 
 EntityCondition.makeCondition(originalPortalPageId, EntityOperator.EQUALS, 
 portalPage.getString(portalPageId))),
 EntityOperator.AND);
 List GenericValue privatePortalPages = 
 delegator.findList(PortalPage, cond, null, null, null, false);
 if (UtilValidate.isNotEmpty(privatePortalPages)) {
 portalPages.remove(portalPage);
 portalPages.add(privatePortalPages.get(0));
 }
 }
 {{code}}
 code iterate on a list and modify it, I don't know how it works before ;-)
 I propose to use an other list on iterate 
 2) on appbarclose.ftl for tomawak theme there is
 {{code}}
 #assign portalPage = delegator.findOne(PortalPage, findMap, true)
 {{code}}
 when you click to revert to original in dasboard screen
 {{code}}
 Error on line 45, column 5 in component://tomahawk/includes/appbarClose.ftl 
 delegator.findOne(PortalPage, findMap, true) is undefined. It cannot be 
 assigned to portalPage The problematic instruction: -- == 
 assignment: portalPage=delegator.findOne(PortalPage, findMap, true) [on 
 line 45, column 5 in component://tomahawk/includes/appbarClose.ftl] -
 {{code}}
 2.1) to see the error, modify ExampleMenus.xml and change menu-item name from 
 Dasboard to Dasboard1 
 2.2) go to example / dashboard and edit one page
 2.3) click to revert to original
 I propose to add ?if_exists 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5189) Portal page personalization is not working

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5189:
--

Description: 
Two simples errors after last change from FastList to standard java List :
1) go to example component / Dasboard 
1.1) click on edit for one page
Screen is blocked
reason : 
{code}
for (GenericValue portalPage : portalPages) {
cond = EntityCondition.makeCondition(UtilMisc.toList(

EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS, 
userLoginId),

EntityCondition.makeCondition(originalPortalPageId, EntityOperator.EQUALS, 
portalPage.getString(portalPageId))),
EntityOperator.AND);
List GenericValue privatePortalPages = 
delegator.findList(PortalPage, cond, null, null, null, false);
if (UtilValidate.isNotEmpty(privatePortalPages)) {
portalPages.remove(portalPage);
portalPages.add(privatePortalPages.get(0));
}
}
{code}
code iterate on a list and modify it, I don't know how it works before ;-)
I propose to use an other list on iterate 

2) on appbarclose.ftl for tomawak theme there is
{code}
#assign portalPage = delegator.findOne(PortalPage, findMap, true)
{code}
when you click to revert to original in dasboard screen
{code}
Error on line 45, column 5 in component://tomahawk/includes/appbarClose.ftl 
delegator.findOne(PortalPage, findMap, true) is undefined. It cannot be 
assigned to portalPage The problematic instruction: -- == assignment: 
portalPage=delegator.findOne(PortalPage, findMap, true) [on line 45, column 5 
in component://tomahawk/includes/appbarClose.ftl] -
{code}
2.1) to see the error, modify ExampleMenus.xml and change menu-item name from 
Dasboard to Dasboard1 
2.2) go to example / dashboard and edit one page
2.3) click to revert to original
I propose to add ?if_exists 




  was:
Two simples errors after last change from FastList to standard java List :
1) go to example component / Dasboard 
1.1) click on edit for one page
Screen is blocked
reason : 
{{code}}
for (GenericValue portalPage : portalPages) {
cond = EntityCondition.makeCondition(UtilMisc.toList(

EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS, 
userLoginId),

EntityCondition.makeCondition(originalPortalPageId, EntityOperator.EQUALS, 
portalPage.getString(portalPageId))),
EntityOperator.AND);
List GenericValue privatePortalPages = 
delegator.findList(PortalPage, cond, null, null, null, false);
if (UtilValidate.isNotEmpty(privatePortalPages)) {
portalPages.remove(portalPage);
portalPages.add(privatePortalPages.get(0));
}
}
{{code}}
code iterate on a list and modify it, I don't know how it works before ;-)
I propose to use an other list on iterate 

2) on appbarclose.ftl for tomawak theme there is
{{code}}
#assign portalPage = delegator.findOne(PortalPage, findMap, true)
{{code}}
when you click to revert to original in dasboard screen
{{code}}
Error on line 45, column 5 in component://tomahawk/includes/appbarClose.ftl 
delegator.findOne(PortalPage, findMap, true) is undefined. It cannot be 
assigned to portalPage The problematic instruction: -- == assignment: 
portalPage=delegator.findOne(PortalPage, findMap, true) [on line 45, column 5 
in component://tomahawk/includes/appbarClose.ftl] -
{{code}}
2.1) to see the error, modify ExampleMenus.xml and change menu-item name from 
Dasboard to Dasboard1 
2.2) go to example / dashboard and edit one page
2.3) click to revert to original
I propose to add ?if_exists 





 Portal page personalization is not working
 --

 Key: OFBIZ-5189
 URL: https://issues.apache.org/jira/browse/OFBIZ-5189
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
 Environment: trunk
Reporter: Olivier Heintz
 Fix For: SVN trunk

 Attachments: OFBIZ-5189.patch


 Two simples errors after last change from FastList to standard java List :
 1) go to example component / Dasboard 
 1.1) click on edit for one page
 Screen is blocked
 reason : 
 {code}
 for (GenericValue portalPage : portalPages) {
 cond = EntityCondition.makeCondition(UtilMisc.toList(
 
 EntityCondition.makeCondition(ownerUserLoginId, EntityOperator.EQUALS

Re: Slim-down effort: current situation

[Olivier Heintz]

Very clear and efficient

Le 07/01/2013 09:20, Jacopo Cappellato a écrit :

Let's see if we can move on the slim-down effort in this direction; here is a 
slightly more detailed proposal:

* svn layout of the project will stay as is now: 
framework+applications+specialpupose; if you checkout the trunk you will get 
everything as it is now
* however all the specialpupose components will be disabled by default; 
building the project will not build them, running tests will not run the tests 
on them etc...

+1

* we will provide easy mechanisms (ant scripts/settings or similar) to enable 
specialpurpose components; in this way developers interested in testing/working 
on some specialpurpose components will have an easy way to do this

+1

* the official releases (and release branches) will not contain the 
specialpurpose folder

+1

* we could release specialpurpose components separately (OFBiz Extra 1.0, 2.0, 3.0 etc...) if 
there is interest; we could even release individual components if there is interest (OFBiz Extra - POS 
1.0, OFBiz Extra - Birt 1.0)

+1

* key point: it will be acceptable to commit code to improve OFBiz even if it 
breaks some of the specialpurpose components: e.g. API changes, jar updates 
(duplicated of jars in some specialpurpose components) etc...

+1
maybe it will be necessary in future to decide how to process when a 
component in specialpurpose has junit and selenium test for all functions


The last point is the most important because with it we will reach some 
important goals that could alleviate the tension/conflicts we had in the past 
while discussing topics about what should go in OFBiz and what not:
a) committers will have a core set of common, generic and more frequently used 
components (framework/applications) to focus on; it will be easier to maintain 
a smaller codebase and this will speed up the evolution of OFBiz; it will also 
remove a lot of burden in the release management because we will have less 
external dependencies to look for for vulnerability reports; for example, if a 
vulnerability report is reported by the Birt community, and we are distributing 
the Birt jars in our releases, in the current situation we would be forced to 
issue a new release (as a side note, I am not even sure if we are keeping an 
eye on vulnerability reports from all the projects we have pulled jars from)

+1

b) committers interested in keeping up-to-date some of the specialpurpose 
components could easily update the code and commit it; over time we will see 
what are the specialpurpose components that are actively maintained (and we 
could issue releases for them) and what are the components that are not (and we 
could discuss if it is worth of keeping them in the trunk or not, but they will 
not cause any major issues even if they stay there)

+1


Some clarifications:
* we may want to review over time the list of components currently under 
specialpurpose; if there is a general consensus in the direction of keeping a 
few of them in the releases then we could keep them enabled and include them in 
branches
* we will have to change something in the way we build the classpath in ant in 
order to include jars and build the component only if the component is enabled; 
it should not be difficult to achieve but this is important because it will 
allow us to have potentially conflicting jars in the framework/applications and 
specialpurpose

+1


As a roadmap, we could try to implement this approach before the next cut of 
the 13.04 release branch (in April 2013): that branch could be the first one 
without the specialpurpose components.

What do you think?

Completely agree
even if I would have liked a little note on the notion addon (smaller 
than a component) :-)


Jacopo

On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:


Yes thanks!

Jacques

From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com

On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:


I even wonder if Jacopo did not make a more recent (and flexible) proposition 
with which I totaly agreed (during fall, it seems to me but, I can't find it), 
Jacopo?

Do you mean the following?


BTW, some time ago I also proposed an alternative path: see email with subject 
[PROPOSAL] from specialpurpose to extras: to that I can add that we could 
provide two set of ant scripts, one similar to the one we have that builds/tests 
everything (framework+applications+specialpurpose) and one (the default) that only 
builds/tests the framework+applications; the release branches may only contain the 
framework+applications and separate releases of specialpurpose applications could be 
voted/released at different time. This approach may reach two goals:
1) slim down the main code that the community is more focused to 
improve/maintain/release
2) keep under the OFBiz community the ownership of all the other specialpurpose 
components; if one of them will get more attention and interest and could grow 
in 

Re: OFBIZ-4872: webdriver integration

[Olivier Heintz]

Le 06/12/2012 16:40, Erwan de FERRIERES a écrit :
 2012/12/6 Jacques Le Roux jacques.le.r...@les7arts.com

 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 On Dec 5, 2012, at 2:54 PM, Jacques Le Roux wrote:
  ../..
 All that said, I want to clarify that I am not feeling any pressure and

 Sure but what is refraining you for web driver? More that you feel there
 is no needs than code quality, right? So you will see it more in Extras?
 What others think about it? Are you interested?

 I don't think this could be moved to extras, but this is more a framework
 addition. The integration that has been done is designed to be fully
 integrated with OFBiz and part of the framework.
 It's not a standalone component. It's like you would remove the testtools
 from framework, this would have no sense at all.
I think, there are multiple questions about webdriver integration :
1) Is it necessary to have a UI test process integrated in OFBiz ?
2) is it time to integrate a UI test tools in OFBiz ?
3) is webdriver is a good tools for web UI test ?
4) is the webdriver integration proposed is correct ?

Of course, answer can be simple like yes or no
OR maybe the wording of the question is not correct and it's necessary
to reformulate.

Trying to help discussion, NOT TO hide some part of it or constrain
someone to say something.

Re: OFBIZ-4872: webdriver integration

[Olivier Heintz]

Le 06/12/2012 17:20, Jacques Le Roux a écrit :
 From: Scott Gray scott.g...@hotwaxmedia.com
 On 7/12/2012, at 12:43 AM, Jacopo Cappellato wrote:

 On Dec 6, 2012, at 12:29 PM, Olivier Heintz wrote:

 If I correctly understand the commiter groups roles, it's to coordinate,
 animate and help the community to enhance (technically, functions,
 quality, ...) the project, not to force or constrain to work only on a
 short list of subject.
 Correct, and no one is *forcing* anyone (again, please help to keep the 
 conversation relaxed): the committer group is helping to show some of the 
 priorities of the project but anyone is free to work on different tasks; 
 but of course this doesn't necessarily mean that the committers will have 
 to make it part of the project even if they do not think it is a good fit 
 (here I am talking in general, not on this specific topic).

 Erwan works on software quality from a long time and it's not its first
 contributions on this subject. I don't understand why he should wait
 someone ask him to work on it.
 See above (of course Erwan is free to work on what he wants but if he wants 
 to commit it to OFBiz and there are concerns in the committer group they 
 have to be addressed).

 Jacopo

 One thing I'm starting to get tired of is contributors (and committers) 
 beginning major works without a thorough discussion about the suitability of 
 the work for OFBiz before starting.  I find it frustrating that reviewers 
 are then forced to review under some sort of urgency because it is ready to 
 commit and also made to feel like the contributor's time has been wasted if 
 there are any major issues/disagreements with the design decisions made in 
 the work.
 I agree Scott, this is a *strong* argument! But I fear we can't expect all 
 new comers to know this rule if we don't make it more explicit somewhere, 
 near the root of documentation for instance?

 Also if I remember well Erwan worked on webdriver for a long time already. It 
 was even part of a Google summer code effort, IIRW. And Erwan interacted with 
 the community, so it's not new to us, right? It's easy to jump on it 
 afterward and criticize.
 The addons for Apache OFBiz extras is another topic, where indeed you are 
 totally right. Like the new webhelp which will certainly sadly be put aside 
 now, since Tom deceased.
I don't want to say all I do is correct, but for  ofbiz addon
1) I have start by a situation status  on my mail OFBiz Plugin
Management, status and propositions  18th March
2) as proposed by Jacopo, work in OFBiz extra to be able to prepare
ready to use tools to help ofbiz community testing it and doing remarks
on bad and good point;
3) prepare a track on ApacheCon to explain how to use it and to meet
other ofbiz community member
4) nicolas continue to help by writing a short howto

I understand everybody is overbooking by its own customer project, but
we really try to follow PMC and commiter advices to present contributions
  
 In regards to Jacques, I also find it frustrating that he encourages and 
 actively participates in this behavior without actually really performing 
 much in the way of design review other than a generic does it seem like a 
 good feature? test.
 There are 3 points we are/were mostly discussing at the moment
you forgot portletWidget in the list,
a large point too, with a lot of job to facilitate review : jira,
sub-jira for each technical point, usage of example component, usage for
party component to be more explicit, detail documentations include in
ofbiz help, ...
 1) Neogia Addons
 2) New Webhelp
 3) Webdriver 
solr implementation is an other subject with a wonderful detail Jira
 Unfortunately 2 is out of scope for the moment :/ And Yes I thought Tom was 
 doing a great job and I did not see any real pragmatic alternatives nor see 
 any in a mid term, apart some rants and advices... And I did design review 
 and even much hours of work, mind you.

 I did not encourage 1 and 3 in any manners before they were proposed to the 
 community, just wrote a line here and there about addons. They seems the only 
 *ready* solution we have to better handle not only components but also inside 
 components code plugin. They are also a perfect fit for Extras. I began to 
 give some feedbacks to the Noegia team, design review here is a bit more 
 involved, I guess you know that...

 And yes I find all 3 of them good for OFBiz, should I been chastised? It 
 seems you think so :)
One more time, nobody search to find who is bad or who is good.
I'm just disappointed that with 25 commiters, there is not enough time
for review. It's not a blame, it's only a fact and we should do with it.

I try to contribute on the correct way and to help to enhance the
contribution process.
 Don't get me wrong, encouraging contributors to contribute is a great thing 
 and Jacques does an amazing job interacting with the community as a whole 
 but whenever a major work is undertaken without prior discussion

Re: OFBIZ-4872: webdriver integration

[Olivier Heintz]

Le 05/12/2012 11:29, Jacopo Cappellato a écrit :
 On Dec 5, 2012, at 8:54 AM, Jacques Le Roux wrote:

 Note: I intentionally used the verb reject, because it seems it how some 
 contributors are now feeling the way the OFBiz project is doing with their 
 proposed contributions
 I understand that this feeling could indeed happen but unfortunately it is 
 a side effect of the most important goal that is to make sure that the OFBiz 
 codebase is consistent, maintainable by the community and its quality is high.
And so, having clear rules and process describing how to do.
 It is in our role of committers and PMC members to do our best to explain 
 this to the contributors, 
When you see all answers Jacques do to users or contributors, he always
explains and argues with mail or code. So attack him on this subject
seems inappropriate.
 rather than trying to induce them to think that there are some evil guys that 
 feel pleasure in rejecting other's great ideas.

 Jacopo

Re: OFBIZ-4872: webdriver integration

[Olivier Heintz]

Le 05/12/2012 11:52, Jacopo Cappellato a écrit :
 On Dec 5, 2012, at 8:54 AM, Jacques Le Roux wrote:

 Sounds indeed logical to have embedded a mean to test the UI available to 
 all user OOTB.
 Why embedded? All users already have a mechanism to test the UI:
test the UI is one of the important quality criteria, so it would seem
important to have UI test on OFBiz for OFBiz standard UI. So code for
one  tool.
  they can use Selenium or any other similar tool of their preference.
To help contribution and share, it seem important to have, at least, one
tool as default. The goal is not the other tools are bad, but to help
collaboration.
  We should not 

 Even if  not all users will use it, some have already their own way.
 The way I see it is that no one in the project community (nor from the 
 committer groups) asked for this implementation 
If I correctly understand the commiter groups roles, it's to coordinate,
animate and help the community to enhance (technically, functions,
quality, ...) the project, not to force or constrain to work only on a
short list of subject.

Erwan works on software quality from a long time and it's not its first
contributions on this subject. I don't understand why he should wait
someone ask him to work on it.
 and very few ones showed interest for this.
 Who is using it in this community? Jacques, did you test it and are you using 
 it?

 Regards,

 Jacopo

Re: OFBIZ-4872: webdriver integration

[Olivier Heintz]

Le 06/12/2012 08:07, Jacopo Cappellato a écrit :
 On Dec 5, 2012, at 2:54 PM, Jacques Le Roux wrote:

 I must say I don't. The Neogia team is. And they are an important part of 
 the OFBiz ecosystem. Their efforts should not be neglected. Erwan is no 
 longer part of the Neogia team but he is still in contact with them. At 
 least AFAIK...
 This is an interesting point: the Neogia team (company? community?) is 
 important as any other contributor; however they are a separate ecosystem 
 that a long time ago decided to split from OFBiz and develop their own 
 software, best practices, tools etc.. at the point that now the OFBiz 
 community and the Neogia community may have choosen quite different tools and 
 best practices;
The number of difference are not so big. and one of our (OFBiz and
Neogia) biggest common denominator is our commitment to help Apache
OFBiz Project and Its community, even it's not by the same way.
  of course the members of the Neogia team think that what they do is the 
 right way and the same happens to the members of the OFBiz community;  if the 
 Neogia community now wants to share some of their tools or best practices 
 they can offer them,
share to ofbiz has always been a desire on our part but
- on one hand sometime there are licensing constraints (we use GPL
libraries)
- and other hand a large lack of communication on our part
  but we, as the OFBiz community, should not feel any pressure to endorse 
 them; and the fact that all the members of the Neogia team agree that the 
 tools are important is irrelevant (of course they do, if not they would have 
 changed them).

 All that said, I want to clarify that I am not feeling any pressure and no 
 one at Neogia tried to put pressure on me so I am good and I appreciate their 
 efforts in sharing with us what they are doing; in the same time I will not 
 feel bad if I don't think they are a good fit for the OFBiz project (and the 
 fact that I, or we,  and them could be in disagreement on some topics is 
 quite natural as we come from two different ecosystems that voluntarily 
 separated from each other).
We (me most of the time) are trying to have better communication since
one year and we really try to argue on ideas and requirement and not to
impose our existing tools or our choices.
 Kind regards,

 Jacopo
Olivier for Neogia Team

Re: Cleaning up the OFBiz Confluence spaces

[Olivier Heintz]

Le 20/11/2012 19:26, Jacques Le Roux a écrit :
 From: Jacopo Cappellato jacopo.cappell...@gmail.com
 Hi all,

 we all are aware of the problems affecting our content in Confluence but 
 before we discuss the next steps and evaluate different options and their 
 pros and cons, in my opinion it would make sense to aggregate all the 5 
 spaces into 2. This would give us a rather easy and actionable plan that 
 should improve the current situation (less spaces to administer etc...).

 Currently we have the following Confluence spaces:

 Public Wiki
 End-User Documentation
 Technical Documentation
 Requirements and Designs
 Project Administration

 Because of a series of problems (lack of contributions and technical issues 
 with the Confluence instance offered by the ASF) the initial plan was not 
 very successful and we now have some spaces that are not used much and some 
 overlapping and confusion on the content of each.
 For this reason I am proposing the following change:

 1) copy the content from:

 End-User Documentation
 Technical Documentation
 Requirements and Designs

 to Public Wiki

 2) remove the spaces:

 End-User Documentation
 Technical Documentation
 Requirements and Designs

 3) keep the Project Administration space as is for now (where write access 
 is granted only to committers): we could then consider the migration to the 
 new ASF CMS technology starting from this space (if possible); if we are 
 happy and it works well we could plan on migrating the static html files of 
 our site to it too as a second step.

 The end result would be:

 * OFBiz website: html pages or ASF CMS
 * Project Administration: Confluence space or ASF CMS
 * Public Wiki: Confluence space

 What do you think?

 Jacopo
 The plans sounds good to me. I'm constantly  watching changes in wiki, so 
 it's not an issue for me to get the non admin parts open. For the rest (ASF 
 CMS) the future will tell...

 Jacques
Who is able to realize this plan ? or who has planned to realize it ?
Is it possible to help ?

[jira] [Commented] (OFBIZ-5077) apache-ofbiz-getting-started wiki page migration to static

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508640#comment-13508640
 ] 

Olivier Heintz commented on OFBIZ-5077:
---

Bump...

To be sure to not forget, Just a sentence on top of page
I think it's important to add comment on wiki page which have been migrate

 apache-ofbiz-getting-started wiki page migration to static
 --

 Key: OFBIZ-5077
 URL: https://issues.apache.org/jira/browse/OFBIZ-5077
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: apache-ofbiz-getting-started.html, 
 apache-ofbiz-getting-started.html, OFBIZ-5077.patch


 Migration done by creating the new page by copy-paste from index.html and 
 change main content.
 I have choose to use the sidebar to not have link to mailing list or source 
 repository in the main content.
 I have remove in the sidebar the DemoSites part to avoid update maintenance 
 each time a new release is published.
 For the link at the beginning for the ofbiz-getting-started page, I have 
 tried to show clearly it's link to the wiki site.
 Say me if yes or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5091) OFbiz Source repository and access wiki page migration to html

[Olivier Heintz (JIRA)]

Olivier Heintz created OFBIZ-5091:
-

 Summary: OFbiz Source repository and access wiki page migration to 
html
 Key: OFBIZ-5091
 URL: https://issues.apache.org/jira/browse/OFBIZ-5091
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Priority: Minor


I have used mailing-lists.html as a template.
All content of wiki page is migrated.
I have group all Gest Access (svn, webdav, Website) and after committer access

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5091) OFbiz Source repository and access wiki page migration to html

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5091:
--

Attachment: OFBIZ-5091.patch
information.gif
check.gif
ofbiz-source.html

 OFbiz Source repository and access wiki page migration to html
 --

 Key: OFBIZ-5091
 URL: https://issues.apache.org/jira/browse/OFBIZ-5091
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Priority: Minor
 Attachments: check.gif, information.gif, OFBIZ-5091.patch, 
 ofbiz-source.html


 I have used mailing-lists.html as a template.
 All content of wiki page is migrated.
 I have group all Gest Access (svn, webdav, Website) and after committer access

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5087) Mailing-list migration from wiki to html page

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508927#comment-13508927
 ] 

Olivier Heintz commented on OFBIZ-5087:
---

I think it's important to add comment on wiki page to say this page have been 
migrate.

To be sure to not forget, Just a sentence on top of page


 Mailing-list migration from wiki to html page
 -

 Key: OFBIZ-5087
 URL: https://issues.apache.org/jira/browse/OFBIZ-5087
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: documentation-searchingWiki.patch, mailing-list.html


 I have used apache-ofbiz-project-overview.html as a template.
 All content of wiki page is migrated except
 searching in wiki. I have migrated this part to the documentation html page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5078) apache-ofbiz-project-overview migration from wiki to website

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508929#comment-13508929
 ] 

Olivier Heintz commented on OFBIZ-5078:
---

Bump...

To be sure to not forget, Just a sentence on top of page
I think it's important to add comment on wiki page which have been migrate


 apache-ofbiz-project-overview migration from wiki to website
 

 Key: OFBIZ-5078
 URL: https://issues.apache.org/jira/browse/OFBIZ-5078
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: apache-ofbiz-project-overview.html, 
 apache-ofbiz-project-overview.html, OFBIZ-5078.patch


 Created by copied html source of wiki page.
 Comment the workflow deprecated part.
 Add in the beginning page a override style defintion coming from download 
 htlm page to have a correct width page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: New OFBiz webhelp - OFBIZ-4941

[Olivier Heintz]

I have tested the new OFBIz webhelp for the last 3 weeks and migrated
some help we already have (for projectmgr)

On a end user perspective, webhelp is clearly an enhancement, because
search and glossary (and better presentation) help to find the correct
information more quickly.
On a help writer perspective, docbook file structure is easier to
understand that dataresource - content - contentAssoc - ...

There are still some minors problems, but in each case I have found
(with Tom help sometime) how to solve it.

I'm waiting a first release is publish to trunk to send jira with these
enhancements.

User Help is one of the software quality criteria and webhelp will help
ofbiz community to have better one.
Tools is not everything, but it's a good step to motivate the community
to contribute in this area.


Le 28/11/2012 19:22, Jacques Le Roux a écrit :
 Bump ?

 Jacques

 Jacques Le Roux wrote:
 Yes no problems. Depending on what you are starting from, you will need to 
 add binaries files (from my last patch) or not (Tom's
 zips) but with zips you might get some issues, already blurred in my mind. 

 Thanks

 Jacques

 From: Scott Gray scott.g...@hotwaxmedia.com
 It's been all of 3 days since I asked you to wait for a thorough review, 
 has that happened yet or will you just keep asking
 until no one can be bothered asking you to wait any longer?  Patience is a 
 virtue Jacques, the project has gone over 10 years
 without this feature and I don't think a few days/weeks/months will hurt 
 any, especially considering the next release branch
 isn't due to be created for quite some time.   

 Regards
 Scott

 On 19/11/2012, at 8:41 AM, Jacques Le Roux wrote:

 Hi,

 We (Tom and I) are ready to commit the new help (webhelp - OFBIZ-4941) in 
 the content component where all work for us, and will
 be completed by Tom as he suggested. There are some trivial Birt issues 
 which will dissapear when the process will be
 completed, see my last comment. 

 Is it ok to commit as is and to improve later? Mostly we want to move 
 webhelp outside of the content component in a new, to
 stay OOTB, specialpurpose webehlp component. Or do you want this addressed 
 before? Note that if you want this addressed now we
 expect a rapid help from those who want that... 

 Thanks

 Jacques

[jira] [Commented] (OFBIZ-5073) My Portal Preferences error

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507455#comment-13507455
 ] 

Olivier Heintz commented on OFBIZ-5073:
---

After 2 hours :-( find the reason and maybe a solution
solution proposed :
{code}
+++ framework/widget/src/org/ofbiz/widget/WidgetWorker.java (copie de 
travail)
@@ -289,7 +289,7 @@
 writer.append(key);
 writer.append(\ value=\);
 
-String valueFromContext = context.containsKey(key) ?
+String valueFromContext = context.containsKey(key)  
context.get(key)!= null ?
 context.get(key).toString() : parameter.getValue();
 writer.append(valueFromContext);
 writer.append(\ type=\hidden\/);
{code}

the problem is visible on ListPortalPages, which list all 
portalPage-GenericValue for one parentportalPageId received in parameters.

parentPortalPageId is a field of PortalPage-GenericValue, so context contain 
parentPortalPageid as genericValue field and in this case value is null.

I don't understand the previous patch done @Rev1392766 about OFBIZ-2628 :
{code}
-writer.append(parameter.getValue());
+
+String valueFromContext = context.containsKey(key) ?
+context.get(key).toString() : parameter.getValue();
+writer.append(valueFromContext);
{code}
because with the @Rev1392766 patch, value will be genericValue.field and not 
the from-field form.

The solution I propose works in the ListPortalPages list, but in some other 
case @Rev1392766 patch (even with my correction) with generate wrong value.

 My Portal Preferences error
 ---

 Key: OFBIZ-5073
 URL: https://issues.apache.org/jira/browse/OFBIZ-5073
 Project: OFBiz
  Issue Type: Bug
  Components: framework
 Environment: demo site https://demo-stable.ofbiz.apache.org/myportal
Reporter: Naofumi Fukue

 Select My Portal  Preferences, displays bellow error.
 org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
 [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
 java.lang.NullPointerException (null)
 Reverting org/ofbiz/widget/WidgetWorker.java previous latest OFBIZ-2628 bug 
 fix, then the problem recovered.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5073) My Portal Preferences error

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5073:
--

Attachment: OFBIZ-5073.patch

 My Portal Preferences error
 ---

 Key: OFBIZ-5073
 URL: https://issues.apache.org/jira/browse/OFBIZ-5073
 Project: OFBiz
  Issue Type: Bug
  Components: framework
 Environment: demo site https://demo-stable.ofbiz.apache.org/myportal
Reporter: Naofumi Fukue
 Attachments: OFBIZ-5073.patch


 Select My Portal  Preferences, displays bellow error.
 org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
 [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
 java.lang.NullPointerException (null)
 Reverting org/ofbiz/widget/WidgetWorker.java previous latest OFBIZ-2628 bug 
 fix, then the problem recovered.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5088) Remove GenericPortlet from OFBiz

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5088:
--

Attachment: OFBIZ-5088.patch

on previous patch, I have forgot to remove a form

 Remove GenericPortlet from OFBiz
 

 Key: OFBIZ-5088
 URL: https://issues.apache.org/jira/browse/OFBIZ-5088
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Olivier Heintz
Priority: Minor
 Attachments: OFBIZ-5088.patch, OFBIZ-5088.patch, OFBIZ-5088.patch


 GenericPortlet are some portlet ready to use, working with attributes 
 (parameters) to give formName, menuName, ...
 It's currently not used in ofbiz and with portletWidget it is no more 
 necessary because now it's very simple to define a simple portlet and it's 
 more clear that having formName as a attribute.
 Generic portlet was the first test to simplify using portlet in ofbiz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OFBIZ-5088) Remove GenericPortlet from OFBiz

[Olivier Heintz (JIRA)]

Olivier Heintz created OFBIZ-5088:
-

 Summary: Remove GenericPortlet from OFBiz
 Key: OFBIZ-5088
 URL: https://issues.apache.org/jira/browse/OFBIZ-5088
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Olivier Heintz
Priority: Minor


GenericPortlet are some portlet ready to use, working with attributes 
(parameters) to give formName, menuName, ...
It's currently not used in ofbiz and with portletWidget it is no more necessary 
because now it's very simple to define a simple portlet and it's more clear 
that having formName as a attribute.

Generic portlet was the first test to simplify using portlet in ofbiz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5088) Remove GenericPortlet from OFBiz

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5088:
--

Attachment: OFBIZ-5088.patch

 Remove GenericPortlet from OFBiz
 

 Key: OFBIZ-5088
 URL: https://issues.apache.org/jira/browse/OFBIZ-5088
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Olivier Heintz
Priority: Minor
 Attachments: OFBIZ-5088.patch


 GenericPortlet are some portlet ready to use, working with attributes 
 (parameters) to give formName, menuName, ...
 It's currently not used in ofbiz and with portletWidget it is no more 
 necessary because now it's very simple to define a simple portlet and it's 
 more clear that having formName as a attribute.
 Generic portlet was the first test to simplify using portlet in ofbiz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5088) Remove GenericPortlet from OFBiz

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5088:
--

Attachment: OFBIZ-5088.patch

on previous patch I have forgot to remove refreshPortlet on 
portal-controller.xml and so replace refreshPortlet by showPortlet in party

 Remove GenericPortlet from OFBiz
 

 Key: OFBIZ-5088
 URL: https://issues.apache.org/jira/browse/OFBIZ-5088
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Olivier Heintz
Priority: Minor
 Attachments: OFBIZ-5088.patch, OFBIZ-5088.patch


 GenericPortlet are some portlet ready to use, working with attributes 
 (parameters) to give formName, menuName, ...
 It's currently not used in ofbiz and with portletWidget it is no more 
 necessary because now it's very simple to define a simple portlet and it's 
 more clear that having formName as a attribute.
 Generic portlet was the first test to simplify using portlet in ofbiz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5077) apache-ofbiz-getting-started wiki page migration to static

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504731#comment-13504731
 ] 

Olivier Heintz commented on OFBIZ-5077:
---

I wanted to add a comment in the wiki Page to explain this page is now manage 
on ofbiz website
But I'm not authorized.

If a committer can add a comment it will be great.

 apache-ofbiz-getting-started wiki page migration to static
 --

 Key: OFBIZ-5077
 URL: https://issues.apache.org/jira/browse/OFBIZ-5077
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: apache-ofbiz-getting-started.html, 
 apache-ofbiz-getting-started.html, OFBIZ-5077.patch


 Migration done by creating the new page by copy-paste from index.html and 
 change main content.
 I have choose to use the sidebar to not have link to mailing list or source 
 repository in the main content.
 I have remove in the sidebar the DemoSites part to avoid update maintenance 
 each time a new release is published.
 For the link at the beginning for the ofbiz-getting-started page, I have 
 tried to show clearly it's link to the wiki site.
 Say me if yes or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5078) apache-ofbiz-project-overview migration from wiki to website

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504733#comment-13504733
 ] 

Olivier Heintz commented on OFBIZ-5078:
---

I wanted to add a comment in the wiki Page to explain this page is now manage 
on ofbiz website
But I'm not authorized.

If a committer can add a comment it will be great.


 apache-ofbiz-project-overview migration from wiki to website
 

 Key: OFBIZ-5078
 URL: https://issues.apache.org/jira/browse/OFBIZ-5078
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: apache-ofbiz-project-overview.html, 
 apache-ofbiz-project-overview.html, OFBIZ-5078.patch


 Created by copied html source of wiki page.
 Comment the workflow deprecated part.
 Add in the beginning page a override style defintion coming from download 
 htlm page to have a correct width page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Important: OFBiz website update required before the end of the year

[Olivier Heintz]

Le 26/11/2012 16:59, Jacopo Cappellato a écrit :
 Here is an update on this effort.
 In rev. 1413687 I have committed a series of changes to the website; here is 
 the commit log:

 ===
 First pass in the last step of the removal of automatically generated pages 
 from Confluence from the OFBiz website:

 * moved a bunch of links to Confluence-based documents from the index.html 
 page to the documentation.html page where it is clearly mentioned that they 
 refer to the Wiki
 * several links to Confluence-based pages now open the page in a new browser 
 tab: this should help the user understand what is from the site and what is 
 from Confluence
 * removed the Confluence search box from the header and moved to the 
 documentation.html page where it is clearly stated that it is a form for Wiki 
 searches
 * converted two Confluence-based documents (Getting Started and Project 
 Overview) to static html pages; thanks to Olivier Heintz for the 
 contribution (OFBIZ-5077, OFBIZ-5078); this commit contains a slightly 
 modified version of the work contributed by Olivier;
 * the new documents are now children of the main documentation.html page
 * cleaned up and improved page title/ elements
 * fixed some formatting
 ===

 I apologize for the big commit but this first step was difficult to do in 
 small chunks because there was a need for some structure before moving 
 things around; now we have a simple one and it should be easier to complete 
 the work.
 However I did my best to not change the content of the website and I did my 
 best to add the bare minimum of new content required to glue the 
 documentation.html page together; please review what I did and let me know if 
 you see something wrong. All the main new content is in the 2 new pages that 
 contain the text migrated by Olivier from Confluence.

 Now the next steps should be:

 1) remove the features tab from the top bar and add a link to the main new 
 features document to the document.html page
maybe features tab should go to the Project Overview page
 2) convert the following two pages to static html:
 https://cwiki.apache.org/OFBADMIN/mailing-lists.html
I will do it
 https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html
 3) remove some of the right bar links from the index.html and move the ones 
 we need to the documentation.html page

 The above tasks should be enough for what we have to complete by the end of 
 the year.

 Kind regards,

 Jacopo

[jira] [Created] (OFBIZ-5087) Mailing-list migration from wiki to html page

[Olivier Heintz (JIRA)]

Olivier Heintz created OFBIZ-5087:
-

 Summary: Mailing-list migration from wiki to html page
 Key: OFBIZ-5087
 URL: https://issues.apache.org/jira/browse/OFBIZ-5087
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Priority: Minor


I have used apache-ofbiz-project-overview.html as a template.
All content of wiki page is migrated except
searching in wiki. I have migrated this part to the documentation html page


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-5087) Mailing-list migration from wiki to html page

[Olivier Heintz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Heintz updated OFBIZ-5087:
--

Attachment: documentation-searchingWiki.patch
mailing-list.html

 Mailing-list migration from wiki to html page
 -

 Key: OFBIZ-5087
 URL: https://issues.apache.org/jira/browse/OFBIZ-5087
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Priority: Minor
 Attachments: documentation-searchingWiki.patch, mailing-list.html


 I have used apache-ofbiz-project-overview.html as a template.
 All content of wiki page is migrated except
 searching in wiki. I have migrated this part to the documentation html page

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4768) Improvement for flatgrey theme

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504874#comment-13504874
 ] 

Olivier Heintz commented on OFBIZ-4768:
---

Wai,

I have used this Jira and its patch to create two addon on ofbizextra-addons-dev
- flatgrey-update2variation : apply your patch to the flatgrey theme
- theme-flatgreyvariation : add a new theme flatgreyvariation which is the 
flatgrey theme with your patch applied.

regards,
Olivier


 Improvement for flatgrey theme
 --

 Key: OFBIZ-4768
 URL: https://issues.apache.org/jira/browse/OFBIZ-4768
 Project: OFBiz
  Issue Type: Improvement
  Components: themes
Reporter: Wai
Priority: Trivial
 Attachments: after-sample-catalogmgr1.png, 
 after-sample-catalogmgr1.png, after-sample-catalogmgr2.png, 
 after-sample-catalogmgr2.png, after-sample-partymgr.png, 
 after-sample-partymgr.png, after-sample-webtools.png, 
 after-sample-webtools.png, before-sample-catalogmgr1.png, 
 before-sample-catalogmgr2.png, before-sample-partymgr.png, 
 before-sample-webtools.png, flatgray-images.tar.gz, ofbiz-4768.patch, 
 ofbiz-4768.patch, ofbiz-style1.patch, ofbiz-style1.patch, ofbiz-style2.patch, 
 ofbiz-style2.patch


 Improvement to flatgrey theme.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5077) apache-ofbiz-getting-started wiki page migration to static

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502696#comment-13502696
 ] 

Olivier Heintz commented on OFBIZ-5077:
---

Good remark,
Maybe added a Langage menu in the page, when someone have migrate the Chinese 
version

We can choose this way for the existing ofbiz website page with a transalated 
version.
Before migrate to the Apache CMS, we should not have a large number of pages.

 apache-ofbiz-getting-started wiki page migration to static
 --

 Key: OFBIZ-5077
 URL: https://issues.apache.org/jira/browse/OFBIZ-5077
 Project: OFBiz
  Issue Type: Improvement
Reporter: Olivier Heintz
Assignee: Jacopo Cappellato
Priority: Minor
 Attachments: apache-ofbiz-getting-started.html, 
 apache-ofbiz-getting-started.html, OFBIZ-5077.patch


 Migration done by creating the new page by copy-paste from index.html and 
 change main content.
 I have choose to use the sidebar to not have link to mailing list or source 
 repository in the main content.
 I have remove in the sidebar the DemoSites part to avoid update maintenance 
 each time a new release is published.
 For the link at the beginning for the ofbiz-getting-started page, I have 
 tried to show clearly it's link to the wiki site.
 Say me if yes or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-5073) My Portal Preferences error

[Olivier Heintz (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502718#comment-13502718
 ] 

Olivier Heintz commented on OFBIZ-5073:
---

After reading commit Trunk @Rev1392766 about OFBIZ-2628, I do not saw a 
relation with portal.
So I have make correction at the screen / form level
before in Form
{code}
field name=portalPageId title=${uiLabelMap.CommonEdit}
hyperlink description=${uiLabelMap.CommonEdit} 
target=ManagePortalPages
parameter param-name=portalPageId/
parameter param-name=parentPortalPageId 
from-field=parameters.parentPortalPageId/
/hyperlink
/field
{code}

and I have as result in the web browser
the error message and in source
{code}
input name=parentPortalPageId value= html head titleOpen For Business 
Message/title meta http-equiv=
{code}

After, I have added in action part of screen
{code}
set field=parentPortalPageId 
from-field=parameters.parentPortalPageId/
{code}
and in Form, i have changed
{code}
field name=portalPageId title=${uiLabelMap.CommonEdit}
hyperlink description=${uiLabelMap.CommonEdit} 
target=ManagePortalPages
parameter param-name=portalPageId/
parameter param-name=parentPortalPageId/
/hyperlink
/field
{code}

And now, all is fine.

I not understand why the initial solution not works (but I not understand the 
content of @Rev1392766 commit, it's too technic for me ).

Hoping that it helps to find the proper correction.


 My Portal Preferences error
 ---

 Key: OFBIZ-5073
 URL: https://issues.apache.org/jira/browse/OFBIZ-5073
 Project: OFBiz
  Issue Type: Bug
  Components: framework
 Environment: demo site https://demo-stable.ofbiz.apache.org/myportal
Reporter: Naofumi Fukue

 Select My Portal  Preferences, displays bellow error.
 org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen 
 [component://common/widget/CommonScreens.xml#GlobalDecorator]: 
 java.lang.NullPointerException (null)
 Reverting org/ofbiz/widget/WidgetWorker.java previous latest OFBIZ-2628 bug 
 fix, then the problem recovered.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira