Hi,

I am configuring "ERPAL for Service Providers" for my own use. I want to migrate all my current system (bills, projects, customers info, timesheeting) to this system, which seems really fantastic.

Unfortunately I have already an issue with tasks. When I create a task related with a project, the task is well created (I can see it on admin/content page).

image

But I cannot see it on project page:

image

I tried several times to create tasks in any way. I cannot figure out how to link a task with a project. Normally tasks should appear in second image, as explained in this screencast:

http://www.erpal.info/blog/blog/erpal-for-service-providers-project-mana...

EDIT

As tashaharrison80 said:

The Administrator can see the list of tasks, but the user who the job is assigned to can't see it in the list but does have access to the actual node. I've given them roles of account manager and project manager.

Comments

118218’s picture

Issue summary: View changes
118218’s picture

manuelBS’s picture

That is really strange. Do you see the tasks in the tree view?

tashaharrison80’s picture

I'm having this issue too. The Administrator can see the list of tasks, but the user who the job is assigned to can't see it in the list but does have access to the actual node. I've given them roles of account manager and project manager.

manuelBS’s picture

Are you both using the version 2.2? If so please try an update to the latest dev version and tell me your result.

tashaharrison80’s picture

I has just tried the latest dev version but it still doesn't work. The view that seems not to be working is Tasks (Content) and the display is Tasks by project pane list.

118218’s picture

I managed to solve the issue by re-installing the whole project from scratch.

The first time, I installed Erpal partially with drush. May be this approach was causing the issue.

I thought it was related with Memcache Storage (https://www.drupal.org/project/memcache_storage) module, but I installed it again in new Erpal installation and it works well now.

tashaharrison80, do you have another language installed? In the first installation (the one which is not working) I had a second language (french), I have not installed it yet in the second installation, so may be this could be related with the issue.

I am using the version 2.2 in both installations.

118218’s picture

Issue summary: View changes
118218’s picture

Issue summary: View changes
tashaharrison80’s picture

I've only used one language. I did test it in a reinstall but it still didn't work.

francewhoa’s picture

Same bug here. We're currently trying to reproduce it with a fresh ERPAL install on another server.

Anyone found the source of that bug? Maybe we did a user configuration error, maybe a bug. We don't know at that point.

Sites are also using a multilingual ERPAL. URLs format as follow:

  • English
    • https://example.com/en/node/[NODE-ID]/tasks
    • https://example.com/en/node/[NODE-ID]/tickets
  • French
    • https://example.com/fr/node/[NODE-ID]/tasks
    • https://example.com/fr/node/[NODE-ID]/tickets

Using

  • ERPAL: 7.x-2.1+10-dev
  • Drupal: 7.36
  • Debian: Wheezy 7.8
  • Apache: 2.2.22
  • MySQL: 5.5.43-0+deb7u1
  • GD library: 2.0.36
  • jQuery Update: jQuery 1.8.2 and jQuery UI 1.10.2
  • PHP memory limit: 256M

We noticed a new ERPAL dev was released yesterday 2015-Jun-09. Yayaya :) That might fix that bug.

francewhoa’s picture

Version: 7.x-2.2 » 7.x-2.x-dev
Component: User interface » Code
tashaharrison80’s picture

I've just tested the new dev release and still no tasks. Does anyone have any other ideas?

francewhoa’s picture

tashaharrison80, thanks for your update :)

You mentioned you only used one language. What path format for that one language?

example.com/node/[NODE-ID]/tasks

or

example.com/en/node/[NODE-ID]/tasks

or

en.example.com/node/[NODE-ID]/tasks

or

else?

francewhoa’s picture

Good news. We found a fix for this bug. We'll post it here shortly.

francewhoa’s picture

Status: Active » Fixed

Steps we did that resolved this bug

  1. Update ERPAL to latest dev from 2015-Jun-20. Both ERPAL (erpal-7.x-2.1+18-dev) and Drupal core (drupal-7.38). Both are included in the file at http://ftp.drupal.org/files/projects/erpal-7.x-2.x-dev-core.tar.gz
    1. Follow the update instructions at https://www.drupal.org/node/2473655
    2. Notice in those instructions there are two important steps:
      1. Using your browser go to /profiles/erpal/do_migrate.php
        • Note: That script includes a rebuild of the registry in Drupal.
      2. Go to /update.php
        • Note: We also did those two steps during the last update. But we notice that this time there are more update. ~18 updates.
  2. Clear all caches. Including both Drupal core caches and opcaches if you use those. Such as APC or Memcache.
  3. Done. Enjoy ;)

We spent hours with various tests and narrowing down that bug. I'm setting this ticket Status to Fixed. Feel free to re-open it if needed.

francewhoa’s picture

For reference. Here are the messages displayed after we ran /update.php

====================

Drupal database update

Installation tasks

Verify requirements(done)
Overview(done)
Review updates(active)
Run updates
Review log

Warning message

Before you run any database updates, make sure you have a backup of your database. Use Backup and Migrate to create that backup now.

The version of Drupal you are updating from has been automatically detected.

18 pending updates

ctools module

