OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-3071) assigning security group to a party without validations

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Nicolas Malin (Jira)

[jira] Created: (OFBIZ-3071) assigning security group to a party without validations

assigning security group to a party without validations
-------------------------------------------------------

Key: OFBIZ-3071
URL: https://issues.apache.org/jira/browse/OFBIZ-3071
Project: OFBiz
Issue Type: Bug
Reporter: Abdullah Shaikh
Priority: Minor

When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.

If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-3071) assigning security group to a party without validations

[ https://issues.apache.org/jira/browse/OFBIZ-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdullah Shaikh updated OFBIZ-3071:
-----------------------------------

Attachment: OFBIZ-3071_assigning security group to a party without validations.patch

Checked if the thruDate is specified in previous record, if not then a error message during adding of new record and also if specified, then if fromDate of new record is after the thruDate of the previous record otherwise an error message.

> assigning security group to a party without validations
> -------------------------------------------------------
>
> Key: OFBIZ-3071
> URL: https://issues.apache.org/jira/browse/OFBIZ-3071
> Project: OFBiz
> Issue Type: Bug
> Reporter: Abdullah Shaikh
> Priority: Minor
> Attachments: OFBIZ-3071_assigning security group to a party without validations.patch
>
>
> When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.
> If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

David E. Jones commented on OFBIZ-3071:
---------------------------------------

There are good reasons sometimes to have records with overlapping dates. The pattern generally used (hopefully always used!) for finding a unique record is to filter out all records where the current date is outside the record's date range, and also sort by the fromDate (most recent, ie highest, first).

There are some nice things you can do with that, like setting up a temporary override that will become active with the fromDate comes up and will automatically revert to the previous record once the thruDate is crossed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Abdullah Shaikh commented on OFBIZ-3071:
----------------------------------------

Yes the records with overlapping dates has good reasons I was not aware of, got something new learned.

But still I guess,

1) If thruDate is not specified, the record goes forever, and we shouldn't allow one more record.

2) If thruDate specified, then I guess the overlapping should be limited to a limited time, what I mean is, the next overlapping records fromDate should be validate to be a month or so, before the thruDate of the previous record.

For example :

I have added PROJECTUSER group to a specific user, the fromDate & thruDate of first record was 2007-10-10 10:55:10.000 & 2009-10-02 10:55:26.000 respectively, and then I added one more record, with fromDate & thruDate to be 2007-11-10 10:55:10.000 & 2009-10-02 10:55:26.000 respectively.

In this case the validation should have been that,

1) The fromDate of second record can be maximum of a month before the thruDate of the previous record.
2) The thruDate of the second record should be more than that of the previous record, bcoz I guess no point in having same thruDate

I couldn't look for more scenarios because of time constraint, but I would definitely do it when time permits.

Please let me know if this makes sense or if you have some other scenarios or ideas, I would be happy to makes changes to the patch and resubmit.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Abdullah Shaikh commented on OFBIZ-3071:
----------------------------------------

Sorry forgot to add that the time limit for validation I guess should be configurable in a property file or a database table, if something like this is already configured in a database table.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Jacques Le Roux commented on OFBIZ-3071:
----------------------------------------

Hi Abdullah,

{quote}
1) If thruDate is not specified, the record goes forever, and we shouldn't allow one more record.
{quote}

This would prevent to do what David said, you could not create a temporary permission for a limited span of time

{quote}
2) If thruDate specified, then I guess the overlapping should be limited to a limited time, what I mean is, the next overlapping records fromDate should be validate to be a month or so, before the thruDate of the previous record.
{quote}

Why a month ? I can see any reasons to chose a month or anything else. Even int the case of 2 "same" tuples with the thruDate not specified, we would simply takeinto account the "highest" (the one with the most recent fromDate)

In your example,
2007-10-10 10:55:10.000 & 2009-10-02 10:55:26.000
2007-11-10 10:55:10.000 & 2009-10-02 10:55:26.000
with David's scenario the 1st tuple (2007-10-10) would be simply ignored as it would be replaced by the 2d. I can't see any problems with that.

I can't see any reasons to have a single properties to set span of time. Sorry but, except if you have strong argument, I think I will close this issue soon as invalid.

