Re: [DISCUSSION] Improving the OFBiz User Interface

[Jacques Le Roux]

Hi Julien,

Just few questions inline


Le 29/11/2016 à 23:35, Julien NICOLAS a écrit :

Hi Sharan, everyone,

It was idea like seed that start to grow up in my mind since I start with OFBiz. Today, after several try on the project I think the community is 
very closed to find the best way to improve the UI.


The first sharing was with Gil and Nicolas, then we decide to submit a talk about that. The big surprise was that Taher have the quite same ideas 
than us !!!


There are many things that must be done to have a good UI.

 - All the UI could be managed by the theme without modifying the framework.

 - Each screen must be linked to a screen structure.


What would be this screen structure? You don't need to develop much at this 
stage, just that I can't vision what it would be.



 - We need a UI standard that the developer need to follow for screen creation.

 - We must have a common theme (remove all theming stuff from the framework)

 - It could be interesting to have a new component to improve / test a new theme

 - We have to create at least a new theme without limits ! Be crazy !

It's a long term project, but it must be our concern, all the people that want a beautiful and UX UI must be involved \o/ I remember when I start 
bootstrap topics, that we were many ;)


This project is more ambitious, a long term one that will improve the theming automatism to provide to the webdesigner an unlimited tool and, in the 
same time, an easy to maintain framework for us ;)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too heavy. Then I was thinking that I have to improve the UI to provide a best 
one. After several try I understand that the actual UI is not a final user interface. It is a developer one. It's a developer UI because it contain 
all the features developed. But definitively, we can't provide this kind of UI to final users, we have to simplify it. In the same times, we can't 
delete the current UI because developers need to improve it with new features that will help us to deploy new features to our final users.


For this new component, we can implement an existing component but simplified 
and ready for the new theme(s).


You mean we could take and existing component, say example for instance, and would simply it at the UI level. I picked example because it's already 
rather simple and contains demonstration of features.




In conclusion, if the new component dedicated for test a new theme match to the community needs, Taher think to a super simplified developer user 
interface that facilitate developers to improve the software. A new interface without any constraint that allow developers to develop easily new 
features.




Another thing I can't vision at this stage, no hurry, I guess I'll later :)

All the rest is OK with me, or at least I think I did grab the ideas

Thanks!

Jacques



What about the new theme ?

A new theme, maybe more than one theme. It could be crazy but if we need to be sure that we can do anything we want and that the screen structure 
allow webdesigner to do whatever we want, we can imagine 2 new themes exactly different in structure :)


I have at least an idea, just for the look and feel. I can share it and we can improve it all together (or just scrap it and start with a new idea 
^^). In the same times, at the Apache Con we meet Victoria Bondarchuk  
(work in UX project management) that want to help us in this task, and Darshan Kumar (work also in UX) who want to join the OFBiz project starting 
on that task.



How to start ?

I propose to start by creating a main Jira about Improve the UI (maybe this one already exist since a long long time ago ^^) and then link all the 
subtasks to this main one. Maybe we can start a topic by subtask to share with the community.



Before creating anything it could be interesting to have opinion of all people who want UI changes. All the community I think, so I hope server will 
not be down because of the OFBiz community involving ^^


I hope Paul, Gaurav and all the people that try or already improve the UI will 
help on this task \o/

I want to be an actor of this changes and I hope you want it too !

Thanks for all your help in advance.

Julien.


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the 
OFBiz track at Apachecon that were about how we could improve our UI.


If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are just included as optional). What if 

Re: buildbot failure in on ofbiz-trunk

[Deepak Dixit]

I think its an false report, as  testIntegration return success on local
box.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Tue, Nov 29, 2016 at 11:47 PM,  wrote:

> The Buildbot has detected a new failure on builder ofbiz-trunk while
> building . Full details are available at:
> https://ci.apache.org/builders/ofbiz-trunk/builds/1765
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit'
> triggered this build
> Build Source Stamp: [branch ofbiz/trunk] 1771935
> Blamelist: deepak
>
> BUILD FAILED: failed shell_1
>
> Sincerely,
>  -The Buildbot
>
>
>
>

buildbot success in on ofbiz-trunk

[buildbot]

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1766

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1771995
Blamelist: paulfoxworthy

Build succeeded!

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Shi Jinghai]

Well done Olivier!

Personally, I think we should consider Hadoop in OFBiz roadmap. In the past 10 
years, I have to agree, Hadoop is the most important progress, and it's from 
Apache.

-邮件原件-
发件人: Olivier Heintz [mailto:holivier.li...@ofbizextra.org] 
发送时间: 2016年11月30日 1:33
收件人: dev@ofbiz.apache.org
主题: Re: [DISCUSSION] Defining an OFBiz Project Strategy

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: Use of utility method for checking null GenericValue

[Paul Foxworthy]

See Jira issue OFBIZ-4427 https://issues.apache.org/jira/browse/OFBIZ-4427.

Ratnesh is absolutely right. UtilValidate.isEmpty and ...isNotEmpty should
only be used in places where "emptiness" is relevant. They should not be
used when all that is needed is == null or != null .

The issue has a patch that is now quite old, and a couple of unresolved
questions.

