Category: Feature request

__Not to be confused with PluginSign!__

In Tiki23 Plugin signature allow a user with editing permissions to save inline (inside the plugin code) a signature: "stored within the plugin content as image/png base64"
https://doc.tiki.org/PluginSignature

While this is visually nice, it doesn't really fit possible use case where a user signature is needed as acceptation or approval of "things" like terms acceptance, money transfer, administrative documents approval, administrative authorisation, etc.

We don't want to give the user the right to edit the page.
We need a new permission: "can use plugin signature". So a user can only sign without changing or viewing the code.

In Tiki23 Plugin signature allow a user with editing permissions to save inline (inside the plugin code) a signature: "stored within the plugin content as image/png base64"
https://doc.tiki.org/PluginSignature

While this is visually nice, it doesn't really fit possible use case where a user signature is needed as acceptation or approval of "things" like terms acceptance, money transfer, administrative documents approval, administrative authorisation, etc. Saving plugin code into the page has a tendency of helping page and plugin content breakage (like with the plugin convene).

The signature should be save as a file in the file galleries.

With it, Tiki admin should be able to add essential parameters to make the feature useable (not only nice to see but to fit real life case).
For exemple if the signature is used as formal approval or authorisation and need to be matched later with a user acceptance we certainly need things like:
* Username
* Date of acceptance (file creation or lasted)
* IP address used
* What document/object it is attached to
* ...

So later a Tiki admin or the owner of the Tiki can match document (version) and signature (user) and is able to prove "this" user with IP xx.xx.xx.xx signed this document on the xx/xx/xx.
Information exist in log more of less (username, action, ip, date, etc) we need it to be stamped with the signature file.

It would be nice this "stamped" information can be displayed easily.
IE: This signature was used by "username/ip" for "object" (version?) on the "xx/xx/xx at xx:xx"

A mechanism to reuse or forbid reusing is something we can think of.
IE : One signature for page, item and account approval.
Counter-IE: It should not be possible to reuse a signature (twice or later or after a document is changed)


By extension the file and approval can be then attached to an object (not only I a wiki page plugin body) and can be used for tracker items (important for forms, shopping, registration, etc) calendars event or other feature, etc.

For multipage wikis the display of the "table of content" using __maketoc__ isn't ideal as this statement requires to be placed on every page otherwise it wouldn't be visible for other pages.
Usually this "table of content" is used for quick navigation purposes. Therefore an alternate to the __maketoc__ statement should be provided which should allow to specify the wikipage which shall be outline. Such a statement can then be used in a module nearby the original wikipage.

This request is related to another: http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5053

My goal is to provide my users a consistently-formatted view of the tracker, and hide from them any internals of the tracker itself.

I currently list the items on a wiki page using pluginTrackerFilter. A wiki template page is specified for formatting.

The template includes edit and delete links. The edit link is to a wiki page using pluginTracker. The pluginTracker also uses a template page for formatting, and uses the URL field to return the user to original wiki page that lists the items using pluginTrackerFilter.

But I could not find a plugin that would allow deleting an item. The best I could do was to link to \tiki-view_tracker.php?trackerId=X&remove=Y (where X and Y are the tracker and item IDs). This is the URL I found for the delete icon in the tracker view page. Upon confirming the action the user is taken to the standard view tracker page where the remaining items are listed in the standard tabular form.

Per my stated objective, I would prefer my users to be returned to the original wiki page that lists the items using pluginTrackerFilter. So, the feature request is for either
a) a "remove" option on pluginTracker, or
b) a new pluginTrackerRemoveItem, with a URL parameter such as the one pluginTracker already has

Thanks.

This request is related to another: http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5052

I am trying to hide the internals of my trackers from the users as much as possible. In particular, I do not want them to have to understand how item-list fields work.

Say:
Tracker 1 includes an item-list field.
Tracker 1 has items a, b, and c
Tracker 2 includes an item-link field that points to tracker 1
Tracker 2 has items d, e, and f. Items d and e point to item a.

If the user deletes item (a), (d) and (e) are ophaned, so to speak. As the admin, I can go search for these and delete them on occasion, but it would be far better if these linked items were removed at the same time.

So the feature request is for a plugin that searches for orphaned items and deletes them. You might consider the following fields:

===PluginTrackerRemoveOrphans===
{DL()}
trackerId : ID of tracker in which to search for orphaned items
fieldId : Delimited list of fields to search (field is ignored if not an item-link. All item-link fields searched if no ID specified). If the value is for an item that no longer exists, linking item is removed.
Bool : If false (default), any item-link field pointing to an non-existent item will cause the item to be removed. If true, all fields (or all fields in fieldId parameter, if specified) must point to non-existent items before the item is removed.
URL : Page to which the browser will be directed after the action is performed. If not set, will go to tiki-view_tracker.php&trackerId=trackerId
Confirm : If true, Text , action button, and abort button are displayed. Otherwise the action is executed without user interaction. Default is true.
Text : Text to display to the user regarding the action that is about to take place. Default: "You are about to remove table items referencing other items that no longer exist.
action : Text for button that executes the command. Default is "Continue".
abort : Text for button that aborts the command. Default is "Cancel".
{DL}

How I would use this:

I list the items of tracker 1 on a wiki page using pluginTrackerFilter. Let's say it is named "Catalog". A wiki template page is specified for formatting.

The template includes edit and delete links. The delete link is to a wiki page using pluginTracker or pluginRemoveItem (see http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5052) to remove the item in tracker1. The URL field for this plugin points to a third page that uses PluginTrackerRemoveOrphans. The trackerId field is set to the ID for tracker 2, the confirm field is set to false so the action takes place without user action, and the URL field is set to "Catalog" so that the user returns to the original list of item - {PluginTrackerRemoveOrphans(trackerId="2", confirm='false", url="Catalog") \}.

The user has removed the item from the catalog and all items that linked to it, without knowing anything about the internals.

Thanks.

Currently, marking "Restrict non admins to wiki page access only " on a tracker breaks the TrackerCalendar plugin. Clicking a calendar item with the before mentioned option set in the tracker brings forward a screen saying that the user must be an admin. This is the conflict bug portion of this request.

The feature I am requesting will remedy the above mentioned bug. I am requesting a feature of making "read only" views of the calendar entry available for use after the calendar date item is clicked. This can be achieved through the addition of a "url" field in the TrackerCalendar plugin parameters that permits jumping to any link when the calendar date item is clicked. This feature would allow for linking to another wiki page that has a "TrackerList" plugin on it to show the related data, possibly through a pretty tracker.

I am attaching updated wikiplugin_trackercalendar.php and trackercalendar.tpl files that work to implement the feature/fix solution. I'm not checking them in because my javascript skills aren't what I would like them to be and I'm sure this provided solution can be improved upon with better use of the javascript fullCalendar event.url element. Feel free to reach out if I can provide any assitance or insights.

I gave "easy to solve" a score of siz as an average. It is a "1" for me or I would have done it, it might be "9" for someone who clearly understands javascript.

Plugin TrackerToggle doesn't display the hidden field if attempting to change value in a previously saved itemId

I followed the documentation found here:
https://doc.tiki.org/PluginTrackerToggle
with this type of syntax in a pretty tracker page:
{CODE()}{TRACKER(trackerId="1" fields="2:5:10:11" showtitle="n" showdesc="n" showfieldsdesc="y" showmandatory="y" showstatus="y" wiki="Template1")}{TRACKER}

{trackertoggle fieldId="5" value=1 visible="y" id="condiv"}
{CODE}

And the wiki page Template1 contains:
{CODE()}
Field 2: {$f_2}
Field 5: {$f_5}
{DIV(id=condiv)}Field 10: {$f_10}{DIV}
Field11: {$f_11}
{CODE}

and the field is hidden by default, however it doesn't get displayed when the radio button gets the value "1" (yes) when visiting a previously saved item; e.g., with the url like:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3

(please note that this itemId3 has field5 stored with value 0 (case A). That's why even if you click (at item edition time) to the second value of the radio button (value 1 - case B), nothing is shown (because field5 has value 0 stored or in the session or something).

---

See it reproduced here:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3
u: admin
p: 12345

If I enter a PluginCategory on page A, and the plugin lists page B, then page B should have a backlink to page A.

When I use ((doc:PluginConvene)), I often have some slots that I ''could'' do but it would mean bumping another meeting, or some other annoyance.

Could we have additional options? Like "Ok, but..." and this would be worth fewer points (say 0.5).

And then, meeting organizer could make a better decision...

((doc:PluginConvene)) is pretty cool!

See image attached to this tracker item.

But once date is picked, unless a manual operation is done like this: https://tiki.org/tiki-pagehistory.php?page=Roundtable+Meeting+2021+10&newver=42&oldver=41&bothver_idx=22 the user is left wondering: when is the meeting?

((doc:PluginCountdown)) is pretty basic, not visually appealing.

Let's move to:
http://keith-wood.name/countdown.html
https://github.com/kbwood/countdown/tree/Release_1_6_3

((doc:PluginCountdown)) a great idea. But showing time to the seconds is not a good default.

Wish:
Make options; Days, Days & hours, etc

Should be an option as to how to handle once time is passed.

__x days since__ or __the event has happened__

And locate time has no effect here:
http://tikiwiki.org/TikiFestNY

I'm wondering how to expose the param zoom Level (as seen here: https://github.com/robicch/jQueryGantt/blob/master/ganttZoom.jsmarc ) to the tiki ((doc:PluginGanttChart)), so that in real world scenarios where we have lengthy tasks across several years, we can have a nicer default view for decision makers.

Any hints?

You can get a working instance to start with by means of applying the ((pr:GanttChart)) profile.

PluginLayout assumes there will be one content area in the foreground and one full-width background area behind the content. To create a full-width area for the page background image, PluginLayout changes -+div class="container"+- to -+div class="container-fluid"+-.

But for some page content layouts, the page backgrounds, etc. are full-width, but the text content is limited to the normal container width (1270px or whatever) in (vertically) alternating sections of the page, like on [http://demo.zukathemes.com/Happy+Scroll].

The layout on that page starts out with a full-width page to get the wide backgrounds behind the headings. Then -+div.container+- is used in the sections with columns of text. But with the plugin currently, ''every'' instance of -+container+- gets changed by the plugin to -+container-fluid+-.

Setting the "contentwidth" parameter to 80% or whatever doesn't help because this also limits the width of the section background images.

It would be good if only the outermost instances of -+div class="container"+- were changed by the plugin (not the nested or child instances), so any instances of -+div class="container"+- in the wiki text wouldn't be touched by the plugin - they would remain -+div class="container"+-. This would enable alternating sections of full-width backgrounds and container-limited content on the page.

(Of course I'm open to other ways of achieving the same result with this plugin, if there's a better/easier way.)

((doc:PluginMaketoc)) is cool.

1-It should be more like other plugins. ex.: in ((doc:Plugin Help))

2- There should be an option (perhaps default?) to float right like in
http://themes.tikiwiki.org/PluginMaketocbox

"Lead, follow or get out of the way" is a common saying.

However, there are some subtleties.

* __Lead__ implies "I agree and will put my energy where my mouth is."
* __Follow__ implies "I am ok with it but I won't lead"
* __Get out of the way__ implies "I don't agree but I won't object (perhaps it doesn't affect me or I will just accept or leave)

There is also:
* __Go along__ (I am not thrilled by the proposal, but I have nothing better for which I will offer leadership)
* __Block__ this is just bad, and I will actively oppose.


In ((doc:PluginProposal)) currently, "undecided" implies, "I'll think about it more and I'll change my vote later". Whereas people that are OK with any proposal are not really counted properly. This will be useful to know if we have enough eyeballs to go ahead.

3 for, 1 opposed is not the same with 0 or 10 __I am OK with any__

The proposal plugin is very cool:
http://doc.tikiwiki.org/PluginProposal

1- It makes it quick to vote and tally votes
2- The proposal and the votes are kept in the wiki page so it's still possible to improve the original proposal and to change the votes (there is wiki page version history so everyone can see the evolution)

Suggestion:
# To have a text box next to the vote where people can add a short comment. When people vote, there can be a +1 if..., -1 unless...
This lets people qualify their vote

PluginR is a mods, and mods should be shut down.

Now that licensing issues have been resolved, please move to the main code base.

Since a few month Google is pushing/improve video content search-ability.
Now they added some verification a wiki page with a youtube tiki plugin to display a youtube video on a page will have the Search Console to report errors.

''Google could not determine the prominent video on the page
The videos on these pages aren’t indexed or served on Google as video results''

The only solution I found so far is to use an iframe
{CODE()}
<div class="iframe-container">
<iframe class="iframe-video" src="https://www.youtube.com/embed/videoseries?list=PLkjRsdmwSB14C2mEI6N9apC_wTLaoZXqD" allowfullscreen></iframe>
</div>
{CODE}

Not sure if this is a bug as it may be something we forgot, code we didn't update or Google added.

You can do this now with a ((doc:plugin alias)) but you need to change the name. Not cool.

Goal:
to be able to centrally, without changing the code, overriding the defaults for certain plugins.

Ex.: for my site, I want sticky=y for ((doc:pluginmouseover))

I should be able to edit each quadrant:
http://tikiwiki.org/SWOT

Currently, after a report, the filter fields still appear at the top. This looks weird. Should be below or should be possible not to show, and you have a button "another search"


Or: send to another page?

{syntax type="tiki" editor="plain"}
PluginTrackerItemField has rather limited expressive power.

Plural WikiWords seem to work fine for CamelCase words.

We would need it to work when we use ((

And backlinks should work as well. We will DogFood on doc.tikiwiki.org instead of all those page redirects (which are OK, but not the best))

Related:
[wish1489|Wiki page name Alias]
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.