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

Hi

When Search engine friendly url feature is enabled. The registered users cannot delete their own post. Please note the registered user can delete the post when search engine friendly url is turned off.

The url on the browser appear as follow
[http://localhost/tikiwiki3/blog9&remove=25|http://localhost/tikiwiki3/blog9&remove=25]

When i print out the $_REQUEST array. The result was as follow

blogId is 9

There was no "remove" in $_REQUEST array.

Please suggest the workaround for this issue.

To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

And see the same page as user:
u: user1
p: user1
which has been granted local permission to view and edit that page, and global permission to edit structures. If you attempt to go to edit the structure,
http://xavi-9794-5464.show.tikiwiki.org/tiki-edit_structure.php?page=D1+Cover&page_ref_id=1

you get:
{QUOTE()}
Error: You do not have permission to use this feature: tiki_p_view
{QUOTE}

Potential Workaround:
Comment out the check for the permission to display any part of the edit strcutures interface. Line 22 from tiki-edit_structure.php should become:
{CODE()}
//$access->check_permission('tiki_p_view');
{CODE}

And line 123 from templates/tiki-edit_structure.tpl should change from:
{CODE()}
{if $editable == 'y'}
{CODE}
to
{CODE()}
{if $editable == 'y' && $tiki_p_edit == 'y'}
{CODE}

Should that be enough?

I couldn't test properly due to the interference of this other bug which prevents assigning object permissions:
https://dev.tiki.org/item5916

Removing a tracker field should remove also the references to that field in the popup fields definition in the tracker properties

respect/obey object permissions (beyond global) with plugin pivottable
To be reproduced in short.
Cases to be handled properly:
a) granted globally but restricted locally
b) granted only locally

Reproduced:
admin access:
http://xavi-9794-6148.show.tikiwiki.org
u: admin
p: 12345

__Case a) granted globally but restricted locally__
http://xavi-9794-6148.show.tikiwiki.org/tiki-index.php?page=Homepage+for+Staff
u: client1
p: client1
Group clients has global perms to view and edit wiki pages, but for that specific page, Clients can only see the page, and not edit it (managed through object perms).
However, user client1 currently can see the button to "Edit pivot table" (by mistake), while can't see the button to edit the wiki page (as expected). If the user clicks at edit pivot table, can change controls, but at saving time, nothing is changed (as expected, since he/she doesn't have perm on that page to edit it).

__Case b) granted only locally__
http://xavi-9794-6148.show.tikiwiki.org/tiki-index.php?page=Homepage+for+Staff
u: staff1
p: staff1
That page has object perms (not global) for group staff to view and edit. User staff1 can edit the page, but this user doesn't see the controls to edit the pivottable plugin.

If you rollback a page to a previous version, the links to that page are show with a question make instead of a proper link.

RSS feed for Articles in tiki.org produces WSOD. Reproduced here:
https://tiki.org/tiki-articles_rss.php?ver=5

or
https://tiki.org/tiki-articles_rss.php?ver=5&css=y
(as indicated here https://profiles.tiki.org/RSS+Handler which used to be a valid url afair)

or
https://tiki.org/tiki-articles_rss.php?ver=2

However, it works well in themes.t.o:
https://themes.tiki.org/tiki-articles_rss.php?ver=5

I wanted to add that articles rss feed to the Admin UI backend rss module ( loaded from here https://profiles.tiki.org/Unified_Admin_Backend_Default_Dashboard_1 ), but there is no point if it triggers some error 500 or WSOD by any other reason.

Any tip anyone on how to solve? @ohertel maybe?

It is the second time (and I see others having the same issue) that saving a comment using the "Save and Comment" button when completing a tracker item on tracker5 creates 2 identical comments instead of one.

__Releated to:__ item8186-to-be-synched-fetched-event-details-of-of-Calendar-event-and-details-in-a-Tracker-item-with-Tracker-field-Calendar-item

__The cause:__

Given a Tracker has a field of type 'calendar item' and a number of other fields, for example a 'Textarea' or a 'Textfield'...

Given a user creates a Tracker item and desides to add an event to the Tracker item, __then__ the user can edit the Calendar event from inside the tracker, after the Tracker item is saved the first time (with existing event).

It is quite probable that a user who wants to edit a Calendar event might need to edit another field of the same tracker item at the same time.

Looking at the UI of the Tracker form, a user would most likely asume, that he can add or edit data in the Textarea, then edit and save the event and then save the Tracker item without losing any data.

In fact, when the user clicks at the edit-event button and then the save-event button, __all changes made to the Tracker item in the other fields will be lost.

__Observation:__

After saving the event, the whole page (browser tab) reloads the non-edit version of the page, instead of only saving the Calendar details to the Calendar and keeping the other field's data 'alive'.
Thus if you have filled a form or edited fields previously filled and then edit the event and then save the event, the just filled data get's completely lost

I imagine, that there would be some kind of AJAX event needed that pushed the Calendar event data to the database, without reloading the page.

Depending on the respective Tracker form, this could cause the loss of work and thus frustrate users to some unreasonable extent.

{syntax type="tiki" editor="plain"}
If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:))

Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors.

This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages:
*Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page.
*If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing.

It asks for password, but then, give "Error saving image: HTTP/1.1 401 Authorization Required"

Regarding:
[http://doc.tiki.org/Clean+URLs]

The documentation linked above states (my emphasis added):

"Search engine friendly url Postfilter - ~~#090:__To generate SEFURLs for all Tiki links, also check the second checkbox__~~ which creates short URLs by filtering the output. The SEFURL Postfilter consumes more processor (CPU) time than the non-filter version (it deals with all the text and it deals also with cached text like modules while the 'on the fly' filter does not do it. ~~#00F:__In future versions the SEFURL Postfilter will not be used__~~ - it is only necessary until the template SEFURL work is finished. ~~#906:__Either one or both features (SEFURL and SEFURL Postfilter) may be used.__~~

I had both checked. This worked when I was on 4.x, and started failing when I moved to 5.0. This is why I marked it as a regression. The problem still exists in 5.3.

Each now works OK separately, but the they no longer work together. I've disabled the postfilter.

Is the postfilter no longer necessary, or am I no longer generating sefurls for all links? Priority of 3 based on the assumption that the postfilter is still necessary, otherwise I would have set it to 1.

{syntax type="tiki" editor="plain"}
When searching for terms which appear in areas for which a user has no permission, the search results show the full number of pages on which the term appears but the detailed results are limited to pages for which the user has permissions. This makes a certain amount of sense but may be confusing for users who are not aware that they are restricted from some content.
I'm not sure at this point whether this applies to only FT Search, Tiki search or both. (I've pretty much stopped using Tiki)

On Tiki23, when captcha is set to the original one (not Google) an image is displayed below an input field where you need to enter what you see on the image.

However with Select2 enable as soon as I change focus on the input field (click in it) the feedback message "No items to show" is displayed over the image the user should "read" hidden it.

Select2 is located here: Control panels, Features, Interface;
jQuery Select2 Select Boxes : enable
Select2 Sortable Multiselect : enable

Captcha is located at Control panels, Log in, Captcha.

See this screenshot (dev upload is broken) : https://ibb.co/h1pQz95

Selecting a new wiki homepage "Courses:_:Foo" got understood as "Courses" as the new wiki homepage.

I'm using :-: as the default namespace separator for workspaces.

This was working as expected in Tiki12.
---
Reproduced here:
http://xavi-9794-6103.show.tikiwiki.org/tiki-admin.php?page=wiki
u: admin
p: 12345

page selected as homepage was:
Course_Template:_:2016 Fall:_:Course Outline

but it was stored as:
Course_Template

In addition, there are some other oddities with workspaces in 15.x, but that is another story (to be reported aside elsewhere)

This profile https://profiles.tiki.org/Bug_Tracker_15 makes an attempt to allow the user to set the sender_email if they haven't done so yet (which is usually the case when we are creating new show.t.o instances, or reproducing some scenario in localhost to debug some feature, etc.)

I'm using the same type of syntax which seems to be working in other profiles:
But this one in Bug_Tracker_15 profile seems not to work:
{CODE()}
sender_email: $profilerequest:sender_email$YourEmail@example.com$
{CODE}