On 24 June 2016 at 00:24, Ratnesh Upadhyay 
wrote:

> Thanks everyone for your valuable inputs on it. I'll create logical sub
> tickets to establish this practice in OFBiz.
>
> Regards,
> Ratnesh Upadhyay
> HotWax Systems | www.hotwaxsystems.com
>
> On Mon, Jun 20, 2016 at 3:04 PM, Scott Gray 
> wrote:
>
> > +1, good idea thanks Ratnesh
> >
> > Regards
> > Scott
> >
> > On 18 June 2016 at 02:30, Ratnesh Upadhyay 
> > wrote:
> >
> > > Hello community,
> > >
> > > There are lots of places in code where we have used
> > > UtilValidate.isNotEmpty() or UtilValidate.isEmpty() for GenericValue
> > object
> > > . GenericValue is never empty. Its always null or not null. So should
> we
> > > use directly null or not null check instead of
> UtilValidate.isNotEmpty()
> > > and UtilValidate.isEmpty() for GenericValue objects ?
> > >
> > > Basically these validation methods should preferably be used on Strings
> > or
> > > Lists and normal Maps.
> > >
> > > Thanks!!
> > >
> > > Regards,
> > > Ratnesh Upadhyay
> > > HotWax Systems | www.hotwaxsystems.com
> > >
> >
>



-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Re: OFBiz security issues

[Paul Foxworthy]

Hi all,

Using JIRA is a good idea, and we need to be able to find them. But a
security issue is not a subtask and not a component. I think a tag will
work fine.

Thanks

Paul


On 30 November 2016 at 00:42, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Tags or components are fine to me (you can specify more than one component
> to each ticket); I agree that a tag may be more appropriate for this use
> case. My preference is just to not use subtasks.
>
> Jacopo
>
> On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits 
> wrote:
>
> > Well...
> >
> > CVEs can occur on any component (even though past issues have been
> related
> > for most to framework components. So having a particular component just
> for
> > CVE reference purposes would complicate matters as much as converting
> JIRA
> > issues into sub-tasks.
> >
> > Applying a tag to the issue (e.g. CVE) and using a persisted filter in
> JIRA
> > would be sufficient to link to from the download page (and elsewhere e.g.
> > the 'keeping OFBiz secure' cwiki page.
> >
> > Best regards,
> >
> >
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > Rather than using subtasks I think it would be better to use a
> component
> > > (named CVE or similar).
> > >
> > > Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" <
> jacques.le.r...@les7arts.com>
> > > ha
> > > scritto:
> > >
> > > > Also it would be better if we can group all security issues in Jira.
> > For
> > > > that I created OFBIZ-1525, please if you create Jira security issues
> > > create
> > > > (or convert) them as subtasks of OFBIZ-1525
> > > >
> > > > Thanks
> > > >
> > > > Jacques
> > > >
> > > >
> > > > Le 29/11/2016 à 11:05, Pierre Smits a écrit :
> > > >
> > > >> Of course, I implied this policy to be in line with
> > > >> http://www.apache.org/security/
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Pierre Smits
> > > >>
> > > >> ORRTIZ.COM 
> > > >> OFBiz based solutions & services
> > > >>
> > > >> OFBiz Extensions Marketplace
> > > >> http://oem.ofbizci.net/oci-2/
> > > >>
> > > >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin <
> > > nicolas.ma...@nereide.fr
> > > >> >
> > > >> wrote:
> > > >>
> > > >> Yes I agree with Jacopo, when can create the issue only when they
> are
> > > >>> corrected
> > > >>>
> > > >>> Nicolas
> > > >>>
> > > >>>
> > > >>>
> > > >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :
> > > >>>
> > > >>> We can definitely create one Jira ticket for each CVE number with
> all
> > > the
> > >  details we want and link them from the "security" section of the
> > OFBiz
> > >  download page.
> > >  This was probably implied in Pierre's proposal, but I prefer to
> > >  explicitly
> > >  state here: these tickets will be created only after the CVE are
> > >  publicly
> > >  disclosed (i.e. the tickets will be created and resolved at the
> same
> > >  time).
> > >  The good news is that we can create now all the tickets for the
> CVE
> > >  processed so far in the history of OFBiz, in order to implement
> what
> > >  Pierre
> > >  has proposed here.
> > > 
> > >  Jacopo
> > > 
> > >  On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits <
> > > pierre.sm...@gmail.com>
> > >  wrote:
> > > 
> > >  Hi all,
> > > 
> > > > Recently we have seen some security issues fixed in the code base
> > > > (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated
> > in
> > > > identifying, analysing and fixing these OFBiz security threats.
> > > >
> > > > When I look at how we communicate to our adopters that there are
> > > > threats
> > > > and how they can be mitigated [1] I believe we could and we
> should
> > > do a
> > > > little bit more. There we merely put a reference to the CVE [2]
> > issue
> > > > (see
> > > > [3] for example) there and and advice to upgrade. But on that
> page
> > we
> > > > leave
> > > > out any particulars on how the issue affected OFBiz and what was
> > done
> > > > to
> > > > it. Rightly so as it is just a list of notifications.
> > > >
> > > > The details about the effect of the issue and the mitigation is
> in
> > > > commits.
> > > > But there is no apparent relation between the notification on [1]
> > and
> > > > the
> > > > actual commit that mitigated. Also reporting the CVE in JIRA
> issues
> > > not
> > > > optimal. This leads to the fact that details don't appear in
> > release
> > > > notes
> > > > very well.
> > > >
> > > > I believe we could and should do better. We should *always* have
> a
> > > JIRA
> > > > issue explaining the CVE issue and its effect on the 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

Hi Sharan, everyone,

It was idea like seed that start to grow up in my mind since I start 
with OFBiz. Today, after several try on the project I think the 
community is very closed to find the best way to improve the UI.


The first sharing was with Gil and Nicolas, then we decide to submit a 
talk about that. The big surprise was that Taher have the quite same 
ideas than us !!!


There are many things that must be done to have a good UI.

 - All the UI could be managed by the theme without modifying the 
framework.


 - Each screen must be linked to a screen structure.

 - We need a UI standard that the developer need to follow for screen 
creation.


 - We must have a common theme (remove all theming stuff from the 
framework)


 - It could be interesting to have a new component to improve / test a 
new theme


 - We have to create at least a new theme without limits ! Be crazy !

It's a long term project, but it must be our concern, all the people 
that want a beautiful and UX UI must be involved \o/ I remember when I 
start bootstrap topics, that we were many ;)


This project is more ambitious, a long term one that will improve the 
theming automatism to provide to the webdesigner an unlimited tool and, 
in the same time, an easy to maintain framework for us ;)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too 
heavy. Then I was thinking that I have to improve the UI to provide a 
best one. After several try I understand that the actual UI is not a 
final user interface. It is a developer one. It's a developer UI because 
it contain all the features developed. But definitively, we can't 
provide this kind of UI to final users, we have to simplify it. In the 
same times, we can't delete the current UI because developers need to 
improve it with new features that will help us to deploy new features to 
our final users.


For this new component, we can implement an existing component but 
simplified and ready for the new theme(s).


In conclusion, if the new component dedicated for test a new theme match 
to the community needs, Taher think to a super simplified developer user 
interface that facilitate developers to improve the software. A new 
interface without any constraint that allow developers to develop easily 
new features.



What about the new theme ?

A new theme, maybe more than one theme. It could be crazy but if we need 
to be sure that we can do anything we want and that the screen structure 
allow webdesigner to do whatever we want, we can imagine 2 new themes 
exactly different in structure :)


