Dev - Public CustRequests and busy calendar time block

[Si Chen-2]

Hi everybody -

Couple of data model questions:

1.  What should we use to mark a CustRequest as public?  I noticed a
couple of fields in WorkEffort but nothing like it in CustRequest.  Or
is a CustRequest never supposed to be public?

2.  What should we use to mark a block of time as "unavailable", so
another event can't be scheduled alongside it?  I didn't see anything on
WorkEffort for this.

Thanks,

Si
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

On Jan 26, 2006, at 1:39 PM, Si Chen wrote:

> Hi everybody -
>
> Couple of data model questions:
>
> 1.  What should we use to mark a CustRequest as public?  I noticed a
> couple of fields in WorkEffort but nothing like it in CustRequest.  Or
> is a CustRequest never supposed to be public?

What do you have in mind here? Why would a request be public? Are you  
talking about something like a project issue tracker or something? If  
so it would be best to have permissions on the "project" (WorkEffort)  
and see if the user can see it, and thereby see if the request can be  
viewed by the user.

> 2.  What should we use to mark a block of time as "unavailable", so
> another event can't be scheduled alongside it?  I didn't see  
> anything on
> WorkEffort for this.

I'm not sure where you're going with this either... In general some  
background information as to intent or context is not only helpful  
for data modeling, but critical. In reality, that's all there is  
(intent/context).

The reason this confuses me is because that is basically what a  
calendar event is: scheduled or blocked out time. There is also a  
work effort type for availability which is the opposite, ie it  
denotes explicitly when a certain party or resource (fixed asset,  
facility, etc) is available.

-David


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Hi David,

David E. Jones wrote:

>
> On Jan 26, 2006, at 1:39 PM, Si Chen wrote:
>
>> Hi everybody -
>>
>> Couple of data model questions:
>>
>> 1.  What should we use to mark a CustRequest as public?  I noticed a
>> couple of fields in WorkEffort but nothing like it in CustRequest.  Or
>> is a CustRequest never supposed to be public?
>
>
> What do you have in mind here? Why would a request be public? Are you  
> talking about something like a project issue tracker or something? If  
> so it would be best to have permissions on the "project" (WorkEffort)  
> and see if the user can see it, and thereby see if the request can be  
> viewed by the user.
>

Yes, something like a JIRA site.  So you would create a Request for
Support, which is a CustRequest, that would be visible to other users as
well.  Are you saying that it should automatically cause a WorkEffort to
be created?

>> 2.  What should we use to mark a block of time as "unavailable", so
>> another event can't be scheduled alongside it?  I didn't see  
>> anything on
>> WorkEffort for this.
>
>
> I'm not sure where you're going with this either... In general some  
> background information as to intent or context is not only helpful  
> for data modeling, but critical. In reality, that's all there is  
> (intent/context).
>

WorkEffort can be a Meeting over a scheduled time period.  Is there
anyway to mark someone as "unavailable" while he/she is in the meeting,
so another meeting can't be scheduled during an overlapping time?

> The reason this confuses me is because that is basically what a  
> calendar event is: scheduled or blocked out time. There is also a  
> work effort type for availability which is the opposite, ie it  
> denotes explicitly when a certain party or resource (fixed asset,  
> facility, etc) is available.
>
> -David
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

On Jan 26, 2006, at 2:58 PM, Si Chen wrote:

> Hi David,
>
> David E. Jones wrote:
>
>>
>> On Jan 26, 2006, at 1:39 PM, Si Chen wrote:
>>
>>> Hi everybody -
>>>
>>> Couple of data model questions:
>>>
>>> 1.  What should we use to mark a CustRequest as public?  I noticed a
>>> couple of fields in WorkEffort but nothing like it in  
>>> CustRequest.  Or
>>> is a CustRequest never supposed to be public?
>>
>>
>> What do you have in mind here? Why would a request be public? Are you
>> talking about something like a project issue tracker or something? If
>> so it would be best to have permissions on the "project" (WorkEffort)
>> and see if the user can see it, and thereby see if the request can be
>> viewed by the user.
>>
> Yes, something like a JIRA site.  So you would create a Request for
> Support, which is a CustRequest, that would be visible to other  
> users as
> well.  Are you saying that it should automatically cause a  
> WorkEffort to
> be created?

What I was thinking of is pretty much the other way around if it is  
in the context of a "project". You would have a WorkEffort that  
represented the project, like OFBIZ, OFBAC, etc on our Jira server,  
and the permissions of the request (aka in Jira: issue) would be  
inherited from the project (represented by a WorkEffort).

