[
https://issues.apache.org/jira/browse/OFBIZ-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599388#action_12599388
]
Vikas Mayur commented on OFBIZ-1642:
------------------------------------
Jyotsna, this patch looks fine but I would like to suggest few modifications in
quick add functionality. These modifications are based on idea of using
existing services like createLead and createContact for quick add.
1) Instead of creating new services for Lead and Contact, we can add an boolean
attribute say quickAdd to these services.
2) This attribute can be passed from forms with appropriate values (like
quickAdd = true for quick add forms and quickAdd = false for other forms)
3) In services createLead and createContact, add a conditional check on this
parameter. If it is false than keep the process as it is and if it is true...
4) ... if it is true we need to create only (a) a person (b) a role (c) an
email address. All these can be kept in a simple method which than can be
called inline
in both services.
This way the code will be reduced and will be more cleaner, manageable.
Please let me know if this is doable.
- Vikas
> Screens to manage Contacts in SFA webapp
> ----------------------------------------
>
> Key: OFBIZ-1642
> URL: https://issues.apache.org/jira/browse/OFBIZ-1642
> Project: OFBiz
> Issue Type: New Feature
> Reporter: Anil K Patel
> Assignee: Anil K Patel
> Priority: Minor
> Attachments: quickAdd.patch, SFAContact.patch, SFAContact.patch,
> SFAContact.patch
>
>
> In OFBiz a Contact is a Person, which is a type of Party (the other main type
> being Party Group, which would correspond to an Account). For a more general
> description of the Party structure see the Accounts section above. Each
> contact will be in the Contact role. The following are screens and details
> for them related to a contact.
> These may be best as separate screens or as desired certain ones can be
> combined.
> Find Contact
> • Accessed from the application/header level "Contacts" tab
> • Includes a search fields entry form and a search results display form
> • All search results will be filtered by Contacts the current user is
> associated with (PartyRelationship in relationship of type CONTACT_REL TO
> logged in user) unless the user has permission to view all.
> • Like the normal Party Search except with a filter on partyTypeId=PARTY_GROUP
> or PERSON and include a PartyRole record for the "CONTACT" roleTypeId.
> • Includes a link to the Create/Edit Contact page with no "partyId" to
> identify the account for the purpose of creating a new Contact; note that for
> Edit Contact the partyId can correspond to either the Group or Person. After
> a contact is created, it should be setup in Relationship of type CONTACT_REL
> with logged in user.
> • Contact Home (Summary)
> • This page will include summary information for the account including basic
> Contact
> fields plus other related information (to be defined....)
> • Will have link to and information about Account associated with contact;
> since this
> is modeled as a PartyRelationship can theoretically have multiple Accounts
> but the
> UI will limit the setup of a single Account per Contact.
> • Create/Edit Contact
> • If a "partyId" parameter is passed in this page will act as an Edit Contact
> page (the
> partyId can for the Group
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
