Draft:Module Partnership management
(Draft page, no need to be translated) This is a draft on how the module "Partnership management" can be designed.
This module can be used to receive request by a company to be a preferred partner. Validate, follow and cancel partnership. The module is generic and it will be possible to use it for a lot of use case. This module will be used for example by the foundation for its Preferred Partner management program.
Module Partnership management
The module name and path will be "partnership".
The module add a new table llx_partnership
The module also add a new tab "Partnership" on the record of a thirdparty or a member (depending on setup). So a logged user can make a request and see its partnership status from its own thirdparty or member record.
A batch can disable the status of a partnership if partnership is based on members and if subscription has expired since x days.
Setup of module
We choose if the partnership is for a 'thirdparty' or for a 'member' (option named PARTNERSHIP_IS_MANAGED_FOR).
New object Partnership table
Properties:
- rowid autoincrement
- fk_soc ID of thirdparty
- fk_member ID of member
- date_partnership_start
- date_partnership_end
- status Partnership status (0=draft, 1=accepted, 2=refused, 9=canceled)
- date_creat
- fk_user_create
- tms
- fk_user_update
- note_private
- note_publice
- count_last_url_check_error (see later)
- reason_decline_or_cancel
Allow extrafields. (For example, for the Dolibarr foundation: "Github user")
Menus
- Enabling the module will also add menu entries into thirdparty menu (if PARTNERSHIP_IS_MANAGED_FOR = 'thirdparty') or into member menu (if PARTNERSHIP_IS_MANAGED_FOR = 'member'):
- Partnership - List - New
On the member Tab partnership on a member and thirdparty
Show a form (on record thirdparty if PARTNERSHIP_IS_MANAGED_FOR = 'thirdparty') or on record of member (if PARTNERSHIP_IS_MANAGED_FOR = 'member') to request to be a partner if there is no record into table llx_partnership yet.
If there is already record, show the status and information of memberships. On this tab, we should also have a button "Manage Partnership"
Card partnership
On the page to show a partnership we have a button
- Send email using templates. The module must add 2 templates of email for type 'partnership': On to say partnership is refused, one to say partnership is accepted.
- Validate
- Accept -> Set to status ACCEPTED.
- Refuse -> Ask a reason and set to status REFUSED and fill the "reason_decline" field.
- Cancel
- Delete
On the list of partnership
If PARTNERSHIP_IS_MANAGED_FOR = 'member', we add a column on list of partnership to show the date of membership expiration. We must be able to sort on this date.
We must have the mass action "Send email"
We must have the mass action "Cancel"
We must have the mass action "Delete"
Enhance module Member
Add property "url" on the member card
Add this property on table llx_adherent, on screen and can edit it.
Add option in member module setup to "Create an external user login for each new member subscription validated"
On a new member subscription (module member), we currently send an email with invoice automatically after receiving the online payment.
We must also create an external account for each new member and have the login and pass of the external account included into email (A substitution key __MEMBER_USER_LOGIN_INFORMATION__ can be used into email template).
Add a mass action "Create external user" on the member list.
Permissions
Permission supplied by module "Partnership"
- read (Read partnerships)
- create/modify (Create/modify partnerships)
- delete (Delete partnerships)
Batch
Cancel Partnership For Expired Members
We must have a cron job that cancel status of partnership when subscription is expired + x days (x is a parameter of the cron job). This cron task must be supplied by module. If option 'PARTNERSHIP_IS_MANAGED_FOR' = 'thirdparty', this cron job does nothing.
Warning of partnership if Dolibarr backlink not found on partner website
Batch not enabled by default. Every week, check that website contains a link to dolibarr.(org/fr/es) Web site. The url to check is a regex set as a parameter of module. If regex not found into the website of partner, batch increase a counter check fail (field count_last_url_check_error into table llx_partnership), if found, reset value to 0. If counter > 2, send email to partner (template email mut be defined in setup). If counter > 4, set status of partnership to canceled (set also reason of partnership cancelation).
Note
Module and new managed objects must be generated with Module ModuleBuilder.
Goal is to have module included in core so modification of core files is possible. However, process to submit the work must follow this rule:
- A) Code submission must be done using Pull Request on GitHub.
- B) PR content must be the smaller as possible. Each PR must keep the application working the same way as before the merge, when the module is not enabled. For example, you can make one PR for the database addition and migration, and another PR for adding the module descriptor, another one for adding a page, another one for modifying a core file keeping backward compatibility, ...)
- C) PR must be atomic (PR must be submitted only once everything seems stable inside 1 PR.
For example, you can't push one PR to make the migration of tables to add a field and another for the script to create the table for a first installation. If you do this, it means there is an inconsistency into the snapshot if we merge only one PR and not the other one.
- D) Try to wait that first PR are merged to continue to submit other PR to follow previous rules.
For example: if you add a page that use a new field and want to do it into a different PR to match rule B, wait the previous PR that add that the creation/migration of the new field has been merged. If not, you will break the rule C.
All other development rules must be applied. If not, the PR will not be refused and if development of module were subcontracted, delivery will be refused and payment may not be done.