Not that we have to implement it this way... I think it makes sense  
to have public and private projects (which is what Jira has), but  
perhaps also to have public and private support requests. In other  
words, a private support request to a public project. If that was  
needed then yes, a flag or enum or something would be needed on the  
CustRequest entity.

>>> 2.  What should we use to mark a block of time as "unavailable", so
>>> another event can't be scheduled alongside it?  I didn't see
>>> anything on
>>> WorkEffort for this.
>>
>>
>> I'm not sure where you're going with this either... In general some
>> background information as to intent or context is not only helpful
>> for data modeling, but critical. In reality, that's all there is
>> (intent/context).
>>
> WorkEffort can be a Meeting over a scheduled time period.  Is there
> anyway to mark someone as "unavailable" while he/she is in the  
> meeting,
> so another meeting can't be scheduled during an overlapping time?

You mean like the little flags in time management software and PDAs  
and such to say what that the person is "busy", or I guess for more  
"advanced" systems they have an option to specify the status of each  
person during the event? This would go on the  
WorkEffortPartyAssignment entity and not the WorkEffortEntity itself  
because it is not per-event, but rather per-person-per-event. There  
is an expectationEnumId, but that is a different concept. I think it  
would make sense to have another enum there for a personal public  
status or something...

-David


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

David E. Jones wrote:

>On Jan 26, 2006, at 2:58 PM, Si Chen wrote:
>
>  
>
>>Hi David,
>>
>>David E. Jones wrote:
>>
>>    
>>
>>>On Jan 26, 2006, at 1:39 PM, Si Chen wrote:
>>>
>>>      
>>>
>>>>Hi everybody -
>>>>
>>>>Couple of data model questions:
>>>>
>>>>1.  What should we use to mark a CustRequest as public?  I noticed a
>>>>couple of fields in WorkEffort but nothing like it in  
>>>>CustRequest.  Or
>>>>is a CustRequest never supposed to be public?
>>>>        
>>>>
>>>What do you have in mind here? Why would a request be public? Are you
>>>talking about something like a project issue tracker or something? If
>>>so it would be best to have permissions on the "project" (WorkEffort)
>>>and see if the user can see it, and thereby see if the request can be
>>>viewed by the user.
>>>
>>>      
>>>
>>Yes, something like a JIRA site.  So you would create a Request for
>>Support, which is a CustRequest, that would be visible to other  
>>users as
>>well.  Are you saying that it should automatically cause a  
>>WorkEffort to
>>be created?
>>    
>>
>
>What I was thinking of is pretty much the other way around if it is  
>in the context of a "project". You would have a WorkEffort that  
>represented the project, like OFBIZ, OFBAC, etc on our Jira server,  
>and the permissions of the request (aka in Jira: issue) would be  
>inherited from the project (represented by a WorkEffort).
>
>Not that we have to implement it this way... I think it makes sense  
>to have public and private projects (which is what Jira has), but  
>perhaps also to have public and private support requests. In other  
>words, a private support request to a public project. If that was  
>needed then yes, a flag or enum or something would be needed on the  
>CustRequest entity.
>
>  
>

That's what I thought.  Ok, we'll deal with it when we get there.

>>>>2.  What should we use to mark a block of time as "unavailable", so
>>>>another event can't be scheduled alongside it?  I didn't see
>>>>anything on
>>>>WorkEffort for this.
>>>>        
>>>>
>>>I'm not sure where you're going with this either... In general some
>>>background information as to intent or context is not only helpful
>>>for data modeling, but critical. In reality, that's all there is
>>>(intent/context).
>>>
>>>      
>>>
>>WorkEffort can be a Meeting over a scheduled time period.  Is there
>>anyway to mark someone as "unavailable" while he/she is in the  
>>meeting,
>>so another meeting can't be scheduled during an overlapping time?
>>    
>>
>
>You mean like the little flags in time management software and PDAs  
>and such to say what that the person is "busy", or I guess for more  
>"advanced" systems they have an option to specify the status of each  
>person during the event? This would go on the  
>WorkEffortPartyAssignment entity and not the WorkEffortEntity itself  
>because it is not per-event, but rather per-person-per-event. There  
>is an expectationEnumId, but that is a different concept. I think it  
>would make sense to have another enum there for a personal public  
>status or something...
>
>  
>

This is a great point.  Thanks for clarifying it and for your feedback
in general.

>-David
>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev