[
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.