while these other ones, in [https://profiles.tiki.org/Easy+GeoBlog|Easy GeoBlog], for instance, work as expected:
{CODE()}
style: $profilerequest:style$gradiant.css$
sitetitle: $profilerequest:sitetitle$My Easy GeoBlog$
sitesubtitle: $profilerequest:sitesubtitle$My thoughts and musings$
browsertitle: $profilerequest:browsertitle$Easy GeoBlog$
{CODE}

I tried if the issue was adding an "@" character in the working fields of Easy Geoblog, but that worked as expected also even if an email was written there.

When you set some expiry time for a group membership (through the admin groups interface), this information is stored in mysql table users_usergroups, and this is taken into account when you use ((doc:PluginMemberPayment)).

However, in other cases of letting a user join a group which has some expiry date set, that information (expiry date) is not stored at mysql table users_usergroups as expected.

Reproduced here:
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

You can also test with a few users already created:
u: foo1
p: 12345

or
u: user1
p: user1

Cases:
!!! a) Through usual Registration
if you set some group to be selected at registration time
You can register a new user to test case (a), and select either Group1 or Group2 at registration time (both have expiry date 2 days later):
http://xavi-9794-5946.show.tikiwiki.org/tiki-register.php

!!! b) Through Plugin subscribegroup
if the user clicks at ((doc:PluginSubscribeGroup)) (with perms and site config set up appropriately),
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#Plugin_subscribegroup

!!! c) Through Plugin MemberList
if the user selects to join him/herself thorugh ((doc:PluginMemberList))
(with perms and site config set up appropriately), or the admin join a user to that group
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginMemberList

However, looking at the user through tiki-assignuser.php?assign_user=foo , the right expiry information is shown.
http://xavi-9794-5946.show.tikiwiki.org/tiki-assignuser.php?assign_user=foo1

But if you use ((doc:PluginGroupExpiry)) (which looks for that date at table users_usergroups) no date is found and it reports back that the group membership never expires.
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginGroupExpiry_info

