Development of Storm Teammember

Have you tried the Storm Team member module (which comes as part of the Storm package)?

I think that this new item is a repeat of this one.

I am starting to use/test storm again and i do not think the Team Member module is working? If I set up a team member from one org to see the project of another it still does not allow access. I have tried specifying task and ticket as well. I am assuming that the Team Member module is set up to allow me to specify Project, Task or Ticket level of access depending on how much info I select in the Team Member form? Either way it is still not allowing any level of access. BTW, the other issue marked as a duplicate has the same info I would provide. I am off to read some code.

R,
C

If i'm absolutely honest, i haven't had a look at all at the team member (don't really know how it works) but it will be something that is looked at in due course.

@magnity I am changing the status on this issue. Feel free to change it back, but IMO without the ability to assign Team Members from other organizations to a Project, Task or Ticket it renders Storm nearly useless in a multi-organization set up. If everyone is listed under the same organization and you do not mind if everyone can see all the projects in that organization you are OK. But in reality I think most projects will have developers/designers/team members from different organizations working on a project. And you may not want to give them access to all projects in an organization. The strength of Storm is the out of the box permissions that it allows for basic project management and the concept of Team Members seems to be a central concept here. I'll have a quick look at the code but not sure I will be able to do much.
R,
Coby

Let me clear this one up a bit - You can assign a Team Member from one Organization to a Project, Task or Ticket of another Organization - it just does not do much for you regarding permissions. I had a quick look through the code and it does not look like the multi-organizational use case has been coded for yet. If you stick within one organization to create Team Members I think you will be OK for now. But to support Teams that may cross organizational boundaries with the proper permissions it's will take some thought as to how you want to implement:

1) Could be a new set of permissions such as 'Storm project: view of user team'
2) Allow for projects to be assigned/owned by Teams instead of organizations
3) Some other way(s) I am sure I have not thought of

I am happy to help sketch some of this out, but do not want to get in @magnity's loop any more than I probably have. I notice there is more than one issue in the queue that could be related so I will back off and let @magnity set me straight before causing too much confusion.

After looking at the code I am not sure it is a bug but rather a feature request to extend the current Team Member sub module to also influence Storm permissions???

It sounds like its about time that I had a dig through Teammember to find out exactly what's going on. First of all, i'm just looking through the issues regarding Storm Teammember, and would like to combine #348600: Team members permissions into this one. I had already been thinking a little bit (since I last admitted my lack of knowledge of S.T) about where the team functionality would fit in. I suspect that my ideal solution would be similar to 2), but it would require a slightly more than simply replacing organizations.

@cglusky - i'm very happy for you to have a look through and see what you can make of it too. The more people who get involved, the more will get done!

Perhaps we could have a bit of a brainstorm at first and see what we come up with.

Another issue that could be solved in the same move with some careful thought: #392414: Assign projects, tasks, and tickets to people.

I'll sleep on it...

Hi,

I'm loving the idea of Storm and can see this issue is clearly being worked on. Dunno if this fits your plans, but...

I imagine that a 'team' should work on a 'project'. As has been noted above the team members can come from different organisations.

This makes me think that the headings on the admin page (currently "Organization, Project, Task, Ticket" in the latest dev. release) should defiantly include the "Person" being assigned in that particular row.

I'm also thinking that Task and Ticket are a little too granular in this context. I mean, would you ever build a team just to handle a specific ticket? Or have I missed something?

@magnity i think you will find the code pretty straight forward. looks like it was set up to do all the basic stuff to manage team members. what i found was none of the other modules are set up to use the team member concept as access control. everything is based on Own, Organization, or All permissions. The way I might do it would be to create permissions to check a users team info in each of the other modules. the nice thing about the way team members is set up now is you have project, task, ticket info available to enter. and i would say that gives you the ability to have the granularity to assign a team member to something as small as a ticket - could be some specialist that only needs to work on that ticket. might be overkill - not sure. i am seeing a bit of repetitive code throughout storm in the access check area so i think you could create a few functions that could make your life easier and allow for this use case.

r,
coby

Ah... I think I get it.

Can one think of the teammemeber module as a way of assigning tickets, tasks, projects (and maybe more to come) to users?

I said earlier that cannot see the point of being able to assign a teammemeber to a task, but if doing that is the same as assigning the task to the member then why not? In fact, having the teammember for a task in a many to many relationship like this is great for having more than one user assigned to a single task.

In which case the solution to the access problem becomes to allow a user to see any object they are a teammember of.

What this would also mean is that the project, task and ticket pages should have Teammember icon to the right (in much the same way the project has 'notes', 'tickets' and 'timetrackings' at the moment). Actually, project should also get a teammember icon too.

And there should be a page that shows projects, tasks, tickets (and maybe more to come) items that the current user is a teammember of - kindof like a 'what are my priorities and tasks' dashboard.

Is that more on the track this is supposed to be?

