Category: Perspectives

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

It would be nice to be able to select a perspective depending on the current content's categories and their respective jails.

I have made a hack that achieves this, but it would be nice to have it implemented as a feature. I described my hack and included the code here:

https://dev.tiki.org/lookup+perspective+according+to+category+IDs

Hi,

I have the idea for a new feature or better to say a major extension of the use of existing features.

Areas would be related with the usability of the Website, where you can assigne content to certain perspectives in a way, that a link to this content will guide you sametime aswell to the content as to the related perspective.

Anonymous users (and registered) would find the content in the context of menus and modules, the webdeveloper decides.

I see "Areas" Important for certain usecases, it could be built with up mainly with existing features - only few code should be necessary.

See more description on http:dev.tiki.org/Areas

Cheers
Torsten

It's sometimes useful to allow anonymous or other users without full perspectives-related permissions to switch perspectives. For example, I want to demonstrate themes by using a link such as -+ tiki-switch_perspective.php?perspective=21 +- , in a dropdown menu, to switch to perspective 21. This perspective has preferences including a home page with info about the theme, using the theme itself, and so on, all set by the perspectives feature. The user continues to be in that perspective after leaving the page, so can see a blog or calendar or whatever using that theme, until switching to another perspective. This works fine for admin, who has all current perspectives permissions, but doesn't work at all for anonymous users. Visiting the page shows the theme set for the page but doesn't change the perspective.

I imagine there could be other scenarios where users would select a perspective and stay in it until they switch to another one.

There are now four permissions related to perspectives:
* Can admin perspectives (tiki_p_perspective_admin)
* Can view the perspective (tiki_p_perspective_view)
* Can edit the perspective (tiki_p_perspective_edit)
* Can create a perspective (tiki_p_perspective_create)
I propose that another permission be added:
* Can switch perspectives (tiki_p_perspective_switch)

Or whatever fix would be effective here. The "Users can change theme" option on tiki-admin.php?page=look serves the same purpose but seems to be set via that admin page rather than on tiki-objectpermissions.php.

Somewhat strangely, if I give anonymous the "Can create a perspective (tiki_p_perspective_create)" permission, then switch-perspective works for anonymous, who can see the list on tiki-edit_perspective.php and can input a perspective name but it doesn't appear in the list to be edited, etc. so this could be a hacky workaround but the clean solution of a new permission would be much better.

Related: ((Areas Perspective Multi-domain dogfood))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

In version 9.11, creating a Workspace using Perspectives and Category Jail would permit a user to view a tracker and all of its tracker items when that tracker was categorized appropriately. Upon upgrading to version 12.11, the tracker is still visible to users within the Perspective, but the "View Items" page does not list any items. The items are still accessible and editable by the user if they know the Item ID or have links to them, but they cannot be browsed. The item count will show correctly when viewing the list of trackers, but the tracker itself will report that it contains 0 items when viewing the items list.

Steps to reproduce:
#Go to https://tiki.org/News
#Go to https://tiki.org/article452-Tiki-18-1-has-been-released-fixes-and-security-update
#Click "New Article"
#Enter a TEST title, Classification > Topic Releases and Patches, Publication > __uncheck the "Published" checkbox!__
#Click the "Save" button

