[jira] [Closed] (OFBIZ-10245) File transfer management with communicationEvent and new contactMech FTP_ADDRESS
[
https://issues.apache.org/jira/browse/OFBIZ-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gil Portenseigne closed OFBIZ-10245.
> File transfer management with communicationEvent and new contactMech
> FTP_ADDRESS
>
>
> Key: OFBIZ-10245
> URL: https://issues.apache.org/jira/browse/OFBIZ-10245
> Project: OFBiz
> Issue Type: Improvement
> Components: content, party
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-10245.patch
>
>
> This Jira introduce a new way to manage file transfer in OFBiz.
> Inspired by mailing communication event management, a new
> communicationEventTypeId is created ('FILE_TRANSFER_COMM').
> Such commEvent with classics :
> partyIdFrom/partyIdTo/contactMechIdTo/entryDate etc. are analysed by a job
> (like sendEmailDated), to send associated contents to a configured
> FTP/SFTP/FTPS server. If failure happens, it is catched and stored in
> communicationEvent, waiting for a new try.
> For this purpose :
> # A new contactMechTypeId is introduced (FtpAddress), with its corresponding
> table. This contactMech store needed information for basic user/password
> authentication (server url and protocol, port, username, password, etc.)
> # A new service sendFileTransferDated (wip) that will look for pending file
> transfer and call following service.
> # A new service sendCommEventAsFtp that take a selected commEvent, check its
> structure and manage its status after trying the associated content file
> transfers
> # A new service sendContentToFtp, that take a content and transfer it to a
> given FtpAddress
> # A seca createCommEventFromFtpTransfer on sendContentToFtp to manage plural
> content file transfer, creating children communicationEvent to follow each
> content transfer separately (only for several content transfers).
> # A new Interface FtpClientInterface, with the 3 implementations of FTP,
> FTPS (To be Done), SFTP clients to manage Ftp connection and transfer
> # A new property file to enable and manage redirection for testing purpose
> With this implementation, creating a communicationEvent, with a FtpAddress
> contactMechIdTo, and sendFileTransferDated job planned :
> * The file is transfered to the ftp : communication event status set to
> COM_COMPLETE
> * Error occured : communication event status set to COM_BOUNCED with error
> message on communicationEvent note
> The POC is working nicely for our customer, i adapted and tested it on trunk
> here :
> https://labs.nereide.fr/10031/Communautaire/compare/trunk...SendCommEventToFtp
> (some more job to be done, but in a working state)
> I can provide the current patch on demand but i will propose more polished
> work in some days.
> Looking forward reading you !
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480715#comment-16480715 ] Michael Brohl commented on OFBIZ-10141: --- Yes, intentionally. See my comment on 20/Feb/18 17:14 I'll complete this when we decide to use this approach, trying to be efficient ;) > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch, > OFBIZ-10141_Add_VERSION_file_simpler_solution.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480704#comment-16480704 ] Jacques Le Roux commented on OFBIZ-10141: - Right, and CommonRelease is just containing the text "Release" so your solution seems indeed better. We will always have the release number showing in footer, but that seems like a good idea. I have though still a concern: only the current default theme is addressed ;) > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch, > OFBIZ-10141_Add_VERSION_file_simpler_solution.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10145) Remove the Gradle wrapper from our release packages and add a step to our build notes
[
https://issues.apache.org/jira/browse/OFBIZ-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480679#comment-16480679
]
Nicolas Malin commented on OFBIZ-10145:
---
Hello,
I started a download script for unix [^init-gradle-wrapper.sh] to set on
directory $OFBIZ_HOME/gradle/ and run like
{code}
sh gradle/init-gradle-wrapper.sh
./gradlew
{code}
it's simple and just a try. Peraphs it's possible to realize the same for
windows
> Remove the Gradle wrapper from our release packages and add a step to our
> build notes
> -
>
> Key: OFBIZ-10145
> URL: https://issues.apache.org/jira/browse/OFBIZ-10145
> Project: OFBiz
> Issue Type: Task
> Components: Gradle
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: init-gradle-wrapper.sh
>
>
> Following the discussion at http://markmail.org/message/nd7grfiyobjkfwae,
> considering LEGAL-288 and based on a lazy consensus on dev ML, we want to
> remove the gradle-wrapper.jar file from the next packaged releases and use
> [~jacopoc]'s related proposition to document how to have Gradle working in
> the main README.md file.
> # Extract the archive file to your local directory.
> # Download gradle-wrapper.jar and place it in the
> OFBiz-root-dir/gradle/wrapper folder.
> I'm not sure if we should recommend a link to download the
> gradle-wrapper.jar. This might change in the future (versions, etc.), so
> indeed maybe simply asking to download is enough, cf
> https://www.google.com/search?q=gradle-wrapper.jar+download=UTF-8
> Also we need to add a point about removing gradle-wrapper.jar in
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10145) Remove the Gradle wrapper from our release packages and add a step to our build notes
[ https://issues.apache.org/jira/browse/OFBIZ-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin updated OFBIZ-10145: -- Attachment: init-gradle-wrapper.sh > Remove the Gradle wrapper from our release packages and add a step to our > build notes > - > > Key: OFBIZ-10145 > URL: https://issues.apache.org/jira/browse/OFBIZ-10145 > Project: OFBiz > Issue Type: Task > Components: Gradle >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Major > Fix For: 17.12.01 > > Attachments: init-gradle-wrapper.sh > > > Following the discussion at http://markmail.org/message/nd7grfiyobjkfwae, > considering LEGAL-288 and based on a lazy consensus on dev ML, we want to > remove the gradle-wrapper.jar file from the next packaged releases and use > [~jacopoc]'s related proposition to document how to have Gradle working in > the main README.md file. > # Extract the archive file to your local directory. > # Download gradle-wrapper.jar and place it in the > OFBiz-root-dir/gradle/wrapper folder. > I'm not sure if we should recommend a link to download the > gradle-wrapper.jar. This might change in the future (versions, etc.), so > indeed maybe simply asking to download is enough, cf > https://www.google.com/search?q=gradle-wrapper.jar+download=UTF-8 > Also we need to add a point about removing gradle-wrapper.jar in > https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480660#comment-16480660 ] Jacques Le Roux commented on OFBIZ-6766: Reading https://www.fastly.com/blog/headers-we-dont-want and then checking at https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control https://stackoverflow.com/questions/34663916/are-cache-control-pre-check-and-post-check-headers-still-supported-by-ie https://blogs.msdn.microsoft.com/ieinternals/2009/07/20/internet-explorers-cache-control-extensions/ I see that we can update our headers: * Expires: Fastly recommends to remove but Mozilla is more concervative: keeping * Pragma: same * Cache-Control: same + adding private * Cache-Control post-check and pre-check: according to Stackoverflow and especially Microsoft, removing * x-frame-options: see my comment in user ML at https://markmail.org/message/hcw7du22vqcbe4oo TL;DR better to use a CSP policy * x-ua-compatible: it's only in html files. I think it's more history and cargo cult, but I'll though ask on dev ML * others: we are not concerned :) I have attached the OFBIZ-6766-UtilHttp.java.patch and will ask about x-ua-compatible on dev ML before committing > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01 > > Attachments: OFBIZ-6766-UtilHttp.java.patch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-6766: --- Attachment: OFBIZ-6766-UtilHttp.java.patch > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01 > > Attachments: OFBIZ-6766-UtilHttp.java.patch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-297) Have screen widgets render for in-page links
[ https://issues.apache.org/jira/browse/OFBIZ-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-297. - Resolution: Not A Problem Assignee: Jacques Le Roux Nobody cares, closing > Have screen widgets render for in-page links > > > Key: OFBIZ-297 > URL: https://issues.apache.org/jira/browse/OFBIZ-297 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Marco Risaliti >Assignee: Jacques Le Roux >Priority: Minor > Attachments: proposed-anchorScreenWidget.patch > > > Copy of http://jira.undersunconsulting.com/browse/OFBIZ-753 from Leon Torres. > > Some pages can be very long, so it would be extra helpful to have a way to > jump to a particular part of the page using the HTML anchor tags name="">. > For instance, if the screen widget allowed, > > This is a List of Orders > > And the ListOrders form had a header-link with #ListOrders as part of the > target, it would jump back to the location of the anchor. > > > AllCommentsWork LogChange History Sort Order: > Comment by Leon Torres [17/Feb/06 07:20 PM] [ Permlink ] > Here's an update to the screen widget system that allows the use of name=""/> to render . > Not sure if the tree widget or anything else needs it or not, please double > check. > Comment by David E. Jones [26/Feb/06 01:15 AM] [ Permlink ] > I'll have to think about this a bit more... It probably does make the most > sense to put it in the screen widget, but this seems right now to me to be a > little too close to HTML and not generic enough for use in non-HTML rendering > of screens. We don't have anything to do this right now, but it is very much > part of the intent to keep this direction open and explicit. > If you have any ideas along these lines let's discuss them, and I'll think > about it as well. Perhaps just an element like this is generic enough... but > there is probably something more generally applicable we could do. > Comment by Si Chen [27/Feb/06 08:56 AM] [ Permlink ] > David, > I see what you mean. DocBook also has an "anchor" tag: > http://www.docbook.org/tdg/en/html/anchor.html > Do you think that qualifies it as a "universal" or "generic" document format > concept? > Si > Comment by David E. Jones [12/Mar/06 10:23 PM] [ Permlink ] > Si, > Yes, and I guess even more significantly HTML has such a concept (I'm > guessing there's still a lot more HTML being generated through the screen > widget than DocBook). That's what concerns me the most: it's a very document > oriented concept and not something that you find as much in applications, or > in "screens". > Still, I think it's a useful concept and perhaps one that would be nice to > have as a special screen widget element because if I understand correctly > what you're shooting for it is to have a reference point for the beginning of > different sections of a screen. > And if it is really for the beginning point of a section of a screen... we > already have a nice place that would fit in: the section element. We could > just change the HTML generation to create an anchor () for the > start of each section if the section has a name associated with it... > Does that sound like it would hit more or less the goal you are shooting for? > Comment by Leon Torres [16/Mar/06 04:39 PM] [ Permlink ] > David, > I don't like the idea of using section element names for two reasons: > 1) I would have to wrap each block that needs such an anchor in a > and then a , creating additional lines of code. While it would be > nice to reuse the code and not introduce more form elements, in > reality it would just shift additional code to the user the form-widget. > 2) Anchors are important elements of many UI applications which work with > complex documents. For example, the Eclipse IDE, like most editors, allows > you to click on a method name and then scrolls your code to the line where > the method is defined. Thus, the method name could be thought of as an > anchor. > So I still think we should have an anchor tag. > - Leon > Comment by Si Chen [22/Mar/06 07:58 AM] [ Permlink ] > David, > So do you not like this patch? If not, just let us know, and I'll close out > the issue, and we'll do it some other way. > Thanks, > Si > Comment by Marco Risaliti [13/Sep/06 04:27 PM] [ Permlink ] > What to do here, close it or move it. > Thanks > Marco -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480579#comment-16480579 ] Michael Brohl commented on OFBIZ-10141: --- Please have a closer look at my patch, it is using a VERSION file... > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch, > OFBIZ-10141_Add_VERSION_file_simpler_solution.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480576#comment-16480576 ] Jacques Le Roux commented on OFBIZ-10141: - I agree Michael's patch is simpler. The only drawback is that the version number is hidden "deeply" in CommonRelease label and needs a running version. Where a VERSION file is easier for any user to read and when needed given (mostly to us when helping on user ML). Also changing the CommonRelease label can be forgotten, but changing the VERSION file also. So all in all, I have no strong opinion anyway and I'd like more opinions than just Michael's and mine :D > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch, > OFBIZ-10141_Add_VERSION_file_simpler_solution.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[ https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480561#comment-16480561 ] Michael Brohl commented on OFBIZ-10141: --- We have two different proposals/ patches so we need some opinions which one we want to commit > Add a VERSION file in root dir > -- > > Key: OFBIZ-10141 > URL: https://issues.apache.org/jira/browse/OFBIZ-10141 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01 > > Attachments: OFBIZ-10141.patch, > OFBIZ-10141_Add_VERSION_file_simpler_solution.patch > > > Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have > decided to > # have VERSION file at project root to store released version. > # Render the version in the applications footer template as a HTML comment. > Also [~mbrohl] suggested that > # it can be automatically set by (custom) builds to be generated. > # It should be made configurable in general.properties to prevent to show it > if the user does not want this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10141) Add a VERSION file in root dir
[
https://issues.apache.org/jira/browse/OFBIZ-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480547#comment-16480547
]
Nicolas Malin commented on OFBIZ-10141:
---
{quote}Any thoughts on the patches provided?\{quote}
I like :) , I think we can commit this on released version and trunk
> Add a VERSION file in root dir
> --
>
> Key: OFBIZ-10141
> URL: https://issues.apache.org/jira/browse/OFBIZ-10141
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Fix For: 17.12.01
>
> Attachments: OFBIZ-10141.patch,
> OFBIZ-10141_Add_VERSION_file_simpler_solution.patch
>
>
> Following discussion at http://markmail.org/message/ut74mzptruubw4ty we have
> decided to
> # have VERSION file at project root to store released version.
> # Render the version in the applications footer template as a HTML comment.
> Also [~mbrohl] suggested that
> # it can be automatically set by (custom) builds to be generated.
> # It should be made configurable in general.properties to prevent to show it
> if the user does not want this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10409) Generic message from entity-auto service can be enhanced
[ https://issues.apache.org/jira/browse/OFBIZ-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suraj Khurana updated OFBIZ-10409: -- Description: Currently, it is using entityName from ModelEntity, we can enhance it by using entityTitle from ModelEntity. So that instead of *_ProductStoreFacility Updated Successfully_*, we can have better success message as *_Product Store Facility Updated Successfully_*. was: Currently, it is using entityName from ModelEntity, we can enhance it by using entityTitle form ModelEntity. So that instead of *_ProductStoreFacility Updated Successfully_*, we can have better success message as *_Product Store Facility Updated Successfully_*. > Generic message from entity-auto service can be enhanced > > > Key: OFBIZ-10409 > URL: https://issues.apache.org/jira/browse/OFBIZ-10409 > Project: OFBiz > Issue Type: Improvement >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Minor > > Currently, it is using entityName from ModelEntity, we can enhance it by > using entityTitle from ModelEntity. > So that instead of *_ProductStoreFacility Updated Successfully_*, we can > have better success message as *_Product Store Facility Updated > Successfully_*. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet
[ https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480337#comment-16480337 ] Jacques Le Roux commented on OFBIZ-4274: Hi Mathieu, Also while at it, I wonder if [Eclipse MicroProfile|https://dzone.com/articles/building-your-next-microservice-with-eclipse-micro] could not have an interest for your project. > Implement a REST Servlet > > > Key: OFBIZ-4274 > URL: https://issues.apache.org/jira/browse/OFBIZ-4274 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Adrian Crum >Priority: Minor > Labels: REST > Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, > rest-conf.xml, swagger-pos-openapi.png > > > Implement a REST servlet that will map REST requests to OFBiz services. > Details are in the comments. > [here is the discussion which took place on the dev > ML|http://markmail.org/message/ai6q2fbksowaayn4] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10406) Dynamic values not rendering properly in property tag of fail-property attribute
[
https://issues.apache.org/jira/browse/OFBIZ-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480339#comment-16480339
]
Suraj Khurana commented on OFBIZ-10406:
---
Thanks [~jacques.le.roux]. :)
> Dynamic values not rendering properly in property tag of fail-property
> attribute
>
>
> Key: OFBIZ-10406
> URL: https://issues.apache.org/jira/browse/OFBIZ-10406
> Project: OFBiz
> Issue Type: Bug
>Reporter: Suraj Khurana
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01, 16.11.05
>
> Attachments: OFBIZ-10406.patch
>
>
> While calling checkProductRelatedPermission, if permission is failed than
> fail-property tag uses ${checkActionLabel} which is not handled properly in
> MessageElement.java.
> There are 2-3 other occurrences as well of such type but not in working
> condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OFBIZ-10406) Dynamic values not rendering properly in property tag of fail-property attribute
[
https://issues.apache.org/jira/browse/OFBIZ-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-10406.
---
Resolution: Fixed
Fix Version/s: 16.11.05
17.12.01
Thanks Suraj,
I did only review (no tests) but that makes perfectly sense. Your patch is in
trunk r1831831
R17.11 r1831832
R16.12 r1831833
> Dynamic values not rendering properly in property tag of fail-property
> attribute
>
>
> Key: OFBIZ-10406
> URL: https://issues.apache.org/jira/browse/OFBIZ-10406
> Project: OFBiz
> Issue Type: Bug
>Reporter: Suraj Khurana
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01, 16.11.05
>
> Attachments: OFBIZ-10406.patch
>
>
> While calling checkProductRelatedPermission, if permission is failed than
> fail-property tag uses ${checkActionLabel} which is not handled properly in
> MessageElement.java.
> There are 2-3 other occurrences as well of such type but not in working
> condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10406) Dynamic values not rendering properly in property tag of fail-property attribute
[
https://issues.apache.org/jira/browse/OFBIZ-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-10406:
---
Assignee: Jacques Le Roux (was: Suraj Khurana)
> Dynamic values not rendering properly in property tag of fail-property
> attribute
>
>
> Key: OFBIZ-10406
> URL: https://issues.apache.org/jira/browse/OFBIZ-10406
> Project: OFBiz
> Issue Type: Bug
>Reporter: Suraj Khurana
>Assignee: Jacques Le Roux
>Priority: Major
> Attachments: OFBIZ-10406.patch
>
>
> While calling checkProductRelatedPermission, if permission is failed than
> fail-property tag uses ${checkActionLabel} which is not handled properly in
> MessageElement.java.
> There are 2-3 other occurrences as well of such type but not in working
> condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
