Inbox Panel : Bug with Vanilla 2.2

Tof

Vanilla 2.2
Theme Bootstrap
Serveur de Test : http://88.181.151.128:8080/
PLUGIN : Inbox Panel

Hi,

With VANILLA 2.2, it's impossible to activate the plugin.

Thank for your answer

Tof

rbrahmson

I am not sure what is the cause but I suspect it may have to do with changing the permission from lowercase "view" to upper initial "View". For some reason Vanilla didn't like that.

Two ways to deal with that:
1. Very carefully edit the database changing the existing old "view' to" View" in the permission table in the inboxpanel entry.

2. Change the plugin source to lowercase "view" (in all occurrences)

If you wonder why I changed it-I realized that most plugins using the "view" permission use uppercase first letter convention and that my use of the lowercase created another unnecessary column in the presentation of the permissions in the roles screen, one stuck so far to the right that it could easily be missed.

@hgtonight, @R_J: anyway I could have prevented that error when changing the permission in the plugin source of the newer version?

R_J

New permissions are created automatically if you have a 'RegisterPermissions' element in the plugin info array. But you can define them "manually" and thus undefine them by the help of the PermissionModel:

$permissionModel = new PermissionModel();
$permissionModel->undefine('Any.Permission.You.Like');
$permissionModel->undefine(
    array(
        'Even.More',
        'Than.One',
        'As.Much.As.You.Like'
    )
);

If you put that in your setup and undefine the lowercase view, you would make sure that even those who activate your plugin twice will have no problems.

If you want to prevent it from the beginning, you can start cleaning up what you do.

public function setup() {
    // here you create tables and set config options
}

public function onDisable() {
    // undefine previously registered permissions, delete (drop) tables/columns, delete config settings, whatever mess you otherwise would leave behind
}

If you go the onDisable way, don't forget that configuring or filling tables might be a tedious work and someone who only wants to temporarily deactivate your plugin would loose all his work.

hgtonight

anyway I could have prevented that error when changing the permission in the plugin source of the newer version?

You can undefine permissions via the permission model. In your plugin, add a setup method and a structure method. Example:

public function setup() {
  $this->structure();
}

public function structure() {
  $permissionModel = new PermissionModel();
  $permissionModel->undefine('Plugins.inboxpanel.view');
  $permissionModel->define(array('Plugins.inboxpanel.View' => 1));
}

The setup method gets called when you enable the plugin. The structure method gets called during updates (or visiting /utility/structure).

Since you are doing the registration of the permission manually, you should remove the RegisterPermissions key from the plugin info array.

EDIT - Sweet plugin @rbrahmson

rbrahmson

Thanks both @hgtonight and @R_J ! Very helpful. I of course prefer to use the automatic permission handling on the plugin info array, but apparently by changing the setting to a different permission I put myself into manual mode...

However, if I used a new permission when I upgraded the plugin, why should it cause an error. I understand that I may leave "dirt" behind, but instead the new plugin version could not be activated causing a "duplicate" column error. That is still an unsolved mystery to me...

@hgtonight said:
EDIT - Sweet plugin @rbrahmson

Thanks! I had to learn more php, Vanilla, JS and Jquery for that plugin and I still have a lot to learn.

hgtonight

@rbrahmson said:

I understand that I may leave "dirt" behind, but instead the new plugin version could not be activated causing a "duplicate" column error. That is still an unsolved mystery to me...

According to this source, column names are not case sensitive:

Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases.

rbrahmson

OK, I get it now, but still not 100% satisfied (with how it works, I cannot but praise your assistance) -- notwithstanding the caveat that other databases may not be case insensitive (I'm just speculating), it would be nice it it was enforced in Vanilla so that when I look at the permission list in the dashboard Roles pages I wouldn't be able to see different entries for "View" and "view". That is what caused me to change to "View" to be like most other Plugins and in doing so shoot myself in the foot...

hgtonight

@rbrahmson said:
it would be nice it it was enforced in Vanilla so that when I look at the permission list in the dashboard Roles pages I wouldn't be able to see different entries for "View" and "view".

I can see your issue, but this is the system being flexible. You chose (inadvertently) to use a different casing than other projects.

rbrahmson

Yes, you see my case;-)

rbrahmson

I'm having problems with the manual permission settings. I made the two changes above that were suggested by @hgtonight (structure and setup - pasted them verbatim). Not getting errors. BUT - the new permission settings are not there (in the roles screen). No error messages, it's just ignored.

I checked in the database -- the permission exists (there is a column Plugins.inboxpanel.View). But it is not shown on the role permissions settings screen.

I am running Version 2.1.13. Is the suggested code supported in that version?
Unfortunately this is an intranet forum so I cannot offer external access;-(

rbrahmson

and to add to my report, when I add back the permission definition to the plugininfo array the permission appears again on the roles screen. Something with the structure/setup and the permission model suggestion does not work...

Tof

Hi all,

Sorry for my late reply because I was sick.

I just tried version 1.3.0 and i have always the same error:
Duplicate column name 'Plugins.inboxpanel.View'

As for the discussion, I did not really understand because I am French and I speak little English. I have to edit files?

thank you for your answer

Tof

rbrahmson

@Tof - for you the simplest solution will be:

1. Disable the plugin.
2. Edit the "class.inboxpanel.plugin.php" file and
3. change ALL: "Plugins.inboxpanel.View" to "Plugins.inboxpanel.view"
4. Save
5. Enable the plugin

Tof

it's ok, thank you my friend

rbrahmson

I am happy this solved the issue, mon ami!