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.

Bug 7872 - Press "enabled" flag does not do much
Press "enabled" flag does not do much
Status: REOPENED
Product: OJS
Classification: Unclassified
Component: Journal Management
3.0
All All
: P3 normal
Assigned To: PKP Support
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-10 16:55 PDT by Alec Smecher
Modified: 2013-04-04 17:47 PDT (History)
3 users (show)

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Smecher 2012-09-10 16:55:34 PDT
Currently it controls tombstone generation and hides content from the OAI interface but otherwise doesn't affect the front end.
Comment 1 Jason Nugent 2012-09-11 05:35:07 PDT
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). 

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?
Comment 2 beghelli 2012-09-11 06:17:51 PDT
(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".
Comment 3 Alec Smecher 2012-09-11 08:03:25 PDT
OK -- I missed that in grepping. Sounds fine.
Comment 4 Alec Smecher 2012-09-18 16:44:29 PDT
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.
Comment 5 beghelli 2013-01-10 13:08:13 PST
(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?
Comment 6 Alec Smecher 2013-01-11 14:06:18 PST
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.)
Comment 7 beghelli 2013-03-25 09:56:17 PDT
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.
Comment 8 beghelli 2013-03-25 10:02:25 PDT
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.
Comment 9 Juan Pablo Alperin 2013-04-04 17:47:36 PDT
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.