 |
|
|
Joined: 7/8/2008
Posts: 20
|
|
|
Jerry Andersen wrote
And last, if you are going to allow users to add modules to your site, which I don't really think you want to because you want a workflow process, I would use this module...I like it better than the TRT one, which I tried but didn't have any luck with. You can find it here: http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=7994
These are just suggestions so I hope this helps
Jerry
Thanks for the suggestions, Jerry. They are good solutions if I did not need to keep track of changes. Basically, what I need is something like Engage Publish, but extends to ANY module installed on the system, regardless. Why? If a mistake was made on the site, even if it was spelling, for example, I could trace back who made the change and let them know a mistake was made and ask them to repair it. Otherwise, you're staring at the faces of a crowd of people who are daily making chnages to the site, with no-one admitting who did it. In a corporate environment, this is important. Changes made to a large coporate site can do major damage to a company's credability. It also reflects poorly on their attention to quality assurance. These are the kinds of answers CEO's and CTO's want the answers too when something hits the fan on their website. DNN has nothing in place that indicates who created the content, who approved it, and who published it.
|
| |
|
|
 | |
|
|
Joined: 7/16/2006
Posts: 230
|
|
|
canamguy wrote
Jerry Andersen wrote
And last, if you are going to allow users to add modules to your site, which I don't really think you want to because you want a workflow process, I would use this module...I like it better than the TRT one, which I tried but didn't have any luck with. You can find it here: http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=7994
These are just suggestions so I hope this helps
Jerry
|
Thanks for the suggestions, Jerry. They are good solutions if I did not need to keep track of changes. Basically, what I need is something like Engage Publish, but extends to ANY module installed on the system, regardless. Why? If a mistake was made on the site, even if it was spelling, for example, I could trace back who made the change and let them know a mistake was made and ask them to repair it. Otherwise, you're staring at the faces of a crowd of people who are daily making chnages to the site, with no-one admitting who did it. In a corporate environment, this is important. Changes made to a large coporate site can do major damage to a company's credability. It also reflects poorly on their attention to quality assurance. These are the kinds of answers CEO's and CTO's want the answers too when something hits the fan on their website. DNN has nothing in place that indicates who created the content, who approved it, and who published it.
As some one already mentioned, Enterprise forms may be a solution to your worflow problem. As I see Enterprise forms has the best workflow engine than any other modules available in the community. Not only that you are not limited to just the standard approval process (Create --> Approve --> Publish) you are essentially able to create any type of workflow required.
With that said, Enterprise forms has feature called Workflow Processing, a type of plugin/exension which could be created external to the Enterprise forms application. I think there are two Workflow Processing plugins that are included with the distribution and is relevant to this topic; Text/HTML Workflow Enabler and Announcement Workflow Enabler. Both of these extensions are used to enable workflow capabilities to the two core DNN modules; Text/HTML and Announcements modules (). In a sense you are still able to utilize the core modules but if you want to enable workflow in content editing you can certainly do so with Enterprise forms.
|
| |
|
|
| |
|
|
Joined: 9/3/2004
Posts: 2185
|
|
|
canamguy wrote
Thanks for the suggestions, Jerry. They are good solutions if I did not need to keep track of changes. Basically, what I need is something like Engage Publish, but extends to ANY module installed on the system, regardless. Why? If a mistake was made on the site, even if it was spelling, for example, I could trace back who made the change and let them know a mistake was made and ask them to repair it. Otherwise, you're staring at the faces of a crowd of people who are daily making chnages to the site, with no-one admitting who did it. In a corporate environment, this is important. Changes made to a large coporate site can do major damage to a company's credability. It also reflects poorly on their attention to quality assurance. These are the kinds of answers CEO's and CTO's want the answers too when something hits the fan on their website. DNN has nothing in place that indicates who created the content, who approved it, and who published it.
This is really getting well outside the scope of DNN. At the level of Administration and page editing, DNN is an application framework, not a productivity tool. DNN also doesn't contain tools for creating or recording workflow procedures. The correct way to use DNN is as a framework for managing the display and security of modules.
Your office staff should only ever be granted module edit or content submission permissions on any module. Plenty of modules provide authoring and approval workflow at that level. The modules are where the workflow lies and the module edit permissions are provided for the purpose. Granted, many modules don't abide fully as I've previously mentioned.
Also, workflow in a business is something that has to be supported and regulated by policy and procedure. One cannot rely on every application recording every step in order to avoid proper policy. If there is a need to police the publication of web content then that is a simple thing to do using a policy, a procedure and permissions. If the person adding the FAQ module to the page is not permitted to publish it live without approval then don't let them. If your publishers are required to track changes and get approval, then make them. DNN can help, but it is not a ready-made publishing process.
Rob
|
| |
|
|
| |
|
|
 |
Joined: 12/16/2005
Posts: 218
|
|
|
canamguy wrote
ROBAX,
You are moving along the right tracke here. The only thing that I could add to your analysis is the requirement of logging changes. ALmost EVERYWHERE I have come accross providers of DotNetNuke services and software, I have also found that they're list of clientele stops short of large/corporate sized businesses. DotNetNuke for small busness, or personal users has no need to keep track of when things change on their site. If I might be so bold, many of these service providers consider my requests to keep a log of changes made, or recognize 'versioning' has an absolute needs as 'over-the-top'. This has been frustrating to put it mildly. At it tells me that every answer I get from a DNN professional that sounds like that, tells me this person has never worked in a coporate environment.
I'm going to go out on a limb and say that 80-85% of corporate requirements would ask for versioning and change control. And within that change control, a need to pull up a logged history of changes made to EVERY little think done to the site. I feel like unless DNN, or some other company, addresses this issue, I fear they will never be recognized as a legitimate solution for large clients.
Your suggestions for test is a step in the right direction, but it will not allow one to properly view things like status. A change either happens, or it doesn't. Typical workflow tends to operate in the fashion of:
Content Creation/Edit --> Content Approval --> Content Publish
Engage does this part well, but it assumes it is the ONLY module you will use. That module is used only for Text/HTML.
I guess herein lies the rub. To enable workflow DNN-wide, one would have to modify every single existing module to work under one system. Or else new modules would have to be create, then substituting for the ones in DNN so that they could understand the rules of workflow defined by the workflow piece. Huge job, but sure to make a mint for the first company to tackle it, and as a result, propel DNN to a new level of customer.
I would like to add that the Arcie WorkFlow module does keep track of changes and who made them if this helps you determine the next steps you should make. However it does not allow you to roll back to a previous version. But I think they are working on that on the next release.
|
| |
|
|
| |
|
|
|
Joined: 12/16/2005
Posts: 218
|
|
|
canamguy wrote
Jerry Andersen wrote
And last, if you are going to allow users to add modules to your site, which I don't really think you want to because you want a workflow process, I would use this module...I like it better than the TRT one, which I tried but didn't have any luck with. You can find it here: http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=7994
These are just suggestions so I hope this helps
Jerry
|
Thanks for the suggestions, Jerry. They are good solutions if I did not need to keep track of changes. Basically, what I need is something like Engage Publish, but extends to ANY module installed on the system, regardless. Why? If a mistake was made on the site, even if it was spelling, for example, I could trace back who made the change and let them know a mistake was made and ask them to repair it. Otherwise, you're staring at the faces of a crowd of people who are daily making chnages to the site, with no-one admitting who did it. In a corporate environment, this is important. Changes made to a large coporate site can do major damage to a company's credability. It also reflects poorly on their attention to quality assurance. These are the kinds of answers CEO's and CTO's want the answers too when something hits the fan on their website. DNN has nothing in place that indicates who created the content, who approved it, and who published it.
I agree with you and it's too bad DNN nor a third party publisher has really addressed this issue. Like Rob suggested, until DNN really address this issue, it may not be a real enterprise CMS contender. I don't want to sound like a cheerleader for arcie, but they do support up to 5 or more different modules and are planning to add more, but that announcement was made months ago, and I haven't seen any real progress on that...
Jerry
|
| |
|
|
| |