Category: Profile Manager

Tiki trackers are great for a bug tracker, as we are dogfooding here.

But what about for a "help desk" setting? -> Private requests from many customers to one company.

Imagine a hosting company. They may have public forums & trackers. But they also have a place where customers can ask direct support requests. And only the customer and the company can follow this tracker.

There is a way for people to just modify their own tracker. But this is more for a user profile, than a series of support requests.
http://doc.tikiwiki.org/tiki-index.php?page_ref_id=3204

You can also give permission to add a tracker item but not view. But they can't modify existing tracker items. (like sending in a black hole)

If we want people to submit many tracker items, but only see/edit their own, what should we do?

Currently, there is and option "Item creator can modify his items?" at tiki-admin_trackers.php

Maybe we need one: Only item creator can view his items?" Of course, staff working for the company would be admins and could see the trackers for all companies.

Or there could be login drop-down, and only that user can see. Even nicer would be that it's possible for people of the same group to see.

Maybe this possible with the current feature set. In which case, just documentation is necessary.

Some things to experiment:
"My items" in tiki-my_tiki.php

Current workaround is to make a tracker for each customer.

Please see: ((Issue Tracker))

---
Related:
Trackers need "tiki_p_trackers_view_own" permission to view own items only
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=211

That is truly confusing as the Tikiwiki system apart from that seems really polished. We started a new community page and realize that there truly is nothing like a user list in tikiwiki 3.2. The friendNetwork system shows as "deprecated" under "experimental" and the mods-section is empty except a few themes so the userlist-plugin is not there as well. It is unfortunately important for a bigger site to have a chance for normal user to search for user, list the team depending on groups people are part of and all this with a clickable list showing homepage (if entered), ICQ (if entered), a profile link, list of pages and forum posts etc.
All those I miss dearly and the tikiwiki documentation for the tracker (which seem to be able to do that with some programming?) is for a just-user-type like me not understandable I fear. :-/

It changes the syntax.

It would be time to rewrite the ((Wiki Parser))

Profiles using -+[[ value1, value2, value3 ]+- syntax for array values for preferences now cause a fatal error and usually WSoD.

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

{syntax type="tiki" editor="plain"}
In barebones profile and in featured profiles, there is intro text about 1st login being necessary with u: admin p: admin (good)

However, this message stays and needs to be deleted by admin (bad)

Perhaps we should have a module with is only visible if admin password has not yet been set.

XML files are cool for data interchange.

For example, you can create an xml file to feed a Flash animation. However, you still need to update that XML file via FTP. What if you could edit a wiki page (with permissions, history, etc) and have the Flash animation get the data from it as if it was xml?

Or maybe a button on a wiki page "save to .xml", which would save on the filesystem WikiPageName.xml? (where the Flash would know to look for it)

Related idea:
* {wish id=467}
* {wish id=3103}


Louis-Philippe Huberdeau --will look into-- used [http://www.yaml.org/|YAML] --to see if this could be useful-- and it is very useful for the ((Profile Manager))

It would be *great* to have way to generate profile YAML from an existing Tiki site.

We are documenting some ((info:Use Cases)) which will become profiles. To be able to developer/test/improve these profiles, we would need a site like [http://www.opensourcecms.com/index.php?option=com_content&task=view&id=180|Open Source CMS] but for all profiles. This site only shows one profile.

These 20+ demo sites would provide admin access to easily test any profile. It would encourage people to generate and improve various profiles as well.

Related:
((Profile Manager))
((TRIM))

{syntax type="tiki" editor="plain"}
There needs to be a restriction on the group handler similar to the mode in some of the other handlers.

Currently, if user A creates "Group A" and becomes the admin, then user B comes along and also creates a group called "Group A", then user B gets the same admin rights as user A.

This could be a problem any time two users are trying to create the same named groups.

Pretty_Tracker_Demo cannot be applied any more wihtin the admin's profiles.
Instead of loading the profile, a new pages opens with the link "jdoe@company.commsmith@company.com" and the pages keeps loading.

Perhaps it is due to the new release 5.2.

After an issue reported by a user in dev.t.o, and an example produced in the corresponding show.t.o site, I decided to create the corresponding profile to be able to test dynamic items list easily from now onwards in different tiki versions, etc. That's the rationale of this profile:
https://profiles.tiki.org/Dynamic+items+list

After I added the sections with data ("Objects in Products Tracker" and "Objects in Service Tracker"), the profile doesn't load any more in the Tiki admin panel for profiles.

And when I added that yaml code in tiki-admin.php?page=profiles&cookietab=3 > "Profile Tester", then I got this error message:

{CODE()}
Fatal error: Call to a member function getRequiredProfiles() on a non-object in /var/www/trunk/lib/core/Tiki/Profile.php on line 479
{CODE}

Any tips?

---
And if I apply only the 2 sections defining the tracker and tracker fields (no sample data), then I get:
{CODE()}
An error occurred: Unknown objects are referenced: tiki://local/Test#products, tiki://local/Test#products_name, tiki://local/Test#products, tiki://local/Test#products_name, tiki://local/Test#products_version
{CODE}
---
After I removed the $ at the end of the objects defined elsewhere, then I ended up with this error through the Profile tester and only the section with trackers and tracker fields (no tracker data):
{CODE()}
Fatal error: Call to a member function getRequiredProfiles() on a non-object in /var/www/xavi-9794-4911/lib/core/Tiki/Profile.php on line 479
{CODE}

Some profiles bring up this fatal error when you try to preview the changes to be made:
{CODE()}
Fatal error: Uncaught TypeError: Argument 1 passed to Tiki_Profile_Installer::install() must be an instance of Tiki_Profile, boolean given, called in /var/www/clients/client1/web16/subdirs/tiki19x/admin/include_profiles.php on line 85 and defined in /var/www/clients/client1/web16/subdirs/tiki19x/lib/core/Tiki/Profile/Installer.php:409 Stack trace: #0 /var/www/clients/client1/web16/subdirs/tiki19x/admin/include_profiles.php(85): Tiki_Profile_Installer->install(false, 'all', true) #1 /var/www/clients/client1/web16/subdirs/tiki19x/tiki-admin.php(545): include_once('/var/www/client...') #2 {main} thrown in /var/www/clients/client1/web16/subdirs/tiki19x/lib/core/Tiki/Profile/Installer.php on line 409
{CODE}

__Update__
In 22.x it brings an Error alert dialog:
^__Error loading profile__
This message will move to the top of the page after a few seconds.^

Clicking the "Preview Changes" button to preview a profile in trunk fails with some badly broken full-tiki page in modal content and a CSRF error message in it:
{img fileId="1211" thumb="box"}

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"}

{syntax type="tiki" editor="plain"}
When trying to execute a profile, validation simply cancels the execution request instead of showing a message with where the validation failed.

Previous versions of Tiki used to do this and is very helpful when testing and developing profiles.

For the first time I tried to use the Profiles Wizard right after install on a 17.x.

For the micro setting : Multilingual Wiki, I clicked "apply profile now".
It send me to the profile page without any profile selected or searched for…

Work (better) in 16.x so there is a clear regression.

———

On the Admin profile page : tiki-admin.php?page=profiles, I searched manually for the profile "Multilingual_Wiki_12x" when I clicked on it I got a loading message (loading profile) but nothing happened…

So I tested other profiles. Some other did the same and finally very few loaded properly.
Same results on 17.x and 16.x

* Admin Home > Profiles > Featured Profiles
* Click on Collaborative_Community_12x
* Text "Loading profiles..." appears for one second then disappears
* But the profile does not get installed
* The bug happens no matter what profile you click on, and whether it's a Featured Profile, or Mini, or whatever.

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.

Profiles wiki handler: translations param doesn't work. To reproduce, see and apply profile: http://profiles.tiki.org/Consensus+Forums

This page:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instructions+for+the+Consensus+Forums

should be in the same trnaslation set as the equivalent Spanish one:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instrucciones+de+los+Foros+de+Consenso

This is how the pages are defined in the profile decalaration:
{CODE()}
objects:
-
type: wiki_page
ref: consensus_forums_include
data:
name: Instructions for the Consensus Forums
description: Instructions on how to use forums to help users seek consensus on discussion threads
lang: en
mode: create_or_update
translations: consensus_forums_es_include
content: wikicontent:Consensus_Forums_Instructions
-
type: wiki_page
ref: consensus_forums_es_include
data:
name: Instrucciones de los Foros de Consenso
description: Instrucciones sobre como users los foros para ayudar a los usuarios a buscar consensos en cada hilos de debate
lang: es
mode: create_or_update
translations: consensus_forums_include
content: wikicontent:Consensus_Forums_Instrucciones
{CODE}

However, the "translations" keyword doesn't seem to take effect.

When applying profile some profiles have possibility to input custom user value(s), for example:
{CODE()}name: $profilerequest:User Tracker Name$User Tracker${CODE}
It displays a text input field before applying profile with label User Tracker Name and prefilled value "User Tracker".
If user tries to change that e.g. to "My User Tracker" instead, after applying the profile the user value gets ignored and uses the pre-defined one "User Tracker" anyway.

This used to work in the past Tiki versions I am pretty sure.

To replicate try searching for [https://profiles.tiki.org/User_Tracker|User Tracker] profile on the -+tiki-admin.php?page=profiles+- and before applying the profile change some value in the fields.

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.