Tracker log

After making changes and restarting, I created a new link and new version, published the new version and got the exact same results, to include the messages in events.log.

Actually did it twice because the first time errored ... reindex_object should have been reindexObject.

Added 1085 day(s) ago.

Original link:
UID of link object: d184af79b3696b35c9437789e943b86f
UID of target object: 6eef1b4916709f6525f481b5a91184a1

New Version of Link (while still in draft):
UID of link object: 233f32528e5a72817bf1be78042c9798
UID of target object: 6eef1b4916709f6525f481b5a91184a1

Archived version after publishing:
UID of link object: 233f32528e5a72817bf1be78042c9798
UID of target object: None Found

New version after publishing:
UID of link object: d184af79b3696b35c9437789e943b86f
UID of target object: 6eef1b4916709f6525f481b5a91184a1

These messages appear in the events.log when I publish the new link:
2009-02-19T12:50:51 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of information-technology/custom/test_link/at_references/3e5e5719cacb20d5008a7f5b7cec863d.
------
2009-02-19T12:50:51 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of information-technology/custom/test_link-new-version/at_references/3e6108f404dcf924ac7d939c4aa7fc50.
------
2009-02-19T12:50:52 INFO Archetypes [00m[01;32mProducts/Archetypes/Field.py[1598]:get
[00m2 references for non multivalued field internal_link of <ComboLink at test_link-old-version-replaced-19022009-125051>

------
2009-02-19T12:50:52 INFO Archetypes 2 references for non multivalued field internal_link of <ComboLink at test_link-old-version-replaced-19022009-125051>

------
2009-02-19T12:50:52 INFO Archetypes 2 references for non multivalued field internal_link of <ComboLink at test_link>


I will now make the changes you recommended and test again.

Added 1085 day(s) ago.

The error message was reported earlier in issue # 33. Will try to get the tests/changes you recommend done today.

Added 1086 day(s) ago.

For the record, this last comment has been followed up in another issue: http://plone.org/products/stagingaddon/issues/38

Added 1086 day(s) ago.

Err... forget what I said. I do not think that they have the same UID. But the catalog might very well think that they do, since we do not reindex them after having swapped the UIDs.

Could you please try the following:

- revert your changes so that you have the code of the 1.7.1 release and can reproduce the bug;

- add the following lines in "StagingAddOn/content/staging_tool.py", at line 324 (just after "obj._setUID(old_uid)") :

    old.reindex_object(['UID'])
    obj.reindex_object(['UID'])

- restart Zope and try to reproduce the bug.

If you confirm that it fixes your bug, you will have to reindex your old objects (actually, only the "UID" index) to be on the safe side. I will try to make a release but this will not happen before next week, I guess ("Kölle Alaaf!").

(The code of "Archetypes.Referenceable.Referenceable._setUID()" says that the item will be reindexed in the reference catalog, but it does not talk about the "portal_catalog", which seems to be used by default by ATReferenceBrowserWidget. Hence the proposed solution, which would trigger the reindexation of the content.)

Added 1086 day(s) ago.

First, is this an error or only a warning? I suppose that it is a warning. If this is an error message, would it be possible to post the complete error traceback?

If I understand correctly, your ComboLink content type has a "internal_link" field that contains an UID (changed via an ATRefBrowserWidget). But I am not sure I understand when the error occurs: when you create and publish a new version of the combo link, or when you create and publish a new version of the linked item. I suppose that it is the latter, right? Given the error message and the way you make it disappear, I would say that both the old (archived) and the new (published) version of the linked item have the same UID. Would it be possible to check? (Just call "UID()" on each object. I do not think that the method is published, so you will probably have to do that from a script. Ask me if you need assistance.)

... But this should not happen, since the code clearly swaps UID when the new version is promoted and replaces the published version. So that may man that, in the first place, both the currently published version and the new version (not yet published) have the same UID. Could you check that, please? That is, create an item, then click on "create a new version", and check the UID of these two items. They should not be equal. I mean, theoretically, they should not, but this would explain the bug you describe...

Issue state: Unconfirmed → Confirmed.
Responsible manager: (UNASSIGNED) → dbaty.
Target release: None → 1.7.1.
Added 1086 day(s) ago.

In reference to issue number 33, removal of '_updateBackReferences()' apparently does have undesireable side-effects. We are receiving numerous error reports in our error log as follows:

Jan 14 00:23:07 extzope1 Archetypes 2 references for non multivalued field internal_link of <ComboLink at report_criminals>

ComboLink is a local extension of ATLink that adds an internal_link field using ATReferenceBrowserWidget.

Testing has revealed that the cause of the reported problem is Creating a new version (using StagingAddOn 1.7.1) and publishing the new version. Once I delete the old archived version, the problem disappears.

I readded the _updateBackReferences call and definition, retested, and the problem does not occur.

Any chance of getting it added back in?

Added 1087 day(s) ago.

Removal of '_updateBackReferences()' apparently does have undesireable side-effects. We are receiving numerous error reports in our error log as follows:

Jan 14 00:23:07 extzope1 Archetypes 2 references for non multivalued field internal_link of <ComboLink at report_criminals>

ComboLink is a local extension of ATLink that adds an internal_link field using ATReferenceBrowserWidget.

Testing has revealed that the cause of the reported problem is Creating a new version (using StagingAddOn 1.7.1) and publishing the new version. Once I delete the old archived version, the problem disappears.

I readded the _updateBackReferences call and definition, retested, and the problem does not occur.

Any chance of getting it added back in?

Added 1121 day(s) ago.

FYI THis is because CMFEditions or some other product has been previously added which installs its own uid handler class - this class does not contain the unrestrictedQueryBrain functions, and so you get errors.


This is really a problem with CMFEditions, or Plones class-loader system (if there is one). CMFEditions should not be overriding Plone base classes with incompatible versions.

Added 1470 day(s) ago.

1. I do not think that hiding the portlet from users who do not have the 'Modify portal content' permission is more appropriate than the current behaviour, *in the general case*. We disagree on this, definitely. However: you are the first one who raised this issue; and, as the author of this product, I reserve the right not to include a change that an user has asked for. That is my own little decree of the month, if you would accept it. ;)

2. I do not have any good idea for an UI which would let a manager change this behaviour. Having a text property where we could set the name of the permission to check is not something I want to do: if the administrator knows the name of the permission, there is a good chance that (s)he knows how to customize the portlet. I could add a drop-down, but it seems a bit ridiculous to me.

There are a ton of things which could be customizable with forms. However, I do not want to implement them since most of the changes could be done by customizing the product. That is one of the big features of Plone and I prefer to use it instead of providing cluttered forms.

That said, and even if I disagree with your particular comment, your feedback is definitely much appreciated. (Sorry if I have been a bit rude in my previous comment. That was certainly not intended.)

Added 1649 day(s) ago.

Damien,

The motivation of my feedback was to make this product more usable and adaptable by others in a generic way without too much hassle ("customization"). Well, good luck and thanks for the nice work.

Zoltan

Added 1653 day(s) ago.

*With other words, this product only works with the default plone workflow.*

Should I have guessed what workflow you use and what special rules you have in mind? Quite hard, I think. ;)

The portlet can be customized. Actually, that is what you have done, so you have the solution.

Since your change may not be what other users want (including me, actually), I will not include it in the product.

*Somewhat related issue is that the configuration settings must also "published"*

This is a known issue. In the next version of SAO, implementation of the configuration will change and this problem will hopefully disappear.

Issue state: unconfirmed → rejected.
Added 1653 day(s) ago.

Tried thee suggested code changes and the product is now broken. Traceback is:
2007-07-18 16:05:23
failed:
Traceback (most recent call last):

  File "/var/opt/zope/default/Products/CMFQuickInstallerTool/QuickInstallerTool.py", line 322, in installProduct
    res=install(portal)

  File "/opt/zope/lib/python/Products/ExternalMethod/ExternalMethod.py", line 225, in __call__
    try: return f(*args, **kw)

  File "/var/opt/zope/default/Products/StagingAddOn/Extensions/Install.py", line 95, in install
    type_info.manage_changeProperties(global_allow=True)

AttributeError: 'NoneType' object has no attribute 'manage_changeProperties'

Added 1668 day(s) ago.

Thanks - it appears getVersions index is associated to the Help Centre. We don't need it so I have removed it however still having the same problem.
Will try your coding solution and see how we get on.

Added 1668 day(s) ago.

In portlet_staging.pt the following worked for me:

<tal:portlet metal:define-macro="portlet"
             tal:define="stool python: portal.portal_staging"
             tal:condition="python: stool.showPortlet(context) and (user.has_permission('Modify portal content', context))">

Added 1668 day(s) ago.

When creating a new version for a document, the staging portlet will be visible. This is fine for authors and maybe authorized users, but there is no reason for users who don't have access (view or edit) to (none-published) content to be there. The portlet should be visible based on roles -- maybe disabled for anon users. With other words, this product only works with the default plone workflow. Somewhat related issue is that the configuration settings must also "published", otherwise the site won't be accessible to anon users with no read permission to "visible" state. This might be a security issue. Otherwise great product!

Added 1668 day(s) ago.

Well, I suppose that if you have added this index, it is because you had to, didn't you?

If you do not need this index, then yes, remove it, because it tries to call 'getVersions()' on the configuration item when you add one. It therefore calls 'getVersions()' of 'StagingTool' by acquisition, which needs an argument. Because the catalog does not provide any argument, an exception is raised.

If you do need this index, then you could try to customize StagingAddOn by changing 'content/staging_tool.py' from::

 def getVersions(self, obj, sortFunc=None):
        """Return versions of ``obj`` which are accessible by the current
        user.

        All versions of ``obj`` are returned, including ``obj``
        itself. If ``sortFunc`` is provided, the method uses it to
        sort the items.

        **Warning:** only viewable items are returned.
        """
        if not self.isCurrentVersion(obj):

to::

 def getVersions(self, obj=None, sortFunc=None):
        """Return versions of ``obj`` which are accessible by the current
        user.

        All versions of ``obj`` are returned, including ``obj``
        itself. If ``sortFunc`` is provided, the method uses it to
        sort the items.

        **Warning:** only viewable items are returned.
        """
        if obj is None: return None
        if not self.isCurrentVersion(obj):

Issue state: open → rejected.
Added 1673 day(s) ago.

Yes I do - should I remove it?

Added 1673 day(s) ago.

Do you have a catalog index named 'getVersions' or an index which calls a 'getVersions' attribute? I think this could be the cause of the problem.

Added 1673 day(s) ago.

Sorry Damien, I am a bit of a newbie to this.
Traceback attached as a PDF file.
cheers
frank

Added 1673 day(s) ago.