Hide Info-tab by Default for Course, Group and Folder

1 Initial Problem

Tabs shown like Learning Progress or Members can be hidden by configuration. It is not possible though to configure objects such that users do not see a single tab.

However objects like Courses, Groups and Folders could be tab-less if only the Info-tab would go away.

A tab-less object offers little distraction because there is less to click and explore and it will look sleaker. 

2 Conceptual Summary

Configure the Info-tab
In categories it is already possible to switch the info tab on and off. This feature should be extended to other objects.
The Settings-tab of all following objects should have a checkbox to switch on or off the Info-tab in 'Presentation' section.

• Course  > Settings-tab
• Group  > Settings-tab
• Folder > Settings-tab 

Users who want to look up something on the Info-Screen, they have to switch it on to do so.

"From the Outside"

• A User has the permission 'visible' on an object. 
• The Info-tab of that very object is set to 'off' in the Settings.  
• That User clicks on / enters a Permanent link to the object and ILIAS displayed the Info-tab, even though it is switched off "on the inside". 

"In Case of Emergency"

• A User has the permission 'visible' on an object.
• The Info-tab of that very object is set to 'off' in the Settings.  
• Something terrible happens and ILIAS can still dump the User on the switched off Info screen. 

3 User Interface Modifications

3.1 List of Affected Views

• Course  > Settings-tab
• Group  > Settings-tab
• Folder > Settings-tab 

3.2 User Interface Details

3.3 New User Interface Concepts

None

4 Technical Information

Killing, Alexander [alex], 2 Oct 2017: Again I think we need a way for a common settings section the settings forms.

5 Contact

• Author of the Request: Lenich, André [andre.lenich]
• Maintainer: literally everybody
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• BGHW

7 Discussion

AT: I revised the article somehow, but mostly the other one mentioned in the former JF comments. This one changes very little: The contradiction is healed in the other article. I have talked this over with Richard Klees and he is fine with the idea of dealing with this siiue using settings if a global default can be set.  
I re-submit. 

Killing, Alexander [alex], 19 Oct 2017: I support the request, if we implement this together with Making Operating Information of the Info-tab and Info-Action in Lists permission-sensitive, my prefernce/understanding would be:

• We only deactivate the subtab "Info" > "General". The option needs to explain, that a) the "Operating" information stays being accessible and that users with "Visible" permission only, will still be forwarded to this screen, since clicking the title of the object will lead to this screen (titles will always be linked).
• In the case of anonymous user we might display a standard message saying that logging in will give more access on the "Info" > "General" screen.

JourFixe, ILIAS [jourfixe], Oct 23, 2017: We highly appreciate this suggestion and schedule it for 5.4. We would like to have the following changes:

• Enabling 'Info Tab' should always be placed in section 'Presentation'. A byline should explain its behaviour (see below)
• Object titles are always linked if VISIBLE permission is given.
  • For users with role ANONYMOUS a related message is presented on the Info screen saying they need to login in / register to get access to object. Please discuss wording with product manager.
  • Logged in users with only VISIBLE see the 'Info' page anyway.

Kergomard, Stephan [skergomard], 20 SEP 2024: I don't see a good way to support this behavior in objects currently. Once we have a centralized way to set the visibility of the Info-Tab (the groundwork has been layed with the introduction of object properties), we can think about starting to do this, but not before. Special casing a special case is simply a very bad idea. Additionally this should be implemented as a facility in `ILIASObject` that than could be used by other objects.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.