PKP Bugzilla – Bug 7872
Press "enabled" flag does not do much
Last modified: 2013-04-04 17:47:36 PDT
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
Currently it controls tombstone generation and hides content from the OAI interface but otherwise doesn't affect the front end.
Looking at TemplateHandler, the press switcher (for instance) includes all presses regardless of whether or not the press is 'enabled' so long as there is a user logged in. If not, it only displays enabled ones. (lines 111-115 in TemplateManager).
Does this checkbox imply that it should be impossible to navigate to a press if it is marked as disabled, even if you know the press URL? Or are we simply using it to hide presses from the index page navigation?
(In reply to comment #1)
> Hi Alec,
> Looking at TemplateHandler, the press switcher (for instance) includes all
> presses regardless of whether or not the press is 'enabled' so long as there
> is a user logged in. If not, it only displays enabled ones. (lines 111-115
> in TemplateManager).
I think that this is what we want. The enabled setting has a label like this:
"Enable this press to appear publicly on the site".
OK -- I missed that in grepping. Sounds fine.
Behavior is weird with a single press when it's disabled: you'd never know it wasn't supposed to be publicly available, except that the search box disappears. Need to consider what should happen when a press exists but it's not enabled.
(In reply to comment #4)
> Behavior is weird with a single press when it's disabled: you'd never know
> it wasn't supposed to be publicly available, except that the search box
> disappears. Need to consider what should happen when a press exists but it's
> not enabled.
What we mean by not public available? Only the books? Or any data, like contact, description, etc? If we mean the last one, every time a not logged in user tries to access any disabled press, we can redirect him to the login page. In the login page template, we can show a message telling that the content of that press is not public.
That should work for both single and multiple press scenarios.
Does that sound reasonable?
Bruno, yes -- if a press is disabled, none of the associated content should be available to the public. (The Press Manager, however, should be able to access it.)
The context enabled setting is used in many places in OJS, like OpenAccessNotification, SubscriptionExpiryReminder (both use this setting to send or not notification to users), ProfileForm (open access notifications related), GatewayHandler (to list journals to enable locks), SitemapHandler (to select journals to create site map), RegistrationHandler (enabled only appear on the registration list), ResolverPlugin (to export holdings), BooksForReviewReminder (to send reminders), and son on.
If we just remove the enabled setting and keep the require logins the way it is now, managers will not have the chance to avoid all those functionalities described above. They will hide their journal from the public access, but notifications will still be sent, users will still be able to register on their journals, the site map will still map the journal, etc.
That's what Alec proposed to do with the context enabled setting:
>Currently in OJS we have two ways of limiting access to journals (beyond of
>course article- and issue-level restrictions like subscriptions):
>- Require logins. When this setting is enabled, none of the journal pages
>(About; Archive; Search; and all the rest) are available to users unless they
>have first logged in.
>- Disable journal. When this setting is enabled, the journal pages (again,
>About; Archive; Search; and all the rest) are available, but never advertised
>on the site level -- the user must have a URL given to them by some outside
>source like an email or an outside URL they clicked. (This is commonly used
>e.g. when a journal is created but not ready to be publicized).
>These two are a little redundant, and the second in particular can be forgotten
>by the JM since a journal will operate OK without it being set correctly --
>it'll just hamper the finding of the journal in a multi-journal installation.
>I propose we remove the second option (disabling the journal) and focus instead
>on the first (allowing the JM to require logins if they choose).
The comment 7 is a response to this idea.
It is still important to be able to hide the journal from the listing, as a journal that is not yet live shouldn't appear listed among publicly available journals.