Here My scenario, Developers and Testers are part of the Project but only Developers should have rights to download Source Code from the web client whereas Testers should not have rights to download Source Code from the Web client. I checked with Access Control but I didn't get any idea regarding to the scenario. Please suggest some ideas to My scenario.
Regards / Kiran
You can start checking out "Controlling access to source control artifacts in Rational Team Concert".
It does list for instance "Read protect some files or folders within a component but give public access to others", which could fit your requirements.
Drill down and find the sensitive file or folder.
Select Change Access Control from the context menu
In the resulting dialog, select the Project area or team area option, click Browse and then select the private JUnit Project. Click OK.
The visibility of the file is now dictated by the JUnit Project so only members of that project can see the file.
A better solution is to assign those who are not developers, a contributor license. That provides read only access to all source operations. If you want to remove the link from the web client, you can create a custom theme and add that to the server. This would require working with the HTML/CSS/JS.
Related
I am using Eclipse in combination with the ABAP Development Tools (ADT) as main plugin for SAP-development.
Now I created some additional templates (View: Templates) and I just want to know where they are stored as I lost some of the templates and I want to check if I can find them in a backup somewhere (on file structure level).
Are the (additional created) templates as well stored in the workspace? Eclipse/ADT deliver also some basic templates, where are they stored?
Thank you for helping me to find the correct folder/file where this information is stored.
I am currently building an application which will allow mini-plugins to aid the use of my application. It is a lot like Slack, allowing user-contributed, custom plugins to aid the user. These plugins will be Swift classes. I will be setting up a system where users can submit their custom plugins to be hosted on a webpage. Users in my application will be able to select a few of these plugins that they need, and the application would import those plugins only, and add the classes containing the plugins to a top-level file so that everything in my application can use these plugin classes. How can I import these selected modules into my application files?
For example, if I have a variable webpageURLContainingPlugin, then is there anything that will allow me to import the class/module at that link?
Also, I wouldn't want to download all those plugins when creating my XCode project, as I feel it would take too much unnecessary space to store all of the possible plugins, whereas a user may only choose upto five of those to use.
If it is not possible to import a file from the internet containing these modules, please can you suggest a workaround to this issue?
Edit: I am not looking for a way to create the plugin architecture, and I have an idea of how I'd like to do that, my question is more about accessing Plugins hosted online on a webpage and putting it onto my top level files so I can access them. However, if there is a specific plugin architecture that I must follow to be able to do this, then please suggest it.
You can't. IAPs might be an option worth exploring.
AppStore review guidelines
2. Performance > 2.5 Software Requirements
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other apps. Apps designed to teach, develop, or test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
In MS Dynamics CRM how do we register a plugin or a workflow as part of a solution? whatever i register through registration tool, just goes to the root solution of the system.
Expanding on what #Henrik said, the process would be as follows.
For the sake of this example, let's assume you have a single assembly (dll) with two plugins and each needs two steps.
Register the assembly as usual with the Plugin Registration Tool.
For each of the two plugins, register the two steps they require. This should leave you with four in total.
Leave the Plugin Registration Tool and go to your solution in CRM. You will see two sections there: Plug-in Assemblies and Sdk Message Processing Steps.
You will need both of these to fully register a plugin with your solution.
Go to the Plug-in Assemblies section and use the Add Existing button. This will bring up a standard lookup dialogue that will let you select your assembly. Add it.
Next, go to the Sdk Message Processing Steps section and use the Add Existing button to add any plugin steps you want as part of the solution.
That's it. Your assembly, plugins, and steps are now part of the solution. Any step images that may exist are automatically added as part of the step so no need to worry about them.
One caveat though is that assemblies must be stored in the database and not as files for this to properly work. There is no specific limitation on sandboxed plugins (unless deploying to CRM Online) but using those would simplify solution deployment.
Finally, this walkthrough which was taken from the How To button in a solution.
Walkthrough: Register a plug-in using the plug-in registration tool
As for workflows, they need to be added in the Processes section of a solution. This section will cover workflows, dialogs, business process flows, and actions. As before, use the Add Existing button.
There is no direct support for adding plugin assemblies or plugin steps to solutions when registering with the Plug-in Registration Tool.
Your plugin steps and assemblies will always be present in the layer of unmanaged customizations ("root solution").
You can use the Plug-in Registration Tool as usual and only later manually add your assembly and steps to the relevant solution(s).
Since Access 2013 is not any longer offering direct source control compatibility: how is your workflow to integrate a source code control into MS Access, especially TFS?
Edit: workflow of access2013 -> ANY source code system appreciated
First thing I think of is exporting all objects into Text Files withe the builtin function SaveAsText which is available for almost every item in your database.
Application.SaveAsText acModule, d.Name, sExportLocation & "Module_" & d.Name & ".txt"
I would load, save and maybe even check the plain files in with VBA functions. The question is: is there a better workflow for this task... I really doubt that this is the best way to integrate Access 2013 projects in Sorce control.
I heard of OASIS SVN but I think this is basically the same mechanism I would use.
Please tell me how you manage your access projects
I use OASIS-SVN here to export all objects in my access database file to be text files.
I then use git, souretree, etc...
It has worked well for me and has a number of settings that are useful (eg you can choose to export data, to export table links etc)
It is not ideal, but is manageable and better than nothing!
As you might expect, I use a git project and separate local directory for every access file.
Another option that is recently on the market can be found here "entAscc" now known as Ivercy!
This looks very promising as the source control is integrated into the development environment. I've not used it, but would like to!
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 :)