Mean.io - Best practice to extend User model - authentication

Mean.io comes with a built in user model within the user package. What is the best practice for extending that user model if I want to attach additional data to it?
My experience with Django had me creating a "profile" that had a foreign key pointing towards the user object it belonged to. I like this approach because I don't touch the user package that way. But is this a best practice? If this is, how can I ensure the creation of a profile doc at the creation of a user doc? If not, what is?

I'm not sure qm69's solution would be the best for future compatibility with mean. In the mean.io documentation http://learn.mean.io/ it states the developer shouldn't alter any core packages, including the user package.
The mean.io pattern is to implement any and all extensions as a custom package. And override default views using the $viewPathProvider.override method.
Secondly the User package is fundamentally a security/authentication feature and not a profile implementation which regularly receives updates. Altering this will most likely break future fixes and risk introducing security bugs.
My advice would be to implement a profile using means package system and add a service dependency for the User service. I've done this in previous projects and it works well.
To implement a profile package, follow the below steps:
1) Create a custom package called profile using mean package profile.
2) Implement model/view/control for all profile requirements in the custom package. DONT ALTER ANYTHING IN THE USER package.
2) Use dependency injection to include the Global service service. This will give you access to Global.user data so you most likely don't even need to use the User services.
3) Override any User views using the $override method mentioned in the above doco.
Hope this helps ;)

Related

How can i introduce my own permission in a plugin

I would like to write an plugin for the cockpit app. The feature i would like to add includes also an additional item in the drop-down menu. However i also would like to introduce my own permission. If the role of the user has the permission the item in menu will be shown otherwise not. Is this possible at all? And how does at look like? I checked the online documentation but couldn't find anything about it. I hope someone could help me...
The only way to introduce new permissions is through a microservice in its manifest. With purely UI you cannot add those.
As an alternative you could base your plugin on any property of the user. You probably would than want to have a second plugin to set/manage this for a user.

Where to put database Model for extensions?

I want to write a small extension that is able to take some informations from the database, based on some user filter preference, and show them on the main page.
I have read: PHPBB extensions development and took a look at: ACME DEMO extension but i didn't find an answer to where the database handling should be placed. Normally this should go into a Model that will handle the data to a Controller, in this case I was not able to figure out where the Model should be placed in to the structure and how it should work.
How should an extension database model should be handled? Where should it sit in to the extension structure?
I'm guessing you would need an event listener.
PHP event listeners work with core events to inject code into phpBB.
Core events are like hooks, and they can be found throughout phpBB’s
codebase at key points. They give your extension access to phpBB’s
variables and allow you to use and modify them or to inject additional
PHP code during phpBB’s execution. -per the Skeleton Extension
Page

Alfresco permissions depending on whether document is currently part of workflow or not

Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.

How to log searches in rails?

I'd like to keep a log of all searches that users do on my site which uses the sunspot-rails gem. I don't need the logs to be real-time accessible by my application as they're for analytics that will be processed later.
I'm thinking that I should do the logging in rails rather than in solr itself so that I have access to the entire session, but I'm not sure how to build that. Is there a standard method for this? I saw this question but I would think there would be something more generic than writing it all myself in ApplicationController.
The ultimate answer depends on howwhere you're implementing your search. If you have a single search controller, do the logging there. If you have a collection of search controllers, either do it in each one, or create a base class, do the filter/logging in the base class.
Can you provide any more details?

ecommerce using stripes

We have planned to start an e commerce project using Stripes + Hibernate.
Please let me know if it is good to have admin & user part in same project or two separate ones.
If it is a single project , how do i separate admin side code & user code.
for eg: if i have admin actions in com.ecommerce.adminactions pacakge and user actions in com.ecommerce.useractions package should i use dynamicmappingfilter to direct admin request to com.ecommerce.adminactions and user request to com.ecommerce.useractions ?
-http://myecommerce.com/admin/* - > should always go to com.ecommerce.adminactions
-http://myecommerce.com/ -> should go to com.ecommerce.useractions
or
Should i use #urlbinding(/admin/st.action) in each class (Hard code).
The requirement is they need multistore concept.
Please let me know your thoughts on this.Your thoughts & suggestions will be helpful
Thanks
The Stripes framework does not really influence decisions on how you should organize you're project, or how you should organize your IDE project structure, or even Java package structure or URL structure.
One or more project
Unless you have many developers, keep it all in a single project.
Package structure
A package structure should organize you're Java classes so that you put classes that are logically related (as defined by your architecture!) is in the same package. For example: com.ecommerce.action.admin and com.ecommerce.action.. See also: Properly package your Java classes
URL structure
Typically you want you're URL structure to reflect the logical structure of your website (not the same as your technical structure). To accomplish this, you should not rely on the default URL's but use #UrlBinding. With the annotation you do not hard code links, as all generated links will automatically use the UrlBinding pattern.
Multi store concept
For a multi store concept, you will need to build logic in your application for distinguishing between the different shops. For example by adding a shop id to your URL parameters. Or more sophisticated by detecting the (sub)domain name used and map that to a shop id (You can implement this by using an interceptor).