Ticket #1852 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Draft content that is not visible should not be displayed on "What's going on?" page

Reported by: hans Assigned to: pjotr
Priority: major Milestone:
Component: generic Version:
Keywords: Cc:
Time spent: Time remaining: 0h
Time planned:

Description

Draft content that is not visible should not be displayed on "What's going on?" page.

Currently we display links to these resources:

In general: no links should point to draft content that is not marked as "visible for other users".

Change History

11/17/08 17:03:14 changed by pjotr

  • owner changed from anonymous to pjotr.
  • status changed from new to assigned.

11/17/08 17:06:12 changed by pjotr

This one is a problem of catalog.

When someone publishes a resource (like webpage), and then uses "Set to draft" function. The state of the object itself is changed to either "draft" or "private", but the catalog still has the old state "public". In Resources.py >>> retract method >>> we need to use reindexObject to update the catalog values.

11/18/08 14:09:38 changed by pjotr

  • status changed from assigned to closed.
  • resolution set to fixed.
  • tt_remaining set to 0h.

(In [2690]) Fixes #1852, also added state reindex to publish method, in case the old coverImage is kept and and full reindex not run

11/26/08 21:41:49 changed by hans

  • status changed from closed to reopened.
  • resolution deleted.

Is this fix part of 2.6.1 that should be running on lemill.net now? This resourcehttp://lemill.net/content/webpages/digitiiger-11/view is still displayed as a third result on http://lemill.net/content/language?language=et page.

11/26/08 22:49:42 changed by pjotr

It should be a part of that release. And no new cases of that kind should be happening any more. But we did not reindex all the catalog, but made the thing for some portion of content resources through the Install.py upgrade. This way it just didn't get reindexed. I think we are dealing with unneeded material in this case. If reindexing the whole catalog is no a good action to take (and that might be the case) - someone with administrative privileges should just save again or do something like that. This should trigger the catalog update for these specific objects. I suppose we don't really have many cases of that kind. So, any time that is done - this ticket can be closed. Or we should run the recataloging for all the objects that can have these the "private" state - this way we will be on the safe side for sure.

If the choice would be the latter option, I will write the migration script just some time I'm still in Georgia. Then I'll test and commit it as soon as I get back to work.

01/12/09 13:34:03 changed by pjotr

  • status changed from reopened to closed.
  • resolution set to fixed.

As the catalog will be modified in the next release. Any of the cases should get fixed. Closing the ticket.