[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203302#comment-14203302
]
Nicolas Malin commented on OFBIZ-5848:
--
{quote}did you try R12.04 with Java 6 and TLSv1.0?{quote}
Yes I tried java 6 , TLSv1.2 and TLSv1.0
{quote}As regards 12.04: we should figure out if there is something we can do
to enable TLS, or we could:
1) anticipate the end of life of the release branch
2) publish a final release with the upgrade to Java 7: it should be used only
by users that can't upgrade to 13.07 but are ready to upgrade their production
instances to java 7
{quote}
To unsupported the 12.04 maybe wait the next stable branch. If we convert the
12.04 to use Java7, why anticipate the end of life ?
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203304#comment-14203304
]
Nicolas Malin commented on OFBIZ-5848:
--
Sorry Jacopo, I confused anticipate by precipitate, so I read and understood
advanced the end of life date :)
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203319#comment-14203319
]
Deepak Dixit commented on OFBIZ-5848:
-
SSLv3 and TLS will be disabled by default in Firefox upcoming releases.
https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-5844) Convert java files to EntityQuery
[ https://issues.apache.org/jira/browse/OFBIZ-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Patidar updated OFBIZ-5844: Attachment: OFBIZ-5844-Party.patch Attached modified patch for party component Convert java files to EntityQuery - Key: OFBIZ-5844 URL: https://issues.apache.org/jira/browse/OFBIZ-5844 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Arun Patidar Priority: Minor Attachments: OFBIZ-5844-Party.patch, OFBIZ-5844-Party.patch Recently [~lektran] has been converted java files to use Entity Query methods in place of Entity Engine methods. Components that has been converted are as below: - content - humanres - manufacturing - ordermgr (partially converted) - Replaced findOne() method in all components And commit revisions are: r1635380, r1635381, r1635382 and r1635383 Remaining components to be convert are: - product - party - commonext - securityext - workeffort - ordermgr (remaining part) - specialpurpose -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[
https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203338#comment-14203338
]
Jacopo Cappellato commented on OFBIZ-5793:
--
Thank Ivan.
I have committed your patch with r. 1637535 with some minor modifications.
Misc comments:
* I have modified some minor formatting
* I have removed the field serviceNameOnExpiry from SubscriptionForms.xml
* performance enhancement - add a condition to only select records with null
expirationCompletedDate field in the query:
{code}subscriptionList = delegator.findList(Subscription, cond, null,null,
null, false);{code}
and then remove the if block:
{code}if (expirationCompletedDate == null) {{code}
* performance enhancement - move the code:
{code}Calendar currentDate = Calendar.getInstance();
currentDate.setTime(UtilDateTime.nowTimestamp());
{code}
out of the for block
* instead of:
{code}subscriptionResource =
EntityQuery.use(delegator).from(SubscriptionResource).where(subscriptionResourceId,
subscriptionResourceId).queryOne();{code}
you could have used:
{code}subscription.getRelatedOne(SubscriptionResource){code}
modify logic to only run expiry service once when subscription expires
--
Key: OFBIZ-5793
URL: https://issues.apache.org/jira/browse/OFBIZ-5793
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: Trunk
Environment: not relevant
Reporter: Ivan Cauchi
Assignee: Jacopo Cappellato
Priority: Minor
Labels: subscription
Fix For: Trunk
Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch
Original Estimate: 672h
Remaining Estimate: 672h
Background
---
Recenlty, the trunk version of OFBiz was augmented with a new service called
runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled
to run, using the demo data, once a day. Its algorithm looks up all
subscriptions which have expired, which is defined as the current time being
greater than the sum of the subscription.thruDate +
subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false.
For all such subscriptions, the service runs any service named in
SubscriptionResource.serviceNameOnExpiry.
This provides users of the OFBiz framework who provide subscriptions to their
customers using the framework, to trigger an external deprovisioning action
when a subscription expires, implemented as a service whose name is inserted
into SubscriptionResource.serviceNameOnExpiry.
Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry
is run every time the master service runServiceUponSubscriptionExpiry goes
through its algorithm (once a day in the demo data). Typically, for
subscriptions which require a deprovisioning action when the subscription
expired, one and only one deprovisioning action would be required.
proposed solution
---
To resolve this, it is being proposed to make the following adjustments:
a) augment the OFBiz data model with the following new field:
Subscription.expirationCompletedDate
b) modify the algorithm of runServiceUponSubscriptionExpiry to also check
whether the expiry service has already run, by checking that
expirationCompletedDate is null.
- if expirationCompletedDate is null (and the other conditions are
satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and
update the date/time into expirationCompletedDate
- if expirationCompletedDate is not null, skip the expired subscription and
move to the next
Testing
-
1. create a new subscription through OFBiz with demo data
2. modify the subscription's thru date and gracePeriodOnExpiry so the result
of their addition is in the past of the system date
3. verify that Subscription.expirationCompletedDate is empty
4. either wait for the daily running of runServiceUponSubscriptionExpiry, or
trigger the service manually
5. verify that the log file contains a reference to the subscription having
expired, and that Subscription. expirationCompletedDate contains the
date/time the service was run
6. either wait for the daily running of runServiceUponSubscriptionExpiry, or
trigger the service manually, for a second time
7. verify that the log file does not contain a reference to the subscription
having expired, and that Subscription.expirationCompletedDate still contains
the date/time the service was run
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203345#comment-14203345
]
Jacques Le Roux commented on OFBIZ-5848:
Deepak, yes, I already use
https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/
Jacopo, I agree about no longer supporting R11.04 (actually it's already a
fact).
For the R12.04, let's see if we can reasonably use Java 7 indeed.
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (OFBIZ-5848) Poodle-disable sslv3
[
https://issues.apache.org/jira/browse/OFBIZ-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato reopened OFBIZ-5848:
--
Reopening this ticket to finalize the back porting to the release branches
Poodle-disable sslv3
Key: OFBIZ-5848
URL: https://issues.apache.org/jira/browse/OFBIZ-5848
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Environment: unix
Reporter: Poodle Fixer
Assignee: Jacques Le Roux
Priority: Critical
Labels: patch, security
Fix For: Upcoming Branch, 12.04.06, 13.07.02
{panel:title= WARNING ABOUT THE FIX|bgColor=red}
*We will certainly have to evolve this in the future because this correction
forces the protocol to TLSv1.2*
{panel}
[~jacques.le.roux]: I have put a reminder for myself to follow the status of
the Poodle issue in Tomcat
Hi there--
This topic seemed relevant because it is a major security issue that recently
came up and will affect many ecommerce sites for ofbiz.
I am in process of trying to disable sslv3 on our version of of
ofbiz uses tomcat 6.
This is to eliminate the security vulnerability from poodle bleed.
http://www.symantec.com/connect/blogs/ssl-30-vulnerability-poodle-bug-aka-poodlebleed
We have tried updating the of ofbiz-containers.xml file like below, but it
did not disable sslv3. Poodle is still there.
I have also seen fixes that update server.xml with something similar.
property name=sslProtocol value=TLS/
property name=sslEnabledProtocols value=TLSv1/
Has anyone else had luck fixing the poodle issue on Apache ofbiz?
Or in any of biz products… where is the best place to fix this in of biz??
Thanks!
The Poodle fixer :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[ https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato updated OFBIZ-5793: - Fix Version/s: (was: Trunk) Upcoming Branch modify logic to only run expiry service once when subscription expires -- Key: OFBIZ-5793 URL: https://issues.apache.org/jira/browse/OFBIZ-5793 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Environment: not relevant Reporter: Ivan Cauchi Assignee: Jacopo Cappellato Priority: Minor Labels: subscription Fix For: Upcoming Branch Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch Original Estimate: 672h Remaining Estimate: 672h Background --- Recenlty, the trunk version of OFBiz was augmented with a new service called runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled to run, using the demo data, once a day. Its algorithm looks up all subscriptions which have expired, which is defined as the current time being greater than the sum of the subscription.thruDate + subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false. For all such subscriptions, the service runs any service named in SubscriptionResource.serviceNameOnExpiry. This provides users of the OFBiz framework who provide subscriptions to their customers using the framework, to trigger an external deprovisioning action when a subscription expires, implemented as a service whose name is inserted into SubscriptionResource.serviceNameOnExpiry. Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry is run every time the master service runServiceUponSubscriptionExpiry goes through its algorithm (once a day in the demo data). Typically, for subscriptions which require a deprovisioning action when the subscription expired, one and only one deprovisioning action would be required. proposed solution --- To resolve this, it is being proposed to make the following adjustments: a) augment the OFBiz data model with the following new field: Subscription.expirationCompletedDate b) modify the algorithm of runServiceUponSubscriptionExpiry to also check whether the expiry service has already run, by checking that expirationCompletedDate is null. - if expirationCompletedDate is null (and the other conditions are satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and update the date/time into expirationCompletedDate - if expirationCompletedDate is not null, skip the expired subscription and move to the next Testing - 1. create a new subscription through OFBiz with demo data 2. modify the subscription's thru date and gracePeriodOnExpiry so the result of their addition is in the past of the system date 3. verify that Subscription.expirationCompletedDate is empty 4. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually 5. verify that the log file contains a reference to the subscription having expired, and that Subscription. expirationCompletedDate contains the date/time the service was run 6. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually, for a second time 7. verify that the log file does not contain a reference to the subscription having expired, and that Subscription.expirationCompletedDate still contains the date/time the service was run -- This message was sent by Atlassian JIRA (v6.3.4#6332)
search in documentation
The search function in http://ofbiz.apache.org/documentation.html seems not work. There is no button to submit a search input and pressing ENTER does not submit the search. It would be helpful to search all sources with one search function.
javascript doc - missing links
In https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo some links to javascript and ajax e.g. in section Ajax - Javascript - Json An easy way to get a data structure from server to Javascript in client browser and Integrate OFBiz with Yui-Ext seem to be not valid anymore. Did the articles moved somewhere else? Is there any further documentation on javascript/ajax? I would like to choose a product-list in ecommerce via javascript/ajax and could not find an example for this. Thank you for help!
RE: search in documentation
It is working for me (with firefox). I had to press enter and it works. Select end user documentation, enter catalog in the search parameter and hit enter. Here is the result of my query: https://cwiki.apache.org/confluence/dosearchsite.action?where=OFBENDUSERqueryString=catalog Regards: Ejaz Ahmed Date: Sat, 8 Nov 2014 13:04:12 +0100 From: i...@agentur-m3.de To: dev@ofbiz.apache.org Subject: search in documentation The search function in http://ofbiz.apache.org/documentation.html seems not work. There is no button to submit a search input and pressing ENTER does not submit the search. It would be helpful to search all sources with one search function.
Re: search in documentation
Enter works here. There is also no button in Firefox search bar, for instance. Adding an option for all workspace is a good idea. But the only way I know for that is to have favourites Confluence workspaces (obviously here OFBiz ones) where to search. AFAIK favourites workspaces are only available to Confluence profiles. I guess you see the problem. We recently discussed the idea of grouping all Confluence workspaces in one. But this means a lot of restructuring effort, when we only are slowly revamping the doc... This could be done after this phase... Jacques Le 08/11/2014 13:04, i...@agentur-m3.de a écrit : The search function in http://ofbiz.apache.org/documentation.html seems not work. There is no button to submit a search input and pressing ENTER does not submit the search. It would be helpful to search all sources with one search function.
[jira] [Commented] (OFBIZ-5853) The createPartyRole service does not check a duplicate key.
[
https://issues.apache.org/jira/browse/OFBIZ-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203432#comment-14203432
]
Nicolas Malin commented on OFBIZ-5853:
--
Hi Hans I understand that on old time it was more easier to call a create
service with test presence to sure they was no error on creation. But as says
Leon now we are more than 100 createPartyRole calling. After a quick check :
~50 are present on party creation service, so it's good using.
~40 are present on with a check sequence like this :
{code}
entity-one entity-name=partyRole
if-empty field=partyRole
call-service service-name=createPartyRole/
/if-empty
{code}
only five call directly createPartyRole without check and have a pk conflict
possibility. My apologize I don't detected them during my control.
After that we have some code like this :
{code}
eca service=createBillingAccountRole event=invoke
condition field-name=roleTypeId operator=is-not-empty/
condition field-name=partyId operator=is-not-empty/
action service=ensurePartyRole mode=sync/
/eca
{code}
Like you says we have many entities that use partyRole as pk and we have
different management. I don't search to change create by ensure just I prefer
it (I admit when I drink my coffee I remember that it's a better name :) ) but
to increase the using coherence.
In the other way, the crud service have generally this naming convention
create${EntityName}, update${EntityName} and remove${EntityName}. At a
crossroads, use createPartyRole for creation only and ensurePartyRole to create
a party role only if not exist would be appear that a real good compromise.
It's the reason that I don't jump to revert createPartyRole, simply that we
lost some coherence and I think isn't a good way.
The createPartyRole service does not check a duplicate key.
---
Key: OFBIZ-5853
URL: https://issues.apache.org/jira/browse/OFBIZ-5853
Project: OFBiz
Issue Type: Bug
Components: party
Affects Versions: Trunk
Reporter: Supatthra Nawicha
Assignee: Nicolas Malin
Priority: Minor
Fix For: Trunk
Attachments: OFBIZ-5853.patch, OFBIZ-5853.patch,
ofbizbug_CreatePartyroleService.diff
The createPartyRole service is changed from minilang to entity-auto which
does not check a duplicate key. It effect to the
createPartyRelationshipContactAccount service which call the createPartyRole
service without check a duplicate key. And it might effect to other code that
call the createPartyRole service as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: search in documentation
I use firefox 33.0 with Ubuntu Trusty 14.4. The page does not react on ENTER key. I tried this: http://www.quirksmode.org/js/keys.html in anothter TAB and ENTER is detected.
[jira] [Commented] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[ https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203449#comment-14203449 ] Ivan Cauchi commented on OFBIZ-5793: thank you Jacopo for your interest, review and commit. We have noted your suggestions, with which we agree. We'll bundle them into a future change to the code. I'll be updating Confluence with a description of the amended functionality. Thanks again. modify logic to only run expiry service once when subscription expires -- Key: OFBIZ-5793 URL: https://issues.apache.org/jira/browse/OFBIZ-5793 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Environment: not relevant Reporter: Ivan Cauchi Assignee: Jacopo Cappellato Priority: Minor Labels: subscription Fix For: Upcoming Branch Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch Original Estimate: 672h Remaining Estimate: 672h Background --- Recenlty, the trunk version of OFBiz was augmented with a new service called runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled to run, using the demo data, once a day. Its algorithm looks up all subscriptions which have expired, which is defined as the current time being greater than the sum of the subscription.thruDate + subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false. For all such subscriptions, the service runs any service named in SubscriptionResource.serviceNameOnExpiry. This provides users of the OFBiz framework who provide subscriptions to their customers using the framework, to trigger an external deprovisioning action when a subscription expires, implemented as a service whose name is inserted into SubscriptionResource.serviceNameOnExpiry. Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry is run every time the master service runServiceUponSubscriptionExpiry goes through its algorithm (once a day in the demo data). Typically, for subscriptions which require a deprovisioning action when the subscription expired, one and only one deprovisioning action would be required. proposed solution --- To resolve this, it is being proposed to make the following adjustments: a) augment the OFBiz data model with the following new field: Subscription.expirationCompletedDate b) modify the algorithm of runServiceUponSubscriptionExpiry to also check whether the expiry service has already run, by checking that expirationCompletedDate is null. - if expirationCompletedDate is null (and the other conditions are satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and update the date/time into expirationCompletedDate - if expirationCompletedDate is not null, skip the expired subscription and move to the next Testing - 1. create a new subscription through OFBiz with demo data 2. modify the subscription's thru date and gracePeriodOnExpiry so the result of their addition is in the past of the system date 3. verify that Subscription.expirationCompletedDate is empty 4. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually 5. verify that the log file contains a reference to the subscription having expired, and that Subscription. expirationCompletedDate contains the date/time the service was run 6. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually, for a second time 7. verify that the log file does not contain a reference to the subscription having expired, and that Subscription.expirationCompletedDate still contains the date/time the service was run -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: search in documentation
I also use firefox 33.0 on Ubuntu 14.04 and it still works for me. Maybe you have some custom configurations which are causing this behavior. Regards: Ejaz Ahmed Date: Sat, 8 Nov 2014 15:03:29 +0100 From: i...@agentur-m3.de To: dev@ofbiz.apache.org Subject: Re: search in documentation I use firefox 33.0 with Ubuntu Trusty 14.4. The page does not react on ENTER key. I tried this: http://www.quirksmode.org/js/keys.html in anothter TAB and ENTER is detected.
[jira] [Closed] (OFBIZ-5793) modify logic to only run expiry service once when subscription expires
[ https://issues.apache.org/jira/browse/OFBIZ-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato closed OFBIZ-5793. modify logic to only run expiry service once when subscription expires -- Key: OFBIZ-5793 URL: https://issues.apache.org/jira/browse/OFBIZ-5793 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Environment: not relevant Reporter: Ivan Cauchi Assignee: Jacopo Cappellato Priority: Minor Labels: subscription Fix For: Upcoming Branch Attachments: OFBIZ-5793.patch, OFBIZ-5793.v3.patch Original Estimate: 672h Remaining Estimate: 672h Background --- Recenlty, the trunk version of OFBiz was augmented with a new service called runServiceUponSubscriptionExpiry through JIRA5333. This service is scheduled to run, using the demo data, once a day. Its algorithm looks up all subscriptions which have expired, which is defined as the current time being greater than the sum of the subscription.thruDate + subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is false. For all such subscriptions, the service runs any service named in SubscriptionResource.serviceNameOnExpiry. This provides users of the OFBiz framework who provide subscriptions to their customers using the framework, to trigger an external deprovisioning action when a subscription expires, implemented as a service whose name is inserted into SubscriptionResource.serviceNameOnExpiry. Currently, the service mentioned in SubscriptionResource.serviceNameOnExpiry is run every time the master service runServiceUponSubscriptionExpiry goes through its algorithm (once a day in the demo data). Typically, for subscriptions which require a deprovisioning action when the subscription expired, one and only one deprovisioning action would be required. proposed solution --- To resolve this, it is being proposed to make the following adjustments: a) augment the OFBiz data model with the following new field: Subscription.expirationCompletedDate b) modify the algorithm of runServiceUponSubscriptionExpiry to also check whether the expiry service has already run, by checking that expirationCompletedDate is null. - if expirationCompletedDate is null (and the other conditions are satisfied), run the service in SubscriptionResource.serviceNameOnExpiry and update the date/time into expirationCompletedDate - if expirationCompletedDate is not null, skip the expired subscription and move to the next Testing - 1. create a new subscription through OFBiz with demo data 2. modify the subscription's thru date and gracePeriodOnExpiry so the result of their addition is in the past of the system date 3. verify that Subscription.expirationCompletedDate is empty 4. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually 5. verify that the log file contains a reference to the subscription having expired, and that Subscription. expirationCompletedDate contains the date/time the service was run 6. either wait for the daily running of runServiceUponSubscriptionExpiry, or trigger the service manually, for a second time 7. verify that the log file does not contain a reference to the subscription having expired, and that Subscription.expirationCompletedDate still contains the date/time the service was run -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: search in documentation
Maybe you have some custom configurations which are causing this behavior. I tried to search for any configuration to cause this, but have no idea what it could be. In the meantime inserting the line: input type=submit name=submit value=Search! after this tag input id=searchDocs value=Search... class=class1 class2 accesskey=s name=queryString type=text solves the problem for me. Maybe inserting a button like that sometime could be helpful. Am 08.11.2014 um 15:41 schrieb Ejaz Ahmed: I also use firefox 33.0 on Ubuntu 14.04 and it still works for me.
Re: search in documentation
I use 33.0.2 w/o enter pb Jacques Le 08/11/2014 15:03, i...@agentur-m3.de a écrit : I use firefox 33.0 with Ubuntu Trusty 14.4. The page does not react on ENTER key. I tried this: http://www.quirksmode.org/js/keys.html in anothter TAB and ENTER is detected.
[jira] [Assigned] (OFBIZ-5800) Manage multi pk with sub-sequence on entity-auto
[ https://issues.apache.org/jira/browse/OFBIZ-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin reassigned OFBIZ-5800: Assignee: Nicolas Malin Manage multi pk with sub-sequence on entity-auto Key: OFBIZ-5800 URL: https://issues.apache.org/jira/browse/OFBIZ-5800 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Nicolas Malin Assignee: Nicolas Malin Priority: Minor Labels: entity-auto Fix For: Upcoming Branch Attachments: OFBIZ-5800.patch, OFBIZ-5800.patch Add the possibility to the entity-auto engine on the create action to manage entities with more than 2 primary keys which one is under sub sequence or fromDate, like PerfReview (employeePartyId, employeeRoleTypeId, *perfReviewId*) or PartyQual (partyId, partyQualTypeId, *fromDate*). Improve return message for the create action if the entity value exist and the delete action if the entity value not exist instead of the database message error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-5800) Manage multi pk with sub-sequence on entity-auto
[ https://issues.apache.org/jira/browse/OFBIZ-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin closed OFBIZ-5800. Manage multi pk with sub-sequence on entity-auto Key: OFBIZ-5800 URL: https://issues.apache.org/jira/browse/OFBIZ-5800 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Nicolas Malin Priority: Minor Labels: entity-auto Fix For: Upcoming Branch Attachments: OFBIZ-5800.patch, OFBIZ-5800.patch Add the possibility to the entity-auto engine on the create action to manage entities with more than 2 primary keys which one is under sub sequence or fromDate, like PerfReview (employeePartyId, employeeRoleTypeId, *perfReviewId*) or PartyQual (partyId, partyQualTypeId, *fromDate*). Improve return message for the create action if the entity value exist and the delete action if the entity value not exist instead of the database message error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5370) OrderItemShipGrpInvRes incorrect when receiving an inventory item that relates to more than one record
[ https://issues.apache.org/jira/browse/OFBIZ-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203680#comment-14203680 ] Joe Eckard commented on OFBIZ-5370: --- Is this the right approach to fixing the underlying issue? It seems like the “reassignInventoryItems” service will cancel and re-reserve ALL reservations for a specified product - which does avoid the reported problem, but can perform lots of unnecessary work and create many unnecessary artifacts (since it is called every time you receive inventory or perform a physical inventory / variance). I ask only because I encountered this bug in an older codebase through a different set of circumstances, and trying to understand balanceInventoryItems has been a very confusing experience. I would love to see it cleaned up, removed or replaced. My initial impression is that balanceInventoryItems was intended to be called whenever some inventory was added in order to immediately relieve as many backorders as it could. If that is the case, why not look for reservations with quantityNotAvailable 0 instead of the current logic? If that approach is sound, there is still the case where balanceInventoryItems is called as an ECA when you perform a physical inventory and record a negative variance instead of a positive variance, but I think reassignInventoryItems might be the right thing to use there. OrderItemShipGrpInvRes incorrect when receiving an inventory item that relates to more than one record -- Key: OFBIZ-5370 URL: https://issues.apache.org/jira/browse/OFBIZ-5370 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 12.04 Reporter: Christian Carlow Assignee: Anil K Patel Attachments: OFBIZ-5370-trunk.patch OrderItemShipGrpInv records that share the same inventoryItemId calculate incorrect results when receiving inventory for the product. To reproduce: 1. Create an order for product PEPPERS-G with a quantity of 10 and click Finish Order 2. Add another ship group and click Continue 3. Assign 5 of the order items to the second ship group created and then finish the order 4. Navigate to the Receive Inventory page of the WebStoreWarehouse facility 5. Enter PEPPERS-G into the productId field and click Receive Product 6. Enter a quantity of 6 into the quantityAccepted field and click Receive 7. Open the OrderItemShipGrpInvRes table and notice that the quantityNotAvailable field has been set to blank for the first record and 4 for the second record and that they both share the same inventoryItemId 8. Now navigate back to the Receive Items page and receive in the product again but with a quantity of 1 9. Refresh the OrderItemShipGrpInvRes results and notice that the first record has a new inventory item applied to it with a quantity of 1 and the other record has been updated to reflect a new quantityNotAvailable value. It seems like OrderItemShipGrpInvRes should be deleted anytime the quantityNotAvailable field gets set to 0, blank, or null. I've noticed this logic performed in other methods that deal the entity. Step 9 should not add quantityNotAvailable back to the first record one it has been fulfilled. The second item was supposed to have its quantityNotAvailable field decremented by 1 but no change took plce for it. I believe this problem is probably caused by an inventoryItemId being associated with more than one record in the table. This problem basically happens anytime the inventory received is greater than the quantityNotAvailable field of the first OrderItemShipGrpRes table. It happens when you have orders from two different customers and you receive more inventory than the quantityNotAvailable for the first customer order item. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
