ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Brohl (Jira)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-8297) Convert <property-to field functions to tenant-aware solutions
Date Sun, 02 Feb 2020 10:29:00 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17028363#comment-17028363
] 

Michael Brohl commented on OFBIZ-8297:
--------------------------------------

{quote}Michael, 

First you claimed that the provided patch would break functionality.

However if you would have looked a little further you would have found that the key-value
pair exists in CommonSystemPropertyData since 2012-02-01 see [https://fisheye.apache.org/browse/ofbiz-framework/framework/common/data/CommonSystemPropertyData.xml?r2=13ff4e3f4c6f41864d62c6cdb6931a02f4b85e73&r1=c690a5aba578f0df25df572cec734f4eb3c57038]

The CommonSystemPropertyData is loaded as seed data (see the ofbiz-component.xml.
{quote}
I am aware of this. With the patch you changed the retrieval of the property from file properties
to just database driven SystemProperty.

This assumes that users always use the SystemProperty mechanism to retrieve properties which
is not valid. There are good reasons to not use SystemProperty at all as a default and just
use it to override file properties at runtime, especially when you have a multi stage server
setup with different property sets.

So if you want to enhance the mechanism to cover both worlds correctly, you should use the
EntityUtilProperties mechanism.

 
{quote}In 2019 you claimed the patch was incomplete, without providing additional information.
{quote}
Correct, see above. The patch is breaking existing mechanisms and therefore can be viewed
as incomplete.

 
{quote}It seems to me you were 'managing' the ticket and expecting others (me) to resolve
your concerns, instead of working it yourself.
{quote}
 

If a contributor provides a patch, it is the committers responsibility to check if the solution
is valid, does not break functionality and has an overall quality to be introduced to the
codebase. This does IMO not imply that he is responsible to rework a patch until it fits.
It's a strange viewpoint to expect the committer to do the corrections himself instead of
the original contributor feeling responsible for his solution.

As you can see from the history, I gave my opinions and asked you to rework it with a hint
what is wrong with the first solution.

*No answer for a year.*

I then asked you if your are going to provide a corrected patch (note that I picked it up
again, not you). You then criticized that the patch is getting old and asked me to rework
your patch and immediately got an answer from me.

*No answer for another year.* I closed the issue as announced a year ago.

That's where we are now and you are going to criticize how I deal with this ticket instead
of working on the solution you want to be in the codebase?

This pattern repeats on several of your issues and might be one of the reasons why they are
picked up by the community less frequently than others.

 

 

> Convert <property-to field functions to tenant-aware solutions
> --------------------------------------------------------------
>
>                 Key: OFBIZ-8297
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-8297
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL COMPONENTS
>    Affects Versions: Trunk
>            Reporter: Pierre Smits
>            Assignee: Michael Brohl
>            Priority: Minor
>         Attachments: OFBIZ-8297-AgreementScreens.xml.patch, OFBIZ-8297-AgreementScreens.xml.patch
>
>
> *<property-to-field* functions look specifically to content in .property files when
it comes to retrieving configuration variables. This doesn't work in a multi-tenant setup.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message