@raintonr - not sure it's a way to assign projects/tickets/tasks. right now projects are owned by organizations and thus so are the tasks and tickets of that project. i see teams as a way to extend that ownership concept when required by adding people (possibly some from other organizations) to a project/task/ticket. i am thinking of a team as a way to extend an organization and thus who owns and can view/edit/delete nodes in storm - a team member could be treated as a temporary member of an organization. it's a matter of selecting all users from the organization and team members with the proper permissions for the current action. i am not sure that is the way to go but seems to be in line with the current code. assigning a user to a project/task/ticket would also need to take into account organization and team concepts in order to return the correct set of users allowed to be assigned to project/task/ticket.

Re: #11

Hmmmm... I don't like the concept that a teammemeber is a temporary part of an organisation. That's because doing this would grant that member access to all the organisation's projects and data which is not very good if all that was really meant was that a person from another organisation was required to work on one specific project, task or ticket.

I guess the point is who is in charge of this and what direction do they want to go in? Which of the suggested (or their own) ways forward with the teammember module do they like the most?

Re the direction that i'd like to go in... to be utterly honest i'm yet to decide that. There are obvious pros and cons to each method and I don't want to rush into a method without thinking it through fully!

I realise that this (being the entire concept of facilitating multi-organizational collaboration across Storm) would be a huge step forward - so it will be on the list of things to do, and I will post back here once I have thought through it all and come up with a rough strategy.

Please do continue to post here with your thoughts - especially descriptions of what your use of this feature would entail. I'll be using this thread as a reference when sketching out the design.

@raintonr - I agree that a team member should not be given the same privileges as a member of an organization - unless you want them to be treated that way. My thought was that based on how much info was given when creating the team member would decide the level of access:

Project - access to entire project so essentially treated like a member of the projects organization
Task - restricted to the task and tickets associated
Ticket - restricted to that ticket

I probably caused confusion because i was using the term organization in a more general project sense and not specific to storm when I said temporary member of an organization. Yes, there should be ways to further limit that access - just as you would in a physical security sense at a facility.

I do think with some refactoring in the code a couple functions could be developed to help with access checks in general and team members specifically. All I have is some pseudo code in my head at this point, which doesn't do @magnity much good I am afraid.

I think if we can get this concept included and perhaps integration with the Pop-up API so we can do inline node add/updates, Storm would be very hard to resist - Yes, I know there are some who complain about not using the "Drupal Way" with CCK and Views, but honestly I see the out of the box permissions, structure and interface as a win. Besides, @magnity has done a great job with starting Views integration. But those are all things for separate issues.
R,
Coby

I wonder if trying to integrate Storm with Organic groups makes any sense? Team members could be subscribers to the group, etc.

I am not sure how well Storm would work with OG - I have not tired it. OG and Storm both handle access control in their own way so it could perhaps be a bit of a challenge. I ended up creating my own semi-custom Storm knockoff using OG/CCK/Views and had to do things like hack OG to change the interface text to reflect Projects rather than Groups - about an hour to go through the files and search/replace and test. Not very handy to sustain though since you have to make those changes to every new release of OG. I think @magnity will get it figured out in Storm so you do not need a dependency.

Referencing: #285700: sub organizations. The idea was to have sub-organizations - whereby a parent organization can see the content of all child organizations etc.

This needs to be considered as part of the redevelopment of Storm Teammember.

i will try to simplify what i have understood for now:
we should have three entities:

Organization
Team (sub organization) - part of organization
Teammember - member of team or organization, even member of multiple teams and organizations

and three types of work:

Project - access to entire project so essentially treated like a member of the projects organization
Task - restricted to the task and tickets associated
Ticket - restricted to that ticket

where you can assign any entity to any type of work: all of this with many-to-many connections.

With this kind of setup, we would need something like
Project Manager and
Team leader
and their role would have rights to assign Teams and Teammembers to Projects, Tasks and Tickets.

I can see the need for this, and it's importance. It would, certainly, make my life easier.

So, can this be some kind of a draft?

#18 - homoludens: I'd add one setting -- a checkbox-like boolean variable that allows one to create a team that is either inter-organizational or intra-organizational.

That would permit internal teams grouped by organization, and external teams grouped by project.

The result would be that projects should also have a similar boolean, to differentiate whether a project is focused within a particular organization or includes several organizations.

The reason? A project that has lead org or team but which encompasses several organizations in order to do something like a community project would be possible, and so would projects that are focused within a specific organization but may still incorporate teams consisting of the core organization plus third-party vendors. An example of the latter would be, for example, a major rollout of an ERP package -- the company which is receiving the rollout would be the target organization; there could be a single contractor/vendor (our company) managing the consulting aspect of the rollout and working as a general contractor for several other vendor teams that are working with us to pull together the disparate projects and tasks that must be accomplished for an enterprise-wide rollout.

The core logic should be able to remain the same; searches would be similar, but could include a filter on the booleans for project scope and team scope that allows one to list only all-one org projects (but still multi-org teams) or all one-org teams (but still multi-project) or all one-org team and one-org projects, or only multi-team/multi-projects.

Projects and teams, in my work, can be intra-organizational so this capacity to recognize and tag them as such would provide more flexibility w/o (theoretically) much heavy-lifting.

*edited 'cuz I had "intra-organizational" twice instead of "inter-organizational" and "intra-organizational" -- hope it makes more sense now.

Hi, sorry, but I can't follow one point:
In the stable version of STORM, how are permissions set for a Teammember?

OK, I created a project as Fritz. I also added the Teammember Otto to this project (directly, not to a task or ticket).
Now, I log in as Otto. I don't see the project in the list. If I go to Teammember, I see the entry and the project title.
If I click on this title, I receive an error, that I am not allowed to see the project.

Fritz and Otto are both in the same company.

What do I have to change, so that Otto can see the projects where he is assigned as Teammember but not all projects of the organization??

Is this something allready working, or dicussed as new feature?

Kind regards

Kai

in this thread we are discussing new features for teammember module, and probable complete redesign of it.
we believe that it is easier to redesign than to fix all this small issues that everybody has with it.

I have also reverted title to "Development of Storm Teammember".

Yes - the development of Storm Teammember is one that needs work across the board. If we consider the functionality as a whole rather than in individual parts, I believe that we will achieve a much better solution. Therefore, I do not apologise to the people kept waiting for this feature as I believe it will ensure that we get it right. I do realise however that the wait is probably infuriating for those who need this feature.

As a background for those interested: Storm Teammember has had very little love in the time that I have been a maintainer for Storm (about 3 months). I believe also the previous module maintainer (the original author of Storm) did not do too much to it either. From what I gather from various past issues I have read through, the Storm Teammember module was contributed by a member of the community (whose identity I do not know), and the last I saw was that there were various things that the previous maintainer had on his 'list of things to do' for that module. I hope this helps people understand why there is at the moment a bit of a lack of knowledge about the Storm Teammember module and where it was heading.

In order to help with this issue, I would very much like to hear use cases from people about the teams / collaboration functionality that they require from Storm, so an appropriate strategy can be drawn up.

Good morning @all,
thank you for reply and the "new" statement from you, Magnity.
So I am right that my feature request is not allready implementated in Teammember at the moment????

Magnitiy, you want to hear about use cases on Teammember - I will try to explain my own need.

I have to start a new part on a Drupal project. We want to build up an intranet part for freelancers. The following list describes the needs for this portal:
1. Freelancers are organized by town (region). To do this, I modified Organisation to "Partner network".
2. Feelancers are added to one of the Partner networks
3. Freelancers are able to create and modify there individual STORM-content (people, projects, tasks, notes, ...).
--> Here is a first little feature whish: It would be great if I would be able to assign projects to "people" or people to projects. I mean, to be able to create a project on base of one person (people), as in my case the people are the customers a project is based on.

4. Now, if there is a new project (for a customer), they might want to work together with an other freelancer. They add a freelancer from the list of people to teammember.
5. OK, what permissons would I like to be usable?!
a) All content is private and only assigned to the owner by default
b) If a teammember is added to e.g. a task this task must be viewable by the teammember -> it has to appear in his list of tasks.
c) It would be great to be able to set up read/write attributs for the teammember by the owner
d) In MY case, it would be great, if the permissions are bequeathed up AND down, so the teammember can see all activities added below "his" new task and also the direct "line" up (Project-description and Kontakt-data)
e) There must be the possibility to set some elements back to private (choise on create process if task is viewable only private or for all Teammembers)

Is there allready something like a roadmap existing?

Kind regards

Kai

Hi Magnity - Here is my use case:

I have a number of customers, some in-house consultants, and some contracted consultants who are all working on various projects. So for customer A's project C, I might have consultant 1 and contractor 3 working on it. They need to be able to share tasks and tickets. I might want only customer A to be able to create new tasks, or I might allow only consultant 1 to create new tasks. When a new task or ticket is created (or updated), I need to be able to notify all the other team members.

Customer A might also have project D with a team of consultant 1 and contractor 4. I don't want contractor 3 to see anything about project D, nor would contractor 4 see anything about project C. People can only see the projects, organizations (customers in my implementation of storm), and etc for those they are assigned to via the team.

Team members could not view other's timetrackings, expenses, and invoices related to the project unless they had explicit permission to do so.

Only certain users would be allowed to create and setup a team. If allowed to create a team, they would also have to define the permissions for the team (who can create tasks, who can create timetrackings, for example).

I am integrating storm with the workflow module, so everything with teams needs to be compatible & interoperable with workflow. I don't think that would be technically difficult, but want to mention it to make sure it is considered.

I like the idea of granular permissions from Project->Task->Ticket acheived via the Team Member function to expand Storm to multi-organisational working.
I also like the idea of having an Project/Team/Ticket owner so you can see who's in charge of what.

The way our current system works is...
Tickets are logged for a person in an organisation.
These are 'unallocated' until someone either gives or takes ownership of them
Anyone within the organisation can add Time to the ticket.
Once completed the time is reviewed prior to invoicing.

I'm still yet to replicate this in Storm, but I think it can be done with...
Add a CCK Node Reference for Person on the Ticket called 'Contact' - This is who to contact about the call or the instigator
Add a CCK Node Reference for Person on the Ticket called 'Owner' - This is who is the ticket is assigned to or who is in charge
Add a CCK Node Reference for Person on the TimeTracking called 'Person' - This is who did the Time, needed so anyone can enter time for anyone

But obviously the more in core Storm the better.

Just to say that I didn't go down the CCK Node Reference route and I've successfully coded a 'Contact' Person on Tickets.
The 'Contact' person select list is filtered according to the selected Organization.

I only note it here in case someone was interested in the patch.

Having thought again about this whole issue.....
I would suggest implementing a 'Team' table then altering the structure so that it flows 'Organization'->'Team'->'Person'
If you also implemented a role/type/description to the teammember table you could describe the relationship for say contact/project manager/ticket owner.
You could then specify wether an organization or team or person has rights to an organisation or project or task or ticket and also indicate why by the role/type/description.
This should cover all inter/intra organisational aspects as well as handling assignments/management

I would suggest the first step to take would be to implementing a Team table along with the Organization/Team/Person relationships.

Using CCK Node Reference would be great and drupalish way, but it's a pity that node and user reference fields are not in core drupal 7, I'm not sure if they are planing to move them in core - witch would be great for storm, since then we could use them without too much thinking about them.

Until then, we should search for other solutions and choose the optimal one.

@Mark_Watson27 So, I'm interested in your patch, please post it here.

@homoludens, I could provide the patch but I really think the emphasis of development should be teams as opposed to adding fields to tables as this would provide so much more to Storm.
Personally I think the development of Teams and Roles should be the number one priority.
I'd be happy to look in to this if no-one else has suggestions.

Marked #392414: Assign projects, tasks, and tickets to people as duplicate of this issue

Marked #544254: Adding new fields as filter options and on lists as duplicate of this issue

subscribing

OK - This issues is the main one that I hope we can solve for the next snapshot.

As far as I can see, there are particular problems with the current way that the teammember functionality is managed (i.e., it doesn't really do anything). Also, I feel that the place to store the team data should be with the particular project / task / ticket that is being referenced.

Therefore, I propose that we do the following:
- 'Decommission' the Storm Teammember module. I'm not sure whether the data is in a useful enough format to automatically update to the new format - ideally yes, but if not, it may be a case of warning users and simply deleting that data.
- Create a new module - say 'Storm Team' to be clear about the change, which simply allows creation of teams. A team basically would be a node, with a title/name, and also the facility to add Storm Organizations or Storm People. This would allow teams of a single or multiple organization. When viewing, it would be good if any Storm people were grouped by Organization. If the whole organization has been added, it could simply say "Organization\n -all".
- For each module, such as project, task, ticket, implement fields referencing any contacts / owners / leaders / managers / teams that are needed. I thought these could be set to allow the input of either a Storm Organization, Storm Person, or Storm Team.

Any thoughts, questions, clarifications needed? I'm open to all opinions.

The next step would be to identify which fields are needed for which modules, I think.

Sorry - been busy & away a while. Sounds like a good start. My main requirement is that I can assign people from multiple Orgs to a Team, and send emails to the Team when the node's status changes (via the workflow module).

@Magnity: Sounds good to me. As the lack of this feature is pretty much holding me back from implementing Storm I'd be more than happy to help in anyway I can.
Cheers
Mark

@Magnity: Noticed you've started implementing Manager and Assigned to Project.

I was thinking that for flexibility the links between modules shouldn't really be static on the table. I realise this maybe a step too far for peformance versus flexibility. But looking at all of the various usage scenarios above this flexibility would help.

If you had a seperate table to hold the links in say containing:
Source Module, Destination Module, Link Type

Source Module being Project/Task/Ticket
Destination Module being Organisation/Team/Person
Link Type being Assigned To, Manager, Contact etc

Is this too much?

Cheers
Mark

Mark, could you explain more?

I'm not 100% on what the benefits of your system would be. Would you be thinking that the site admin could add and remove fields via a ui?

Perhaps I'm making assumptions on your usage of the manager_nid/manager_title and assigned_nid and assigned_title, were you going to link these to organisations or teams or persons?

I presumed you were going to link them to persons, so I only ask as what if you need to assign a project/task/ticket to a team as opposed to a person?

Will we be limited to just manager and assigned or are you planning to extend this to add other fields?

I'm probably just jumping the gun in which case I do apologise.

Perhaps it's easiest if I expand a little on my plans, then you can say whether that's what you understood and whether you can see a better way.

1) Storm Team will consist of nodes: with title, description, links to many organizations and people. The principle being that when a particular team is referenced, it will allow all persons in that team or persons from all organizations listed in that team to have the permissions of a team member.

2) Nodes such as Storm Project nodes will have fields such as 'Project Manager', 'Assigned to'.
- Some such as 'Project Manager' would only really suit a reference to a single person.
- Some such as 'Assigned to' would allow a single person, organization OR team to be referenced. This would be determined by the nid.

Therefore, there could be the permissions:
- Edit when project manager, a single person has this.
- View when assigned to project, the entire team could view. Each teammember is a stormperson node referenced on a stormteam node.

I think the only difference between my vision and your understanding is that 'assigned' would not necessarily be linked to a person.

I wasn't planning to have any facility for admins to extend this to other fields simply due to the nature of the code involved with linking the permissions, but I was planning to add assigned fields to other storm nodes - such as tasks and tickets.

Subscribed this thread and provied my 2cents.

1. Based on the heirarchy of Org -> Proj -> Task -> ticket
2. Team can be the logic grouping of any level of heirarchy, while grouping, it is also grant the inheritence of Ac List [read, eidt, add, del, control], and this ACL can be roganized by Role, Profile or what make sense.
3. In the AC list, the 'control' right of the heirarchial objects can serve as as manager (orgnaization, project) and assigned (task, ticket) flags.

I am not sure the above idea can covered the senarios discussed above, just feed in what I think.

Thanks for the good work to improve this module getting a lot better.

An update:
- Stormteammember has gone
- There are new fields in Stormproject, 'Project Manager' and 'Assigned to'. Currently, they can only reference people.
- There are new permissions in Stormproject which will control actions based upon these new fields. They haven't been 'plumbed in' to the access functions yet.

Over today and the next few days, the permissions will be plumbed through and the new Stormteam module will be committed. After this, i'll look at the fields that could be useful on other types of Storm nodes.

...as usual, it is worth having a copy of Storm -dev to try these things out on.

Interesting, I did try on my test system, the functions are working but I will do a more throughout test letter. However, there are a few feedbacks:

1. What's different between Project Manager and Assigned to? Now there are two ACL to assign to these 2 ref. users but maybe we need a better label to state the purpose.
2. Can this be made to only one field and selecting multiple users? Such as for the project members to operate.
3. Does this two settings have inheritance ACL funciion, which means assinged as project mgr. it will have the Task and Ticket rights also.
4. I still see the Team sub-module exist, what's its status now?
5. Do you consider to integrate the contributed patch for Task asssignee at http://drupal.org/node/509168 also?

Again, thanks for the good works.

Answers:
1) There is currently no difference between PM and assigned - but my plan was that once i've finished the Stormteam module (about 50% there with it), that assigned would be able to take an entire team, whereas PM would be restricted to a single person.
2) This would be the point of the new Stormteam module. When a team is assigned to a project, for example Foobar Team A, it would be as if all members of the Foobar Team A had been individually assigned to the project.
3) Not currently. I'll think about that.
4) In development offline, not committed yet. I reckon i'm about 50% there with it.
5) Once Storm team is working with the project assigned field, i'll roll out fields to other parts such as tasks and tickets. It is likely that the functionality of that patch will be included even if not in exactly the same form.

Thanks for the feedback - its useful to hear that people are testing it out, especially as my plan is to roll the next stable release once this issue is finished, so testing is really important.

Just to give all an update - i'm gradually rolling out the Storm Team functionality to the demo site. I know a few people are waiting to see what it looks like.

The code is pretty much done - i'm mainly bug fixing, and also need to sort out a few of the access functions.

I've just committed the new module - Storm team. Treat it as early beta quality. The dev release will roll again at midnight.

Things still to do
- Some work on access functions
- Think about whether an upgrade function from Storm Teammember is possible / good use of time to write
- Anything else in the code that has a // TO BE COMPLETED label.

Please do test. This adds around 700 lines of code to the Storm project, and so will need plenty of testing before the stable release is rolled.

Further work planned
- Allow users to reference entire organisations in a team
- Allow users to reference teams as pm / assigned to fields in projects etc.
- Please complete this list for me if I've missed something...

Hello @Magnity

I get the following error:
Fatal error: Call to undefined function stormteammember_access() in storm/storm.module on line 608
This is due to the the addicon function, if we change line 239 in storm.theme.inc to
$add_icon_type = 'stormteam';

Then rename the image file from teammembers.png to teams.png, then change the storm.css, lines 138, 139 to

dt#stormteams {
background: transparent url(images/teams.png) no-repeat top left;

I haven't had a play yet with the functionality but am looking forward to getting this working.

Cheers
Mark

Thanks - that's fixed (new release at midday)

OK, the first try, and reporting what I get.

1. I added the team name and members and get the message (I think it is for debuging SQ display) as:

"stdClass Object ( [uid] => 1 [created] => 1254136312 [type] => stormteam [language] => [changed] => 1254136312 [title] => TeamName1 [members_array_1] => 72 [members_array_2] => 59 [members_array_3] => 0 [teaser_js] => [teaser_include] => 1 [body] =>

