Ticket #1470 (closed defect: fixed)

Opened 14 years ago

Last modified 14 years ago

Content Portlet doesn't refresh

Reported by: PM Owned by: jmorliaguet
Priority: P1 Milestone: CPS 3.4.0
Component: CPSPortlets Version: 3.3.6
Severity: major Keywords: Content Portlet Cache
Cc:

Description

Hi,

I'm experiencing a problem whith content portlets which doesn't refresh. The ticket  http://svn.nuxeo.org/trac/pub/ticket/787 is closed and should be reopened.

I use the following use case :

  • A SectionReviewer? creates a content portlet in his private directory. This portlet is used to display the documents waiting for validation.
  • A member creates a new document and submits it into a section.
  • The content portlet in the Reviewer home directory is correctly updated.
  • The reviewer clicks on the link to the document and accepts => the document is now published
  • The reviewer returns to his home directory, the accepted document is in the content portlet
  • A member submits another document into a section
  • The content portlet is refreshed and contains only the new submited document.

I tried those cache parameters in portal_cpsportlets -> Cache parameters :

no-cache:(contextual)
user
event_ids:workflow_accept,workflow_reject,workflow_unpublish,workflow_create,workflow_publish,workflow_modify,sys_del_object,workflow_cut_copy_paste,workflow_copy_submit
event_in_folders:(folder_path)
event_on_types:(searchable_types)
baseurl
current_lang

and

no-cache:(contextual),(folder_path)
user
event_ids:workflow_accept,workflow_reject,workflow_unpublish,workflow_create,workflow_publish,workflow_modify,sys_del_object,workflow_cut_copy_paste,workflow_copy_submit
event_in_folders:(folder_path)
event_on_types:(searchable_types)
baseurl
current_lang

The problem is the same when listing recent documents, or when rejecting a document...

Is this a bug or a bad configuration ?

Thx

Change History

comment:1 Changed 14 years ago by jmorliaguet

  • Status changed from new to assigned

OK, I'm checking this.

it could be related to the 'event_in_folders' cache parameter, the doc says:

  • event_in_folders

description:

the list of folder paths inside which events will be monitored

used in:

the content portlet

comment:2 Changed 14 years ago by jmorliaguet

  • Milestone changed from CPS 3.3.6 to CPS 3.4.0

comment:3 Changed 14 years ago by jmorliaguet

This occurs when the document is published for the first time.

but adding 'workflow_accept' and 'workflow_reject' solves the problem as far as I can tell.

(see [33573] and [33574])

comment:4 Changed 14 years ago by jmorliaguet

I'm adding an upgrade step too.

comment:5 Changed 14 years ago by jmorliaguet

  • Status changed from assigned to closed
  • Resolution set to fixed

added an upgrade step in [33577]

please upgrade to the trunk version and run an upgrade on your test site, and reopen the ticket if the bug persists.

also make sure that the portlet tool is an enabled subscriber in portal_eventservice.

comment:6 Changed 14 years ago by janguenot

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:7 Changed 14 years ago by janguenot

  • Milestone changed from CPS 3.4.0 to CPS 3.4.1

comment:8 Changed 14 years ago by PM

As said in the ticket's description I already added the event_ids workflow_accept and workflow_reject but this doesn't solve the problem.

In the changesets 33573 and 33574 the events workflow_accept and workflow_reject are added into the portlet cache parameters. I don't see any other significative change.

I tested with a CPS 3.3.6 stock and I experience the same problem.

comment:9 Changed 14 years ago by jmorliaguet

It solves the problem in the setup I have (I could reproduce the bug but after adding the new parameters the portlet got refreshed). Can you try with a fresh CPS-3.4.0 instance?

comment:10 Changed 14 years ago by janguenot

  • Status changed from reopened to closed
  • Resolution set to fixed

I juste tested using a stock 3.3.6.

I reproduced the initial problem described.

As soon as I added the workflow_accept and workflow_reject events within the content portlet cache parameters the problem disapeared, as expected.

You can grab information from the log files related to threw up events durinf the transaction. Use the DEBUG level.

comment:11 Changed 14 years ago by janguenot

  • Version changed from unspecified to 3.3.6
  • Milestone changed from CPS 3.4.1 to CPS 3.4.0

One last comment about this ticket.

The fix and the upgrade mentionned above are relevants and are working while upgrading a 3.3.x CPS version to 3.4.x. Just use the new upgrade step or change the cache parameters configuration withion the portlets tool. It will do the job. If you do have to remain on a CPS <= 3.3.8 there's a small workaround you must setup. You will have to add the 'workflow_accept' and 'workflow_reject' within the getCPSPorletCacheParams.py itself. The _rebuidl() method of the CPSPortlet class was buggy and didn't use the persistent configuration within the cpsportlets tool but the skins script to update the portlet properties.

You may ovveride this script skins by adding the modified script within your own product skins directory.

Note that your changes within the ZMI on the cache params won't be taken into consideration if you rebuilt the portlets though... Consider updating to 3.4.0 if you really need this.

comment:12 Changed 14 years ago by jmorliaguet

You will have to add the 'workflow_accept' and 'workflow_reject' within the getCPSPorletCacheParams.py itself. The _rebuidl() method of the CPSPortlet class was buggy and didn't use the persistent configuration within the cpsportlets tool but the skins script to update the portlet properties.

actually somewhere around that time (3.3.8) the cache parameter configuration moved from the portlets to the tool. Before that the information was stored locally and _rebuild() was used to "upgrade" portlets. After that _rebuild() did not need to upgrade portlets since the information was already stored in the tool.

currently the cache parameters information is set up from the skin (getCPSPorletCacheParams.py) when resetting parameters via the ZMI and from GenericSetup? in XML when installing/upgrading the application.

the best way is to upgrade to 3.4.0

Note: See TracTickets for help on using tickets.