I need support with the usage of Google Docs: I want all the docs every employee in our agency creates be uniform in terms of font and headline settings. We are working with templates in our google workspace, but the default way people open new docs is not the template.
They just open a new doc and it's understandable because that's one click less. So it would be great if the general docs setting could be set once and are valid for all the users… Any expertise here in the group? Thx, Timm
I am afraid it is not possible at the moment. The Google Docs default settings cannot be changed in any possible way. Using templates would be the best option so that your users can just create a copy of the documents and keep working on the copies.
What you can do to make it easier for them to open the templates is to create bookmarks on their browser (only works in Chrome) so that they have a bookmarks folder with all the templates on it, so it is easier for them to access everything. For this you can use this Chrome policy in the Admin console to add control the managed bookmarks folder.
Related
I'm working on a Liferay portal instance that has generated some 60000 sites/communities. These communities are already in use. We've built up a theme for the portal, and we're trying to deploy it to ALL communities within the portal. We've already tested it on a few communities manually, and of course, we've already set the default theme via control panel, but there;'s got to be a smarter way to make the switchover than manually swapping 60000 sites.
Any ideas? I'll mention: I'm not a Liferay expert, and I don't have a lot of access to the innards of this environment, so I'm hoping the solution doesn't involve writing a new portlet or something.
You will definitely require to create a utility(portlet/hook) based on, when you want to apply the theme, at the time of deployment or through some button click.
You need to use LayoutSetLocalServiceUtil to perform that, if you want to apply theme to all pages of each community/sites.
Thanks,
Ankit
I'm looking to use Redmine for document management. I know that Redmine is not ideal for this task but there is already a lot of content on the site so I'd like to utilize it if possible.
Redmine currently does not a have great documents module. The files we've uploaded look to be amended on that specific page and it doesn't seem to be able to move to another page (unless you download and re-upload to the proper page).
Idea 1
I see there is a Files section, which could work as a central repository (and you can upload document based on release) however, is there a way to set up a nice-looking 'front-end' page that automatically updates based on new submissions to the Files tab? I envision this front end to be a simple wiki page with the document name, a short description and a links to the file posted in the Files tab.
There are so many documents uploaded to varying pages on the Redmine site. I would only do the whole download and re-upload of files if there was a way to automatically update the 'front end' wiki.
Idea 2
I see there is a DMSF plugin for Redmine. Has anyone used this before and has is solved document management issues? I'd like to hear your feedback. Even if DMSF doesn't totally solve my issue, anything is better than what I have now.
Thanks!
In my opinion DMSF module is a perfect companion for Redmine. We have adopted it in our company. You can easily deal with document versions, webdav access, custom approval workflow, document modifications notification with the extra value of being well integrated with Redmine features (roles, dynamic links in Wiki and issue text and notes).
Ok,
So about a year ago (I think) google went through a transition where they made Google Apps accounts "real" so we could use them in places like the Chrome Web Store. Unfortunately, prior to that happening I had written some extensions that were under the now conflicting account. So, now what I've got is a two accounts where the old extensions are under this conflicting account and anything past that date is under the new account.
So, it is time to upgrade some of these (old extensions), what I'd like to do is move the extensions under the apps account in a way that doesn't cause problems for the users. Does anyone know a way? It seems like the only option is just to place the extensions under the new account and delete them under the old account, but then I think all of the users would have to know to install the new one.
Thoughts? Has someone gone through this process?
EDIT: As #artur-nowak pointed out in the comments it is now possible to transfer extensions between accounts using this form.
If only your extensions were hosted outside Chrome Web Store (CWS) it would be possible to solve this by modifying update_url in manifest.json (so that extensions will start to download updates from another source). But they are not, and CWS doesn't allow you to modify the update_url param. Because of that, I believe you have two options left:
wait for google to add 'change ownership' function in CWS
or add your extensions to CWS again as a desired user and update the old ones to display a popup/notification "please update" with a link to the new version. Users should be more eager to update if you include some new features to attract them. Also, it will be less annoying from them if config will be preserved. To achieve this, export settings to bookmarks panel (it will be easy to access them) and import them in the new version of extension when it's installed.
I'm creating a custom master page for my SharePoint 2010 publishing site. There are images, css files and js files associated with this custom master page. Where should they be stored?
I'm using the SiteAssets library for now - is this a good choice?
Thanks.
Yeah that is a good choice, also make sure you Provision all these files using Feature, this way upate of Files becomes easier.
In my opinion, you should store everything under the site collection libraries, this way you get:
Easy recovery in the cases you need to re-install the server[s]
Versioning and permissions on resources
Separation of resources between site collection
Simple deployment between environments, as you do not need to copy the files manually or design and deploy a feature to do it for you
The preferred place is of course Style Library, this is what it is intended for.
If you are creating and deploying your files through code, you can also use the _layouts directory to store your files. This makes it simpler to share files between site collections. Visual Studio 2010 makes it really simple to add a reference to the Images folder and any files will then be deployed to the _layouts/Images URL.
The only advantage of this is that a site collection administrator cannot make changes to these files, only someone with access to the physical server. (Although this can also be a disadvantage if your logos or images are changing regularly).
I usually store them in _catalogs/masterpage/ORGNAME/...
You can refer this blog for actual implementation
http://markviky.blogspot.com/2010/11/sharepoint-2010-web-content-management.html
-Vighnesh Bendre
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.