test teamname1
[format] => 1 [title_old] => [revision] => 0 [log] => [name] => cqcrm [date] => [status] => 1 [promote] => 1 [sticky] => 0 [op] => 儲存 [submit] => 儲存 [preview] => 預覽 [form_build_id] => form-32b839e3c6a3b731c317d782b7ac8f48 [form_token] => d339046bdaa2e7a7a9dc9c47f07f6627 [form_id] => stormteam_node_form [book] => Array ( [menu_name] => [mlid] => [nid] => new [router_path] => node/% [has_children] => 0 [options] => Array ( ) [module] => book [original_bid] => 0 [parent_depth_limit] => 8 [plid] => -1 [weight] => 0 [bid] => 0 [pick-book] => 變更手冊(更新上層列表) ) [comment] => 2 [menu] => Array ( [mlid] => 0 [module] => menu [hidden] => 0 [has_children] => 0 [customized] => 0 [options] => Array ( ) [expanded] => 0 [parent_depth_limit] => 8 [link_title] => [parent] => primary-links:0 [weight] => 0 [plid] => 0 [menu_name] => primary-links ) [path] => [upload] => [attach] => 上傳 [teaser] =>

test teamname1
[validated] => 1 [is_new] => 1 [timestamp] => 1254136312 [vid] => 98 [moderate] => 0 [tnid] => 0 [translate] => 0 [nid] => 95 )
"

This debug line should be remarked out.

2. After I added the team, should it be listed in the Project Editing's "Assigned To" drop-down list? Currently it is not!! Maybe I am wrong. But at this moment, after the team created, it is not showing at any other module: I try, task, ticket, person/people, organization, notes. None of them have team field referenced. I am not using other module: expense and invoice.

That's what I can tested so far, for I don't know what is next step.

Thank you for the progressing anyway, I will actively perform the test when the new code posted.

Thanks!

1) Yes, a debug line I had missed. It is now gone.

2) Will probably get to this bit tomorrow or within a couple of days.

Thanks for the report.

Update / nightly brain dump:

- Names of permissions changed so that that the capitalisation matches the other storm modules. If you're testing this feature, you'll need to reselect the permissions.
- You can now assign teams to projects, but there is a bug in the access at the moment that denies when a user should be able to view the project based on the team being assigned.
- Some general cleaning up and adding of 'module_exists('...')' in Storm project.
- Fixed bug with access related to assigning to storm person.
- An entire organization can be assigned to a team, but the access functions need doing - so currently this is stored but doesn't affect access.

To do:
- Views integration (will need field handler)
- Access bug mentioned above for assigning teams to projects
- Access for assigning organizations to teams (and knock on effects for projects) also mentioned above

- Views integration done.
- Bug introduced yesterday meant nothing was displaying in the dropdown when adding teams (now fixed).
- Access bits mentioned yesterday sorted out.

Therefore, i'm now calling this issue fixed.

The addition of the Storm Team module is around 850 lines of code now, and I haven't tried to count the lines of changes to the Storm Project module - therefore I would ask that all people wanting to use this section of Storm install / upgrade to the latest dev as soon as convenient and test out these changes. There will be lots of different ways that people intend to use this functionality - so there may be combinations of settings / modules / etc that I haven't remembered to test.

Follow on issues to wrap up loose ends:
- #595276: Assign to fields for tasks and tickets
- #595278: Remove old Storm Teammember table

Ok, here is the testing No1:

1. When adding new team, I still don't have anything to select team member
2. After the team added (without any member), then go back to do editing, the dropdown shown "-PEOPLE-" and the organization list, I believed that it should list all people under -PEOPLE- but it is not.
3. Check into Project editing, Project manager shown -People- and the list, it matched the spec. discussed above, but just a thought, what's wrong to have a team as project manager? It is just an option to allow backup or assistance project manager.
4. Assigned to shown -People- and its list as well as -TEAMS- and its list. It is good.

However, I cannot test any access right for I can't assigned any member to a team. I will try organization and see what happened.

Just another thought, when adding member to a team, can it be added another team? This could require some control to prevent self-included loop but it will save a lot of routine team setting jobs.

Thanks again and looking forward to the new updated fixes.

OK, last #52 testing was not the right updated version, for some reason the development snapshot download link still give me the 10/2 dev. version, I checked the link under "Release notes" and get the 10/3 dev. version.

So, I will report this new version's test later.

ok, here is the testing report:

1. When users who is not (Drupal) admin and access project (storm/project), the warning msg:
warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /.../modules/storm/stormteam/stormteam.module on line 646.

2. users who set as "Assigned to" in a project cannot view the project (Storm project: view if assigned to project) is checked.

3. the user is set as "Project Manager" of a project can only view the project, but cannot edit the project (Storm project: edit if project manager) is checked.

3. The users who is "Assigned_to" or "Project Manager" in the project but not set as the person of the Organization cannot see the Tasks or Ticket under the project. The access permissions are not passing down to the task and tickets in the project checked.

4. Currently, the Teams setting is designed to accross organizations, so the access rights should override the orignial setting by Persoan of the Organization. But now it is not doing so.

The original storm permission/access is set by person of a organization, who is the member/person of the organization can access/edit/all task/ticket/project in the org by Drupal's access/permission settings. The problem of Org. setting is that it cannot pin-point to its projects individually under the same Org. So, the Project_manager(PM) and Assign_to(AT) cannot be used at project level which is go solution but current PM and AT settings did not passing down the permissions nor override the permission set by Org's Person.

