Hi Guys,
I have started a new project and I have a question around auto-population of a table.
The broad outline of the project :
This CPT will be viewed as a pod for an argument for this question. Every pod will have "many" clients (table) split into three categories (Table) ie Level 1, level 2 level 3.
For each level, you will need to submit a set of documents (table) annually.
Now the question when the new year is opened (table) we want the query to auto-populate the list of required documents depending on the status of the client's category. Ie If client us Level 1 the list of documents ie 6 Documents must auto-populate the outstanding documents table. Level 2 may have 10 Documents and level 3 may have 15. Each level will have overlapping documents ( ie not 100% unique list) In other words every level will have its own predefined list of documents.
I did a very basic schematic on excel that I included as an image to show the relationship of the applicable tables
Hi, the word "table" is a bit confusing here because it can mean different things, like a database table or a visual display of content in rows and columns. So let me restate your description as I understand it, and please correct me if I'm wrong about these assumptions:
- You want to have a custom post type, which we will refer to as Pods.
- Clients (i.e. site Users) can be associated with one or more Pods.
- Each association between one Client and one Pod is assigned one of three "levels". In other words, Client A can be associated with Pod 1 in Level 1, but Client A can also be associated with Pod 2 in Level 2.
- Each Year, a Pod can be assigned a new set of associated documents, per Level.
- Each Document can be associated with one or more Pods, in one or more Level, during one or more years.
- When a Client visits the site, s/he should be able to view a list of their required documents per year, per Pod.
- A site administrator will manage documents in wp-admin.
Let me know if I'm understanding correctly.
Hi Christian, Thx for your reply. Ok table was referring to a database table. (old school ms access days).
You can take the pod out of the equation. What the pod more refers to is the fact that this will be a resellable system. and each one sold will be a pod. for ease of reference best is to leave the pod totaly out of the discussion.
Each client will only be linked on one pod/account. A client will either be a level 1 , 2 or three. Depending on level 1 2 or 3 a predetermined group of documents for each level will be required. when the new year's verification start the list of documents must then be populated so that the client can see which documents have been submitted. When a client submits the document ( upload via this cpt,) the status of the document must then change from outstanding to submitted. Once the document has been verified as correct, admin will then change the status to completed.
Maybe if i give you a bit of background it will make more sense what we are trying to achieve. I South Africa all companies that want to do business with more than just micro businesses you need to have what they call a BBBEE (broad-based black economic empowerment) score, this means you must comply with certain regulations the government has imposed on companies.
On an annual basis, you need to submit a certain set of documents to prove if you are compliant with the regulations to keep your BBBEE score. There are three levels of BBBEE compliance, each needing their own set of documents. Our clients are companies that assist these businesses in proving they are compliant with the requirements.
for reference in this setup our clients will be refered to as "clients" and our client's clients wil be "customers"
In light of this, Our clients are each a pod. ( own system not linked to each other) Our client need to load their clients on the system, open the new year outstanding documents for the current year (ie 2018) Their customer must then upload the documents that are then verified as correct and marked as completed. The customer can then see exactly which documents has been rejected, outstanding or completed.
Ie the above will basically be an online document tracking for our client's customers required documentation required to obtain or maintain their BBBEE status.
I hope this will clarify it a bit more.
Okay thanks, this is fairly complex app and I can only give you some general advice based on the description you provided. Toolset doesn't include a built-in document upload and verification workflow like this, and I think it will likely require a significant amount of custom code to get it just right depending on the customization level and requirements. I've noted those custom code requirements below.
1. Create a custom field on User profiles. This field will be used to set the User Level, so use a select field or a radio button with 3 options. When your client sets up customers as Users in the site, s/he will select the appropriate level for each User.
2. Create a custom post type called "Submissions". This post type should include one custom file upload field, and one radio button field with 3 options: Pending Review, Rejected, and Completed. Each time a User uploads a file a new Submission post will be created. (optional: add custom code that sets the Submission post title based on the required document and User name)
3. Create a custom post type called "Requirements". A Requirement post should be created by the Admin for each required document. Add a custom field to capture the requirement Year, and add a checkboxes group field that represents each User Level. Before the Year starts, an Admin will add each requirement post, select the appropriate year, and select the appropriate Level checkboxes.
4. Create a View of Requirements, filtered by Year and by Level. Display this View of Requirements to each User so they can see each required document for the current Year and their specified level.
5. Set up a many-to-many post relationship between Submissions and Requirements.
6. Create a Form that creates new Submission posts. Set the status custom field default to Pending Review. Remove the status radio button from the Form so it only includes the file upload field.
7. Create links that direct to the page containing the New Submission Form, and add those links to the View of Requirements (step 4). Set up a URL parameter to pass the Requirement ID into the new Submission Form. Use the Forms API and Post Relationships API to automatically connect the new Submission to the corresponding Requirement. *custom code is required here*
8. Create a View of Submissions filtered by post author (the current User) and filtered by related Requirement (set the current post in the loop). Show the status of each Submission by including the status field in the View loop.
9. Place this View inside the View of Requirements (step 4) so each User can see the Submissions they have created for each Requirement.
10. Move your "add new submission" link into the "No results found" section of the View of Submissions. This can be the indication that this required document is outstanding.
11. Add email notifications as needed to the New Submission Form (step 6) so Admins are notified when a Submission is available for review.
12. Add workflow for the Admin to approve or reject the submission. You can use Forms to handle this on the front-end of the site and trigger automatic notifications to the Submission author, or you can let the Admin handle this manually in wp-admin somehow.
We're barely scratching the surface here, but it's a general idea of what might be required in Toolset. As more and more customization is added, more and more custom code will probably be required. For example, calculations are not built in to Toolset so if you wanted to create a report-style View of how many outstanding documents a specific Client has for the current year, it would require custom PHP code. Similarly, if you want to add file upload validation specs for each required document, that could require custom code.
As you can see, this is a complex project that cannot be easily explained in a single ticket. If you have questions about any specific process I've mentioned here, we can discuss in more detail in a separate ticket.
Christian,
wow thx a million for this detailed breakdown this has now given me a much more comprehensive overview of the approach! Much appreciated.
Coming back to my original question, With regards to the auto-population of the required document db table from the "Level" table when a new year is opened. How would I go about achieving this?
In my example, the site admin creates Requirement posts at any time and chooses a single Year (a custom field) for each Requirement. On the front-end of the site, your Users see a list (a View) of required documents. This View is filtered by the Level of the current User, and also filtered by the Requirement Year custom field. The filter can be configured to show "this year" according to whatever the current year is, or it can be set manually by the site admin to show only 2018 or only 2019, or it can be chosen on the front-end by the site Visitor like a custom search field.
So it depends on how you want to manage the switch to a new year. The dynamic "this year" approach would require no manual intervention to switch the display to a new year of requirements, it's automated based on the current date. It may require a custom code snippet to produce the current Year in a shortcode attribute. I have such a custom shortcode available if you need it: https://toolset.com/forums/topic/trying-to-display-the-current-month
The format in your case would be %Y, to get the four-digit current year.
Thx Christian,
Ok, I will work on it and shout again if I need assistance. I am going to leave the ticket open for now just until I have managed to get it done! Thx once again for your assistance!
I'll stand by for your update.