I have at least an idea, just for the look and feel. I can share it and 
we can improve it all together (or just scrap it and start with a new 
idea ^^). In the same times, at the Apache Con we meet Victoria 
Bondarchuk 
 
(work in UX project management) that want to help us in this task, and 
Darshan Kumar (work also in UX) who want to join the OFBiz project 
starting on that task.



How to start ?

I propose to start by creating a main Jira about Improve the UI (maybe 
this one already exist since a long long time ago ^^) and then link all 
the subtasks to this main one. Maybe we can start a topic by subtask to 
share with the community.



Before creating anything it could be interesting to have opinion of all 
people who want UI changes. All the community I think, so I hope server 
will not be down because of the OFBiz community involving ^^


I hope Paul, Gaurav and all the people that try or already improve the 
UI will help on this task \o/


I want to be an actor of this changes and I hope you want it too !

Thanks for all your help in advance.

Julien.


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was 
around the UI. In fact we had at least 2 presentations from the OFBiz track at 
Apachecon that were about how we could improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are 
just included as optional). What if we slimmed down all the screens to have a 
sensible default UI for users. The UI could also be modifiable by service 
providers. Simplify the screens with defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the UI? (a 
simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if we 

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Nicolas Malin]

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
>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

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.


Cheers,
Nicolas

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Nicolas Malin]

Hi all,

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 business automation suite.

Agree nothing to add

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
- An ERP system ready for immediate use by business owners (not geared for
end-users)
Yes the best hunting area for OFBiz is create a business application 
quickly but permanently. So we don't need to focus on your different 
point because too many project work as well on each of them
Our strong is on the business automation suite : coherence on each 
element to realize business application not to create a business 
application.


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.
Capitain ! The work is in progress, the earth is far but the sea is 
quite and the sun shine :)


First refactoring the screen engine base
Second define new best practice for screen development
Third create a tiny demo application for end user

Oh you give me an idea for the adoption. When a user download ofbiz he 
need to run a gradle target present on the documentation.

So we can add two new targets :
 * ./gradle simpleUse that enable the tiny demonstration application 
and disable all application component (for the webapp)

 * ./gradle advancedUse that enable all application component.

We just need change the documentation to :
for run ofbiz just : ./gradle simpleUse loadDefault ofbiz
If you are a developer you can do : ./gradle advancedUse loadDefault ofbiz



- 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.

dream, but it's not my strong ^^


- 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?

I wil try to follow you Taher :)

Cheers,
Nicolas


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 the 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Nicolas Malin]

Completely Paul for the standardization.

Currently we try to go out all ftl templating from framework to push on 
theme with the purpose to have only the screen logic on the framework.

All the rendering would be define and surcharge on the theme.

