Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
How can we keep content current?
System
We are looking to implement an automated system where TeamSite can send out email notififications to the designated content contributor after a certain period of time, based on when the file was last modified. Our purpose is to maintain currency of the content. Would this be possible? If so, how? I was thinking that the Metatagger can be involved to designate the contributor. I also thought that maybe the "Last Modified" field can be extracted and be used as a trigger.
Here's a scenario we would like to see: TeamSite periodically scans the whole workarea, maybe at the end of each day, to see which files have not been modified for, say, 6 months or a year (it can be arbitrarily chosen - maybe it's something we can attach to the document via MetaTagger as well) by comparing the "Last Modified" date with the system date, which should be today's date. TeamSite would then send out an email to the doc contributor, extracted from the metatag attached to it. The owner would have to reply, say within a day or so, choosing to say that the file does not need to be updated, or update as necessary, then kick off a review workflow after that. If no response is received, the branch admin gets notified to take proper action.
We already have a review workflow in place that does send out email notifications, but they are triggered only from the workflow.
I'd really appreciate it if anyone has any ideas on how this can be implemented. Thank you.
Find more posts tagged with
Comments
Migrateduser
You're opening a big can of worms. So let's say the contributor replies that they don't need to update a particular file that hasn't been updated in the past year. Will he get another email the next night as well? And the next night? Also, what if the same person owns 100 files that haven't been updated in the past year. Will they get 100 emails? I'm sure there are more issues, but those jumped out at me.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
You're right. Maybe using the "Last Modified" field might not be a good idea. Maybe a date metatag can be implemented then. Compare it against system date, then reset it to current date after a reply is received. Implementing that would be another thing, but if possible, it's something we can look at.
Or, what if, by replying that it does not need to be updated, "Last Modified" gets updated as if triggered by a file import or an upload? Then the "Modified By" field would have to be updated as well, in case someone other than the owner has modified the file previously.
As for the user receiving 100 emails at one time, it's a possibility, but our group thinks that would be more an exception than the norm. 20 to 30 max might be more of an average in one time. Plus, management views it as a better solution than manually browsing through the site and kicking off workflows manually.
You've raised really valid issues to think about. Thank you.
Migrateduser
As for the user receiving 100 emails at one time, it's a possibility, but our group thinks that would be more an exception than the norm. 20 to 30 max might be more of an average in one time. Plus, management views it as a better solution than manually browsing through the site and kicking off workflows manually.
What might be better would be to keep a hash with the keys being the users who are owners of the files you found and the values being an array of filenames. Then you can send one email to each owner and list all the filenames they need to check on.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
My recommendation would be to create a cron job or scheduled task (depending on your OS) to run a Perl script which goes through and checks the last modified date (either as a metatag or other). I would generate a database (either a relational database or XML or other) of files that need to be modified and who owns them. Then I'd create email notifications to anyone who owns files that need to be modified. I'd list all of the files that they own that need to be modified and give them a link to a CGI which gives them the option to postpone updating the file or put the file in a workflow for immediate update. If they choose to postpone, I'd give them the option of choosing how long to postpone and then update the metadata (last modified) with that info.
Having never implemented this solution, I'm not sure what kinds of pitfalls you'll run into, but this seems like a fairly flexible solution which doesn't require the users to receive 20+ emails per day. Instead it's just one email with all files listed in it and a link to a CGI which gives them the option to do stuff with those files. The CGI would read from the database or XML file to display all of the files that they are assigned to update. Kicking off the workflow with the appropriate files attached might be the hardest part to figure out on this solution. But I know that's possible so the whole solution should be feasible.
Any thoughts? Comments? Awestruck at my brilliance? hehehe
- Jason
Adam Stoller
It sounds like you (amolivar) already have MetaTagger, do you also already have/use DataDeploy / DAS ?
If you're using DAS - you can do a bit more automation of what jmeyer503 was suggesting - which is you can push the contributor name, the last-modified date and something like a "review-by" date (or some such term) and of course the filename / vpath to the DB every time the file is modified -- this would happen on a file-by-file basis as they are modified.
Alternatively (and perhaps better) automate part of this with workflow so that whenever a file is modified and the review-by-date is in the past, re-set the review-by-date to the current date + some-period-of-time (hmm, I can see some logic issues that still need to be worked out - but I think this is generally in the right direction)
Then a nightly (or weekly or monthly) process that performs a query on the DB to extract the information, sort it according to user and send out the email with the list of all files needing to be [or soon needing to be] reviewed.
I like the idea of having the email provide a URL to a CGI that would facilitate the review process - but failing that, CCI URL's for each of the files could also be used.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
You have some really good ideas there. It's not something we currently have set up. I do know that we have configured the OD engine to scan the Staging area on a daily basis to see which files have been modified from the previous edition, cut a new edition, and deploy them out to the production server. Maybe it's something we can take advantage of as well, using that script to scan and look for the files' "date" metatag.
We're all in some sort of brainstorming phase, and I really appreciate your input. Thank you.
Migrateduser
Thanks, ghoti. Not sure if we have DataDeploy / DAS. We only have OpenDeploy, as far as I know.
I can see how CCI URL's can be implemented. Not quite clear yet with the URL to CGI option.
Setting up the automation within the workflow and the periodic query on the DB is something we'd have to look into. But it looks like we may need to have DataDeploy in place before we can do something with it.
Again, thanks for your input.
Migrateduser
I like Ghoti's idea in theory. However, I've found that writing to a database (even with DD) can be time consuming and ends up making the deployment workflow take significantly longer than it would have. I think that updating the database with each deployment is probably overkill especially if there are a large amount of jobs per day. If there's only a few jobs per day, it might be a good trade-off to have the database updated with each file deployment.
I don't think it's necessary to have Data Deploy to get this to work. You can use Perl DBI which actually gives a bit more flexibility as far as logging the results. Also it has a lower learning curve (if you already know Perl) and can call any SQL statement or stored procedure.
As for the CGI, I envision it like this:
User gets a URL -
http://IWOVSERVER/iw-bin/theCGI.cgi?uid=userID
If you need more security to make sure that other users don't access eachother's CGI, you may want to implement a password or authenticate against a domain or something like that.
The CGI will read in the userID and will compile a list of files that need to be updated (from the Database) that are assigned to that user. Then it will display back the files. The rest of this is just brainstorming: Each file will have 2 radio buttons next to it. The radio buttons will be to postpone or update now. For the files they choose to postpone, they will be asked for how long they want to postpone updating them. For the ones that are going to be updated now, they can be put into individual workflow jobs or grouped together in one job which would be assigned to that user.
Hope that makes it a little more clear. It's a big undertaking. But it's definately a good idea and is absolutely doable.
- Jason
Migrateduser
You used to get a copy of DD with OD and with TeamSite, so you may have a copy, even it if's not installed. You might want to check into that.
lissa
JonathonG
Well, I know I'm a little late to the game, but here's an idea that builds somewhat on some of the other ideas, but goes in a slightly different direction:
1) Give every file a "Last Updated" and an "Owner" metadata
2) Create a cron job that nightly (or whatever frequency) scans through the workarea looking for files whose "Last Updated" date is too old, and where the file is not currently attached to a workflow.
3) For each file, kick off a workflow programmatically. This workflow would email the owner, then assign a task to that owner with the file attached.
4) The owner then *must*, at a minimum, update the "Last Updated" metadata (maybe via a CGI task in the workflow?)
5) The workflow continues with the review cycle.
The nice thing about this is that the idea of "I don't need to change it" gets reviewed by someone. You could also institute a timeout on the usertask that would bump the task on to the branch admin.
One place to think about would be at step 3. Do you want an individual workflow for each file, or a workflow that captures all the files for a given owner? I debated which way to put it in this post. I chose the way I went because I could envision scenarios where a user may be ready to work on 1 of the files, but not all of them.
To my way of thinking, this involves the least number of "moving parts", i.e. custom scripts/DBs/etc. Of course, I could be missing something obvious...other thoughts?
Jonathon
Independent Interwoven Contractor
Migrateduser
Thanks. Found out that we do have a copy of DD, but it was just installed in our development server, not the production server.
Migrateduser
Thanks for the reply. As for the debate of 1 file per email vs. multiple files per email, it might be a good idea to just have one email with multiple files and give the user the option to acknowledge that a certain file does not need to be updated for now. Then maybe, tie each file to a tag? CCI URL to bring up the MetaTagger GUI so they can at least update the "Last Updated" tag.
Speaking of CCI, I started testing it out, specifically, the edit? CCI. For the most part, it works. It downloads the file and open it in the default editor. For example, if I click on a CCI URL for a .doc file, it downloads the file from the TeamSite server and opens it up in Word. The thing is, it also opens it up in an IE browser, as if I clicked on it via a hyperlink. It's not really a problem, but more of an annoyance. I'm sure we can tell the users to ignore that IE browser. Is there a way to fix this? Essentially, this is what the link looks like:
"
http://[servername]/iw/webdesk/edit?vpath=/default/main/[path
to the file]"
It's essentially straight out of the Tech Notes. So, am I missing anything here?
One problem I also noticed is that, even though I'm logged out, it would still download and open up the file as if I'm logged in. It does look like it takes awhile before it asks me to log back in. I guess there's a different session still going after I log out? I partially solved this particular problem by replacing the ip address with the server name. It at least asks me to log in to get to the "read-only" version of the file, but it still downloads the file anyway.
FYI, we're still using TS 5.5.2. Any help would be appreciated. Thanks.
Migrateduser
just a thought, instead of using e-mail you could instead set up an NNTP server and have the list of non-modified files be posted there, along with some kind of file<->ownership matrix. this is a total tangent, so apologies if it's not totally feasible, but the benefit would be in terms of usability. there's not much point going to all this trouble unless it's going to result in somebody actually doing something about these files at some point in time. if ppl are getting an update of files which nobody has done anything about for a long time every single day, it's likely to become something they don't think about, just part of the ever-growing backlog, whereas if there's a centrally located knowledge base tagged with who's responsible for what, it might be easier to direct people to that knowledge base and get them to use it. after all you want all this effort you're putting in to go to something more than just a batch of intracorporate spam, right?
hth...
