[jira] Created: (OFBIZ-2427) Cases - Sales Force Automation component

[Nicolas Malin (Jira)]

Cases - Sales Force Automation component
----------------------------------------

                 Key: OFBIZ-2427
                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
             Project: OFBiz
          Issue Type: New Feature
          Components: marketing
    Affects Versions: SVN trunk
            Reporter: Ashish Vijaywargiya
            Priority: Minor
             Fix For: SVN trunk


- A case corrospond to a Request(CustRequest) in OFBiz.
- There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.

Following screens should be implemented in this :

- Create/Edit Case: Following fields should be present on the GUI.
"* (Start next to fields)" - showing the required field.

— Company Name - Lookup showing all the Party Group in the role of "Account"
— Requesting Party* - Lookup to select the existing party in the role of "Contact"
— Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
— Type
— Subject* - Map this field into custRequestName field of CustRequest entity.
— Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
— Description -
— Status - Show this field in Edit mode of request only. (While updating request)

- There will be summary section for the cases and following block will be shown in it.
— First block will be the history of the customer request.
— Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
— Request Items.

- There will be following tab button adjucent to Summary Section.
— Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
— Request Items

Details Left Navigation Section.

First Block: Shortcuts

Create New Case
Find Case
My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
Only show those cases that are not in complete status.

Second Block: Quick Add Case
Fields to be present in this block are:
Company Name
Requesting Party*
Subject*

For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------

I will be working on this.  Thnks.

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------

How are the cases related to custRequest entity.  custRequest entity is used in Orders-Request.
There are also status fields and reasons fields in custRequest
Looking more, the description in the issue is already taken care by the Order-Request feature except for the following
- shortcuts & quickAdd

Please add more info or let me know how it will be different from Order-Request.  Instead, can the Order-Request feature be improved?

Thanks

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Ashish Vijaywargiya commented on OFBIZ-2427:
--------------------------------------------

Hello Aswath,

Its good to see your comment on this.
The idea of introducing the "Cases" header item is that it is very commonly used term in CRM prespective.

We should use the CustRequest entity as it is to solve our purpose if we talk about Cases.
Here we should only reuse the required things and will exclude the extra things.

We are trying to provide the easy navigation option to CSR in SFA component instead of moving different application bar in OFBiz.
If you think that I would like to create a service then that service will go into the Order Manager component and will be reused in the SFA component.

So in short we should reuse the CustRequest entity and its associated entity (services or anything else) in our sfa component.  
Does it make sense to you now ?

"Shorcuts" and "Quick Add" section will be part of SFA component.
Please let us know if you need more help in completing this task !

--
Ashish

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------

Hello Ashish,
Thanks for sharing more info to this.

There is also a WorkEffort Entity.  If you look at the Project-Task, Task feature is reusing WorkEffort entity.  
Can Cases use the WorkEffort?  What would be the difference in CustRequest & WorkEffort.

Also, I think we need an 'assigned to' field.    Because a CSR may create a Case, and assign it to another party.  

Thanks.
Aswath

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Ashish Vijaywargiya commented on OFBIZ-2427:
--------------------------------------------

Hello Aswath,

Thanks for your comment.
Here you go.

CustRequest can be a wish list for new feature or bug fix from a customer and after approval it can be associated with the WorkEffort.(aka task)
Now workeffort can be associated with the so many party using WorkEffortPartyAssignement.
The party is nothing but the person who will work on that task.

There is no need to have "assigned to" field in the CustRequest entity.
If the request is delegated to another person (to change the status or supervise the request) then the old party will be expired and the new party will be created. The responsible entity for this operation is "CustRequestParty". The role of the newly assigned party will be again the request tacker.

Please let us know if you have more question.

--
Ashish Vijaywargiya

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Ashish Vijaywargiya commented on OFBIZ-2427:
--------------------------------------------

To better understand the relationship in b/w the component(WorkEffort, Order, Party & other) interacting with each other please purchase the Data Model Resource Book Volume 1.

Here is the link:
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=sr_1_1?ie=UTF8&s=books&qid=1241775845&sr=1-1

--
Ashish Vijaywargiya

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------

Hello Ashish,
I am understanding the custRequest & the CustRequestParty.  The RequestRoles-UI is used here to create CustRequestParty

Lets say, using the RequestRoles-UI, the new RequestTaker is another party 'DemoEmployee'.  So, now, how does the DemoEmployee know that he is the new RequestTaker?

How does the new RequestTaker approve?

I am trying to understand how the complete Cases end-to-end  will work.

Thanks
Aswath

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

BJ Freeman commented on OFBIZ-2427:
-----------------------------------

More of a esthetics approach
Cases is more medical and legal in terminology.
From ofbiz perspective is seem a project task would be more fitting.
from a CRM perspective a Ticketing system is more appropiate, since there is a lot of communication with the customer or client.
In the implementation I use, this includes,
automatic response for requests assigning a project . the Projet Id is used as the ticket number, instead of the requestID.
MCA is used to link the return messages to the correct Project as  task.s The messages are timelined in the project.
This allow the project managment to be used for assigning the task and tracking resources under workeffort.
Just my two cents.

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Ashish Vijaywargiya commented on OFBIZ-2427:
--------------------------------------------

Hello Aswath,

Here you go:

>> Lets say, using the RequestRoles-UI, the new RequestTaker is another party 'DemoEmployee'. So, now, how does the DemoEmployee know that he is the new RequestTaker?

Good question. An email can be invoked after changing the Request Tacker associated with the Request.
It can be handled in another JIRA issue (or we can say new wish list for feature improvement).

>> How does the new RequestTaker approve?
I don't have enough points for this process right now but here we can take help community members.
I would be thankful to see comments from others in this question.

Let me share what I think about it right now:
First request comes then a request tacker is being assigned to it and then he / she will be responsible for that particular request.
He / She can change the status of that request (Other user having more privilege or have access to Request component can also change the status). And then after accepting that request that can be associated with the workeffort and members can start work on that request (request can be either new feature wish list or bug list)

Thanks !

--
Ashish

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------


Here is my understanding of the Cases:
Cases is another UI which is just a subset of Order-Request UI.  There is no cases ENTITY. Is that correct?

Since Cases is a CustRequest, I am trying to understand CustRequest better, and here is my understanding.
A new CustRequest is created based on the customer input.  Then this CustRequest goes into an approval process. (Currently this workflow is not available OOTB).  Is CustRequest like some paper work in the real scenario?  After this,  a workeffort is created and linked to this CustRequest. WorkEffort is where the actual work is taken care.  Hence both CustRequest and WorkEffort has there own workflow.

MyCases:  It will list all the CustRequests, if the recent partyID in CustRequestParty is same as the logged in partyid.

Thanks.
Aswath

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Aswath Satrasala commented on OFBIZ-2427:
-----------------------------------------

Please provide more inputs on the requirements and design.  I don't have clear picture on end-to-end on how cases will work

Is my previous understanding correct?

What will be the RequestRole of the user who is creating the case?

Thanks.
-Aswath

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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

[Nicolas Malin (Jira)]

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

Pierre Smits commented on OFBIZ-2427:
-------------------------------------

The entities RFI and RFQ are to be regarded as opportunities and should be handled as such.

A RfS is an request that is related to an existing support contract and should be handled from that angle.

But, it could lead to a task assignment and the possibility to register worked hours.

A case could be seen as a set of information related to the account.

> Cases - Sales Force Automation component
> ----------------------------------------
>
>                 Key: OFBIZ-2427
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2427
>             Project: OFBiz
>          Issue Type: New Feature
>          Components: marketing
>    Affects Versions: SVN trunk
>            Reporter: Ashish Vijaywargiya
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> - A case corrospond to a Request(CustRequest) in OFBiz.
> - There are many types of requests including RFI (for information), RFQ (for quote), RFS (for support), and so on.
> Following screens should be implemented in this :
> - Create/Edit Case: Following fields should be present on the GUI.
> "* (Start next to fields)" - showing the required field.
> — Company Name - Lookup showing all the Party Group in the role of "Account"
> — Requesting Party* - Lookup to select the existing party in the role of "Contact"
> — Priority - Keep default priority as the medium (either 4 or 5 on the user interface)
> — Type
> — Subject* - Map this field into custRequestName field of CustRequest entity.
> — Reason - associate this field with the enumeration entity and create few records there so that it could be referred here.
> Reason can be "Unexpected Behaviour of Application", "New Feature Request" etc.
> — Description -
> — Status - Show this field in Edit mode of request only. (While updating request)
> - There will be summary section for the cases and following block will be shown in it.
> — First block will be the history of the customer request.
> — Party / Roles - All will be shown in the read mode (Party Group, Requesting Party & Logged in party details who has created request).
> — Request Items.
> - There will be following tab button adjucent to Summary Section.
> — Party / Roles(The two records for Party Group and Requesting Party will be in readable mode. and user should only be able to change the details of Request Tracker i.e the person who has logged in the Request.)
> — Request Items
> Details Left Navigation Section.
> First Block: Shortcuts
> Create New Case
> Find Case
> My Cases - List all the cases of logged in party by default. So it will be easy for him to select and update on those cases accordingly.
> Only show those cases that are not in complete status.
> Second Block: Quick Add Case
> Fields to be present in this block are:
> Company Name
> Requesting Party*
> Subject*
> For the quick add case block we should keep the default priority as medium (i.e 5)

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