attach record to record

This is possible with Cobalt right?

May be not exactly like you have it in mind but generally yes.

This is possible with Cobalt right?

Does Cobalt allows user1 to submit a CV (record) to a company record (job offer) ? And the company to be notified?

First what come to my mind is this.

1. There is CVs section where users can add different CVs

2. There is Job offers section where companies post open positions.

3. Job type have parent fiel and CV has child field and those are connected. CVs are children of Jobs.

4. Change Attach new button to Apply fro Job and set that user may see only his own records. User click this button and see list of his created CVs and chose one.

5. To see list of CVs attached to job offer only author of offer can. But there is permission to attach for any registered user.

This is possible with Cobalt right?

Does Cobalt allows user1 to submit a CV (record) to a company record (job offer) ? And the company to be notified?

Also... that only company has access to who applied but everyone else can only see how much users1 applied ("x persons applied to this job")?

This may be done with small template customization. Single query to DB.

This is possible with Cobalt right?

Does Cobalt allows user1 to submit a CV (record) to a company record (job offer) ? And the company to be notified?

Also... that only company has access to who applied but everyone else can only see how much users1 applied ("x persons applied to this job")?

And if all this is possible, what happens when company removes the job which has records attached ? it simply "unlinks" it ?

Yes

This is shortly main idea.

stblink

And if all this is possible, what happens when company removes the job which has records attached ? it simply "unlinks" it ?

Yes

You mean, all applicant's records stay in DB and users homepage, right?

stblink

Also... that only company has access to who applied but everyone else can only see how much users1 applied ("x persons applied to this job")?

This may be done with small template customization. Single query to DB.

Want to know more about this ;-) (code hints)

You mean, all applicant's records stay in DB and users homepage, right?

When parent is removed it does not remove children. Use stil has his CVs listed. ANd he can apply with the same CV to few Job offers.

You mean, all applicant's records stay in DB and users homepage, right?

Want to know more about this (code hints)

I'll give code example when we get to that point :)

... and he can apply with the same CV to few Job offers.

Yep, makes sense. ._.

Hmmm i see. Well first i have a HUGE problem... since i expect big amount of unemployed users to register i cannot approve them manually.

Unemployed users have to choose profiles during registration AND be automatically published But for companies profiles they need to be approved manually... because they have to proof they are indeed a company... CB is the only component that allows this but it's quite expensive :(

So i will have to wait a little bit.

But it's good to hear that at least most options are available in Cobalt.

You mean, all applicant's records stay in DB and users homepage, right?

well.. it was just a matter of knowing how it works. I believe a job may be deleted because it's filled and that any relations to that job to be deleted as well (only relations, not cv's).

Mostly because if they are not deleted, it's just filling the DB with no use unless the company may re-publish it later.

You mean, all applicant's records stay in DB and users homepage, right?

When parent is removed it does not remove children. Use stil has his CVs listed. ANd he can apply with the same CV to few Job offers.

Great!

Thanks

Unemployed users have to choose profiles during registration AND be automatically published But for companies profiles they need to be approved manually... because they have to proof they are indeed a company...

Depends on how you define "profiles". Do you need specific profile pages for each group? Do you need those profiles

Do you need a different approval for the J! user account OR for the actual entries (CVs, Company)

The actual Cobalt entries are different types and sections. So, they can have different approval settings. Even for Edit. See YourType -> Submission Behavior -> AutoApprove

Apart from that, the Cobalt field "Status" could be used to moderate and approve entries. Might require CustomSQL actions.

Unemployed users have to choose profiles during registration AND be automatically published But for companies profiles they need to be approved manually... because they have to proof they are indeed a company...

...CB is the only component that allows this but it's quite expensive

CB is worth every penny, IMHO. Especially, the adv. and pro plugins are really cool. If you need their functionality or extended Profile Types, go for it.

Do you need a different approval for the J! user account

Yes. And i know there are different approval options for Cobalt records... but this is actually Joomla registration.

I don't want users to register as companies and access information only available to companies.

I know CB is worth every penny but in this case i will only use 10/15% of CB, if i was gonna use CB 100% i would find it cheap.

thanks

but this is actually Joomla registration.

I don't want users to register as companies and access information only available to companies.

Not sure which kind of registration you need or prefer. You have mentioned "Profiles". Can you describe your imagination of "Profiles", and "Register" workflow, please?

Sure...

1 registration form

2 profiles (2 usergroups) that the user can choose

if it's a person... it's normal Joomla registration (send email confirmation and after that, published) and start inserting records

if it's a company... normal Joomla registration + few fields (send email confirmation and do not publish the user), send a specific e-mail to administrator to remind approval.

That's it.. everything else will be Cobalt.

I've been playing with CB for 3 days... to be honest.. i even considered CB for the employees side... leaving Cobalt for the job offers...

But damn.. CB search functionalities are WAY limited... Cobalt search makes CB look like crap although

they are ment for different functionalities.

CB Pro and Auto-Actions. There are two related articles that describe some of the possibilities...

Changing approval workflow based on CB field value

Assigning usergroup based on CB field value

BTW, did you notice this interesting topic and discussion

A side-effect and result was the C8 field - Register

One thing you might think about: Do you really need different J! profiles with fields... or a common register and login (for both groups). Then let the user decide, what he wants to do on your site... a) submit a Job, or b) create Profiles and/or to apply for a Job.

Yes i'm familiar with those topics you mentioned.

But considering the actual employment crisis i expect to have several thousands registrations... and since i need to diferentiate users from companies i really different different approvals for each usergroup.

I'm just 1 person and don't have time to check and approve thousands of registrations.

I will have to opt for CB to manage only the registration workflow and i believe Cobalt will have to go for the rest.

It's also a good thing since CB back-end allows me to have more statistics about users vs Joomla default.

C8 Register field is nice, but there are 3 main features that it would need for it to replace CB in this case:

1 - Send e-mail(or not) to different adress according to usergroup (specially to notify when companies registers)

2 - Set different approval method per usergroup chosen (automatic or manual)

3 - C8 Register field does not work with confirmation e-mail

option 3 allows users to register with fake e-mails and that's not a good practice. And when sending several e-mails to unexisting e-mail accounts the e-mail providers may flag you as spammer.

I know Cobalt has the e-mail field that can be used to send e-mails and that public record insert is available. I've seen sites that have public submissions and they have a nice registration process, like this one:

(starts with no registration)

1 - Press button insert record

2 - Inserts record where e-mail field is required

(at this time the record/user is unpublished)

3 - The record is submitted and an e-mail is sent with a confirmation link, when pressing that link it opens the website with a popup asking the user to select profile(usergroup) and choose a password (since login is the e-mail)

(at this time user is confirmed and published/unpublished according to what approval method the admin choose for each profile)

Of course there are other features like:

• Send different e-mail(and e-mail adress) per each profile(usergroup), since the registration approval is different, the admin must be notified so that he can approve them manually.
• if user does not confirm e-mail for 7 days, remove user and records

So it's a Reverse Method to the actual Joomla registration but it hides the fact that when most end-users (attention.. end-users.. and not we that are used to registrations) see a "register" button the first thing they come up is "privacy issues" and "i don't want any spam" or simply "omg another registration, what a pain".

But this is something more advanced and Cobalt is very very nice at what it does, so this is not a request but something for Mintjoomla to consider. If it's not implemented i fully understand, since CB will do the job for now.

Of course there are other features like:

• Send different e-mail(and e-mail adress) per each profile(usergroup), since the registration approval is different, the admin must be notified so that he can approve them manually.

• if user does not confirm e-mail for 7 days, remove user and records

And

• When inserting a record without login, if the e-mail already exists on the database. It popsup a login form asking e-mail and password (since user is already registered). If it's inserted correctly it logs in and submits the record.

note: i'm exemplifying the register workflow of a website and not making any request.

No problem, actually i always like to hear ideas.

Simply select something, that he has created beforehand can be one solution. I tend to believe, an applicant just need to answer the job-posting with a short summary... additionally attach a file OR just link to full CV/profile with ReadAlso ?!

The idea was to the user create a CV and wouldn't need to do any updates to apply for Job, but i also believe that even a "observations" field would have advantages. The main purpose of the parent-child would be to create only a link... so that the company may be notified and consult who has applied... just by pressing the link to be directed not to user profile but to the record (cv) itself... since the CV has info regarding the user itself.

But since users are able to search job and apply to them, i want the Reverse method to be applied. So companies can search for applicants and notify them of the interest. For this i believe it will be another parent-child limited to their usergroup.

regarding this post i will have to wait till AUP gets J3.0

Believe that it would be great in the future to have Emerald integration with AUP.

Something like insert 50 credits on an Emerald subscription... and use those credits for Record view/create/use e-mail field etc etc... and that really would kill any job components existing... but for that i will have to wait long time :)

I'm having a little problem here. This is not regarding the "Apply to job" feature but it's related to the parent-child field, which i believe that for my case it won't be possible.

I want that during the "insert CV" (aka insert record) the user sees a parent field with the "add" button... the parent field name is "Academic graduations" so that the user can insert their data.

The add button would popup another type(courses) that is on the same section (so the user can fill it and be linked to his CV only).

I noticed that the parent-child field does this... but only to already-inserted-types, correct? Which means that the user would have to create his courses first, and then insert them on the CV. Can't this be done on-the-fly?

I want that during the "insert CV" (aka insert record) the user sees a parent field with the "add" button... the parent field name is "Academic graduations" so that the user can insert their data.

In fact what you want is not records relation. There is no sense to make section to store academic graduation only for listing them in article. What you want we call subform. This is already in our plans. This is something like URL field where you can add few times the same form of 2 fields link and label. But only with ability to change amount of fields and field types.

This is next first fields we will release. As soon as I start create new fields this one wil be first. But unfortunately that wil not be very soon according to our "soon" standards.

Well this was not to "only listing them in article", it would also be an option to companies search for unemployed applicants that have a specific graduation... of course this could be done by select field... but the point here was to avoid to have a form with info and then 4/5 groups of fields exactly the same (each group around 11 fields).

5 groups would be 55 fields... can you imagine how long the form would be? i know i can group it using fieldsets but not the same.

This is something like URL field where you can add few times the same form

Exactly, that's what it's needed... i'll try some work around.

thanks

Sergey could you please tell what was your intencion about the field you mentioned (subform).

I mean, how do think it would be the best idea (or practice) to develop such kind of field?

I will be considering asking a developer to do that field so i wanted to catch some ideas of what's the best way to do it (in terms of performance as well).

thanks