Dynamic User Documents with Versions

[Jim Bailie]

Hello All,

I would like to accomplish this the PW way, but again, I'm struggling conceptually and don't want to burn days experimenting.

So now the people signing the checks want users to be able generate dynamic documents. There are 50-70 documents to chose from and they all will have between 5 and 40 fields...and they need to create multiple versions of each document...repeatedly.

• /john/2019/6/28/tpr-report/v1/
• /john/2019/6/28/tpr-report/v2/
• /john/2019/6/28/tpr-report/final/
• /john/2019/6/28/stfu-report/v1/
• /john/2019/6/30/stfu-report/v2/
• /john/2019/6/30/stfu-report/final/
• /mary/2019/6/29/wth-summation/final/
• /mary/2019/6/29/tpr-report/v1/

What I do know is that I will need ProFields and will be purchasing that. I also know that the reports will need to be their own templates...but the dates and the versioning are the problem for me.

Thank you in advance for any guidance!

P.S. Would one of the blogging modules be a good fit?

[horst]

Not sure about the blogging modules, as I don‘t know them. 

For me this looks like a good fit for urlsegments. Look up the API docs for it, I‘m on mobile.  

Using this, each of your docs template additionally need a date field, if the user should be able to specify the version date manually. If it should be assigned in an automated way, you can use the page creation_date, (or modified one). 

 

[monchu]

I'm not sure your questions, though.

For dynamic documents such as tickets, enquiries etc, I always use this format for page name to make it easier:

date("ymd-His")."-".$user->id."-"custom-name or updated version

it will avoid a clash page names and easy to find them for future use.

[Jim Bailie]

@horst Url segments look like they're pretty easy to manage and a date and date-created field will serve as an index so to speak.

@monchu Yes! I think a single, uniform, parse-able url segment is the best approach. I know the client wants the urls to look like what's in the initial post, but that seems hokey to me.

Now here's a follow-up question: 50+ document templates with 5-40 fields each is going to add up to A LOT of fields...even if a good handful of them will be shared.

Does ProFields offer a way to "consolidate" these fields without adding too many tables to the DB? It seems like it would...

[horst]

1 hour ago, Jim Bailie said:

Does ProFields offer a way to "consolidate" these fields without adding too many tables to the DB? It seems like it would...

Yes it does. For example I often use the Textareas ProField to collect a lot of small textpieces in separate inputfields, but it creates only a single table in DB. On the screenshot you see two db fields / tables, contact and map:

[Jim Bailie]

@horst Yeah, I just went and reread the ProFields page which I should have done earlier.

I'll probably need to resurrect this thread later, but I think I have enough of plan now to start experimenting. Thanks again for the reinforcement!

[gmclelland]

I think RobinS is doing something similar to your project.  You may want to read how he is going about it.