Thanks

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Gray updated OFBIZ-3071:
------------------------------

Issue Type: Improvement (was: Bug)

Changing type from Bug to Improvement

> assigning security group to a party without validations
> -------------------------------------------------------
>
> Key: OFBIZ-3071
> URL: https://issues.apache.org/jira/browse/OFBIZ-3071
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Abdullah Shaikh
> Priority: Minor
> Attachments: OFBIZ-3071_assigning security group to a party without validations.patch
>
>
> When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.
> If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Abdullah Shaikh commented on OFBIZ-3071:
----------------------------------------

Hmm.. yes I agree with David's explanation but there were some doubts in my mind, but I couldn't recollect them as its been a long time I opened this issue.

But the doubt I remember is regarding the permission without thruDate, I couldn't understand "you could not create a temporary permission for a limited span of time", I guess if its a temporary permission it should be for a limited time.

Let me modify my example as per my argument regarding thruDate:

2007-10-10 10:55:10.000 & NO THRU DATE
2007-11-10 10:55:10.000 & NO THRU DATE

In the above example the first permission 2007-10-10 as been specified without thruDate this means the records will go on forever.
The second permission 2007-11-10 also doesn't have thruDate and this too will go on forever.

So as per the above scenario both the permissions will go on forever, for the same thing there are 2 permissions.

What I feel is we shouldn't allow the user to enter one more record without thruDate for the same permission type as no use of the second record.

If the second record is enter with thruDate then it makes sense as it will expire on the mentioned thruDate and the record without thruDate will be active.

I don't know if this is making sense, I mean this was what I was having in mind. Maybe I am missing something else.

Let me know what do you think of this.

> assigning security group to a party without validations
> -------------------------------------------------------
>
> Key: OFBIZ-3071
> URL: https://issues.apache.org/jira/browse/OFBIZ-3071
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Abdullah Shaikh
> Priority: Minor
> Attachments: OFBIZ-3071_assigning security group to a party without validations.patch
>
>
> When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.
> If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Jacques Le Roux commented on OFBIZ-3071:
----------------------------------------

Yes it makes sens but do we really need to constrain that ?
What kind of trouble may we have ? For me it's only redundant and not a big deal;
Also is your patch handling this issue and only this issue ?

> assigning security group to a party without validations
> -------------------------------------------------------
>
> Key: OFBIZ-3071
> URL: https://issues.apache.org/jira/browse/OFBIZ-3071
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Abdullah Shaikh
> Priority: Minor
> Attachments: OFBIZ-3071_assigning security group to a party without validations.patch
>
>
> When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.
> If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations

In reply to this post by Nicolas Malin (Jira)

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

Abdullah Shaikh commented on OFBIZ-3071:
----------------------------------------

Good to hear that it makes sense ..

Even if we don't constrain that it should work just fine, we wont have any trouble.

But what I feel is if we have found the issue then lets just fix it, only because it wont cause any trouble or it's only redundant that will do, will accumulate more and more of this kind of issues and maybe later we will start finding this kind of issues and fixing it later.

As Ofbiz is an ERP it maybe grow more & more bigger, it's better if we fix the issues irrespective of how big or small the issue is.

I dont remember but I guess the patch was handling more than this ..

If you feel that we can commit the thruDate fix, then I can work on the patch to just fix this issue and remove the other stuff, let me know.

> assigning security group to a party without validations
> -------------------------------------------------------
>
> Key: OFBIZ-3071
> URL: https://issues.apache.org/jira/browse/OFBIZ-3071
> Project: OFBiz
> Issue Type: Improvement
> Reporter: Abdullah Shaikh
> Priority: Minor
> Attachments: OFBIZ-3071_assigning security group to a party without validations.patch
>
>
> When adding user login to Security Group, the fromDate & thruDate input fields are not mandatory, if not specified the fromDate is set to current timestamop and thruDate is entered in database as null, which means the user login is assigned that Security Group forever, but when if the same Security Group is added, it again adds it, but instead it should check that if the thruDate is null in the already entered record then shouldn't add new record.
> If incase the thruDate is specified during the creation of 1st record then while adding the 2nd record for the same Security Group, it should check if the thruDate of previous record is before the fromDate of the new record, this check also doesn't happen.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.