Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5551

Cannot delete the record When Server Timezone and Application timeZone are different.

    Details

      Description

      I have added a role 'PROJECTADMIN' to admin when System timezone is in CST, Then i changed the timezone to 'Hongkong' and tried to delete the recoed, Nothing happens.

        Activity

        Hide
        pfm.smits Pierre Smits added a comment -

        It seems to me that this is correct behaviour.

        When a role has been assigned deleting it would have far reaching consequences on depending data elements in various entities. Expiring the applicability of the role by setting a thruDate as end date is a better solution.

        Regards,

        Pierre

        Show
        pfm.smits Pierre Smits added a comment - It seems to me that this is correct behaviour. When a role has been assigned deleting it would have far reaching consequences on depending data elements in various entities. Expiring the applicability of the role by setting a thruDate as end date is a better solution. Regards, Pierre
        Hide
        jacopoc Jacopo Cappellato added a comment -

        Could you please provide some more information about the screen you have used, what is the timestamp in the record and what is the timestamp in the session when you try to delete it? do you see errors in the log?

        Show
        jacopoc Jacopo Cappellato added a comment - Could you please provide some more information about the screen you have used, what is the timestamp in the record and what is the timestamp in the session when you try to delete it? do you see errors in the log?
        Hide
        madppiper Paul Piper added a comment -

        SenthilMurugan, are you trying to remove the entry through the webtools management tools, or directly in the Party Management Application? It would also be helpful if you could share a log entry on this behalf. I have a feeling that if you are trying to forcefully remove the entry, the referencing entries may stop you from doing so unless you edit these as well...

        Pierre's assessment is right in general, however, in most cases a true "delete" is not really recommended nowadays, there are a lot of references that might be affected by this, so the recommended way is to set a thrudate and hence invalidate the data.

        Show
        madppiper Paul Piper added a comment - SenthilMurugan , are you trying to remove the entry through the webtools management tools, or directly in the Party Management Application? It would also be helpful if you could share a log entry on this behalf. I have a feeling that if you are trying to forcefully remove the entry, the referencing entries may stop you from doing so unless you edit these as well... Pierre's assessment is right in general, however, in most cases a true "delete" is not really recommended nowadays, there are a lot of references that might be affected by this, so the recommended way is to set a thrudate and hence invalidate the data.
        Hide
        sentmca SenthilMurugan added a comment - - edited

        I am trying to remove it in Partymgr security permission section, (Clicked delete button, expecting it to add thrudate so that it will not display in the screen.). I have debuge the application and found that the from date is one of the composit key which is passed from the hidden field as it is in the database and when passing through service engine it adds the time based on the current application timestamp (Localizing the form fields), So its not able to match with the databse record.

        I will send you the log as well.

        Show
        sentmca SenthilMurugan added a comment - - edited I am trying to remove it in Partymgr security permission section, (Clicked delete button, expecting it to add thrudate so that it will not display in the screen.). I have debuge the application and found that the from date is one of the composit key which is passed from the hidden field as it is in the database and when passing through service engine it adds the time based on the current application timestamp (Localizing the form fields), So its not able to match with the databse record. I will send you the log as well.
        Hide
        jacopoc Jacopo Cappellato added a comment -

        Steps to recreate:

        1. load demo data and start ofbiz
        2. from any screen in the backend, change the timezone to e.g. Alaska Daylight Time
        3. go to https://localhost:8443/partymgr/control/EditUserLoginSecurityGroups?userLoginId=AcctBuyer
        4. press the "Remove" button
        Show
        jacopoc Jacopo Cappellato added a comment - Steps to recreate: load demo data and start ofbiz from any screen in the backend, change the timezone to e.g. Alaska Daylight Time go to https://localhost:8443/partymgr/control/EditUserLoginSecurityGroups?userLoginId=AcctBuyer press the "Remove" button
        Hide
        jacopoc Jacopo Cappellato added a comment -

        The "Remove" button triggers the service "removeUserLoginFromSecurityGroup" that is defined as engine="entity-auto"; the code in EntityAutoEngine.java attempts to retrieve the record using PrimaryKeyFinder.runFind(...); in this method we have:

        // need the timeZone and locale for conversion, so add here and remove after
        entityContext.put("locale", context.get("locale"));
        entityContext.put("timeZone", context.get("timeZone"));
        modelEntity.convertFieldMapInPlace(entityContext, delegator);
        entityContext.remove("locale");
        entityContext.remove("timeZone");
        

        This is I guess where the fromDate field's value, coming from the db, is modified considering the session timezone (under the assumption it was entered by the user in the session's timezone).

        Show
        jacopoc Jacopo Cappellato added a comment - The "Remove" button triggers the service "removeUserLoginFromSecurityGroup" that is defined as engine="entity-auto"; the code in EntityAutoEngine.java attempts to retrieve the record using PrimaryKeyFinder.runFind(...); in this method we have: // need the timeZone and locale for conversion, so add here and remove after entityContext.put( "locale" , context.get( "locale" )); entityContext.put( "timeZone" , context.get( "timeZone" )); modelEntity.convertFieldMapInPlace(entityContext, delegator); entityContext.remove( "locale" ); entityContext.remove( "timeZone" ); This is I guess where the fromDate field's value, coming from the db, is modified considering the session timezone (under the assumption it was entered by the user in the session's timezone).
        Hide
        jacopoc Jacopo Cappellato added a comment -

        Adrian,

        could you please have a look at my last comment and see if you can provide some help? Feel free to reassign it to me if not or when you are done.
        Thanks

        Show
        jacopoc Jacopo Cappellato added a comment - Adrian, could you please have a look at my last comment and see if you can provide some help? Feel free to reassign it to me if not or when you are done. Thanks
        Hide
        adrianc@hlmksw.com Adrian Crum added a comment -

        I agree with Pierre - the value should be expired, not deleted.

        Aside from that, there might be a problem in the converter framework. The correct value SHOULD be sent to the service:

        DB Timestamp -> Converter -> String
        String -> Converter -> DB Timestamp

        The converters are supposed to be bidirectional:

        A -> B -> A

        should result in no change to A.

        Show
        adrianc@hlmksw.com Adrian Crum added a comment - I agree with Pierre - the value should be expired, not deleted. Aside from that, there might be a problem in the converter framework. The correct value SHOULD be sent to the service: DB Timestamp -> Converter -> String String -> Converter -> DB Timestamp The converters are supposed to be bidirectional: A -> B -> A should result in no change to A.
        Hide
        deepak.dixit Deepak Dixit added a comment -

        Here is the patch for the fix, Expire the UserLoginSecurityGroup record on click on remove button instead of deleting.

        Show
        deepak.dixit Deepak Dixit added a comment - Here is the patch for the fix, Expire the UserLoginSecurityGroup record on click on remove button instead of deleting.
        Hide
        toashishvijay Ashish Vijaywargiya added a comment - - edited

        Thanks SenthilMurugan for reporting the issue and Thanks Deepak for providing the patch.
        Changes are committed at:

        trunk - 1639892
        13.07 - 1639893

        Show
        toashishvijay Ashish Vijaywargiya added a comment - - edited Thanks SenthilMurugan for reporting the issue and Thanks Deepak for providing the patch. Changes are committed at: trunk - 1639892 13.07 - 1639893
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        R12.04 r1639939

        Show
        jacques.le.roux Jacques Le Roux added a comment - R12.04 r1639939

          People

          • Assignee:
            jacopoc Jacopo Cappellato
            Reporter:
            sentmca SenthilMurugan
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 12h
              12h
              Remaining:
              Remaining Estimate - 12h
              12h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development