In addition, it seems that someone already noticed that type of issue, and this comment can be found in lib/userslib.php > function get_extend_until_info:
{CODE()}
(...)
function get_extend_until_info($user, $group, $periods = 1)
{
//use these functions to get current expiry dates for existing members - they are calculated in some cases
//so just grabbing the "expire" field from the users_usergroups table doesn't always work
(...)
{CODE}

---
Update {sign user="xavi" datetime="2016-05-27T14:38:26+00:00"}:
* this issue seems to be fixed in Tiki 15.x (as of r58705, at least). The 3 use cases work as expected (nice!). The extra code in 15.x would need to be backported to 12.x, I guess.
* Assign user to groups has got a regression in 15.x: you cannot see (nor even edit) the group expiry date through the standard user administration UI in 15.x: when you click in "add or remove from a group" in 15.x, you are sent in a modal to this type of url:
+ __tiki-ajax_services.php?controller=user&action=manage_groups&checked=foo1&all_groups%5B0%5D=Admins&all_groups%5B1%5D=Anonymous&all_groups%5B2%5D=Group1&all_groups%5B3%5D=Group2&all_groups%5B4%5D=Registered&offset=0&sort_mode=login_asc&numrows=25&modal=1__
+
+ and no expiry information is shown.
+
+ While in Tiki12, you are sent to:
+ __tiki-assignuser.php?assign_user=foo1__
+
+ This has been added as a new bug report, since it's another issue (regression):
+ [item5953]

In a Tiki22 I have 2 trackers (orders, payments) with relation fields.

They may be one order with several payments (recurrent, monthly payment).
I have actually 4 payments per orders and that’s work ok but on a specific case I have more payment and Tiki throw errors.

{CODE()}
×
 Error
Indexing failed while processing "1268" (type trackeritem) with the error "Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1"
×
 Error
Malformed search query: Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1
×
 Error
The search index could not be updated. The site is misconfigured. Contact an administrator.
Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1
{CODE}

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

By nature relation shouldn’t be limited and able to handle many items.

~~#F00:__UPDATE__~~
It is plaguing and changing behaviour of other components.
In the screenshot below you can see many counter (plugin list count template) displaying a 0 instead of the real value even if the list plugin is set with a different tracker. There is a big chance the index become corrupted or not completed so I escalated.

The fields should be protected in a first place (avoiding using longer data than possible to use) and finally this field specific should be set to a relative high amount of data.

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

I recall this working in 6.x or so, so "tagged as regression".

Using (12.1svn): Abril 4, 2014. r50665

Sharing acccess rights, with token access, seems to be failing.
When using "Tell a firend" for a wiki page, as user with tiki_p_admin, there is a checkboxa message sending time, and the link in the email received by the destination emial contains a TOKEN hash inside. However, once clicked in that link in a browser as anonymous, the user see the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

When using Share, as user with tiki_p_admin to share a wiki page, I see the dropdown to indicate how many times to share access rights with that email. I shared for 3 accesses (the mas allowed in the admin panel, and thus, in the dropdown, also). The eamil that receives a message comes with a token hash inside, but still gets the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

---
u: admin
p: 12345
Homepage restricted to registered users. When SEFURL is off, sharing access rights with friends seemed to work as expected.
http://xavi-9794-5225.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage
---
IT seems the bug was not solved in trunk by then (15.x currently), and a new fix was added by jonnyb in r58322. {sign user="xavidp" datetime="2016-04-14T12:54:16+00:00"}
---
Fix unconfirmed for me {sign user="xavi" datetime="2016-04-18T11:41:19+00:00"} in localhost with a snapshot of this site upgradeed to 15.x (rewrite rules do not work in show.t.o so SEF cannot be tested there). When attempting to view the site as anon. with the url (which includes the token param name and value), I get:
{QUOTE()}
Your access to this page has expired
{QUOTE}

Update June 22, 2016: This issue seems to happen still when any param is added to the url (page_ref_id=nnn - from structures, or fullscreen=y to prevent disclosing information from the side modules that the user has access to, besides the content that would like to be shown frmo the central column). {sign user="xavi" datetime="2016-06-23T07:32:05+00:00"}

{syntax type="tiki" editor="plain"}
If you activate both the SEFURLs and the very useful "Show category objects", the urls generated by the category browser are not correct for trackers and file galleries.

In both cases it only gives the numeric identifier, without the "tracker" or "file" part.

Here is what it produces:
http://site-name.com/2

Here is what it should produce:
http://site-name.com/tracker2

Please see comments of https://dev.tiki.org/item7922-It-is-not-possible-to-upload-a-second-time-an-image-as-banner

I retested today and the log doesn't show the Tiki has been updated while it has:
Last update from SVN (25.0vcs): Saturday February 19, 2022 23:11:31 IST - REV 79744 (InnoDB)

Seen on tikiwiki.org

It gives error 404


Possible solutions:
*Users could be prevented to create pages with characters that conflict with
*Rewrite rules are not activated when page name contains such characters

There is a problem in Slides in 21.x: Section about wiki page comments wrongly placed on top of all slide titles, when some setting is on related to comments.

This was not happening in previous LTS versions, with the former slideshow system (that's why I tagged it as regression; untested in 19.x, 20.x, etc).

Reproduced here:
http://xavi-9794-7332.show2.tikiwiki.org/tiki-slideshow.php?page=Tiki+Wiki+CMS+Groupware#s0
u: admin
p: 12345

Just after enabling the pref:
-+wiki_comments_displayed_default+-
and while keeping the default pref: -+wiki_comments_allow_per_page+- Disabled (which is the default setting).

You don't see the comment as Anonymous.
You'll see the comment if you log as admin.

In all cases, comments should NOT be displayed in a Wiki slideshow: https://doc.tiki.org/Slideshow

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

Slideshow system fails to work if there is no ((doc:PluginSlideshow)) call in wiki page but just automatic link at the page bottom.
It seems as if some library (or something) is missing to allow passing slides forward, because the first slide is shown, and it works to hiughlight bullet points, but when the time to move to the 2nd slide comes, nothing happens and slideshow stays in the first.

If you go to list slides, and attempt to click at any from that list, it seems as if the slideshow systems wants to take you there, but it comes back to the first slide very quickly.

Reproduced in this show2.t.o instance attached to another bug report:
http://xavi-9794-7332.show2.tikiwiki.org/tiki-index.php?page=Tiki%20Wiki%20CMS%20Groupware
u: admin
p: 12345

Once you edit that page, and add a simple call to plugin slideshow inside (no params needed), and tiki caches cleared (just in case), then it works as expected:
{CODE()}
{slideshow}
{CODE}

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.

Going to Admin Categories > Bug on dev.tiki.org returns alerts on top of the page:
{CODE()}
ErrorErrorError
Tracker list_items ran out of memory after 0 items.Malformed search query: Parsing search query failed: "org.elasticsearch.common.ParsingException: [_na] query malformed, must start with start_object"Notice: invalid variable value: $_GET["maxRecords"] = undefined
{CODE}