You get switched back to default perspective. When you switch back to the first tab "Content" you see the form content is gone and the rest of the tabs got reset to the defaults as when you start editing new article... :(

Clean install of tiki-26-0 php8.1.23 apache2 ubunut 22.04
After tiki setup completes eg lock installation and continue, I get a black webpage with this at the top

I wonder is some of the code not compliant with php8.1 the documentation mention arrays have to be a certain configuration:
Note:
Prior to PHP 8.0.0, square brackets and curly braces could be used interchangeably for accessing array elements (e.g. $array[42] and $array{42} would both do the same thing in the example above). The curly brace syntax was deprecated as of PHP 7.4.0 and no longer supported as of PHP 8.0.0.
[https://www.php.net/manual/en/language.types.array.php|https://www.php.net/manual/en/language.types.array.php]


Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, bool given in /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php:49 Stack trace: #0 /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php(49): in_array() #1 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup_base.php(662): AreasLib->getPerspectiveByObjectAndCategories() #2 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup_base.php(668): {closure}() #3 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup.php(66): require_once('...') #4 /var/www/tiki.squadron6.com/tiki-26.0/tiki-index.php(43): require_once('...') #5 {main} thrown in /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php on line 49

forums in t.o unusable: help!

I tried to reply to this forum post https://tiki.org/forumthread62480 with my user "xavi" adding this content:

{QUOTE()}
Hi enelson and welcome to the Tiki Community
Have a look at the authentication methods available in Tiki:
https://doc.tiki.org/Login+Config

and external authentication:
https://doc.tiki.org/External+Authentication

If the main CMS was Tiki, you also configure same login through several methods tested and working elsewhere ( ((doc:Intertiki)), among others). What does composr offer that you can't get in Tiki? (just curious)
{QUOTE}

The post is not saved. I tried 3 times. No way.

Clicking at the top at the link to "prev topic" produces this url:
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=62487&topics_offset=-1

which returns this error message on a semi-WSOD page:
{CODE()}
Error
Notice: invalid variable value: $_GET["topics_offset"] = -1
{CODE}

I tried then to go to the list of forums through the usual SEF url:
https://tiki.org/forums

but that is re-sent to the tiki home page with the blueish perspective
https://tiki.org/tiki-index.php

I'm looking for an alternative way to simply go to the forums list in tiki.org and I can't find it anywhere in the blueish perspective. I presume that this is related to some bad configuration or bugs with perspectives. But I can't confirm, and I can't change them any more as simple user in tiki.org.
Shouldn't we expose the main app menu somewhere (at the bottom, at least) for registered users???

Help!

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

To reproduce the issue:

1- Apply profile http://profiles.tikiwiki.org/Jailroot_Demonstration on trunk

2- Pick perspective "B"

3- Search for "contentA1". You find

A1 and B1 (OK)
A1 A2 A3 (Not OK)

tiki-listpages.php exhibits the proper behavior.

Some prefs should need to be different per language

Ex: logo, site title, meta-description, meta-keywords, menu

So we may avoid:
http://doc.tikiwiki.org/Multilingual%20Menu#Check_language_and_show_alternate_menu


tiki-edit_perspective.php (Tiki5) is an efficient way to override global prefs depending on perspective. So now, how to handle similarly for languages?

Please note that some times, we'll have both perspectives and languages.


Related:
{wish id=968}



Two solutions:
* Add tra() for site title, meta-description
* Make text areas for things that smarty logic would be useful (ex: menu) __Done in Tiki5__

When an iframe in a wiki page loads another page that is associated with a perspective, the perspective class (like "perspective4") is added to the body tag not only of the page in the iframe, but the page that contains the iframe. This is a bug because the page containing the iframe shouldn't have that perspective class.

There was a missing check to make sure users had the permission to switch permission.

This commit was to address this:
http://sourceforge.net/p/tikiwiki/code/46963

However, now, it's not possible for anonymous uses to switch perspectives, even if they have tiki_p_perspective_view

//Update:
//The issue seems not to be a bug, as I cannot at all reproduce an show.tiki.org, where the behaviour is unexpectedly expected ;-)
//Closing for now
//Torsten

In a collaboration platform I use different workgroups. Each workgroup should have an individual home page with group specific information.

For a perspective (example name: proceedings Id: 14) I set up a wiki page as home page (example: page name: "p14") and set th wiki home page to p14 instead of HomePage.

When I switch from any other persective (or default) to this perspective, the user should be referred to the page "p14". Instead he is referred to the standard HomePage like in default.

Altering the Home feature (for example from wiki to articles) in the perspective 14 has no effect. But altering the Home feature globally oberwrites the setting in the perspective.

This behaviour seems to be somehow a partial deactivation of perspectives overwriting.
The effect is not for all preferences - for example perspective-individual themes work.

At first now I try to reproduce on show.t.o

I wish a perspective session (when switched into a perspective) didn't expire so soon. I need to re-activate the perspective view several times a day when logged in onto a site (avan.tech). I dunno the precise time set to expire the session for perspectives but it would be nice to keep it at least for one day but optionally to have it configurable (like we have for the remember me session for example). Presumably it is a cookie which expires too soon and returns user to the default perspective.

Thanks!

To be specific, the perspective's theme is applied on pages like tiki-admin_calendars.php, but not on tiki-edit_perspective.php or pages like tiki-admin.php or tiki-admin.php?page=general. On these pages, the default theme of the site is used instead. I haven't checked yet if other perspective preferences are also ignored.

http://suite.tiki.org/Tiki+Suite is a perspective of http://tiki.org/

In mobile mode of http://suite.tiki.org/, we get "Too many redirects" or "This webpage has a redirect loop". You can also get this by going into mobile mode from suite.tiki.org

{flash type="url" movie="display665" width="1071" height="549"}

Thanks to Simon Boulet for reporting

Using workspaces, when changing workspace names after creation, editing the category to rename its elements works OK for wiki pages and file galleries, but perspectives' names are not changed.
Seems "profile_symbols" & "objects" tables are not updated.

At https://tiki.org/Add-Consultant the value for 3 fields that were added recently (index rebuilt several time since) are not display and the user can’t choose anything.

{img fileId="1280" thumb="box"}

Maybe some of you will think of this as a "marketinhg" thing, but let's face it : for most users on the Web "wiki" is synonym with "MediaWiki-powered sites that look like wikipedia".

What I propose is to create the theme and tools to facilitate migration of mediawiki powered sites to tikiwiki the (very) easy way : fill a form during install that points to the Mediawiki database, and extract all the info to automagically populate the Tiki. I'm willing to participate, but I do not feel I have the required knowledge at this moment to be able to do something useful in the coding part : I know little to no PHP or MySQL stuff, I even wasn't able to install Tiki properly here (shame on me).

in your browser check the source of http://suite.tiki.org/tiki-index.php

{img fileId="910" thumb="n" rel="box[g]"}

suite is a perspective within the community site. They share the same codebase, so maybe there is something with the perspective lib