I am old DNN user, used versions 1.0 - 4.0 years ago. Now I'm coming back to version 7.xx, While I can see huge improvements they come with increased complexity and I have struggled to find definitive answer to the following question:
What is the best way to setup a documents management repository with private (current user only) & members only areas without using third party modules?
Versioning is not essential, but nice to have. The core requirement is the private & members only read only document access.
P.S. Might consider paid modules, but only if developed for DNN 7 from day one and with good support.
Maybe this not helps you, because I think you needs a specific module for the users can manage his own folder, but DNN7 creates a private folder for each user in /Portals/XX/Users/[UserId].
If this not convince you, you can go to Admin>FileManagement and create a folder with specific permisions. To do that:
Create New Folder
Right Click over the folder you just create and edit the permissions for that folder.
Related
Inherited a moodle project that never had any kind of VCS, with some plugins installed from third parties, and a few modules developed in-house.
Problem is, I want to update moodle, and can't just use a brand new copy, since in moodle custom code lies within the "moodle" directory.
In other CMS/frameworks, that code would be physically separated from the core code, and you could mostly update the core files by pulling from the appropriate repo, and checking out the approriate branch (with custom code living in a different repo, and third party code either living in that repo or managed as a dependency).
Is there a way to organize custom moodle development (or downloads from third parties) so it's easy to separate "core" code from installed modules/themes?
We're using the .git/info/exclude file and list there all plugins which are third-party or developed in-house.
However, Moodle has awesome documentations for handling plugins using git in general, check it out: https://docs.moodle.org/32/en/Git_for_Administrators
I'm not aware of a so smart (and elegant) way of separating custom code from a default Moodle instance, even with GIT.
In a custom Moodle instance you may have:
new plugins (self developed or from third parties). You can see the list of additional plugins here:
your_moodle_systemadmin/plugins.php?contribonly=1 (or here: Home->Site administration->Plugins->Plugins overview).
In case you want an upgraded version of Moodle, you install it somewhere and then install on it the list of additional plugins. I would suggest here to check if the plugins have a new available version and consider installing it.
Custom code (that is to say: someone made core changes on Moodle). I would here compare the old code with the new one, or, even better:
a) compare the old customized system (MoodleOld Cust.) with a brand original old system (MoodleOld orig.)
b) Track all the core differences in your MoodleOld Cust with some inline comments
c) Compare MoodleOld Cust with your new system and pay attention only on differences marked by you on MoodleOld Cust.
d) Try to report the customizations on your new system, if wanted and / or necessary.
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
I wish to create a document repository for my company. Reason is because my company have many documents and they did not have a version tracking in place. This means everyone is using different version all the time.
Plone is something new to me and i got to know from a good friend of mine. And too bad he is not around anymore to answer my question. I believed in him and i wish to materialize his idea, to use Plone as a document repository for my company.
I have install Plone and manage to view the default Plone page, add all company's username and change the logo to my company's logo. And now the biggest question is, how to setup the document repository? What i have in mind was to create a "page" for the user to add files, download files, search for files and read its description.
Any lead for me to go about?
Reusable,
Same problem here. We started to use Plone as our main DMS 4 weeks ago (inserting existing docs at present).
For working copies, we use iterate (insert plone.app.iterate under eggs in your buildout.cfg).
For versioning, Products.CMFEditions. I believe this worked out of the box.
For creating new workflow, look into plone.app.workflowmanager and read the docs.
In a previous question we asked, we were still looking at Dexterity which has alot going for it but eventually we decided on adapting an existing content type based on Archetypes.
As for inserting files, as long as the description is ok, they will be found through the in-built search functionality, but you might consider using Iterate mentioned above to make sure that nobody is using the same file twice.
As your new, as I am, the docs seem hard at first but are actually quite good.
And this book is still giving me the foundation we need to keep adding functionality.
Good luck
I think, you should get pretty far with vanilla Plone installation, without developing your own extensions or other customization add-on-products. Therefore, I'd recommend you to start with Plone 4 User Manual to find out everything you could do out-of-the box.
As #Speediro mentioned, versioning support comes built-in for the main content types (and you don't actually see CMFEditions mentioned anywhere), but it's not activated for file uploads. Although, as briefly mentioned in the manual: Content items can be configured to have versioning enabled/disabled through the Site Setup → Plone Configuration panel under "Types".
Working Copy Support (plone.app.iterate) should also be there already waiting for activation on Site Setup's add-ons-panel.
Yet, before the Plone Collective (=community) Developer Docs or Professional Plone 4 Development, I'd recommend Practical Plone 3. It has a bit outdated graphics (because it was made for Plone 3), but it's great next step after the user manual. E.g. how to define content rules to send e-mails notifications for content updates (still through the browser without coding). Or how to create custom forms using Products.PloneFormGen.
When you really need to write your own code, it'd be time for Professional Plone 4 and the Collective Docs.
If you can't have a developer to manage your stuff, I would recommand to stay on official Plone, no custom code and use only widly used addons.
I mean:
stay on the default theme (sunburst)
use the default plone content types
only customize the logo
activate plone.app.iterate in the addon controlpanel
do not play with workflow because they need to know what you are doing. by default a file has the visibility of it's folder. It mean if you can see the folder you will be able to see all files inside. You can just activate default worklfow for files under the ZMI.
Use collective.quickupload addon
Your database will going really fast to a huge size because Plone is doing indexing and indexing means lot's of spaces. So you will have to handle this as system adminstrator;
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.
We're still developing a bunch of our application in Clarion 6 Enterprise. I was wondering if anyone knows of a sourcecontrol system that works well with Clarion 6?
I'd be surprised if the standard source control systems weren't just fine, e.g., Subversion. Is there something special about Clarion 6 enterprise?
I believe Rick Martin has tools that allow Clarion to work with subversion and tortise version control systems. They allow you to export the changed procedures to TXA's and import the changes back into the application.
One of the things I like about his system is that when a procedure is checked back into the Source Control System his tools will build a current version of your product so you can verify that the changes don't create compile errors.
The tools are not for sale though. They come with your buying his consulting services.
You're free to rename the modules in Clarion - so you're not bound to the existing generated names.
However that's not the root problem. the root problem is that you don't want to be editing CLW and INC files, you want to be editing the APP file. Otherwise your changes will be lost when the app regenerates.
You can use Subversion, or any other system, with app files - they're just binary files. From a rollback point of view this is fine.
Unfortunately though when you checkout an app you get the whole app. So no one else on the team can work on any other procedures in the app at the same time. If your apps are small then this is no big deal, but if you have a single-app system, or a system comprising of large apps, then it can become a hindrance.
The other disadvantage is that, being a binary file, it's not possible for the version control to merge files together - it's an all-or-nothing situation.
You can also try TDC. It's more than just a VCS for Clarion because you also have a Tracking System.
By the way, TDC is written with Clarion.
Look on Rick Martin presentation it's very useful, but not for sale :(
http://www.clarionlive.com/images/stories/videos/webinar11.wmv