But standardization on what ?
We have different classification on screen like :
* dedicate screen EventMessages, geoChart, countries
* main decorator screen : GlobalDecorator, LookupDecorator, SimpleDecorator
* embed decorator screen : FindScreenDecorator

My idea like sharing with Julien, Gil and Taher would be to define these 
different standard screen as an API you can be use to structure a screen 
as guideline.
If the API screen is strong, the theme can rendering it as a like, and 
each contributer can create a theme and keep the coherence.


Yes it's a long work but the better way it's start with good base.

Nicolas

Le 28/11/2016 à 21:39, Paul Piper a écrit :

That wasn't meant as trolling, Nicolas. It is a good idea and absolutely
needed. Perhaps as a cautious advice: your problem is going to be
standardization, more so than the UI.

The html in stock ofbiz is a mess and the apps don't really share a common
pattern. For Scipio ERP we cleaned it all up, which took weeks by itself
before we were even able to start on anything useful. Besides that, you will
have to think about the difference in development techniques used. Some apps
rely on *widgets, others on plain ftl. Whatever approach you choose, you
will have to either reimplement all apps, or take care of these differences.



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699747.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

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: svn commit: r1771935 - /ofbiz/trunk/specialpurpose/example/build.gradle

[Jacques Le Roux]

Thanks Deepak!

Completely forgot it :/

Jacques


Le 29/11/2016 à 19:05, dee...@apache.org a écrit :

Author: deepak
Date: Tue Nov 29 18:05:49 2016
New Revision: 1771935

URL: http://svn.apache.org/viewvc?rev=1771935=rev
Log:
Completed: Upgrade Tomcat embed websocket jar to 8.0.39
(OFBIZ-9124)

Modified:
 ofbiz/trunk/specialpurpose/example/build.gradle

Modified: ofbiz/trunk/specialpurpose/example/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/example/build.gradle?rev=1771935=1771934=1771935=diff
==
--- ofbiz/trunk/specialpurpose/example/build.gradle (original)
+++ ofbiz/trunk/specialpurpose/example/build.gradle Tue Nov 29 18:05:49 2016
@@ -1,3 +1,3 @@
  dependencies {
-pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:8.0.36'
+pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:8.0.39'
  }
\ No newline at end of file

buildbot failure in on ofbiz-trunk

[buildbot]

The Buildbot has detected a new failure on builder ofbiz-trunk while building . 
Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1765

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1771935
Blamelist: deepak

BUILD FAILED: failed shell_1

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

[Jacques Le Roux]

Le 28/11/2016 à 14:19, gil portenseigne a écrit :


Also creating new components that will provide simplified, standardized and easy usable processes will enhance adoptability of OFbiz, since it will 
behave as a ready to use *demo* component.

These new components could be the default ones introduced to new user, to show 
the capability of OFBiz to render simple and clean screens.

Then the existing components could be kept as "Developper ShowCase Screens", 
that introduce every functionalities available in OFBiz.

Thanks and regards

Gil 


Gil, I believe this is what David kinda did for/with Moqui.

I also believe that having our own Maven repository for plugins is the 1st step in this process. For that we need to complete/enhance the current 
plugin mechanism (OFBIZ-8251)


Then we can create our own Maven repository on the demo server. I already spoke 
about that at

https://issues.apache.org/jira/browse/OFBIZ-9123?focusedCommentId=15687651=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15687651

Summary:

>


Jacques

Re: [DISCUSSION] Improving the OFBiz User Interface

[Jacques Le Roux]

Like I answered to Taher (and indirectly to Sharan and ideas shared at Seville) 
it's a long term plan.

I must also add that without applying a such plan OFBiz will slowly fading in 
history

We all agree it deserves better :)

Jacques


Le 28/11/2016 à 14:19, gil portenseigne a écrit :

Hello,

I really like the idea of separate HTML/UI stuff from framework where it does not belong. This kind of separation could offer easier and less 
intrusive alternative to implement different UI technology for OFBiz, and even hot-switch between them.


From my point of view, this done, anyone could deploy a solution with its own 
technology and contribute it back to the community with ease.

But defining standard graphic charter for screens is really important and needed to get consistency, allowing each theme to behave its own way on 
defined screen types.


Also creating new components that will provide simplified, standardized and easy usable processes will enhance adoptability of OFbiz, since it will 
behave as a ready to use *demo* component.

These new components could be the default ones introduced to new user, to show 
the capability of OFBiz to render simple and clean screens.

Then the existing components could be kept as "Developper ShowCase Screens", 
that introduce every functionalities available in OFBiz.

Thanks and regards

Gil


On 28/11/2016 11:28, Sharan Foga wrote:

Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the 
OFBiz track at Apachecon that were about how we could improve our UI.


If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are just included as optional). What if we slimmed down all the screens 
to have a sensible default UI for users. The UI could also be modifiable by service providers. Simplify the screens with defaults

- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the UI? (a 
simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if we wanted 
to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work on a Proof of Concept for a common theme  - so do we need to make sure we agree 
conventions etc before much more work is done?)


Thanks
Sharan

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: Updated website with (minimal) information about the new release

[Jacques Le Roux]

For demos, I will ASAP use R16.11 as stable and R13.07 as old

Jacques


Le 28/11/2016 à 08:28, Jacopo Cappellato a écrit :

A few seconds ago, in rev. 1771686, I have updated the website Download
page with the links/info about the new release: please review them and test
the links.
However it would be nice to expand some of the details in the website:
* add one more descriptive sentence to the new release paragraph in the
Download page; remembering Adrian there would be nice
* add a new news entry in the News section in the website lading page

Thanks in advance for your help.

Jacopo

Re: OFBiz security issues

[Jacopo Cappellato]

Tags or components are fine to me (you can specify more than one component
to each ticket); I agree that a tag may be more appropriate for this use
case. My preference is just to not use subtasks.

Jacopo

On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits 
wrote:

> Well...
>
> CVEs can occur on any component (even though past issues have been related
> for most to framework components. So having a particular component just for
> CVE reference purposes would complicate matters as much as converting JIRA
> issues into sub-tasks.
>
> Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA
> would be sufficient to link to from the download page (and elsewhere e.g.
> the 'keeping OFBiz secure' cwiki page.
>
> Best regards,
>
>
>
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > Rather than using subtasks I think it would be better to use a component
> > (named CVE or similar).
> >
> > Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" 
> > ha
> > scritto:
> >
> > > Also it would be better if we can group all security issues in Jira.
> For
> > > that I created OFBIZ-1525, please if you create Jira security issues
> > create
> > > (or convert) them as subtasks of OFBIZ-1525
> > >
> > > Thanks
> > >
> > > Jacques
> > >
> > >
> > > Le 29/11/2016 à 11:05, Pierre Smits a écrit :
> > >
> > >> Of course, I implied this policy to be in line with
> > >> http://www.apache.org/security/
> > >>
> > >> Best regards,
> > >>
> > >> Pierre Smits
> > >>
> > >> ORRTIZ.COM 
> > >> OFBiz based solutions & services
> > >>
> > >> OFBiz Extensions Marketplace
> > >> http://oem.ofbizci.net/oci-2/
> > >>
> > >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin <
> > nicolas.ma...@nereide.fr
> > >> >
> > >> wrote:
> > >>
> > >> Yes I agree with Jacopo, when can create the issue only when they are
> > >>> corrected
> > >>>
> > >>> Nicolas
> > >>>
> > >>>
> > >>>
> > >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :
> > >>>
> > >>> We can definitely create one Jira ticket for each CVE number with all
> > the
> >  details we want and link them from the "security" section of the
> OFBiz
> >  download page.
> >  This was probably implied in Pierre's proposal, but I prefer to
> >  explicitly
> >  state here: these tickets will be created only after the CVE are
> >  publicly
> >  disclosed (i.e. the tickets will be created and resolved at the same
> >  time).
> >  The good news is that we can create now all the tickets for the CVE
> >  processed so far in the history of OFBiz, in order to implement what
> >  Pierre
> >  has proposed here.
> > 
> >  Jacopo
> > 
> >  On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits <
> > pierre.sm...@gmail.com>
> >  wrote:
> > 
> >  Hi all,
> > 
> > > Recently we have seen some security issues fixed in the code base
> > > (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated
> in
> > > identifying, analysing and fixing these OFBiz security threats.
> > >
> > > When I look at how we communicate to our adopters that there are
> > > threats
> > > and how they can be mitigated [1] I believe we could and we should
> > do a
> > > little bit more. There we merely put a reference to the CVE [2]
> issue
> > > (see
> > > [3] for example) there and and advice to upgrade. But on that page
> we
> > > leave
> > > out any particulars on how the issue affected OFBiz and what was
> done
> > > to
> > > it. Rightly so as it is just a list of notifications.
> > >
> > > The details about the effect of the issue and the mitigation is in
> > > commits.
> > > But there is no apparent relation between the notification on [1]
> and
> > > the
> > > actual commit that mitigated. Also reporting the CVE in JIRA issues
> > not
> > > optimal. This leads to the fact that details don't appear in
> release
> > > notes
> > > very well.
> > >
> > > I believe we could and should do better. We should *always* have a
> > JIRA
> > > issue explaining the CVE issue and its effect on the OFBiz product,
> > > have
> > > it
> > > enhanced with the proper tags or labels (e.g. CVE/Security), and -
> > like
> > > any
> > > other JIRA issue - have it showing with which commit(s) it has been
> > > resolved and on which branch it has been implemented.
> > >
> > > With a proper filter definition on JIRA we can then shorten the
> > > vulnerability section in [1] and have that link to that JIRA filter
> > > definition.
> > >
> > > What do you think?
> > >
> > > References:
> > >
> > >  - [1] 

Re: OFBiz security issues

[Pierre Smits]

Well...

CVEs can occur on any component (even though past issues have been related
for most to framework components. So having a particular component just for
CVE reference purposes would complicate matters as much as converting JIRA
issues into sub-tasks.

Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA
would be sufficient to link to from the download page (and elsewhere e.g.
the 'keeping OFBiz secure' cwiki page.

Best regards,




Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Rather than using subtasks I think it would be better to use a component
> (named CVE or similar).
>
> Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" 
> ha
> scritto:
>
> > Also it would be better if we can group all security issues in Jira. For
> > that I created OFBIZ-1525, please if you create Jira security issues
> create
> > (or convert) them as subtasks of OFBIZ-1525
> >
> > Thanks
> >
> > Jacques
> >
> >
> > Le 29/11/2016 à 11:05, Pierre Smits a écrit :
> >
> >> Of course, I implied this policy to be in line with
> >> http://www.apache.org/security/
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM 
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin <
> nicolas.ma...@nereide.fr
> >> >
> >> wrote:
> >>
> >> Yes I agree with Jacopo, when can create the issue only when they are
> >>> corrected
> >>>
> >>> Nicolas
> >>>
> >>>
> >>>
> >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :
> >>>
> >>> We can definitely create one Jira ticket for each CVE number with all
> the
>  details we want and link them from the "security" section of the OFBiz
>  download page.
>  This was probably implied in Pierre's proposal, but I prefer to
>  explicitly
>  state here: these tickets will be created only after the CVE are
>  publicly
>  disclosed (i.e. the tickets will be created and resolved at the same
>  time).
>  The good news is that we can create now all the tickets for the CVE
>  processed so far in the history of OFBiz, in order to implement what
>  Pierre
>  has proposed here.
> 
>  Jacopo
> 
>  On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits <
> pierre.sm...@gmail.com>
>  wrote:
> 
>  Hi all,
> 
> > Recently we have seen some security issues fixed in the code base
> > (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
> > identifying, analysing and fixing these OFBiz security threats.
> >
> > When I look at how we communicate to our adopters that there are
> > threats
> > and how they can be mitigated [1] I believe we could and we should
> do a
> > little bit more. There we merely put a reference to the CVE [2] issue
> > (see
> > [3] for example) there and and advice to upgrade. But on that page we
> > leave
> > out any particulars on how the issue affected OFBiz and what was done
> > to
> > it. Rightly so as it is just a list of notifications.
> >
> > The details about the effect of the issue and the mitigation is in
> > commits.
> > But there is no apparent relation between the notification on [1] and
> > the
> > actual commit that mitigated. Also reporting the CVE in JIRA issues
> not
> > optimal. This leads to the fact that details don't appear in release
> > notes
> > very well.
> >
> > I believe we could and should do better. We should *always* have a
> JIRA
> > issue explaining the CVE issue and its effect on the OFBiz product,
> > have
> > it
> > enhanced with the proper tags or labels (e.g. CVE/Security), and -
> like
> > any
> > other JIRA issue - have it showing with which commit(s) it has been
> > resolved and on which branch it has been implemented.
> >
> > With a proper filter definition on JIRA we can then shorten the
> > vulnerability section in [1] and have that link to that JIRA filter
> > definition.
> >
> > What do you think?
> >
> > References:
> >
> >  - [1] http://ofbiz.apache.org/download.html
> >  - [2] CVE: Common Vulnerability and Exposure
> >  - [3] http://cve.mitre.org/cgi-bin/
> cvename.cgi?name=CVE-2016-6800
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> >
> >
> >
>

Re: OFBiz security issues

[Jacopo Cappellato]

Rather than using subtasks I think it would be better to use a component
(named CVE or similar).

Il 29 Nov 2016 1:50 PM, "Jacques Le Roux"  ha
scritto:

> Also it would be better if we can group all security issues in Jira. For
> that I created OFBIZ-1525, please if you create Jira security issues create
> (or convert) them as subtasks of OFBIZ-1525
>
> Thanks
>
> Jacques
>
>
> Le 29/11/2016 à 11:05, Pierre Smits a écrit :
>
>> Of course, I implied this policy to be in line with
>> http://www.apache.org/security/
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin > >
>> wrote:
>>
>> Yes I agree with Jacopo, when can create the issue only when they are
>>> corrected
>>>
>>> Nicolas
>>>
>>>
>>>
>>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :
>>>
>>> We can definitely create one Jira ticket for each CVE number with all the
 details we want and link them from the "security" section of the OFBiz
 download page.
 This was probably implied in Pierre's proposal, but I prefer to
 explicitly
 state here: these tickets will be created only after the CVE are
 publicly
 disclosed (i.e. the tickets will be created and resolved at the same
 time).
 The good news is that we can create now all the tickets for the CVE
 processed so far in the history of OFBiz, in order to implement what
 Pierre
 has proposed here.

 Jacopo

 On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits 
 wrote:

 Hi all,

> Recently we have seen some security issues fixed in the code base
> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
> identifying, analysing and fixing these OFBiz security threats.
>
> When I look at how we communicate to our adopters that there are
> threats
> and how they can be mitigated [1] I believe we could and we should do a
> little bit more. There we merely put a reference to the CVE [2] issue
> (see
> [3] for example) there and and advice to upgrade. But on that page we
> leave
> out any particulars on how the issue affected OFBiz and what was done
> to
> it. Rightly so as it is just a list of notifications.
>
> The details about the effect of the issue and the mitigation is in
> commits.
> But there is no apparent relation between the notification on [1] and
> the
> actual commit that mitigated. Also reporting the CVE in JIRA issues not
> optimal. This leads to the fact that details don't appear in release
> notes
> very well.
>
> I believe we could and should do better. We should *always* have a JIRA
> issue explaining the CVE issue and its effect on the OFBiz product,
> have
> it
> enhanced with the proper tags or labels (e.g. CVE/Security), and - like
> any
> other JIRA issue - have it showing with which commit(s) it has been
> resolved and on which branch it has been implemented.
>
> With a proper filter definition on JIRA we can then shorten the
> vulnerability section in [1] and have that link to that JIRA filter
> definition.
>
> What do you think?
>
> References:
>
>  - [1] http://ofbiz.apache.org/download.html
>  - [2] CVE: Common Vulnerability and Exposure
>  - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800
>
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
>
>
>

Re: OFBiz security issues

[Jacques Le Roux]

Also it would be better if we can group all security issues in Jira. For that I created OFBIZ-1525, please if you create Jira security issues create 
(or convert) them as subtasks of OFBIZ-1525


Thanks

Jacques


Le 29/11/2016 à 11:05, Pierre Smits a écrit :

Of course, I implied this policy to be in line with
http://www.apache.org/security/

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin 
wrote:


Yes I agree with Jacopo, when can create the issue only when they are
corrected

Nicolas



Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :


We can definitely create one Jira ticket for each CVE number with all the
details we want and link them from the "security" section of the OFBiz
download page.
This was probably implied in Pierre's proposal, but I prefer to explicitly
state here: these tickets will be created only after the CVE are publicly
disclosed (i.e. the tickets will be created and resolved at the same
time).
The good news is that we can create now all the tickets for the CVE
processed so far in the history of OFBiz, in order to implement what
Pierre
has proposed here.

Jacopo

On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits 
wrote:

Hi all,

Recently we have seen some security issues fixed in the code base
(CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
identifying, analysing and fixing these OFBiz security threats.

When I look at how we communicate to our adopters that there are threats
and how they can be mitigated [1] I believe we could and we should do a
little bit more. There we merely put a reference to the CVE [2] issue
(see
[3] for example) there and and advice to upgrade. But on that page we
leave
out any particulars on how the issue affected OFBiz and what was done to
it. Rightly so as it is just a list of notifications.

The details about the effect of the issue and the mitigation is in
commits.
But there is no apparent relation between the notification on [1] and the
actual commit that mitigated. Also reporting the CVE in JIRA issues not
optimal. This leads to the fact that details don't appear in release
notes
very well.

I believe we could and should do better. We should *always* have a JIRA
issue explaining the CVE issue and its effect on the OFBiz product, have
it
enhanced with the proper tags or labels (e.g. CVE/Security), and - like
any
other JIRA issue - have it showing with which commit(s) it has been
resolved and on which branch it has been implemented.

With a proper filter definition on JIRA we can then shorten the
vulnerability section in [1] and have that link to that JIRA filter
definition.

What do you think?

References:

 - [1] http://ofbiz.apache.org/download.html
 - [2] CVE: Common Vulnerability and Exposure
 - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: OFBiz security issues

[Pierre Smits]

Of course, I implied this policy to be in line with
http://www.apache.org/security/

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin 
wrote:

> Yes I agree with Jacopo, when can create the issue only when they are
> corrected
>
> Nicolas
>
>
>
> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :
>
>> We can definitely create one Jira ticket for each CVE number with all the
>> details we want and link them from the "security" section of the OFBiz
>> download page.
>> This was probably implied in Pierre's proposal, but I prefer to explicitly
>> state here: these tickets will be created only after the CVE are publicly
>> disclosed (i.e. the tickets will be created and resolved at the same
>> time).
>> The good news is that we can create now all the tickets for the CVE
>> processed so far in the history of OFBiz, in order to implement what
>> Pierre
>> has proposed here.
>>
>> Jacopo
>>
>> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits 
>> wrote:
>>
>> Hi all,
>>>
>>> Recently we have seen some security issues fixed in the code base
>>> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
>>> identifying, analysing and fixing these OFBiz security threats.
>>>
>>> When I look at how we communicate to our adopters that there are threats
>>> and how they can be mitigated [1] I believe we could and we should do a
>>> little bit more. There we merely put a reference to the CVE [2] issue
>>> (see
>>> [3] for example) there and and advice to upgrade. But on that page we
>>> leave
>>> out any particulars on how the issue affected OFBiz and what was done to
>>> it. Rightly so as it is just a list of notifications.
>>>
>>> The details about the effect of the issue and the mitigation is in
>>> commits.
>>> But there is no apparent relation between the notification on [1] and the
>>> actual commit that mitigated. Also reporting the CVE in JIRA issues not
>>> optimal. This leads to the fact that details don't appear in release
>>> notes
>>> very well.
>>>
>>> I believe we could and should do better. We should *always* have a JIRA
>>> issue explaining the CVE issue and its effect on the OFBiz product, have
>>> it
>>> enhanced with the proper tags or labels (e.g. CVE/Security), and - like
>>> any
>>> other JIRA issue - have it showing with which commit(s) it has been
>>> resolved and on which branch it has been implemented.
>>>
>>> With a proper filter definition on JIRA we can then shorten the
>>> vulnerability section in [1] and have that link to that JIRA filter
>>> definition.
>>>
>>> What do you think?
>>>
>>> References:
>>>
>>> - [1] http://ofbiz.apache.org/download.html
>>> - [2] CVE: Common Vulnerability and Exposure
>>> - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800
>>>
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM 
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>>
>

Re: OFBiz security issues

[Nicolas Malin]

Yes I agree with Jacopo, when can create the issue only when they are 
corrected


Nicolas


Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :

We can definitely create one Jira ticket for each CVE number with all the
details we want and link them from the "security" section of the OFBiz
download page.
This was probably implied in Pierre's proposal, but I prefer to explicitly
state here: these tickets will be created only after the CVE are publicly
disclosed (i.e. the tickets will be created and resolved at the same time).
The good news is that we can create now all the tickets for the CVE
processed so far in the history of OFBiz, in order to implement what Pierre
has proposed here.

Jacopo

On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits 
wrote:


Hi all,

Recently we have seen some security issues fixed in the code base
(CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
identifying, analysing and fixing these OFBiz security threats.

When I look at how we communicate to our adopters that there are threats
and how they can be mitigated [1] I believe we could and we should do a
little bit more. There we merely put a reference to the CVE [2] issue (see
[3] for example) there and and advice to upgrade. But on that page we leave
out any particulars on how the issue affected OFBiz and what was done to
it. Rightly so as it is just a list of notifications.

The details about the effect of the issue and the mitigation is in commits.
But there is no apparent relation between the notification on [1] and the
actual commit that mitigated. Also reporting the CVE in JIRA issues not
optimal. This leads to the fact that details don't appear in release notes
very well.

I believe we could and should do better. We should *always* have a JIRA
issue explaining the CVE issue and its effect on the OFBiz product, have it
enhanced with the proper tags or labels (e.g. CVE/Security), and - like any
other JIRA issue - have it showing with which commit(s) it has been
resolved and on which branch it has been implemented.

With a proper filter definition on JIRA we can then shorten the
vulnerability section in [1] and have that link to that JIRA filter
definition.

What do you think?

References:

- [1] http://ofbiz.apache.org/download.html
- [2] CVE: Common Vulnerability and Exposure
- [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: OFBiz security issues

[Jacopo Cappellato]

We can definitely create one Jira ticket for each CVE number with all the
details we want and link them from the "security" section of the OFBiz
download page.
This was probably implied in Pierre's proposal, but I prefer to explicitly
state here: these tickets will be created only after the CVE are publicly
disclosed (i.e. the tickets will be created and resolved at the same time).
The good news is that we can create now all the tickets for the CVE
processed so far in the history of OFBiz, in order to implement what Pierre
has proposed here.

Jacopo

On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits 
wrote:

> Hi all,
>
> Recently we have seen some security issues fixed in the code base
> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
> identifying, analysing and fixing these OFBiz security threats.
>
> When I look at how we communicate to our adopters that there are threats
> and how they can be mitigated [1] I believe we could and we should do a
> little bit more. There we merely put a reference to the CVE [2] issue (see
> [3] for example) there and and advice to upgrade. But on that page we leave
> out any particulars on how the issue affected OFBiz and what was done to
> it. Rightly so as it is just a list of notifications.
>
> The details about the effect of the issue and the mitigation is in commits.
> But there is no apparent relation between the notification on [1] and the
> actual commit that mitigated. Also reporting the CVE in JIRA issues not
> optimal. This leads to the fact that details don't appear in release notes
> very well.
>
> I believe we could and should do better. We should *always* have a JIRA
> issue explaining the CVE issue and its effect on the OFBiz product, have it
> enhanced with the proper tags or labels (e.g. CVE/Security), and - like any
> other JIRA issue - have it showing with which commit(s) it has been
> resolved and on which branch it has been implemented.
>
> With a proper filter definition on JIRA we can then shorten the
> vulnerability section in [1] and have that link to that JIRA filter
> definition.
>
> What do you think?
>
> References:
>
>- [1] http://ofbiz.apache.org/download.html
>- [2] CVE: Common Vulnerability and Exposure
>- [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800
>
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>

OFBiz security issues

[Pierre Smits]

Hi all,

Recently we have seen some security issues fixed in the code base
(CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in
identifying, analysing and fixing these OFBiz security threats.

When I look at how we communicate to our adopters that there are threats
and how they can be mitigated [1] I believe we could and we should do a
little bit more. There we merely put a reference to the CVE [2] issue (see
[3] for example) there and and advice to upgrade. But on that page we leave
out any particulars on how the issue affected OFBiz and what was done to
it. Rightly so as it is just a list of notifications.

The details about the effect of the issue and the mitigation is in commits.
But there is no apparent relation between the notification on [1] and the
actual commit that mitigated. Also reporting the CVE in JIRA issues not
optimal. This leads to the fact that details don't appear in release notes
very well.

I believe we could and should do better. We should *always* have a JIRA
issue explaining the CVE issue and its effect on the OFBiz product, have it
enhanced with the proper tags or labels (e.g. CVE/Security), and - like any
other JIRA issue - have it showing with which commit(s) it has been
resolved and on which branch it has been implemented.

With a proper filter definition on JIRA we can then shorten the
vulnerability section in [1] and have that link to that JIRA filter
definition.

What do you think?

References:

   - [1] http://ofbiz.apache.org/download.html
   - [2] CVE: Common Vulnerability and Exposure
   - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/