7000 - Enable the custom CSS cache handler.
7001 - Increase the length of the ctools_object_cache.obj column.

draggableviews module

7101 - Upgrades the draggableviews_structure table from 1.x to 2.x (schema_version 7200). This will run if you have 7.x-1.x installed and are upgrading to 7.x-2.x. Otherwise this will be skipped. All of your views will need to be manually updated using the Views UI. Backup your data before you run this!
7201 - Increase sizes of view_name and view_display fields of draggableviews_structure table.
7202 - Add "parent" field to draggableviews_structure table.
7203 - Add indexes to the draggableviews_structure table.
7204 - Add indexes to the draggableviews_structure table.
7205 - Remove unique key on the draggableviews_structure table.

erpal_invoice module

7003 - Update saldo field to decimal instead of float

field_collection module

7003 - Update field_collection_field_schema columns for all tables.
7004 - Add index on {$field_collection_field}_revision_id column for all tables.
7005 - Force the creation of the table cache_entity_field_collection_item. entity_update_7003 will attempt to install entitycache tables for existing modules, but it uses module_list() to get the list of available modules, which, when called from a database update, may not return field_collection since drupal is bootstrapped at a lower level.
7006 - Ensures revision_id indexes are present at field_config table.

node module

7015 - Enable node types that may have been erroneously disabled in Drupal 7.36.

panels_everywhere module

7100 - The site_template variants should not use the IPE, so change them to use the standard render pipeline.

relation_add module

7002 - Drupal menu rebuild.
7003 - Move relation global settings to the instance setting.

relation_endpoint module

7001 - Split combined index into separate indexes.

====================

Drupal database update

Installation tasks

Verify requirements(done)
Overview(done)
Review updates(done)
Run updates(done)
Review log(done)

Status message

draggableviews_update_7101 skipped. Database looks like its already been updated.
No Panels Everywhere displays needed to have their settings updated.

Updates were attempted. If you see no failures below, you may proceed happily back to your site. Otherwise, you may need to update your database manually. All errors have been logged.

Front page
Administration pages

The following updates returned messages
draggableviews module
Update #7205

Unique key DVID successfully removed.

relation_add module
Update #7003

Move relation global settings to the instance setting.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

discipolo’s picture

Status: Closed (fixed) » Active

i am experiencing this same behaviour on a 2.2 install.
updating to 2.3 and running do_migrate did not fix it.
anyone else? help would be appreciated.

Edit: seems to have something to do with the relationship "Entity Reference: Parent" on view /view/tasks (removing it from the relevant panes makes tasks show up)
should that relationship maybe only exist for the entity reference pane?

discipolo’s picture

Status: Active » Needs review
StatusFileSize
new6.4 KB

is the parent relationship in the basic 3 taskpanes view the problem or are my tasks parent fields not set correctly for some reason?

manuelBS’s picture

Strange thing...If you apply your patch in your installation it works?

iprosp’s picture

The problem still exists and can be reproduced by doing the following:
1) Install the latest dev version as usual
2) Update core to 7.34
3) Go to the task list with any user (other than the administrator) an you will not be able to see your assigned tasks.

steve hanson’s picture

I agree with jackpros - there's DEFINITELY a problem with Drupal 7.43. I assume he MEANT 7.43. I was having the same problem because I upgraded to 7.43. I rolled back the Drupal install and projects now work again.

On the other hand, the project really should get upgraded to 7.43for security reasons.

kanroom’s picture

Hello! I had the same problem - "No tasks available" - when I updated my drupal core from 7.39 to 7.52. In my case that was not a permission problem. Before I updated drupal core I installed module Hacked! and noticed all changes that was in core 7.39 and then with total commander I found this changes, the core's module node was changed (file node.module) and I moved this changes in core 7.52, and this help me to solve this problem.

Hope this help someone solve a problem.

Sorry for my English :)

chipway’s picture

Hi kanroom,
Could your explain the changes you made to node.module file?

chipway’s picture

Status: Needs review » Needs work
kanroom’s picture

chipway
In function _node_query_node_access_alter() after a comment "// Otherwise attach it to the node query itself." in condition "else", I replaced code:

$query->exists($subquery)

with this code:

if (empty($tableinfo['join type'])) {
  // If we are looking at the main table of the query, apply the
  // subquery directly.
  $query->exists($subquery);
}
else {
  // If we are looking at a joined table, add the node access check
  // to the join condition.
  $tables[$nalias]['condition'] .= ' AND EXISTS(' . (string)$subquery . ')';
  $tables[$nalias]['arguments'] += $subquery->arguments();
  // Increment the placeholder count on the main query until it matches the placeholders
  // used by the subquery.
  foreach ($subquery->arguments() as $_a) {
    $query->nextPlaceholder();
  }
}
chipway’s picture

Priority: Normal » Major
Status: Needs work » Fixed

Thanks kanroom for your useful comment.

This issue is related to https://www.drupal.org/node/1349080#comment-10953027
Use #332 patch to solve the issue: https://www.drupal.org/files/issues/node_access_for_left_joins_d7.134908...

Note that this leads to a much lower performance, but without this, ERPAL Lists do not work.

Changing to Major and fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

chipway’s picture