Category: Conflict of two features (each works well independently)

{syntax type="tiki" editor="plain"}
As seen on the video attached, In a Tiki25 I use trackers with an IP field. The validation for this field is set to distinct.

If I later edit an existing item it will be impossible to save it. It seems like the code view it as a new item instead of an existing item I modify.

Due to this problem, I can't modify (and save) the item: validation will failed (an item with this IP exist already)

In the video attached we can see that I can't change the status from Open to Close.

Notes: If I do the same operation using the Tiki Trackers list view (batch actions) it work just fine.

{mediaplayer src="display2024"}

{syntax type="tiki" editor="plain"}
Just see ((All Patches)): content that is to be mouse-overed is breaking the page.

And on ((DogFood)), there is no mouse-over

{syntax type="tiki" editor="plain"}
Seen problem on ! and ^

Ex.:
http://dev.tikiwiki.org/tiki-index.php?page=WYSIWYG

{syntax type="tiki" editor="plain"}
Here is an example:
http://dev.tiki.org/Monitoring#Wishes

*Changing from empty to something doesn't go to the history
*Changing from something to something else does go to the history

On a Tiki 25 I have a tracker and I'm using a file tracker field.

Whit the option "File Count" doesn't limit if set to 1 (Maximum number of files to be attached on the field), I should be able to upload only one picture and there should be only one file attached.

But there is another option similar/related near the bottom of the options list.
"Replace Existing File" and if this option is set to no, "File Count" has no effect and as a result, I can upload many files and have many file attached.

We have an interface and logic issue here.
If "File Count" is set to 1, "Replace Existing File" should be always set to "yes" and display a warning, something like: "A file exist for this item, You will overwrite the previously uploaded file. Do you want to replace the existing file". (common expected user interface)

If "File Count" is set to anything but 1, "Replace Existing File" should be hidden.

At tiki-admin.php?page=trackers, when you enable:
* Inline editing
** Tracker list inline editing

And print (tested on Chrome and Firefox) all the fields values are blank.

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

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

{img src=show_image.php?id=10 }

{img fileId="396"}

When trying to highlight text with an URL, it does not work well:
{CODE()}__For more details see https://tiki.org/License__{CODE}

Result (everything below the next line gets bold and messed up):
__For more details see https://tiki.org/License__

{syntax type="tiki" editor="plain"}
Hotword processing needs to be turned off for the text expansion of the built-in macro __toc__: {CODE()}{toc}{CODE}

If a page name in a structure has spaces, and a defined __hotword__ appears as a name in the page, then the __toc__ expansion is corrupted by the __hotword__ processing. For example, if the page name in a structure is __xxx yyy zzz ddd__ and __zzz__ is a defined __hotword__, then the resulting link out of the __toc__ expansion is the equivalent of: {CODE()}((xxx yyy zzz ddd|xxx yyy)) ((zzz)) ddd{CODE}
Note how the trailing portion of the page name is not linked at all now.

This may apply to expanding the built-in macro __maketoc__, especially when aliases are shown, as well.

Verified on the opensourcecms.org installation as requested.

Even when the new unified admin backend isn't turned on, adminui.css is active and imposes style details like link color that conflict with the active theme stylesheet in many cases.

I suggest the page elements of the new backend be given a unique parent class to distinguish them from, for example, the standard navbar that appears in the top or topbar zone when the new backend isn't active, so its CSS rules aren't erroneously applied.

Alternatively, adminui.css could just not be activated unless the feature is.

