Category: Feature request

Granularity of permissions is definitely not good enough here.

E.g. you have to give Editors the tiki_p_admin permission for them to be able to do polls! I think Editors are usually in the position to do polls but not to admin the system.

When using a dropdown tracker field (https://doc.tiki.org/Drop-Down---Radio-Tracker-Field) it is possible to set value with a label. But it is not possible to use the same value for different labels.

The following won’t work and it would useful if it could :
{CODE()}0=false,0=almost false,1=almost true,1=true{CODE}

Still an issue in Tiki25, the last "of the same" value is displayed;

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

Please correct me if I misunderstood this: To me the language system just translates one string of source language into another string of target language, is that right? At least that is suggested by the data structure of language.php.

If that is the case, then there is a fundamental flaw in it: The system cannot (by design) take into account that no function f exists that translations a string of source language into target language.

Because language has a context, and different contexts can radically change to correct translation!

One issue I have only seen now that I have shopping cart activated on one of my Tiki Wikis. There is a button "checkout" to log you off the wiki.

And there is a button "checkout" in the shopping cart, but this will NOT log off the wiki, but close an order, meaning the user requests payment.

The first button "Checkout" is at the moment correctly translated with default values into "Abmelden" in German.

But the second buttons "Checkout" on the shop makes no sense being called "Abmelden" as well, because the user pressing this button does not want to log off, he/she wants to pay, so the only correct translation would be "Bezahlen" (pay).

I believe this contextual change of meaning cannot be dealt with by the current language system, it cannot even handle exceptions?

http://alexandria.wiki.sourceforge.net/Hosted+Apps

http://profiles.tikiwiki.org/SourceForge_Software_Project


((SourceForge Hosted Apps))

!Presentation of the category dependant objets (CategObjects template) [ENH]

This [ENH] changes a little the template to make it easily readable :

A user said "what's that ?" then I enhanced the template :
!! Separates the links to object blocks with the "|" char it could be "•" with blanks
!! Changes in style (common = layout) to separate each category concerned by the object
!! Add comments for reading clearly and understand the content and why this is displayed and how to use.

In my opinion the comments could be optional if a new feature should be introduced "help level related the user habit of using the product with dynamical ability of change"

You can see the effect on screenshots joined

Ready to commit for 6.x proposal and 7.x

!!!Changes in :
*categobjects.tpl
*language.php
*layout.css

trebly
(ref:B10125-05)

Links added in a certain Tiki instance to that same Tiki instance should be wiki links when the target is a wiki page. If not, they should be relative links as much as possible, rather than absolute links. Using relative links eases domain name changes, and facilitates the management of several environments (for example, synchronizing a production environment with a development environment, like nextdev.tiki.org vs dev.tiki.org).

There may be cases where an absolute link is best, but these should be rare. When a user adds an external link to self with an absolute URL - for example "http://tiki.org/Foo" - which starts with one of the Tiki site root's base URL-s - for example "http://tiki.org/" - Tiki should detect the situation and convert to a relative link - for example "/Foo" - unless the user really wants an absolute URL.

One vector through which URL-s are commonly inserted is the External Link tool in the toolbars of parsed text fields. This tool should be modified to detect attempted insertions of absolute links to self and offer the user conversion to relative.

I imagine there should be an administrative preference to control behavior - either automatically convert to a relative link, or prompt users. Should there be more options?
I believe the default should be to prompt users.

Add an AJAX service to check the syntax of custom look and feel prefs before saving to make sure you're not going to break your entire Tiki

On a fresh install, I enabled image galleries without realizing that neither GD or ImageMagick libraries had been installed. I was able to create a gallery and attempt an upload of images, which failed with a vague "Upload can not be processed". It was only after visiting the second admin screen (http://localhost/tiki-admin.php?page=gal) that I was able to see that the proper libraries were not installed.

Before starting an inline edit sessions, it must be checked if another editor is active. Similarly, when the inline editor is active, it should not be possible to start another editor (except by override)

Before it is fixed, using the inline editor can cause data loss if more people edit the same page.

Similar functionality is (seemingly) missing other places.
Should be added as a service.

You can not preview a message written through tiki-messaging system (inter-user messages), prior to its post.

Same on trackers.

User starts editing a tracker item, and wants to preview changes before submitting

{syntax type="tiki" editor="plain"}
Since Tiki27 (may be in tiki26 also) enabling the option "Preview Edits" on the "Editing and Plugins" panel at tiki-admin.php?page=textarea also add a "Preview" tab when you edit a text area field on a trackeritem.

This is pretty annoying as it is not optional and add more on an already crowded modal.

The help text and option on the "Editing and Plugins" doesn't says a lot about this.

I suggest that we keep the "Preview Edits" as parent checkbox and add subset of checkboxes:
* Preview Edits
** Wiki pages (enable by default)
** Trackers (disable by default)
** ...
''(There may be other features where it applies, Articles, Blogs, Forums, Calendar, etc)''

The label option could be clarified, something like; Preview Edits Tabs

Calendar is coming along nicely. It would be nice to have a printable version

# without right & left borders.
# without truncating titles

Trackers are really good for lists. Sometimes, we want to print these lists...

We wish we could print with watermark.

Best Regards

Thomas Johansson

Provide print and save option in insert new item mode
and print in view mode.

This would enable to create fillable forms.

Provide a "denomination" option: tracker/form.
In some instances calling a form "tracker" may deter users...
Form option could offer more presentation features.

Hi there everyone, newbie calling.

I work in a technical operations area. Currently developing the wiki as a wiki for operational staff across various areas but thought I would use some more of the functions that are available.

As an operations area there is a requirement for logs to be written daily by operation staff across different departments and to be e-mailed to management staff.

My idea is to give each department (5 in total) a separate blog. Only members of each department can write to their blog but any member of each department can read the other blogs. So far so good. By tagging each entry searches across blogs can identify faults across departments. This works perfectly and therefore preferable to a forum based solution as I need it to be as simple as possible for the operational staff.

However there is a requirement to print each log on a daily basis and ideally e-mail it to non-members (managers) possibily dependent upon tags. Obviously it is simple to print each separate entry but what I am looking for is a way of printing a 24 hour period of blog entries, or exporting them to a text file (word or e-mail body for example) to be distributed and printed. This is because there can be as many as 100 blog entries per day and it would be time consuming (and forest destroying) to print each one out individually.

Apologies if this is covered in a document that I have missed but I am still trying to absorb all the variables. I have also posted it in the forums to see if someone has any ideas with existing features or indeed using it in this way.

Any help would be greatly appreciated

Hello,

My english is very basic.

I am working into corporative network with proxy server conection. This conection required User and Password. But into TikiWiki's Proxy Configuration is not requiered.

For this reason I am not conect to download profiles from http://profiles.tiki.org/profiles.

I can not install de Profiles. How I can resolve it?

Help me,


Bye.

A new profile handler for wiki structures would be very handy to promote the use of structures in many uses cases (learning environments, project management, TEAMS, workspaces in general, ...)

http://profiles.tiki.org/Structured+Master+Documents

I created a profile to demostrate the use of wiki structures to new wiki admins, but it's missing the change to create the structure directly from the profile, which would be needed to enhance other more advanced profiles (Learning Center, etc)

Profile user experience can be improved.

While effort should continue to improve existing profiles, shouldn't it make sense to focus first on easy steps that can be done:

* Is Profiles the right word to name ? (https://en.wikipedia.org/wiki/Profile), it means so many things...
May be there is not a single word for this. May be we should use word that doesn’t mean anything (Tikifigurator :-) ) so no confusion.
* tiki-admin.php?page=profiles should be revamped
++ {img type="src" src="http://avan.tech/dl2287?display" thumb="box"}
** Help text could be added to explain what, how, why... (may be reuse the remark box - I can’t find it useful for new user - links didn’t work for me in trunk local)
** We could display only one version of the profile, the one that work with the running Tiki (and remove anything about 3x, 4x, 5x, etc)
++ {img type="src" src="http://avan.tech/dl2288?display" thumb="box"}
** We could display already a list of profile by default (last 10 updated) (not the mini profile); it will help to understand what this does
** Remove or modify the "Profile type" selector (confusing)
** The profile repository dropdown could be moved under the advanced tab (till there are more repository)
* When applying a profile
** Once a profile is selected and ready to be applied we shouldn’t see (again) other profiles but only the one selected (so we have more room to see the profile content: setting, instructions, etc)
++ {img type="src" src="http://avan.tech/dl2289?display" thumb="box"}
** The table where is displayed the profile information should be adapted to the size of it’s content (scroll, content is hidden)
** Add some screen shot (corresponding to the version of the Tiki running)
* After a profile is applied
** Hide the long list of "changes has been applied" (viewable on click) - (if someone want to see it he can but we don’t need to put that long and scary list)
** A Success message should be seen first ;)
** The result should be mordernized and help doc should guide better. This screen show the result and it is not the nicest design we can expect with Tiki today and user doesn’t have any guidance about what to do from here.
++ {img type="src" src="http://avan.tech/dl2290?display" thumb="box"}

I have noticed the profile exporter at tiki-admin.php?page=profiles exports only assigned custom modules and ignores the unassigned ones or those used in wiki pages only using the module plugin. These modules are then missing when someone uses the YAML to apply the modules elsewhere. It would be nice if it offered to export all custom modules, not just the assigned ones.

when an new user installs tiki in a browser he does not see the progress of his installation it can cause him to cancel or start the installation again despite the fact that the installation is well done

When using the "Wiki Page Staging and Approval" feature... I would like the "Category for approved pages" option to include a new selection: "Prompt for category"

This would allow users to select a category when they approve the page, allowing approvers to select a different category for pages, rather then selecting a single, overall, "approved" category.

provide a clicable link to login to dev.t.o from a smartphone out of the menu icon at the top right corner

Have you tried recently (in the last several weeks?) {sign user="xavi" datetime="2016-04-06T15:43:28+00:00"}
Same issue when testing https://nextdev.tiki.org

You can't click there at any login link, it's hidden below the square icon of the collapsed menu at the topbar.

And ensure that this fix is applied to the main *.t.o sites , at least. (tiki.org, dev, doc, I would say)

Provide a tablesorter-powered list of profiles in the Profiles Wizard bundled in Tiki to filter on features, tags, names and such

((doc:Profiles Wizard)) has many profiles, and sometimes the admin wants to filter those by feature name that they have enabled, or by tags (demo, learning, advanced, etc).

I don't know yet how to do that at the profiles wizard itself (first screen of that wizard? or second, just after the featured? ....)
There seem to be nice and advanced ways to display the whole list but allowing clever filtering, as seen here:
https://doc.tiki.org/TableSorter

---
Work started to have ((doc:tags)) added to the profiles in profiles.t.o, so that they can be searched/filtered by the features used in them, etc.