Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: Trunk
    • Fix Version/s: None
    • Component/s: ALL COMPONENTS
    • Labels:
      None

      Description

      with the addition of the Website for each component
      1) create product store for Order entry, or use the B2C product store.
      2) move the email widgets from ecommerce to order compontent.
      3) modify the seed data so that Order entry has it own emails from order component.this would be to add emails to

      note: as I go through the different items this is turning out to be a bigger project than I first anticipated.
      so consider this so far just ideas.
      Maybe break down in to small tasks as I have time to do something.

      1. OFBIZ-3894.patch
        63 kB
        Nicolas Malin
      2. OFBIZ-3894.patch
        117 kB
        Nicolas Malin
      3. OFBIZ-3894.patch
        147 kB
        Nicolas Malin
      4. OFBIZ-3894.patch
        146 kB
        Nicolas Malin

        Issue Links

          Activity

          Hide
          Scott Gray added a comment -

          The product store is selectable at the start of order entry, which in turn determines what email templates are available (among many other things). How does that differ from what you are proposing here?

          Show
          Scott Gray added a comment - The product store is selectable at the start of order entry, which in turn determines what email templates are available (among many other things). How does that differ from what you are proposing here?
          Hide
          BJ Freeman added a comment -

          your are correct but only the productstore loaded.
          under seed there is no product store for the orderentry or any other component.
          My original focus was to pull emails back into orders from ecommerce as far as widgets, then change the seed for ecommerce to use the widgets for emails.

          secondarily the B2C productstore has no emails defined for it in demo data. I have not looked at the others.

          further under the Setup this should be added.
          That is when I decided this is more than a simple refactor.

          Show
          BJ Freeman added a comment - your are correct but only the productstore loaded. under seed there is no product store for the orderentry or any other component. My original focus was to pull emails back into orders from ecommerce as far as widgets, then change the seed for ecommerce to use the widgets for emails. secondarily the B2C productstore has no emails defined for it in demo data. I have not looked at the others. further under the Setup this should be added. That is when I decided this is more than a simple refactor.
          Hide
          Bruno Busco added a comment -

          How the productstore and the email templates are linked together is just something I was looking at.

          I have found the "EmailTemplateSetting" entity defined in the framework common component and the "ProductStoreEmailSetting" defined in the product component.

          The "ProductStoreEmailSetting" entity is a copy of the "EmailTemplateSetting" since many fields are duplicated and it is used for instance in the "sendCreatePartyEmailNotification" service to send an email to newly added parties while "sendMailFromTemplateSetting" should have been used.

          As a result of all this we have that the party component (where the "sendCreatePartyEmailNotification" is defined) depends on the product component (where the "ProductStoreEmailSetting" is defined).

          Could we think to reuse the "EmailTemplateSetting" instead of duplicating it in the "ProductStoreEmailSetting" and then having the services defined in party only use the "EmailTemplateSetting" so to avoid dependence on the product component ?

          I am still looking at having only the party and content (and a better myportal) components distributed with the framework and this would help.
          Any ideas?

          Show
          Bruno Busco added a comment - How the productstore and the email templates are linked together is just something I was looking at. I have found the "EmailTemplateSetting" entity defined in the framework common component and the "ProductStoreEmailSetting" defined in the product component. The "ProductStoreEmailSetting" entity is a copy of the "EmailTemplateSetting" since many fields are duplicated and it is used for instance in the "sendCreatePartyEmailNotification" service to send an email to newly added parties while "sendMailFromTemplateSetting" should have been used. As a result of all this we have that the party component (where the "sendCreatePartyEmailNotification" is defined) depends on the product component (where the "ProductStoreEmailSetting" is defined). Could we think to reuse the "EmailTemplateSetting" instead of duplicating it in the "ProductStoreEmailSetting" and then having the services defined in party only use the "EmailTemplateSetting" so to avoid dependence on the product component ? I am still looking at having only the party and content (and a better myportal) components distributed with the framework and this would help. Any ideas?
          Hide
          BJ Freeman added a comment -

          Actually the Productstoreemail was first, and is legacy.
          i am not sure having a template entity in framework does not pose a inter dependence from framework to applications.
          you still need the productstoreemail to define specifics like who the email is from and the customize subject line.

          Show
          BJ Freeman added a comment - Actually the Productstoreemail was first, and is legacy. i am not sure having a template entity in framework does not pose a inter dependence from framework to applications. you still need the productstoreemail to define specifics like who the email is from and the customize subject line.
          Hide
          BJ Freeman added a comment -

          there are many places where the emails are hard coded into the java.
          one of the refactors was to use the procuctstoreemail and the services that support it the default.
          now if we can resolve the dependency issue of EmailTemplateSetting and expand it to handle multiple productstore, and or partiies then it might work.

          Show
          BJ Freeman added a comment - there are many places where the emails are hard coded into the java. one of the refactors was to use the procuctstoreemail and the services that support it the default. now if we can resolve the dependency issue of EmailTemplateSetting and expand it to handle multiple productstore, and or partiies then it might work.
          Hide
          Bruno Busco added a comment -

          BJ, the
          <entity entity-name="EmailTemplateSetting" package-name="org.ofbiz.common.email"
          is already defined in common and it should be used for every base email sending service.
          I mean for example for system notifications, mailing list, new user confirmation.

          Then the product component should have extended this entity adding all needed fields.
          The way it is done right now does not seem really clean to me.

          Show
          Bruno Busco added a comment - BJ, the <entity entity-name="EmailTemplateSetting" package-name="org.ofbiz.common.email" is already defined in common and it should be used for every base email sending service. I mean for example for system notifications, mailing list, new user confirmation. Then the product component should have extended this entity adding all needed fields. The way it is done right now does not seem really clean to me.
          Hide
          BJ Freeman added a comment -

          now that I have my cup of coffee.
          I am not disputing that moving to EmailTemplateSetting is a good goal.
          what I am saying is there are a lot of productions servers that use the legacy system.
          for instance 9.04 does not define EmailTemplateSetting or the services in common.
          to upgrade from 9.04 to trunk require migration code.
          it would be a major task just to do the migration for any production server that upgardes.
          it is not something I would blindly change code to do.
          any new functionality would use EmailTemplateSetting, I agree. That is a no brainer.

          Show
          BJ Freeman added a comment - now that I have my cup of coffee. I am not disputing that moving to EmailTemplateSetting is a good goal. what I am saying is there are a lot of productions servers that use the legacy system. for instance 9.04 does not define EmailTemplateSetting or the services in common. to upgrade from 9.04 to trunk require migration code. it would be a major task just to do the migration for any production server that upgardes. it is not something I would blindly change code to do. any new functionality would use EmailTemplateSetting, I agree. That is a no brainer.
          Hide
          Bruno Busco added a comment -

          If we want to preserve compatibility we will never get the framework independence.
          We can create a branch where those major changes happen.

          Show
          Bruno Busco added a comment - If we want to preserve compatibility we will never get the framework independence. We can create a branch where those major changes happen.
          Hide
          BJ Freeman added a comment -

          clarification I am not saying support compatibility as I am saying provide a migration path.
          It does not make user comfortable to know they investment will cost them considerable to upgrade. It should be the responsibility of the designers to make sure the users upgrade is a painless as possible.
          that is why people don't move from one application to another.

          Show
          BJ Freeman added a comment - clarification I am not saying support compatibility as I am saying provide a migration path. It does not make user comfortable to know they investment will cost them considerable to upgrade. It should be the responsibility of the designers to make sure the users upgrade is a painless as possible. that is why people don't move from one application to another.
          Hide
          BJ Freeman added a comment -

          and I don't see how framework Independence is effected by this operation.

          Show
          BJ Freeman added a comment - and I don't see how framework Independence is effected by this operation.
          Hide
          Jacques Le Roux added a comment -

          Hi,

          I did not look intot the details yet, but I agree with BJ that keeping the upgrade path as simple as possible should be one of our concerns.
          For instance, I was unpleasantly surprised when I saw how Dojo recenlty handled its Tree upgrade.

          Show
          Jacques Le Roux added a comment - Hi, I did not look intot the details yet, but I agree with BJ that keeping the upgrade path as simple as possible should be one of our concerns. For instance, I was unpleasantly surprised when I saw how Dojo recenlty handled its Tree upgrade.
          Hide
          Scott Gray added a comment -

          @Bruno

          Now we're getting into a topic that is more interesting. EmailTemplateSetting was indeed added long after ProductStoreEmailSetting and is an entity much better suited for general reuse. IMO the best way to use it with a ProductStore would be with a join table that would ultimately replace ProductStoreEmailSetting, something like:
          emailTemplateSettingId *
          productStoreId *
          emailTypeId *
          fromDate *
          thruDate

          Additionally one thing that I don't like about either of those existing entity definitions is the lack of Content support. You cannot at run-time alter the contents of the email templates or create new ones. Additionally the subject field doesn't really lend itself to internationalization. All of these issues could be resolved by modeling the actual contents of the email templates against the Content data model.
          A join between EmailTemplateSetting and Content could enable this:

          EmailTemplateSettingContent
          emailTemplateSettingId *
          contentId *
          emailTemplateContentTypeId *
          fromDate *
          thruDate

          EmailTemplateContentType
          emailTemplateContentTypeId *
          description

          Seed data for EmailTemplateContentType:
          <EmailContentTemplateType emailTemplateContentTypeId="SUBJECT" description="Subject"/>
          <EmailContentTemplateType emailTemplateContentTypeId="BODY" description="Email Body"/>
          <EmailContentTemplateType emailTemplateContentTypeId="ATTACHMENT_PDF" description="PDF Attachment"/>

          I dream of a day when users can create new email templates in a WYSIWG editor with the ability to pick from a list of known variables that represents the freemarker data model that will be available during rendering, possibly even providing a sample freemarker data model so that they can see a live preview of the output with variables such as firstName, lastName, etc. prefilled with sample data.

          Show
          Scott Gray added a comment - @Bruno Now we're getting into a topic that is more interesting. EmailTemplateSetting was indeed added long after ProductStoreEmailSetting and is an entity much better suited for general reuse. IMO the best way to use it with a ProductStore would be with a join table that would ultimately replace ProductStoreEmailSetting, something like: emailTemplateSettingId * productStoreId * emailTypeId * fromDate * thruDate Additionally one thing that I don't like about either of those existing entity definitions is the lack of Content support. You cannot at run-time alter the contents of the email templates or create new ones. Additionally the subject field doesn't really lend itself to internationalization. All of these issues could be resolved by modeling the actual contents of the email templates against the Content data model. A join between EmailTemplateSetting and Content could enable this: EmailTemplateSettingContent emailTemplateSettingId * contentId * emailTemplateContentTypeId * fromDate * thruDate EmailTemplateContentType emailTemplateContentTypeId * description Seed data for EmailTemplateContentType: <EmailContentTemplateType emailTemplateContentTypeId="SUBJECT" description="Subject"/> <EmailContentTemplateType emailTemplateContentTypeId="BODY" description="Email Body"/> <EmailContentTemplateType emailTemplateContentTypeId="ATTACHMENT_PDF" description="PDF Attachment"/> I dream of a day when users can create new email templates in a WYSIWG editor with the ability to pick from a list of known variables that represents the freemarker data model that will be available during rendering, possibly even providing a sample freemarker data model so that they can see a live preview of the output with variables such as firstName, lastName, etc. prefilled with sample data.
          Hide
          BJ Freeman added a comment -

          since the discussion had taken on a broader scope changed title and the targets.

          Show
          BJ Freeman added a comment - since the discussion had taken on a broader scope changed title and the targets.
          Hide
          Bruno Busco added a comment -

          I perfectly agree on having a content based email data model similar to the one that you suggest.
          A set of screens in the content component could allow the user to browse between the available email templates and define new ones.

          Show
          Bruno Busco added a comment - I perfectly agree on having a content based email data model similar to the one that you suggest. A set of screens in the content component could allow the user to browse between the available email templates and define new ones.
          Hide
          BJ Freeman added a comment -

          thanks Scott will look at a migration per your suggestion.
          first stage for refactor is identify all the code that needs to modified and make a task for each.
          If someone wants to create task and patch for the content type that would be great also.

          Show
          BJ Freeman added a comment - thanks Scott will look at a migration per your suggestion. first stage for refactor is identify all the code that needs to modified and make a task for each. If someone wants to create task and patch for the content type that would be great also.
          Hide
          BJ Freeman added a comment -

          hope to fold this into this operation.

          Show
          BJ Freeman added a comment - hope to fold this into this operation.
          Hide
          Nicolas Malin added a comment -

          I close the duplicate issue and I try to work on scott analyse the next week

          Show
          Nicolas Malin added a comment - I close the duplicate issue and I try to work on scott analyse the next week
          Hide
          BJ Freeman added a comment -

          I would like the current service be left in place and stubbed out with calls to the new code.
          thanks for your effort.

          Show
          BJ Freeman added a comment - I would like the current service be left in place and stubbed out with calls to the new code. thanks for your effort.
          Hide
          Nicolas Malin added a comment -

          I Begun the refactoring email handling has scott suggest.

          I realized in first step :

          • Create management emailTemplateSetting screen on ContentSetup Menu
          • Change data model ProductStoreEmailSetting
          • Add new Content entity : EmailTplSettingContent and EmailTplSettingContentType
          • Update ProductStoreEmailSetting service and screen.

          To migrate data I propose :

          • Update data model with new enchancement
          • Run SQL UPDATE product_store_email_setting SET email_type_enum_Id = email_type;
            ALTER TABLE product_store_email_setting DROP COLUMN email_type;

          Run service to create new emailTemplateSetting and associate to ProductStoreEmailSetting (not write yet)
          -> Run SQL by call entitySqlProcessor :
          UPDATE email_template_setting SET body_screen_location = (SELECT body_screen_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET xslfo_attach_screen_location = (SELECT xslfo_attach_screen_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET from_address = (SELECT from_address FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET cc_address = (SELECT cc_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET bcc_address = (SELECT bcc_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET subject = (SELECT subject FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          UPDATE email_template_setting SET content_type = (SELECT content_type FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting);
          ALTER TABLE product_store_email_setting DROP COLUMN body_screen_location;
          ALTER TABLE product_store_email_setting DROP COLUMN xslfo_attach_screen_location;
          ALTER TABLE product_store_email_setting DROP COLUMN from_address;
          ALTER TABLE product_store_email_setting DROP COLUMN cc_address;
          ALTER TABLE product_store_email_setting DROP COLUMN bcc_address;
          ALTER TABLE product_store_email_setting DROP COLUMN subject;
          ALTER TABLE product_store_email_setting DROP COLUMN content_type;

          If the following way it's good I continu with :

          • Change all services to use ProducStoreEmailSettingView instead of ProducStoreEmailSetting OR change sendEmailService with sendEmailFromTemplate
          • Add new screen to manage content email
          • Add new service to sendEmailFromContent
          • Update Content screen to give user possibility to edit template with context field selection
          Show
          Nicolas Malin added a comment - I Begun the refactoring email handling has scott suggest. I realized in first step : Create management emailTemplateSetting screen on ContentSetup Menu Change data model ProductStoreEmailSetting Add new Content entity : EmailTplSettingContent and EmailTplSettingContentType Update ProductStoreEmailSetting service and screen. To migrate data I propose : Update data model with new enchancement Run SQL UPDATE product_store_email_setting SET email_type_enum_Id = email_type; ALTER TABLE product_store_email_setting DROP COLUMN email_type; Run service to create new emailTemplateSetting and associate to ProductStoreEmailSetting (not write yet) -> Run SQL by call entitySqlProcessor : UPDATE email_template_setting SET body_screen_location = (SELECT body_screen_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET xslfo_attach_screen_location = (SELECT xslfo_attach_screen_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET from_address = (SELECT from_address FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET cc_address = (SELECT cc_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET bcc_address = (SELECT bcc_location FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET subject = (SELECT subject FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); UPDATE email_template_setting SET content_type = (SELECT content_type FROM product_store_email_setting WHERE email_template_setting_id = email_Template_Setting.email_template_setting_id) && email_template_setting_id IN (SELECT email_template_setting_id FROM product_store_email_setting); ALTER TABLE product_store_email_setting DROP COLUMN body_screen_location; ALTER TABLE product_store_email_setting DROP COLUMN xslfo_attach_screen_location; ALTER TABLE product_store_email_setting DROP COLUMN from_address; ALTER TABLE product_store_email_setting DROP COLUMN cc_address; ALTER TABLE product_store_email_setting DROP COLUMN bcc_address; ALTER TABLE product_store_email_setting DROP COLUMN subject; ALTER TABLE product_store_email_setting DROP COLUMN content_type; If the following way it's good I continu with : Change all services to use ProducStoreEmailSettingView instead of ProducStoreEmailSetting OR change sendEmailService with sendEmailFromTemplate Add new screen to manage content email Add new service to sendEmailFromContent Update Content screen to give user possibility to edit template with context field selection
          Hide
          BJ Freeman added a comment -

          the patterned used to date is to rename the old entity create a new entity with the new fields or without previous fields, the use simple-methods or java with delegate to migrate the data.

          Show
          BJ Freeman added a comment - the patterned used to date is to rename the old entity create a new entity with the new fields or without previous fields, the use simple-methods or java with delegate to migrate the data.
          Hide
          Paul Foxworthy added a comment -

          There's discussion of the pattern BJ mentions in the section "Deprecating entities" at https://cwiki.apache.org/OFBADMIN/ofbiz-contributors-best-practices.html

          Show
          Paul Foxworthy added a comment - There's discussion of the pattern BJ mentions in the section "Deprecating entities" at https://cwiki.apache.org/OFBADMIN/ofbiz-contributors-best-practices.html
          Hide
          Nicolas Malin added a comment -

          In a first time, I try to reuse ProductStoreEmailSetting, but finally is more esaier to deprecate it.
          I update the patch with :
          1. new entity ProdStoreEmailTplSetting and deprecated OldProdStoreEmailSetting (not OldProductStoreEmailSetting more 30 cara.)
          2. Add new upgrade service
          3. Pass ProductStoreEmail screen to deprecated
          4. Add new ProductStoreEmail based on ProdStoreEmailTplSetting (I keep old screen to keep the possibility to manage email setting for old specific customer process, but I suggest to remove it when migration will be done)
          5. Increase model with content (respect EntityType patern)

          All service and screen to manage ProductStoreEmailSetting and EmailTemplateSetting are done.
          Next step, add screen and service to manage EmailTemplateSetting and Content and send an email with dynamic parameters.

          Nicolas

          Show
          Nicolas Malin added a comment - In a first time, I try to reuse ProductStoreEmailSetting, but finally is more esaier to deprecate it. I update the patch with : 1. new entity ProdStoreEmailTplSetting and deprecated OldProdStoreEmailSetting (not OldProductStoreEmailSetting more 30 cara.) 2. Add new upgrade service 3. Pass ProductStoreEmail screen to deprecated 4. Add new ProductStoreEmail based on ProdStoreEmailTplSetting (I keep old screen to keep the possibility to manage email setting for old specific customer process, but I suggest to remove it when migration will be done) 5. Increase model with content (respect EntityType patern) All service and screen to manage ProductStoreEmailSetting and EmailTemplateSetting are done. Next step, add screen and service to manage EmailTemplateSetting and Content and send an email with dynamic parameters. Nicolas
          Hide
          Jacques Le Roux added a comment -

          Hi Nicolas,

          I did not review anything yet. Should I wait next step for review/commit?

          Show
          Jacques Le Roux added a comment - Hi Nicolas, I did not review anything yet. Should I wait next step for review/commit?
          Hide
          Nicolas Malin added a comment -

          I work to create new service for send mail with new model and alert you well is done.

          The next step with content merge to send email, I wish separate on two commits. At this time the patch is so bigger and adding all improvement with content will be difficult to review.

          Show
          Nicolas Malin added a comment - I work to create new service for send mail with new model and alert you well is done. The next step with content merge to send email, I wish separate on two commits. At this time the patch is so bigger and adding all improvement with content will be difficult to review.
          Hide
          Nicolas Malin added a comment -

          I update sendOrderNotification service to use new email system.

          How to test :

          • install t patch on trunk
          • run ant run-install
          • configure notification email on general.properties
          • start ofbiz and run migrateProductStoreEmailSetting service by webtools to convert old cofiguration to new system
          • orderer product and create your order, in debug mode email send will be present in log

          Nicolas

          Show
          Nicolas Malin added a comment - I update sendOrderNotification service to use new email system. How to test : install t patch on trunk run ant run-install configure notification email on general.properties start ofbiz and run migrateProductStoreEmailSetting service by webtools to convert old cofiguration to new system orderer product and create your order, in debug mode email send will be present in log Nicolas
          Hide
          Nicolas Malin added a comment -

          Nobody interested by this refactoring ?

          Show
          Nicolas Malin added a comment - Nobody interested by this refactoring ?
          Hide
          BJ Freeman added a comment - - edited

          Interested in helping where I can.
          Since I have branched, I have no test bed to use.

          Show
          BJ Freeman added a comment - - edited Interested in helping where I can. Since I have branched, I have no test bed to use.
          Hide
          Nicolas Malin added a comment -

          It's possible for a commiter to create a branch ?
          It's really difficult to progress with big patch and this issue is really interesting for refactoring mail system

          thanks by advanced
          Nicolas

          Show
          Nicolas Malin added a comment - It's possible for a commiter to create a branch ? It's really difficult to progress with big patch and this issue is really interesting for refactoring mail system thanks by advanced Nicolas
          Hide
          Erwan de FERRIERES added a comment -

          Nicolas,

          branch has been created at rev 1210406

          the latest patch in this issue has been committed at rev 1210493

          The run-tests task has 10 tasks in error.

          Waiting for your updates !

          Show
          Erwan de FERRIERES added a comment - Nicolas, branch has been created at rev 1210406 the latest patch in this issue has been committed at rev 1210493 The run-tests task has 10 tasks in error. Waiting for your updates !
          Hide
          Nicolas Malin added a comment -

          thanks Erwan, I check it, and continue refactoring.

          Nicolas

          Show
          Nicolas Malin added a comment - thanks Erwan, I check it, and continue refactoring. Nicolas
          Hide
          BJ Freeman added a comment -

          My lack of the merge process prompts me to ask if the migration process will still be intact

          Show
          BJ Freeman added a comment - My lack of the merge process prompts me to ask if the migration process will still be intact
          Hide
          Nicolas Malin added a comment -

          Hi Erwan, is possible to commit the last patch on email refactoring branch ?

          Show
          Nicolas Malin added a comment - Hi Erwan, is possible to commit the last patch on email refactoring branch ?
          Hide
          Pierre Smits added a comment -

          Is this still being worked on? No activity seem to be taking place.

          Show
          Pierre Smits added a comment - Is this still being worked on? No activity seem to be taking place.
          Hide
          Jacques Le Roux added a comment -

          I hate to have to review an abandonned issue and put all this in my brain

          I will look for easier tasks

          Show
          Jacques Le Roux added a comment - I hate to have to review an abandonned issue and put all this in my brain I will look for easier tasks
          Hide
          Jacques Le Roux added a comment -

          Of course is someone is willing to help (review and test) then that will another story...

          Show
          Jacques Le Roux added a comment - Of course is someone is willing to help (review and test) then that will another story...

            People

            • Assignee:
              Erwan de FERRIERES
              Reporter:
              BJ Freeman
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 1,344h
                1,344h
                Remaining:
                Remaining Estimate - 1,344h
                1,344h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development