(Actually, IMO adminui.css (the visual rules like foreground and background colors, etc.) should be a theme (or two - light and dark) that can be selected, or a standard theme selected consistent with the "make it optional" rule. The adminui appearance could be the default for new installations, but could then be deselected for sites where maybe organization or corporate branding is a priority (and at sites that live on the wild side and don't need black and white menus ;-) ).

For some misterious reason, since a few weeks (2 maybe {sign user="xavi" datetime="2015-05-19T08:56:45+00:00"} ) incremental search index fails (using either lucene or mysql full text search as the unified search engines)

Errors are related to permission problems (in an example with Lucene PHP as unified search engine, and at tracker item insertion):
{CODE()}
Search index could not be updated. The site is missconfigured. Contact an administrator.
fopen(temp/site1.example.com////////unified-index/_u.sti): failed to open stream: Permission denied.
{CODE}

{img fileId="1000" thumb="y" rel="box[g]"}


For a forum post, in another tiki 12 site, another user reported this error message:
{CODE()}
Search index could not be updated. The site is misconfigured. Contact an administrator.
fopen(temp/site2.example.com////unified-index/_e.sti): failed to open stream: Permission denied
Search index could not be updated. The site is misconfigured. Contact an administrator.
fopen(temp/site2.example.com////////////////////////////unified-index/_e.sti): failed to open stream: Permission denied
{CODE}

Content is added successfully (wiki page edition, tracker index, forum post, ...), but the error message is shown to the standard non-admin user as "Error", even if the setting "show php errors" is set to "Show to Admins only".



This is afecting all our tiki 12.x that we have in production (4) running on the same ((doc:multitiki)) instance, on an ((doc:ISPConfig))-powered server (in case this matters) . If unix permissions are related, then you need to know in advanced that ISPConfig requires permissions set as www-data for the owner, and clientN for the group, being "N" a number corresponding to the client number in the ISPConfig configuration. See ((doc:ISPConfig))
---
Related bug (I can't seem to select them through the field "Related-to" since they are not shown in the list, which is capped before reaching those ones starting with "Search index could not be updated. The site is misconfigured. Contact an administrator.":

"Search index could not be updated. The site is misconfigured. Contact an administrator."
http://dev.tiki.org/item4115

I added two (2) 'CustomSearch' to a single page in separate sections and separate div id's and different data, the search data and result keeps defaulting to the last CustomSearch on the page. below is the scenario:


{CUSTOMSEARCH}
{CODE(caption="Custom Search 1 & 2:")}{CUSTOMSEARCH( tpl="firstCustomSearch.tpl" id="first_search")}
{filter field="tracker_id" content="2"}
 {output template="templates/first-template.tpl" pagination="y"}   
//output data 1

{CUSTOMSEARCH}

//Some texts and logics seprating them here

//In another section

{CUSTOMSEARCH( tpl="secondCustomSearch.tpl" id="second_search")}
{filter field="tracker_id" content="4"}
 {output template="templates/second-template.tpl" pagination="y"}   
//output data 2

{CUSTOMSEARCH}{CODE}

//Output

Searches in first_search form field defaults to data on 'output data 2' and displays result also in it's custom_search_result div. With this, it skips the data and search on 'output data 1' entirely.

Perhaps, the fact that they share same js 'customsearch' variable picks the last one, not sure.

Also, the inclusion of 'destdiv' parameter with different id's (of course) resulting to respective output data section enters an infinite JQuery loading blocking the data from being populated on the page. While a rename of 'destdiv' parameter to say 'destinationdiv' (undeclared parameter name, yes) populates the display without the blocking but doesn't affect the behavior of Customsearch (of course).

I hope I've been clear enough with this succinct explanation.

Let me know if you would want an elaborate one.

{CODE()}Version 12.0svn is no longer supported. A minor upgrade to 12.0 is required.{CODE}

{img fileId="691"}

{kaltura id="1_5ahsbgoc"}

When typing an email address in a wiki page, Tiki can automatically protect the address.

For example: foo@bar.com

But, if you enclose the email address with punctuation, the anti-spam protection is lost.

For example: (foo@bar.com)

{syntax type="tiki" editor="plain"}
I defined a category Helpdesk and assigned it to a structure Helpdesk FAQ.
Also i defined a group Helpdeskadmin, which useres should be able to add new pages to the structure.
Now if a helpdeskadmin try to Add a page to the structure (with the button on the top of the wikipage with the toc), he must have global permission tiki_p_edit, not only for that categorie.



My analysis:

In tiki-editpage.php there are to permission tests:

First:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

Second:

//Is new page to be inserted into structure?
if (isset($_REQUEST["current_page_id"])) {
[...]
$structure_info = $structlib->s_get_structure_info($_REQUEST['current_page_id']);
if ( ($tiki_p_edit != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit')) || (($tiki_p_edit_structures != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit_structures')) ) ) {
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

The first one is the problem becaus it asks only for globel permission, i think.

If admin log as a user and use a form (tracker view, tracker plugin on a wiki page, etc) for a tracker where there is a username selector tracker field (with auto-select option or not) it will be set as the logged user is the admin or display the list of all the users.

It should work as intended and the username selector tracker field should work as I was the user I choose to log with.

It some case (user tracker information - Tiki log in) it can salvage the admin groups and real name.

{syntax type="tiki" editor="plain"}
Please see the result of the diff:
{flash type="url" movie="display291" width="579" height="545"}

http://demo.tiki.org/wysiwyg-wiki/tiki-pagehistory.php?page=ffffffff&history_offset=1&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=10&paginate=on&history_pagesize=24&bothver_idx=10

{syntax type="tiki" editor="plain"}
WYSIWYG editor is displaying theme background inside of edit box using darkshine. This results in the red and red stripe background behind your editing, but this background does not appear behind the wiki page when viewed (displayed on white, as is desired)

View a Spreadsheet in Mobile mode: tiki complains inifinitely that jquery_ui is not enabled

You enable it, try again, and you get the same error message.

If you switch to non-mobile mode, the tiki sheet is there as usual. But when you switch back to mobile mode, you get the same error again.

If you visit the admin panel "Features", "Interface" tab, you can see that jquery_ui is disabled indeed in Mobile. However, if you switch to non-mobile mode, jquery_ui is shown as enabled.

In mobile mode, as a reference, these seem to be the css libraries loaded (no jquery-ui) when attempting to view a spreadsheet:
{CODE()}
<link rel="stylesheet" href="vendor/jquery/photoswipe/photoswipe.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-mobile/jquery.mobile-1.3.2.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/treetable/stylesheets/jquery.treetable.css" type="text/css" />
<link rel="stylesheet" href="styles/mobile.css" type="text/css" />
{CODE}

When in non-mobile mode, these are the ones loaded (they include jquery-ui):
{CODE()}
<link rel="stylesheet" href="css/cssmenus.css" type="text/css" />
<link rel="stylesheet" href="vendor_extra/elfinder/css/elfinder.full.css" type="text/css" />
<link rel="stylesheet" href="vendor/codemirror/codemirror/lib/codemirror.css" type="text/css" />
<link rel="stylesheet" href="lib/codemirror_tiki/codemirror_tiki.css" type="text/css" />
<link rel="stylesheet" href="temp/public/codemirror_modes.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-ui-themes/themes/flick/jquery-ui.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-timepicker-addon/dist/jquery-ui-timepicker-addon.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/cluetip/jquery.cluetip.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/colorbox/example1/colorbox.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/treetable/stylesheets/jquery.treetable.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-sheet/jquery.sheet.css" type="text/css" />
<link rel="stylesheet" href="styles/fivealive.css" type="text/css" />
{CODE}

Te reproduce, login to view this spreadsheet here:
http://xavi-9794-4985.show.tikiwiki.org/tiki-view_sheets.php?sheetId=1

u: admin
p: 12345

Click at Switch to mobile mode. Done.
---
UPDATE: Closing item as outdated, since Tiki 15+ doesn't have this issue due to Bootstrap. {sign user="xavi" datetime="2017-01-29T14:37:58+00:00"}

wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)

See it reproduced here:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The homepage has at the bottom the standard code for an alias at teh page "HomePage" to be accessed also from "Casa" alias page name.
{CODE()}
(alias(Casa))
{CODE}

Therefore, you can access to the homepage also with:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=Casa

However, if you open that wiki pade for edition with "Inline wiki editor", make some changes, and saved the page through the inline wiki editor (click again at that button that you used to open the inline editor), then the alias link is gone. If you edit the page with the standard wiki plain text aditor, you will see that the code at the bottom is replaced with a standard wiki link pointing to "HomePage" and using "Casa" as label.
{CODE()}
((HomePage|Casa))
{CODE}

Check this page: https://dev.tiki.org/Tiki+Slideshow+used+in+BigBlueButton

See screencast for explanation

{flash type="url" movie="display560" width="859" height="603"}

See screeshot

There's a problem with wiki_watch_minor. It conflicts with notification
wiki_page_changes_incl_minor ("Any wiki page is changed, even minor
changes"). If wiki_watch_minor is disabled, a wiki_page_changes_incl_minor watch will not be triggered by a minor change.

The difference between minor and non-minor edits is done in
notificationemaillib->sendWikiEmailNotification(). This is where the
preference could be taken into account.

This is a regression from r10949. It was discussed on http://article.gmane.org/gmane.comp.cms.tiki.cvs/57346

Adding many users at once to a group fails in 12.x, and it used to work nicely in 9.x LTS at least.

I had Jquery Chosen enabled, and when I disabled it, I was able to add them to a group through tiki-adminusers.php as usual.


To reproduce, go to:
http://xavi-9794-5163.show.tikiwiki.org/tiki-adminusers.php

u: admin
p: 12345

select both users (user1 & user2), click at "Manage group assignments", and choose to assign them to group "Admins". Validate the confirmation step. Nothing happens (they are not added to the Admins group).

Repeat without JQuery Chosen, and it will work as expected.
---
Update {sign user="xavi" datetime="2014-04-07T07:44:15+00:00"}
Actions on multiple users with chosen and sortable tables work, but the second dropdown is not shown properly:
{img fileId="742" thumb="y" rel="box[g]"}
---
Update {sign user="xavi" datetime="2015-04-02T08:04:24+00:00"}
You can't even select any groups at the step to choose group in the multi selection combo box.
{img fileId="992" thumb="y" rel="box[g]"}
---
Update {sign user="lindon" datetime="2015-04-07T03:41:55+00:00"}
I am not able to recreate this [[the former issue report related to jquery sortable tables] using my local 12x - I am able to add or remove multiple users to multiple groups. Did it with 25 users with no issue. The list of groups came up properly and I was able to multi-select.
---
Update {sign user="xavi" datetime="2015-12-16T07:59:32+00:00"}: removed references to Tablesorter as I could confirm that at least with current code (thanks lindon for checking!) the issue seems to be attibuted to Chosen only.