I suggest to:
A. Setting the access control list (ACL) in editing the nodes of each STORM sub modules such as "Org, Proj, Person, Task, Ticket, Note ....), yes set at node level. So the ACL function can be including in each sub modules (better yet, can be dis/enable at Strom configuration, disabled sub-module default to use Drupal permission)
B. The ACL can be (multiple) checked by Storm/Person (list only the Org's member) AND the Team with Create/View/Edit/Del (CRUD) combination.

I think the combination of A & B provide any kind of ACL needs. Of course, to ease the tasks of ACL settings, the inheritance level of Org->Proj->Task->Ticket; Task->timetracking, Task->expense, Task->invoice, should be default unless override by ACL at node level.

I know it looks like a re-write of ACL of Storm but I just provide my experience and hopefully this will help usability of applying the Teams module.

Again, thanks for the short cycle of updating the code.

@tazus, thanks for the report.

1) Fixed

2) 3a) Should be fixed but I need to test properly

3b) This is beyond the scope of this issue - not sure if we have a different issue open for it at the moment but need to - it is something which would aid usability across storm.

4) Not sure what you mean by that one - could you explain?

Also i'm not 100% on what you mean in A and B - do you mean that the permissions for a project (or similar) would be set on creating that project? It does sound very complicated. Assuming i've understood what you meant correctly - i won't rule it out but this wouldn't be part of this issue either - otherwise the stormteam permissions would be doing something different to the rest of storm.

I will try the updated code and report back later.

And sorry for the #54 A and B posting in this issue. May be it should be posted on a new issue, but I think it is the fundamental problem we try to resolve by Teams module. Which is allowing to assign a project flexibly. That is why my thinking-out-loud put down the idea in #54 suggestion. And it was triggered by #54's 4) comment.

First, let me clear #54-4), it is about the access control inside Storm. My testing told me to give a UID to a project I have to:
a. Assign Drupal's role permission at Project (view all) or (edit all), or make the UID owner of the project (view/edit own). AND
b. Assign the UID to a person of Organization. (That's my test to let the UID to able viewing Strom, if I make a mistake, please correct me.)

What I learn by a. & b. setting is:
c. When a UID assigned as two Organization's person and the role permission (view/edit own), the UID will only see the first assigned Org. I think this is the reason Teams module is applied for across project and organization purpose.

That's what #54-4 observation, assigning UID to as only one Org. person and added to a Team. When assigned the Team as the other Org.'s project, because the UID is not the person of second Org, so the UID can't see the project even it is in the Team assigned_to the project.

I hope this clear out the #54-4.

So, the #54-A&B is talking about the overall permission control of Storm inside Drupal. Drupal's permission control by Content Type's (CRUD by own, all and within Organization). But we keep running to multiple Org, Project ... permission problems which are instances/nodes of diff. content types. If we try to maintain the ACL control inside Strom not using OG then seems node level ACL is the most flexible solution.

That's why I suggest to provide ACL in Storm at node level with inheritance from upper level node in Strom. I saw such designed in PHProjekt for every object/node, the ACL can be set to Person of the Org or Teams and task, ticket...that under a project will automatic default to the ACL of the project when created by allow to changed.

I hope this clear out my comments at #54. I will do the test and report back soon.

Testing result of 10-06-2009 devel. version:

Testing senario A
A1. OrgA. with ProjA1 OrgB. with ProjB1
A2. UserA set n TeamA and only the person in OrgA
A3. ProjB1 set TeamA as Assign_to
A4. UserA's role permission include "Storm project: view if assigned to project"
ResultA: problems A is coded as PA#, hereafter.
PA1: UserA doest not have ProjB listed in storm/project
PA2: UserA cannot see and Task/Ticket under ProjB

Testing senario B
B1, B2 is the same as A1, A2
B3: ProjB1 set UserA as Project_manager
B4: UserA's role permission include "Storm project: view if assigned to project" and "Storm project: edit if project manager"
ResultB:
PB1: UserA have ProjB listed in Storm/Project but has not "Edit" icon for editing
PB2: UserA click on PorjB at Storm/Project liste, got "Access Denied"
PB3: UserA cannot see any Task/Ticket under ProjB

Testing senario C
C1: Same as A1
C2: UserA set n TeamA and added as person in OrgA AND person in OrgB (last added )
C3: ProjB1 set UserA as Project_manager
C4: UserA's role permission include "Storm project: view if assigned to project" and "Storm project: edit if project manager"
Result C:
PC1: UserA only see the lists belong to OrgB in Strom/Project, Task, Ticket
PC2: UserA click on any of the list item (project/ticket/task) get "Access denied"

It seems that Person belong to Org. only get the first entry. And the Team permsssion has not effect in project access.

Testing senario D
D1: Same as A1
D2: Same as C2
D3: ProjB1 set UserA as Assign_to
D4: UserA's role permission include "Storm project: view if assigned to project" and "Storm project: edit if project manager"
Result D:
Same as PC1 and PC2

It seems that the Assign_to Team permsssion has not effect.

I hope this help, I will try to test when the new updates issued however I am looking at a pretty busy schedule ahead of me.

Anyway, I will try to contribute whenever I can and thanks for this community. Happy sharing!!

there is a little mistake in function stormteam_user_belongs_to_team in file stormteam.module:

right now it is:

function stormteam_user_belongs_to_team($team, $person_or_organization_nid) {
  $team = node_load($team);
  
  // Check for person_or_organization_nid in the team members array and return TRUE / FALSE
  if (is_array($node->members_array)) {
    return array_key_exists($person_or_organization_nid, $node->members_array);
  } else {
    return FALSE;
  }
}

and should be (change $team= to $node=:

function stormteam_user_belongs_to_team($team, $person_or_organization_nid) {
  $node = node_load($team);
  
  // Check for person_or_organization_nid in the team members array and return TRUE / FALSE
  if (is_array($node->members_array)) {
    return array_key_exists($person_or_organization_nid, $node->members_array);
  } else {
    return FALSE;
  }
}

but you still wont get it listed on "storm/projects". for that there is another mistake in the same file:

function stormteam_user_return_teams($account = NULL) {
  if (empty($account)) {
    global $user;
    $account = $user;
  }
  
  $s = "SELECT nid FROM {stormteam} WHERE members LIKE 'i:%s;' OR members LIKE 'i:%s;'";
  $r = db_query($s, $account->uid, $account->organization_nid);
  $teams = array();
  while ($team = db_fetch_object($r)) {
    $teams[] = $team->nid;
  }

  return $teams;
}

should be:

function stormteam_user_return_teams($account = NULL) {

  if (empty($account)) {
    global $user;
    $account = $user;
  }

  $s = "SELECT nid FROM {stormteam} WHERE members LIKE '%i:%s;%' OR members LIKE '%i:%s;%'";
  $r = db_query($s, $account->stormperson_nid, $account->stormorganization_nid);

  $teams = array();
  while ($team = db_fetch_object($r)) {
    $teams[] = $team->nid;
  }

  return $teams;
}

and here is the patch. this solved some issues for me, maybe there are others.

Status: fixed -> needs review

Thanks homoludens.

I've committed that, and am working on a few other bugs i've found too.

More bugs fixed today:
- View team if belonged showing denied when should allow
- Unknown column spe.user_uid when adding/editting teams or projects when user was did not have permission 'view all'
- Teams no longer defaults with "promote to front page" active
- Issue picking up team name when saving a project

Bugs fixed today:
- Projects that a user could view via assigned to and belong to team permissions not appearing in lists of projects
- Links on team view to people and orgs now check for node_access rights before rendering as a link.

Again posting this tentatively as fixed.

Re comments in #56 and #57:

@tazus: I now think I now see what you mean.

This is something that can be debated - and will definitely link in with the Storm Team functionality, but does not need to be part of the foundations that is provided in this issue. There are two points that you have brought up:

- Inheritance of access rights down from project, task, ticket etc.: This is definitely one route to finish off the structure of the node access grants nicely, but I don't think that it can be assumed that this will be wanted on all storm installations. For example, say a client organization had the permission to view their stormorganization profile - would you want them reading all the notes that you have created about them? Therefore, although this could be a really great step, it needs careful thought before implementing.

- A user should still only be added to one stormperson. If it is desired for the user to be able to see projects of another organization, it is possible to assign that project to a team consisting of that user and a different entire organization. Perhaps there should be some validation on add/edit of a stormperson to enforce that.

Assuming I have understood correctly, would you like to create feature requests for both of those?

@Magnity

Thank you for review my comments again. Yes, you understand correctly and you have the point about the possible not-wanted inheritance open access rights. So, may be we can make it optional and can be override at the lower level ACL settings.

The second scenario can be consider from the perspective of flexibility. Team is a good way to distribute ACL in a group but additional option to assign person is flexible. Then the question would be what is the function of Person in Storm. My suggestion is that it can be used as the "Contact" for noting the contact of the project. Many CRM systems have this function for detail customer information keeping.

I have not problem to put these in a new request. I will do it later.

Hi Guys,

Great work so far

I've been testing the latest dev and it still appears that the team member permissions don't do anything at all.

I've tested it using a simple scenario that I have 3 organisations, 1 person per organisation and two teams,
one person is a team member of both teams and the other 2 people are members of the seperate teams respectively.

I've set a role to allow access to storm and access to the necessary child modules with "view own" or "view if assigned to project" and added this to each user.

I can see listed all listed projects although the settings I have in place suggest that I should only be able to see those i'm assigned to and when trying to click through to the project page I get "You are not authorized to access this page."

Is this still under the knife or should it be working correctly?

Just a note, my test server is currently running php 4.4 and i'm not sure whether this is anything to do with the issue.

This is now a closed issue - so please post your experience as a separate bug report - and we'll try to figure out why it isn't working for you.