Posted by midmood on June 20, 2011 at 2:27pm
2 followers
Jump to:
| Project: | Checklist |
| Version: | 7.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | j_ten_man |
| Status: | needs review |
Issue Summary
As stated in an earlier thread and requested to put it on a new one:
I think should be interesting to extend the module in order to run control checklist.
As an example: i create a checklist with all the due operation to perform a task, and reuse it every time i perform that task
(one could use clone module to clone the checklist to rescan, or simply reset it, or, maybe better, think of checklists as a replicable template).
Comments
#1
Question about how you would plan to use this.
Would you prefer to assign a checklist to a specific user rather than a role group?
I am considering changing how checklists work in order to accomplish this task, but want to find out people's thoughts. In fact, I'm considering developing a generic Usergroups API module that would allow the above to be accomplished along with other groups that must complete a checklist. Maybe this will be version 2.0 though to really allow this to work. I don't necessarily want to add a module dependency between an Alpha and Beta release, but at the same time hardly anyone is using this module anyways...Anyone have any thoughts on this?
#2
as an example, let's say i want to publish a website providing control checklists for drupal site builders (like SEO checklist module) for example:
- checklist describing the step to create a view in drupal
- checklist steps to perform before going live,
- and so on.
When i start a new project i can select the checklists i need and assemble it in a new macrolist.
In this way I assign the needed checklist to myself, as a whole.
When i check all the items in a list, just nothing happen. I simply have performed the task.
If i work on 2 projects at the same time, which need the same checklist as part of the process i can use 2 different instances of the same checklist.
This is the example case, but i suppose the only thing I'm requesting to this module is that i can decide a checklist is not connected to anything, just a plain checklist i can save the state during the process.
my english fails a bit, hope I explained well
#3
Just to verify I understand:
- You want to create base checklists. These are not checklists that people actually complete - more like a template of a checklist.
- You then want to be able to create an instance of a checklist. An instance would be the checklist that you complete.
- A checklist could be completed multiple times if you create multiple instances of it.
- A checklist instance is completed by a single person, in your case you, but you could create a different instance to be completed by someone else.
- A checklist instance is connected to you, or to some group of people, that is trying to complete it (I realize you said that it isn't connected to anything, but I'd like to be able to build this in a way to allow checklists to keep the functionality where it is assigned to a user or multiple users). So basically, it's assigned to some group (and maybe that is just you) to complete.
Based off of the above, the backend code changes I plan to make for version 2.0 (D7 only):
- Current checklist_lists table will become the table that holds the checklist bases.
- Need a new table to hold instances of a checklist (checklist_instances). Several of the fields will be moved out of the checklist_lists table to this table (message, rid_on_complete, first_uid).
- When creating an instance, you can select if every person in the group it is assigned to must complete their own, or if they're all working together to complete the instance.
- checklist_user_checks will get a new foreign key that references the instance that the item is completed for.
- checklist_complete will change from referring to checklist_lists.clid to checklist_instances.instance_id
- checklist_roles will become checklist_groups. Similar to checklist_complete, it will have a foreign key to instance_id instead of clid.
- checklist_roles will interface with usergroups api so that checklist instances can continue to be completed by users with certain roles, but also so that a specific user can be assigned the checklist.
In a later release (I'll create a separate issue once I've completed the above):
- When an administrator sets up a base checklist, they can say that users can create instances of the base checklist to complete. In this way, any user will be able to subscribe/sign up for any checklist.
Lots of work but I think it will make checklists really powerful as well. Not sure about the views integration...going to be a nightmare I suspect :)
#4
Yes, you understood what I meant.
And actually you are right: I don't whether a checklist is assigned or not.
#5
A question: will checklist be nodes?
Maybe a system like the one of webform module could be simpler to implement and manage
#6
No plan to make checklist nodes for right now. In fact, making a checklist a node is the old way of doing things. It's actually recommended not to make things nodes like that. Instead, entities should be used (obviously starting from D7). Maybe at some point I'll look at making checklist entities. While I haven't looked through the entire webform module, the way the handle things on the backend is fairly similar to checklist, except they use nodes.
#7
Version 2.x is going to have this functionality. The current dev version should be working. Note that there is a new dependency that you need to download and install before upgrading: http://drupal.org/project/usergroups_api
#8
thank you very much!
I'm on anhother project now, i'll test it next monday and let you know
Simone