Category: Profile Manager

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.

Setting User Tracker id login and registration fields from Profile fails

See example in this profile:
https://profiles.tiki.org/User_Trackers#Group

{CODE()}
permissions:
Members:
description: members of the association
include: [ Registered ]
user_tracker: $user_tracker #and once this work, we need to tell the system about which field ID to connect to
user_tracker_field: $login # On a clean install, the following both should be at "1"
registration_fields: $profileobject:user_name$
{CODE}

names as indicated in the documentation:
http://profiles.tiki.org/tiki-index.php?page=Permission%20Management&redirectpage=Group%20Handler

a) I spent weeks testing these features one by one.

It will save time if all these features are enabled and complete with samples.

This is the approach used by Joomla and Mambo.

It also helps us learn faster.


b) The assist module is useful but asking users to read a tedious configuration as the first step will eat up too much time.

Site configuration or Look at Feel should be the first one.

It is also the most dangerous but essential.

c) Provide a clue, in the assist if possilbe, to replace a damaged header.tpl with a skeleton header.tpl

I think what's needed is a Gallery of "Tiki Sites in a Box". In other words, Tiki sites that are preconfigured to meet a particular kind of needs. The needs should be defined not in terms of features, but in terms of GOALS of the end user or organisation.

This could be a list of descriptions like this:

- I want a site to enable collaboration inside my organisation.
- I want a site to broadcast my ideas to the world and allow people to add to them and comment on them.
- I want a site that will act as an open knowledge base on a particular topic.
- etc...

Each of these could point to an example which would be a "fake" site that could act as a sandbox. People could go to this fake site, play around with it (but not reconfigure it), to see if it's what they are looking for.

This would allow easy single click configuration of Tiki. The user would simply click on one of the items in the Gallery, and the Tiki site would be configured accordingly.

One issue is: what happens if the user choose wrong and later wants to switch to a different model? I guess if no content has been created in the site it's fine, but what if content has already been created and that content is somewhat incompatible with the new model that the user is choosing?


Related:
*[tiki-view_tracker_item.php?itemId=1513|OpenSourceCMS type demo to test/develop and show off profiles]
*[http://info.tikiwiki.org/Use+Cases|Use Cases]

__Moving discussion of this wish to ((Profile Manager))__