Synopsis
This project provide a complete enterprise project management solution, give you a flexible approach to defining and
managing your projects and the people, schedules, deliverables, and finances associated with them.
Requirements
business_menu, business_toolbar and other modules from business_core(https://www.drupal.org/sandbox/jianhe/2846751).
organization and other module from human_resources(https://www.drupal.org/sandbox/jianhe/2847047).
Roadmap
https://www.drupal.org/node/2846532
Dependencies
Drupal 8.x
Project link
https://www.drupal.org/project/projects
Git instructions
git clone --branch 8.x-2.x https://git.drupal.org/project/projects.git projects
Comments
Comment #2
jian he CreditAttribution: jian he commentedComment #3
PA robot CreditAttribution: PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpsgitdrupalorgsandboxjianhe2847056git
Fixed the git clone URL in the issue summary for non-maintainer users.
We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #4
jian he CreditAttribution: jian he commentedNow the only issue on pareview.sh is: Visibility must be declared on method ...
These issue are all on XxxTest.php, but for drupal testing code standard, do not need visibility declare on testing functions.
Comment #5
PA robot CreditAttribution: PA robot commentedProject 1: https://www.drupal.org/node/2847784
Project 2: https://www.drupal.org/node/2847546
As successful completion of the project application process results in the applicant being granted the 'Create Full Projects' permission, there is no need to take multiple applications through the process. Once the first application has been successfully approved, then the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers ... which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as 'closed(duplicate)', with only one application left open (chosen at random).
If you prefer that we proceed through this review process with a different application than the one which was left open, then feel free to close the 'open' application as a duplicate, and re-open one of the project applications which had been closed.
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #6
jian he CreditAttribution: jian he commentedYes there has two project: Projects Management System and Human Resources Management System.
Now I have make another issue to duplicated status, and make this one to review.
Comment #7
jeetendrakumar CreditAttribution: jeetendrakumar as a volunteer and at HyTechPro.com commentedHello,
Please fix pareview.sh errors.
Comment #8
jian he CreditAttribution: jian he commented@jeetendrakumar, thanks for your preview.
Now all the issues reported by pareview.sh has been fixed except these:
Task module is sub module of projects module, and "task_" is exactly the correct prefix for task module. It seems preview.sh miss reported.
Project module is also a sub module of projects module, and "project_update_" is exactly the correct prefix for update function. This is also a preview.sh issue.
And my code is:
task is my sub module name, and workplan is the entity type. I don't found any issue for my code. I guess it's the preview.sh miss reported it.
Comment #9
pdenooijer CreditAttribution: pdenooijer as a volunteer commentedManual Review
Comment #10
pdenooijer CreditAttribution: pdenooijer as a volunteer commentedComment #11
jian he CreditAttribution: jian he commented@pdenooijer, Thanks for your advice.
I agree with you. I will rename the module name into more meaningful name. And I have renamed the project module into organization_project already. Because the project module depend on the organization module, and the "project" is exactly an organization's project.
And I will rename other module names into meaningful name within next 24 hours.
Comment #12
jian he CreditAttribution: jian he commentedI have reverted module name change commit maked by #9,#11.
This is because the "organization_project" name will make confuse. After making some discuss with my team, here is some conclusion:
1. The module and entity name is important for make business clear.
2. Module name such as "pms_project" will make confuse of business terms, and the config file with "pms_project.type.*" will also make confuse of business terms, and the "project" entity will not only used in PMS, and will used for other business solutions. Just like the organization in HRMS(Human Resources Management System), the "organization" entity and module is not only used in HRMS, it used by PMS(Projects Management System) and IMS(Inventory Management System) and other business solutions, hrs_organization will miss believe it's only HRS, but it's not.
3. All the business modules(such as organization, people, supplier, project, deliverable...) are sub-modules and in "Business" packages, all these entity name and module name has clear business definitions. If the user downloaded the module and want to install it, they will know what's the sub-module is, and will not make the module clash I think.
Sorry for my poor english skill, and I will open for any suggestion and ideas.
Comment #13
pdenooijer CreditAttribution: pdenooijer as a volunteer commentedManual Review
Comment #14
pdenooijer CreditAttribution: pdenooijer as a volunteer commentedComment #15
TR CreditAttribution: TR commented@jian he: About #8, you are correct, your function naming IS correct - pareview is giving you a false error. I reported that a few days ago in #2854785: False error about function naming.
About #12 ...
Unfortunately, Drupal has a flat namespace for module names (and for entity names, and for plugin names). That's not ideal, but it's something that isn't going to change in the near future so we have to live with it and work around it to ensure we don't have accidental name conflicts. The accepted way to do this in Drupal is to prefix your sub-modules with the name of your project. The suggestion from #9 to use pms_ as a prefix is a very good suggestion.
As it stands now, you have sub-modules named "task" and "project", but those names are already in use by other modules. If someone tries to use one of those modules at the same time as yours then they will have major problems. It would be good to avoid those problems by naming your modules uniquely to begin with.
Also, how is testing, installing via drush, etc. supposed to know which "task" module is needed when you list "task" in your dependencies?
This naming is also very important for your entities. An entity with id="project" is certainly going to conflict with other entities on a web site - everybody can't be using the simplest word to name their entity or project, and "project" is already taken.
You do not have to use pms_, but you really, really, REALLY should pick a prefix and use that prefix for your modules and entities and plugins.
Comment #16
jian he CreditAttribution: jian he commented@TR, Thanks for your review.
I agree with you. I will change the sub modules name and entity name to give a prefix.
All the sub modules in the 'Projects' and 'Business core' are exactly the CBOs(Common Business Object). For example, the "Deliverable" sub module is a CBO, it used not only in "Projects Management" business solution, but will also used in other business solutions such as "Supplier Management".
So my suggest is put a "cbo_" prefix for all the sub modules for "Business core" and "Projects" and all my other Business solutions project. I will make the code change immediately if you agree with the "cbo_" prefix.
Comment #17
jian he CreditAttribution: jian he commented#15 has been fixed.
project, task from 'Projects' has been changed into cbo_project, cbo_task.
item, organization, resource from 'Business core' has been changed into cbo_item, cbo_organization, cbo_resource.
Comment #18
jian he CreditAttribution: jian he commentedThe project projects has been promoted to a full project: https://www.drupal.org/project/projects
Thanks all.
Comment #19
jeetendrakumar CreditAttribution: jeetendrakumar as a volunteer and at HyTechPro.com commentedComment #20
TR CreditAttribution: TR commented@jian he:
There has been a major change to the project application process. Please read https://www.drupal.org/drupalorg/blog/goodbye-project-applications-hello...
Yes, you now have git access, so does everyone - there is no longer an application process solely for git access. Your project is now automatically promoted to a full project, but you do NOT have security advisory coverage unless you leave this issue open and complete the process. This is not mandatory, but you should be aware of this major change!
Comment #21
klausiSo I assume this still needs review.
Comment #22
jian he CreditAttribution: jian he commentedThanks @TR and @klausi, Yes the project need have security advisory coverage, so need leave this issue open and complete the process.
Comment #23
apadernoTo the reviewers: Please change back the priority to Normal after doing a review.
Comment #24
sleitner CreditAttribution: sleitner commentedAutomated Review
Pareview details: https://pareview.sh/pareview/https-git.drupal.org-project-projects.git/r...
Review of the 8.x-3.x branch (commit b6297f5):
This automated report was generated with PAReview.sh, your friendly project application review script.
Manual Review
deliverable, issue and workplan
machine name and class/function names to prevent namespace collisionThe starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.
If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.
This review uses the Project Application Review Template.
Comment #25
sleitner CreditAttribution: sleitner commentedComment #26
apadernoComment #27
apadernoIf you are still interested on being able to opt into security coverage for projects you create, please open a new application using a project for which the only commits (for the time required to set the application's status to Fixed) are from you.
Please don't open a new application if you aren't sure to have time to dedicate to the application, or it will be closed again as won't fix.
I am closing this application due to lack of activity.