Project

General

Profile

Actions

Bug #4619

closed

GroupJive Notices in various backend areas after CB 2.0 RC1+ upgrade

Added by nant over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
14 August 2014
Due date:
% Done:

100%

Estimated time:
2:00 h

Description

With CB 1.9.1 CB Quickstart PRO installation and then upgrade to CB 2.0 RC1 2014-08-13 latest build I get:

Notice: Undefined property: stdClass::$access in /Users/nick/Documents/JOOMLAPOLIS/DEV/SITES/J333CB20RCUPRO/components/com_comprofiler/plugin/user/plug_cbgroupjive/admin.cbgroupjive.html.php on line 23

when visiting the GroupJive plugin menu.

and:

Notice: Undefined property: stdClass::$access in /Users/nick/Documents/JOOMLAPOLIS/DEV/SITES/J333CB20RCUPRO/components/com_comprofiler/plugin/user/plug_cbgroupjive/admin.cbgroupjive.html.php on line 2707

when visiting the GroupJive integrations menu.

Actions #1

Updated by beat over 9 years ago

That one deserves some investigation, as it wasn't there with CB 1.9.1, and might be a B/C issue.

Actions #2

Updated by krileon over 9 years ago

It's due to the "access" column changing to "viewaccesslevel" in _comprofiler_plugin. The access is being used purely for cosmetic reasons in custom backends of a few plugins. The plugins using it are also doing direct queries and populating an stdClass so magic methods and such won't work and I don't like the idea of changing it back to access. IMO this one can be ignored.

Actions #3

Updated by krileon over 9 years ago

  • Status changed from New to Feedback
  • Assignee deleted (krileon)
Actions #4

Updated by beat over 9 years ago

  • Assignee set to krileon

Well, the only and very easy way to "fix" that is to leave a dummy column called "access" in that table until CB 2.1 ?

Think that would not be an issue. Thoughts ?

Actions #5

Updated by krileon over 9 years ago

  • Assignee changed from krileon to beat

I don't think that's in line with our deprecation of the other old access columns. I'm in favor of just leaving it as is. It's a non-breaking notice that most won't even see if their debugging or error reporting is off (most likely scenario).

Actions #6

Updated by beat over 9 years ago

  • Assignee changed from beat to krileon

I was thinking to keep viewaccesslevel column in line with other tables, but to add a new dummy access column temporarily here.

Nothing major either way.

Thoughts?

Actions #7

Updated by krileon over 9 years ago

  • Assignee changed from krileon to beat

Right, but I don't think it's necessary for the sake of a minor notice in a few plugins custom backends. It also only applies to upgrades and all will be fixed shortly after we go stable. Since it's non-breaking I think we're ok to just leave as is.

I'm not too keen on the idea of dummy DB columns. If we can get magic getter and setter working ok though that'd also solve it, but last time I tested those there were issues with it.

Actions #8

Updated by beat over 9 years ago

  • Status changed from Feedback to Assigned
  • Assignee changed from beat to krileon
  • Priority changed from High to Normal
  • Estimated time set to 2:00 h

Ok, if this is backend only and notices only, and we fix this in groupjive, think we can live with it.

Leving this now Assigned to Kyle, so that he can close this when it is fixed in all CB plugins that access the access column.

Actions #9

Updated by krileon over 9 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

All plugins using ->access now fixed to use ->viewaccesslevel. Note was only for display purposes in their custom backends.

Actions #10

Updated by beat over 9 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF