Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes and changes accumulated during the effort to stabilize v3.0 for our companies usage #220

Open
wants to merge 197 commits into
base: master
Choose a base branch
from

Conversation

carlosazevedo
Copy link
Contributor

Our two companies (at two different time zones) are in the process of switching all project management into W2P. As such I've worked on it, fixing bugs and changing some functionalities. Some of those changes will conflict with previous decisions so I propose using system configs to enable/disable those changes, if needed. Dropping those changes is not an option.

instead of the previous dumb method which allowed for a pure green
background to have white text, rendering it very hard on the eyes.
user to show up on the drop-down field as modules to apply permissions
on. Otherwise it would be possible to add a permission modifier that
imediatelly disapeared from the permission modifiers list.
shown due to the way the code checked for the currently logged in user's
permissions.
contact info behind is useless (no way of reattatching a user to a
contact info row) and leads to permission errors.
- Links to tasks assigned to others are moved to after my own tasks.
- Headers to indicate which tasks are which.
- Layout changes to the filters.
- Text changes to some labels.
- The cell of a task link  has its whole background painted with the task
color instead of just the text.
Previously a task progress was computed at the 'now' time, even if
the display was relative to an earlier date. This changes that to depend
on the selected date so that if the current date is earlier than the task's
start date it will be reported as a 'future task'.
filtering is done.
Now the 'due in' field depends on the currently selected date,
allowing for 'back in time' views of the tasks.
Also a task may show up in the list even if its completed if
the currently selected date is in the past (before the completion
date).
'View Task' form must always display the time unit as 'hours',
not the tasks' duration unit.
and for edit permission with a call to canEdit.
This avoids permission errors on new subfolders.
files inside the subfolder; if none is found anyone can edit the subfolder,
otherwise the current logged in user has to have a file of which it is the
owner inside it.
These way an empty subfolder can be edited.
The 'folder explorer' view shows empty directories, which makes no
sense in the company and project forms.
other users except the currently logged in user
code always showed the project info in the flat view, even if the files
were being listed in the context of a single project.
The tab lists the messages posted in forums/topics that are marked as
'to watch' and that were posted in the selected date.
creation of task logs for users that are only assignees.
…it on

the getWatchedMessages method. Makes for greater consistency in behaviour.
- Unselecting a contact in the middle now is done properly
- The contact's are now listed by first name, within departments and
  companies.
- Now there's a label in front of the company selection control, for
  clarity.
- The 'Contacts for' string only shows up if there's actually contacts to
  show.
…orum

or topic creation, to specify which users should watch it.
This allows pushing subscriptions without needing to ask every relevant
user to activate the 'Watch' setting per forum/message.
Anyone who can create/edit a forum/message can change the subscriptions.
…if the

user can't edit tasks. Otherwise he'll get a permission error if he clicks
on the button.
others' lists in 'Day View' into separate tabs, to be more consistent with
other parts of W2P.
deadline. To avoid problems when the start date is into the future but the
end date already passed, where the old coding would report all OK.
I know this condition is not supposed to happen but it should be handled
this way anyway.
…le to

log in), just sounding an alert instead of refusing to save the record.
This needs to happen in order to support external users (from other
companies) that can have tasks assigned to them but are not allowed to use
the system.

NOTE: I've setup the alert message for English, other localizations are
      needed.
… the

'_author' case handler the contact information is found for user $value but
the link was created to point to stage data's user_id) and creates a new
suffix called 'date+time', to be used.
A full description has yet to be written but the concept is as follows:

Frequently tasks imply operational dependencies that are not practical to
express in the project's timeline. For instance, assume that a task
requires that tests be made on modified samples of a device. The task
description will only say this but in reality it may involve the following
sequential steps:

1. Request the samples from an overseas factory, through their technical
   department
2. The technical department requests the unmodified samples from the
   warehouse
3. The samples are delivered to the technical department for modification
4. After modifications are done the samples are sent to Q&A
5. After Q&A approval the samples are sent to shipping to be sent to
   company headquarters
6. The samples are received at headquarters and are delivered to the
   task assignee.

Including all these steps in the project's timeline is not practical but
for the task assignee (and also the project manager) to know the task
progress accurately this information is crucial. So for these cases
delegations can be used; the task assignee will delegate the task to the
overseas technical department that will then start a chain of delegations
within the factory (technical->warehouse->technical->shipping) and then
to headquarters. Each of these delegations has a done/not done status,
creating task logs that may impact the task's completion status (if there
are no conflicting task assignee's task logs).
Each delegation can be rejected by its recipient, creating a problem task
log until the project manager disposes of the rejection, either by
accepting or refusing it.
After the delegation is done it should be re-delegated to the next user
responsible, by either the user that finished the work (which can be a low-
level user, permissions-wise) or by the project manager.
implied through the project, meaning that if a file was to be linked to a
company a project owned by that company would be required to host the file.
With this patch a file either belongs to a project/task (and the company is
implied), to a company (and there's no connection to any project/task) or
it belongs to nobody.
This has nothing to do with the file owner, in case you're wondering.

This patch requires a DB upgrade (included).
…rk on

Chrome, as it originally was tested on Firefox only.
task may be assigned to an outside party and it may not be desirable to
allow it to access the system. So an inactive user must be used (as are
created by the importers module code).
be users able to view the admin module (so, Administrators only) but now
is changed to allow anyone that can create projects.
…ctly

in a company create/edit form. So anyone that can add/edit companies will
also be able to add/delete their associated inactive users. I don't
consider this a security breach as an inactive user is unable to login,
therefore is similar to not having any permissions at all (which is their
definition).
But inactive users are needed to express the assignment of tasks to outside
parties without access to the system. This is also required for importing
projects, as the users created there will also be inactive users.
For importing projects it makes more sense the pre-create the users to be
mapped into the project's resources but for that an user allowed to import
a project needs to be able to create inactive users, which might not be the
case and would be impossible to do with the old code.
… view,

as it happens on 'Tasks'. Nevertheless a checkbox allows selecting the
presently default behaviour of showing all tasks, regardless of status.
displayed in the 'View Project' page. The main picture (depecting the
object of the project) is shown to the left of 'Details' while all other
pictures are shown at the bottom of the project info box.
For that purpose, and for users able to edit projects, two new file types
are available when adding files to projects: 'Main Project Picture' and
'Project Pictures'.
If more than one 'Main...' file is added only the first will be considered
the main one and if no 'Main...' file exists then the first 'Project...'
will be considered the main one.
The files must be of type 'image/{jpeg,png,gif}'.

So all that needs to be done is to upload files of those types and
categories and associate them to the project. They will then be displayed
in 'View Project' as indicated.
@caseysoftware
Copy link
Member

I've merged as many of these that I could to 4.0 development. I'll continue pulling in the ones I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants